A VAPT statement of work should define what an acceptable deliverable looks like before testing begins. Phrases such as detailed report, industry standard evidence or free retest are too subjective to govern quality, payment or closure.

Good acceptance criteria do not dictate every sentence. They define observable attributes that protect technical accuracy, confidentiality and decision usefulness while preserving the tester’s professional judgement.

Accept the scope baseline before execution

The SOW should require a target register with environment, version or build, interfaces, roles, tenants and critical workflows. Both parties approve it at kickoff and record later changes.

Acceptance distinguishes in scope, tested, constrained, not applicable and excluded. The final report must reconcile against this baseline rather than merely list findings.

  • Canonical targets and build identifiers.
  • Role and tenant accounts.
  • High-impact workflow list.
  • Approved exclusions and sampling.

Require a coverage deliverable

Define a matrix or equivalent record mapping test areas to targets, identities, status and limitations. This proves where effort was applied without demanding sensitive tester notes.

Coverage must not claim exhaustive assurance when sampling or access constraints were used. Require enough granularity for the buyer to decide whether additional testing is needed.

  • Completed and constrained work separated.
  • Sampling population and rationale.
  • Unavailable access or unstable components.
  • Residual uncertainty stated plainly.

Define mandatory finding anatomy

Every accepted finding should identify affected target, identity and preconditions; expected control; actions; observed result; impact; severity rationale; evidence; remediation; and closure test.

Allow fields to be marked not applicable with justification. Do not accept a scanner alert as a finding until a tester has validated reachability and explained context.

  • Specific title and affected components.
  • Reproducible authorised steps.
  • Control case and prohibited case where relevant.
  • Root cause and observable impact.

Set an evidence quality standard

Evidence must prove the claim while minimizing secrets and personal data. Requests, responses, screenshots, logs or local artefacts should preserve relevant context, identity and state.

Redaction must be consistent and irreversible in delivered files. The SOW should define when raw artefacts are withheld, separately encrypted or deleted.

Acceptance should also require a control comparison when the claim depends on authorization or workflow state. The reviewer needs to see why one identity or sequence was permitted and why the contrasted case should have been denied.

  • Timestamps and build context when material.
  • Caller, object and tenant distinctions.
  • Sensitive values minimized or redacted.
  • Protected transfer and storage.

Make severity transparent

State the scoring framework and required business context. The provider records prerequisites, privileges, reach, scale, data sensitivity, detectability and recovery that informed severity.

The buyer may accept risk but should not edit away verified technical facts. Disputes preserve evidence and reasoned positions through the agreed escalation path.

  • Method applied consistently.
  • Environmental adjustments explained.
  • Uncertainty not hidden.
  • Risk acceptance separated from validation.

Require actionable remediation

Recommendations should target the demonstrated control failure and identify the responsible layer or pattern. Generic statements such as sanitize input are not acceptable when more specific direction is possible.

Where appropriate, distinguish containment from durable correction and include related variants. The provider should not prescribe an unsuitable product without architecture context.

  • Root-cause-aligned control objective.
  • Architecture and trade-offs considered.
  • Immediate and long-term actions separated.
  • Verification criteria included.

Define executive and technical reports

The executive report states purpose, scope, material themes, business implications, limitations and prioritized decisions without false assurance.

The technical report preserves reproducibility, coverage and remediation detail. Findings and counts must reconcile across both versions and any presentation.

  • Consistent severity and totals.
  • No confidential technical detail in broad distribution.
  • Clear limitations and residual uncertainty.
  • Accessible agreed file formats.

Control draft factual review

Set a review window for factual corrections, evidence clarification and remediation-owner input. Review is not permission to suppress an accurate finding.

Require a disposition log for material comments: accepted, rejected with reason, or escalated. Protect final technical independence while correcting genuine errors.

  • Named reviewers and deadline.
  • Version-controlled comments.
  • Evidence-led dispute handling.
  • Final issue date after resolution.

Define retest eligibility and execution

State included cycles, eligible findings, request window, required fix information, environment and scheduling commitment. Clarify whether related variants or regression paths are checked.

Retest evidence should identify build, date, steps and result. A developer statement or changed screenshot alone is not proof of closure.

  • Cycle count and expiry.
  • Partial fixes and redesign treatment.
  • Fixed, partially fixed, not fixed and cannot verify.
  • New vulnerabilities handled separately.

Specify the closure artefact

The final artefact retains original findings and adds retest status, residual risk and evidence. It should be auditable without erasing history.

Define who receives it and whether an attestation letter is permitted. Any letter must match the tested scope and avoid claims that the organisation is secure or compliant beyond the evidence.

  • Original and retest chronology.
  • Status and residual risk.
  • Unverified or expired items visible.
  • Scope-limited assurance language.

Payment can follow kickoff readiness, accepted draft, accepted final report and completed included retest. Do not pay by vulnerability count or severity, which distorts incentives.

Define a cure period for missing fields, broken evidence, inconsistent reports or inaccessible files. Acceptance should be timely and not withheld for unrelated preferences.

  1. Attach the acceptance checklist to the SOW.
  2. Review it with technical and procurement owners.
  3. Test the criteria against the sample report.
  4. Record acceptance or defects for each deliverable.

Use objective language without overengineering

Criteria should be specific enough to resolve disputes but flexible enough for different finding types. Require justified not-applicable entries rather than forcing meaningless screenshots or fields.

The final test is usability: an authorised engineer should reproduce and repair, and a risk owner should understand coverage and consequence.

Use NIST SP 800-115 for planning and reporting concepts and the OWASP Web Security Testing Guide for testing and evidence context. Have legal and procurement owners align acceptance and payment language to the governing contract.

Turn report quality into a verifiable obligation

Acceptance criteria protect both parties: the buyer can identify an unusable deliverable, while the provider is protected from subjective or shifting demands.

WIMD defines coverage, evidence, reporting and closure as linked acceptance gates so technical work becomes an auditable assurance result.