Defining Scope of Work for Penetration Tests

Scope of work definition is the contractual and technical foundation of every penetration test engagement — it determines what systems are tested, which attack techniques are authorized, and what legal protections apply to both parties. A poorly scoped engagement produces results that are neither actionable nor defensible under compliance frameworks such as PCI DSS, HIPAA, or FedRAMP. This page describes how penetration test scope is structured, what elements must be resolved before testing begins, and how scope decisions differ across engagement types and regulatory contexts.

Definition and Scope

In penetration testing, "scope of work" refers to the bounded set of targets, techniques, timeframes, and constraints formally agreed upon between the commissioning organization and the testing provider before any active assessment begins. Scope is not a preference document — it is the operative boundary that defines authorized access and separates legitimate security testing from unauthorized computer access under 18 U.S.C. § 1030, the Computer Fraud and Abuse Act (CFAA).

The Penetration Testing Execution Standard (PTES) identifies pre-engagement interactions — including explicit scope definition — as the first mandatory phase of any structured engagement. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, similarly identifies target scoping, information gathering constraints, and authorization as prerequisites to any technical assessment activity.

Scope documentation typically covers four structural dimensions:

  1. Target inventory — IP ranges, hostnames, application URLs, cloud account IDs, or physical locations subject to testing
  2. Testing boundaries — systems, networks, or environments explicitly excluded from assessment
  3. Technique authorization — which attack classes are permitted (e.g., social engineering, denial-of-service simulation, credential stuffing)
  4. Engagement timeframe — testing windows, blackout periods, and total authorized duration

The distinction between what is in scope and what is explicitly out of scope carries legal weight. Testers who exceed defined boundaries — even inadvertently — may expose both parties to liability under the CFAA and applicable state computer crime statutes. Formal penetration testing authorization agreements are the instrument through which scope boundaries are memorialized.

How It Works

Scope definition follows a structured pre-engagement workflow. The commissioning organization and the testing provider work through a scoping questionnaire or discovery call to resolve the following in sequence:

  1. Asset enumeration — The client provides a complete list of systems, applications, and environments subject to testing. For cloud environments, this includes account IDs, regions, and service boundaries governed by provider-specific penetration testing policies (AWS, Azure, and GCP each publish acceptable use policies for security testing on their platforms).
  2. Ownership verification — The tester confirms the client has legal authority over every target. Third-party-hosted systems, shared infrastructure, and co-located environments require written consent from the infrastructure owner before inclusion.
  3. Technique matrix construction — The parties define which testing techniques are authorized. A full red team operations engagement may authorize physical intrusion, social engineering, and covert persistence; a standard network penetration test may exclude those categories entirely.
  4. Rules of engagement documentation — Specific constraints are codified: notification contacts, emergency stop procedures, data handling requirements, and escalation protocols. The rules of engagement document formalizes these agreements.
  5. Signature and authorization — Both parties execute the scope document, creating the legal authorization record.

NIST SP 800-115 specifies that penetration test plans must include a statement of the level of knowledge provided to testers — corresponding to black-box, white-box, or gray-box testing methodologies — as this determination directly affects what reconnaissance and enumeration activities are authorized.

Common Scenarios

External Network Assessment
Scope is defined by publicly routable IP addresses and domain names owned by the client. The engagement perimeter typically excludes internal network segments, and denial-of-service techniques are explicitly prohibited. This is the most common entry-level scope configuration.

Web Application Assessment
Scope is defined by application URLs, authenticated user roles, and API endpoints. The OWASP Testing Guide provides a standardized methodology reference that many clients use to define technique coverage expectations. Scope must specify whether automated scanning tools are permitted alongside manual exploitation.

Internal Network Assessment
Testers are granted a physical or VPN foothold inside the network perimeter. Scope defines which network segments, domain controllers, and lateral movement paths are authorized. This scenario requires explicit notation of production systems that cannot tolerate disruption — database servers, industrial control interfaces, and healthcare systems operating under uptime requirements commonly appear on exclusion lists.

Compliance-Driven Assessment
PCI DSS penetration testing requirements under PCI DSS v4.0 Requirement 11.4 mandate annual penetration testing of the cardholder data environment (CDE) and network segmentation controls (PCI Security Standards Council). Scope in this context is partially prescribed by the standard — the CDE boundary and all segmentation controls must be included, and exclusions require documented justification.

Decision Boundaries

Several recurring decisions structure the scoping process and differentiate engagement types from one another.

Included vs. Excluded Systems
The most consequential scoping decision is what to exclude. Organizations routinely request exclusions for production payment systems, life-safety infrastructure, and third-party-managed components. Each exclusion narrows the findings and should be documented with a stated rationale. Regulators reviewing PCI DSS or HIPAA compliance records may scrutinize exclusions as gaps.

Time-Boxed vs. Continuous Scope
A traditional engagement defines a fixed testing window — commonly 5 to 20 business days depending on scope breadth. Continuous penetration testing models define a standing scope that is reassessed on a rolling basis as the environment changes. The scope document in a continuous model must include a change management process for adding or removing assets.

Automated vs. Manual Authorization
Some scope agreements explicitly limit testing to manual techniques only, prohibiting automated scanners. Others define a hybrid model. Automated vs. manual penetration testing scope clauses affect both cost and finding depth — automated tools cover surface area faster, while manual testing surfaces logical and chaining vulnerabilities that scanners cannot detect.

Third-Party and Cloud Boundaries
When target environments include cloud-hosted infrastructure, scope must account for provider acceptable-use policies. AWS publishes a Customer Support Policy for Penetration Testing that prohibits testing of certain shared services without prior approval. Failure to align scope with provider policies can result in account suspension independent of client authorization.

References

📜 2 regulatory citations referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator