A VAPT scope statement should let an auditor reconstruct exactly what was authorized, reachable, tested and excluded. Name the legal entity and product, environment, applications, APIs, domains, cloud or mobile components, roles and tenants, test window, assessment type, methodology, limitations and change-control process. Avoid umbrella phrases such as “the platform” without a versioned inventory.
Start with the assurance requirement
Link the scope statement to the applicable audit boundary and requirement. If the compliance boundary differs from the technical architecture, explain the relationship and identify dependencies that remain outside direct testing.
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 statement of work, authorization, versioned asset register, architecture and data-flow diagrams, environment and build, API specification, role/tenant matrix, assessment dates, methodology, exclusions, blocked coverage, scope changes, accepted limitations and final report reference.
Identify the organizational and product boundary
Start with the entity, service and compliance boundary before listing hostnames.
- Name service and owner.
- Identify business process.
- State data classifications.
- Reference compliance boundary.
- List material dependencies.
Use identifiers consistent with system inventory and audit documentation so the same service is not described under ambiguous names.
Enumerate technical targets
List targets at the level needed to understand exposure and coverage.
- Domains and applications.
- APIs and versions.
- Mobile packages and builds.
- Cloud accounts or services.
- Administrative and internal interfaces.
Use a versioned appendix for large inventories; preserve the approved snapshot used during testing.
Define identities and workflows
Authenticated security coverage depends on roles, ownership pairs, tenants and critical states.
- List roles and privileges.
- Define test account pairs.
- Name tenant-isolation cases.
- Identify critical journeys.
- Include background and integration paths.
Record accounts unavailable or workflows that could not be safely exercised as explicit limitations.
State methods and depth
Clarify automated, manual, black-box, grey-box or source-assisted activities without promising exhaustive coverage.
- Name testing standards used.
- Describe authenticated approach.
- Include business-logic testing.
- Explain sampling.
- Define evidence threshold.
A standards reference supplements the scope; it does not prove every technique was applied to every target.
Govern exclusions and changes
Scope changes during an engagement must remain visible in the final evidence.
- Name excluded assets.
- Give reason and approver.
- Record blocked coverage.
- Version additions and removals.
- Describe effect on conclusion.
Do not quietly remove inaccessible systems from the final scope. Keep planned and achieved coverage distinguishable.
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.
Review the draft scope with GRC, system owners, security, operations and the tester. Freeze a baseline before testing and use a change log for every approved adjustment.
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
The final report should restate achieved scope, test period, environment, identities, methods, exclusions, limitations and significant scope changes. Reconcile it against the approved statement.
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
An auditor-ready scope is specific enough to reveal both coverage and gaps. Its purpose is not to make the engagement look broad; it is to make the assurance boundary unambiguous.
Ask WIMD to review your VAPT scope across audit boundary, technical inventory, identities, workflows and exclusions.