Pentest liability review needs the complete agreement and a clear set of questions for counsel. Use four fields for document context, a hypothetical loss scenario, interacting clauses and the reviewer decision. This checklist helps prepare the discussion and does not determine enforceability or insurance coverage.
Sources, review date and section shortcuts
Key claims reviewed: October 19, 2026. A liability cap is a negotiation term, not a guaranteed ceiling; applicability depends on governing law and the complete contract.
Primary documentation · Related practical guide
Go straight to: Decision check · Main workflow · Further detail
Open the Liability discussion handoff for this guide’s task-specific fields and next action.
Model the exceptions before proposing a cap
Write hypothetical claims for service interruption, confidentiality, third-party claims and ordinary negligent performance. Map each to the proposed cap, damage exclusion, indemnity and any separate super-cap. Identify whether the limit is aggregate or per claim, its fee base and time period. Ask counsel to resolve mandatory legal limits and conflicting documents. Do not infer enforceability or insurance coverage from the presence of a number in a clause. Source and scope.
A limitation-of-liability clause allocates certain contractual risks. Its wording does not establish that every loss is capped, every exclusion is enforceable or an insurer will pay. This guide is a discussion checklist for a penetration-testing engagement, not ready-to-sign legal drafting.
Start with governing law and the document set
Identify the parties, governing law, forum, master agreement, SOW, data-processing terms and any incorporated policy. Record their order of precedence. Mandatory legal restrictions and the actual type of claim may limit what the parties can exclude. Do not treat a clause accepted in another engagement or country as a precedent that settles this one.
Define what the proposed cap measures
- Aggregate or per-claim limit, and how related claims are grouped.
- Fees paid, fees payable or another base, with an explicit measurement period.
- Which services and SOWs share the same ceiling.
- Any separate cap for confidentiality, data handling or indemnity obligations.
- Whether defense costs count toward a limit and who controls a defense.
A fee-paid-to-date cap may be very small at the beginning of an engagement. An aggregate cap and a per-claim cap allocate different economic exposure, but labels alone do not resolve interpretation. Model a small set of realistic claim scenarios with both parties before selecting an amount. No fee multiple or lookback period is a universal market standard in this article.
Read caps, exclusions and exceptions together
For each scenario, check the liability cap, excluded damage categories, exceptions, indemnities, confidentiality promises and any remedy language together. Lost profits or business interruption should not be assumed excluded simply because a heading says consequential damages. Ask counsel how the governing law treats the actual wording and circumstances. Avoid making a blanket promise that testing prevents breaches or discovers every vulnerability.
Treat statutory restrictions as jurisdiction-specific
For example, section 2 of the UK Unfair Contract Terms Act 1977 restricts excluding liability for death or personal injury resulting from negligence. This example illustrates why a contract number cannot be assumed to cap every category. It does not establish that this Act governs a particular pentest, that all other losses may be limited or that another jurisdiction has the same rule. Obtain advice for the actual parties and transaction.
Verify insurance separately
Ask the broker or insurer to examine the proposed work, relevant policy period, claims conditions, limits, exclusions and contractual commitments. A certificate or policy limit does not confirm coverage for a particular event. Keep the assessment scope and the insurance discussion consistent, including third-party systems, sensitive data and subcontractors.
Keep operational boundaries concrete
The SOW should identify assets, owner authorization, allowed methods, test windows, stop contacts, data handling, deliverables and retest terms. Uncertainty should be documented rather than replaced by a security warranty. Clear testing boundaries support an informed agreement but do not make a liability clause dispute-proof.
Prepare a concrete review packet
Send counsel the complete document set, a summary of intended testing, data/third-party dependencies and the hypothetical claims mapped to each proposed limit. Mark unresolved contradictions and decisions for negotiation. Do not copy a template into a signed agreement without that review. This page reports no litigated outcome, negotiated market rate or legal conclusion for the reader’s engagement.
Liability discussion handoff
Use these fields to turn this guide into a record for your own task. Keep the actual scope, evidence and unresolved questions together.
On a small screen, scroll the table sideways to read all columns.
| Field | What to record | Your evidence / next check |
|---|---|---|
| Document context | List agreement versions, governing-law questions and precedence issues. | To complete |
| Scenario question | Describe a hypothetical loss without deciding legal treatment. | To complete |
| Clause interaction | Flag cap, exclusion, indemnity and insurance questions for review. | To complete |
| Reviewer decision | Record counsel ownership and unresolved drafting questions. | To complete |
Next action: Send the complete document set and scenario questions to qualified counsel before agreeing terms.
Related task: Use Pen Test SOW Checklist: Scope, Authorization and Acceptance Criteria for that separate part of the workflow.
Worksheet change record — October 20, 2026
Added four task-specific fields, a next action and a related guide. This is a blank editorial working aid, not a completed test or validated assessment. Existing source-review dates retain their own scope; this addition is not a new verification of every statement.
Pentest review packet: a fictional preparation example
The following liability review example shows how to organize a review request. It describes a fictional engagement and contains questions, not proposed contract wording or conclusions about responsibility. Replace the invented details with the actual engagement context and let the responsible reviewers decide which questions matter.
Suppose a team is preparing an assessment of a staging web application. A master agreement, a separate SOW and a data-handling schedule are circulating. The team has not yet resolved whether a shared identity provider or a third-party notification service is included. Its immediate task is to assemble the facts and questions required for review, rather than select a fee multiple from a template.
1. Create a document and decision index
List each document by filename, revision date, owner and review status. Include the proposed SOW, any referenced data schedule and the documents a reviewer needs to understand the intended work. Keep the proposal under review separate from an earlier accepted agreement. Mark which draft contains each unresolved question so the reviewer can find the language without searching an email thread.
For this fictional liability review, the index could say: “SOW draft B describes staging testing, while the asset appendix still includes a production hostname. Owner confirmation is pending.” This records a concrete inconsistency without deciding which wording controls or whether either party has accepted it. Assign one person to maintain the index and capture decisions when the reviewed versions change.
2. Write a scenario without assigning a legal outcome
Describe a hypothetical interruption using operational facts: which application is affected, what testing was planned, who would notice the event and who could stop the work. Keep the consequence and any unresolved dependency visible. Do not label the loss recoverable, excluded or insured in the preparation note. Those are questions for the relevant reviewers and the actual document set.
A useful liability review question is: “If an agreed staging check causes a notification backlog that reaches another service, which documents and assumptions should counsel review?” Add the uncertain service ownership, the proposed stop contact and the relevant draft references. Avoid filling the gap with an assumed cap amount. A second scenario can address evidence handling or an unexpected third-party dependency without asserting that the same answer applies to both.
3. Route distinct questions to the appropriate reviewers
Prepare separate liability review questions for operational owners, counsel and the insurance contact. Ask the operational owner to confirm intended assets, available recovery steps, permitted test windows and the people authorized to halt the work. Ask counsel to review the proposed agreement and the scenario questions. Ask the broker or insurer what additional engagement and policy information they need for their own review.
Record an answer as an answer from its source, with the date and scope of the question. Do not summarize an unanswered request as approval. If a reviewer asks for a missing schedule, mark the decision pending and identify who will provide it. This keeps the preparation packet usable when several people review different parts of the engagement at different times.
4. Close the loop with a revision-aware decision log
For each liability review item, retain the original question, the relevant draft reference, the assigned reviewer, the response and any required follow-up. Link the decision to the version that was actually reviewed. When a scope, subcontractor or data-handling assumption changes, flag the affected review items for another look rather than silently carrying an old answer forward.
A practical handoff is complete when another team member can find the current document set, see which questions remain open and identify the person responsible for the next decision. This is a document-management checkpoint. It is not evidence that a liability limit is enforceable, that insurance will respond or that testing may begin. Keep those separate decisions visible in the engagement’s actual approval process.
Questions to resolve before sending the packet
- Can the reviewer identify every draft and referenced schedule from the index?
- Does each scenario describe facts and uncertainties without supplying its own legal answer?
- Are scope ownership, third-party dependencies and stop contacts confirmed or clearly pending?
- Does each open question have a reviewer, an owner for missing information and a next review date?
Liability review packet questions
What should the first liability review request contain?
Start with a short cover note that names the decision needed, the planned engagement and the people responsible for supplying missing facts. Attach or link the current document index. State whether the team is asking for an initial issue list, a review of a revised draft or clarification of a specific question. These are different requests, so avoid presenting an earlier response as an answer to a later revision.
For the fictional staging engagement’s liability review, the cover note might identify the unresolved notification-service boundary and ask which additional information the reviewers need. Keep the requested decision visible at the top. The packet should make it possible to locate the current scope, the relevant draft and the unanswered question without treating the cover note as a substitute for the underlying agreement.
How should an unknown operational fact be recorded?
In the liability review record, write the unknown fact explicitly, name its information owner and explain which review question depends on it. An entry such as “production data may be copied into staging; data owner confirmation pending” is more useful than silently assuming that the environment contains only synthetic records. Keep the factual confirmation separate from the reviewer’s assessment of its implications.
Use a status such as pending, confirmed with a dated reference, or superseded by a later document. If someone supplies a verbal clarification, record who supplied it and ask the responsible owner how it should appear in the reviewed material. Do not mark a liability question settled merely because a meeting ended. The purpose is to preserve the chain between the fact, the question and the decision.
How many hypothetical scenarios should be prepared?
Choose liability review scenarios because they expose a relevant ambiguity, rather than trying to reach a universal count. Start with the event that is hardest to explain from the current draft. Add another when it raises a materially different operational dependency or review question. A scenario list is a discussion aid; its length does not establish completeness or demonstrate that the engagement’s risks have been assessed.
In the fictional example, service interruption and handling assessment evidence may raise different questions. Give each its own factual assumptions, draft references and responsible reviewers. Do not copy a response from one scenario to the other without checking whether its conditions still apply. Keep any proposed liability answer attributed to the reviewer who supplied it and tied to the actual question they considered.
What belongs in the insurance question list?
Prepare the intended work description, parties, relevant dates, data and subcontractor assumptions, together with the specific proposed commitments that need review. Ask the broker or insurer what documents and facts they require. Keep any certificate, policy wording, correspondence and reviewer response identifiable in the index, with access limited to the people authorized to review them.
The liability review record should distinguish a question sent, an answer received and an issue still open. If the reviewer requests a revised scope or a policy document, assign an owner to obtain it. Do not turn a broad statement about a policy into a conclusion about the fictional event. Record the exact question and response instead of replacing the review with an assumed relationship between a liability cap and an insurance limit.
What should happen when the SOW changes during review?
Make a short change note describing the revised asset, method, dependency, test window or data assumption. Link the old and new versions, then identify the review questions affected. Ask the relevant reviewer whether the earlier response still addresses the updated proposal. Keep the prior response in the history rather than editing it to look as though it concerned the new draft.
For example, adding a third-party integration to the fictional staging scope should create a visible review item with an information owner. The operational team can supply the intended testing details; the appropriate reviewers can address the questions in their own areas. Do not let an apparently small scope edit disappear inside a filename change. A revision-aware liability discussion makes the remaining questions easier to find without claiming to settle them.
What makes the preparation record ready for handoff?
Ask another team member to locate the current document set, identify the highest-priority open question and name the person responsible for the next action. They should be able to do this from the packet, without relying on a private conversation. If the index points to an obsolete draft or a decision lacks its conditions, repair that gap before describing the packet as current.
End the liability review cover note with the decisions requested, the missing facts and the agreed next review point. Keep the actual signing and testing approvals in their own process. This final check concerns the usability of a preparation record. It does not establish legal validity, acceptance of a contract, authorization from an asset owner or insurance coverage. Those outcomes require their own evidence from the people responsible for them.
Prepare the next review request: Save a dated copy of the document index, choose the open question that most affects the planned work and attach its factual assumptions. Name the person responsible for each missing fact and the reviewer expected to answer the question. Keep draft comments, decisions and operational approvals distinguishable. Before sending the packet, check that every link opens the intended version and that the recipient is authorized to receive the material. This gives the next reviewer a concrete starting point and makes a later change visible without inventing a legal answer.