Before issuing a purchase order, the penetration-testing statement of work should make the authorized boundary, method, responsibilities, safety controls, deliverables, acceptance criteria, retest, schedule, data handling and change process explicit. The SOW should be contractually clear without freezing the tester into a payload checklist that prevents adaptive investigation.
Start with the assurance requirement
Translate the approved risk and technical scope into contract language. Resolve any conflict between the proposal, master agreement, data-processing terms, rules of engagement and purchase order.
Record the requesting party, framework or contract clause, assessment boundary, evidence period, due date and decision the evidence must support. Confirm the interpretation with the auditor, assessor or customer where possible. A penetration test can contribute strong assurance, but a report cannot guarantee an audit outcome or replace the organization’s wider control evidence.
Create a traceable evidence index
- Requirement or control identifier and the assertion being supported.
- In-scope systems, interfaces, environments, identities and important exclusions.
- Assessment dates, methodology, tester identity or competence evidence and authorization.
- Finding identifiers, severity rationale, remediation owner, status and exception reference.
- Retest evidence, closure date, residual risk and the location of protected technical detail.
Include legal entities, contacts, authorization, target inventory, environment, roles and tenants, excluded actions, methodology, standards, access prerequisites, client dependencies, dates and time zones, communications, stop conditions, deliverables, acceptance, retest, fees, change control, confidentiality and evidence retention.
Define scope and authorization
The SOW must identify exactly which systems and actions are authorized.
- List targets and versions.
- State test environment.
- Name identities and tenants.
- Record exclusions.
- Identify authorization signatory.
Use a controlled scope appendix and incorporate it by reference so changes remain versioned.
Set method and coverage expectations
Describe required authenticated, manual and business-logic coverage without prescribing every technique.
- Name assessment type.
- Reference relevant standards.
- Require manual validation.
- Identify critical workflows.
- State sampling assumptions.
Avoid guarantees of finding every vulnerability or generic compliance claims unsupported by the engagement.
Allocate responsibilities and safety
Access delays and unsafe ambiguity can derail testing.
- Assign account provisioning.
- Define allowlisting.
- Set test windows.
- Name emergency contacts.
- Write stop and recovery rules.
Make blocked prerequisites and client-caused delay treatment clear before kickoff.
Specify deliverables and acceptance
Acceptance should measure completeness and traceability, not require a preferred security conclusion.
- Define draft and final report.
- Require finding evidence.
- Include executive summary.
- Set review and correction window.
- Define secure delivery.
Do not condition payment on zero findings, lower severity or removal of valid conclusions.
Write retest and change control
Closure and scope variation should not require a new commercial negotiation under deadline.
- State included retest.
- Define eligible findings.
- Set availability window.
- Price additional cycles.
- Define scope-change approval.
Link closure statements to independently retested findings and fixed versions.
Operate the evidence workflow
- Confirm the requirement, evidence owner, reviewer and deadline.
- Freeze a versioned scope and record every approved change or exclusion.
- Collect assessment artifacts through a controlled, access-limited repository.
- Map findings and closure evidence without changing the tester’s original conclusion.
- Perform a completeness and consistency review before external sharing.
Have technical, security, procurement, legal and privacy stakeholders review the same final SOW. Conduct a pre-kickoff reconciliation against the proposal and rules of engagement.
Preserve evidence integrity and confidentiality
Keep the original signed or versioned report, evidence manifest and retest artifacts. Redact copies rather than overwriting the source. Restrict exploit steps, credentials, personal data and internal architecture to approved recipients. Record who received which version, under what authorization and for what purpose.
Quality checks before reliance
- Scope, dates and environment agree across the report, statement of work and evidence index.
- Every closure claim points to a finding identifier and retest result.
- Exceptions name an owner, rationale, review date and compensating controls.
- Control mappings distinguish direct evidence from supporting context.
- Sanitized summaries do not imply broader coverage or stronger closure than the source report.
Use framework language carefully
Use the applicable official control text and assessor guidance as the authority. The NIST Technical Guide to Information Security Testing and Assessment supports disciplined assessment planning and reporting, while the OWASP Web Security Testing Guide provides application testing context. Neither substitutes for framework-specific interpretation by the responsible auditor or assessor.
Report the assurance conclusion
Keep the signed SOW, scope appendix, authorization, approved changes, deliverable acceptance and retest record together in the engagement file.
State observed facts, limitations and management decisions separately. Do not use “compliant,” “certified,” “secure” or “all vulnerabilities fixed” unless the authorized assessor and evidence genuinely support that precise claim.
The GRC decision
A strong SOW makes coverage, obligations and risk boundaries unambiguous while protecting tester independence. It prevents avoidable disputes without pretending the work is fully predictable.
Ask WIMD for a written VAPT scope suitable for technical review, contracting and purchase-order approval.