Security Assessment Statement of Work: Acceptance and Evidence
Make work testable before testing starts
An assessment statement of work (SOW) is a scoped commercial and operational record, not a security guarantee. NIST SP 800-115, published September 2008, describes planning and conducting technical security testing. Use it as a method reference; it does not supply contract terms or allocate legal responsibility. Legal counsel, accountable operator, procurement, and information owner must review final terms.
A usable SOW names customer, supplier, system owner, approving signatory, assessment lead, and emergency stop contact. It identifies targets by hostname, application, account boundary, environment, and version where known. It also lists exclusions. “All company systems” is not scope. Neither is “pentest the website” without domains, routes, APIs, third parties, test accounts, and allowed time window.
Minimum SOW schedule
| Clause | Required content | Acceptance criterion |
|---|---|---|
| Scope and objective | assets, environments, data limits, test questions, exclusions | both parties sign inventory; unknowns become change request |
| Authorization | authorized signatory, dates, target authority, contact | signed before any network or application activity |
| ROE | permitted methods, prohibited actions, rate limits, hours, stop authority, incident escalation | assessor can stop safely; customer responds through named contact |
| Supplier responsibilities | qualified staff, tool/data handling, status reporting, subcontractor disclosure | supplier names responsible lead and follows approved ROE |
| Customer responsibilities | test accounts, allowlisting, contacts, backup/change freeze decisions | customer confirms readiness and authority |
| Evidence custody | collection limits, encryption, access list, transfer, retention, deletion/return receipt | every artifact has owner and handling rule |
| Deliverables | format, audience, severity method, findings, limitations, executive and technical sections | report meets agreed template and redaction rules |
| Acceptance and retest | objective review criteria, review window, correction process, retest scope and time | acceptance is recorded; retest result linked to finding |
| Liability and legal boundaries | allocation, confidentiality, exclusions, governing terms | counsel-approved agreement, not assessor assumption |
Rules of engagement and safe execution
ROE should answer what happens under stress. State whether production is in scope; prohibit denial-of-service, destructive changes, social engineering, physical access, persistence, data exfiltration, and third-party testing unless specifically authorized. Set request-rate ceilings, test hours, maintenance windows, IP addresses, user-agent or test-account labels, and real-time escalation route. Define stop triggers: service degradation, suspected data exposure, alert from customer, or instruction from named authority.
Completed example: customer authorizes authenticated web and API testing of portal.example and api.example from 1–5 September, 09:00–17:00 WIB. Production remains in scope but load testing, account lockout attempts, email delivery testing, and subcontractor endpoints are excluded. Customer provides two test roles, VPN access, allowlisted source IPs, backup confirmation, and a 24-hour stop contact. Supplier may validate authorization defects with minimum records and must stop before viewing personal-data content. This is a bounded authorization, not standing permission.
Evidence, acceptance, and retest
Evidence custody specifies minimum collection. Store timestamps, target/version, method, result, and integrity hash. Encrypt in transit and at rest; restrict access to named roles; send redacted samples where possible; never retain credentials or unnecessary raw personal data. Set retention period and deletion/return receipt. Report disclosed indicators only through approved channels; CISA’s information-sharing guidance does not override customer confidentiality or law.
Acceptance should be measurable: report includes agreed scope, dates, methods, limitations, finding IDs, severity rationale, reproduction conditions, affected assets, remediation guidance, and evidence references; files open in agreed PDF and editable format; customer has ten business days to log factual defects. Acceptance does not mean every finding is fixed or system is secure. Supplier corrects material report errors within agreed window.
Retest should name eligible findings, customer evidence needed, target release, time window, method, and output: verified fixed, still present, not retested, or risk accepted by customer. New scope is a change request. Supplier cannot close a finding merely because a ticket exists.
Acceptance effects and dispute path
State acceptance effect precisely: customer confirms deliverable matches agreed content and starts agreed correction or invoice process; acceptance does not waive unknown defects, accept risk, approve production, or certify security. For a factual defect, customer submits finding ID, disputed statement, and evidence within review window; supplier acknowledges, corrects or explains with versioned delta, and customer records accepted, accepted with exception, or returned. Unresolved acceptance item remains open past review window only under written extension. Retest output changes finding status, not report acceptance or liability allocation.
Liability boundary
SOW must defer liability cap, indemnity, privacy, confidentiality, legal jurisdiction, and insurance terms to counsel-approved agreement. Assessment is best-effort within stated scope and does not promise regulatory compliance, certification, uninterrupted service, absence of vulnerabilities, or regulator acceptance.
Sources
Worked acceptance boundary
For customer portal, state production hostname, staging exclusion, authenticated roles supplied by customer, permitted request rate, evidence handling, and stop contact in signed appendix. Expected behavior: assessor declines newly discovered sibling domain until scope owner adds it. Edge case: emergency maintenance window overlaps testing; pause activity, preserve timestamps, and obtain new authorization. Closure test: compare executed targets, dates, methods, and deliverables against signed scope; every mismatch is approved change or open exception.
Worked closure check
For customer-portal SOW closure, retain signed appendix version, allowed hostnames, test window, supplied roles, rate ceiling, evidence custodian, and buyer acceptance record. Delivery evidence proves agreed work was performed within those boundaries; it neither certifies security nor decides contractual or legal consequences. Maintenance or newly discovered domains require a written change before assessment. An independent contract reviewer compares one executed request and report claim with authorization, handling record, and exception log; mismatches remain open for correction.