Scoping Guide

Penetration Testing Scoping Guide & Checklist

Step-by-step instructions and parameter checklists for defining pentest scope, rules of engagement, and target boundaries before any reconnaissance starts.

Penetration testing scope is the documented boundary of systems, applications, networks, and environments authorised for testing during an engagement. This guide gives step-by-step instructions and parameter checklists for defining that boundary, the rules of engagement, and the target parameters testers may not cross. Use it to produce a defensible scope document before any reconnaissance starts.

What Is Penetration Testing Scope? A Definitive Answer

Penetration testing scope is the documented boundary of systems, applications, networks, and environments authorised for testing during an engagement. Scope defines the “what”: named targets, IP ranges, applications, accounts, and explicit exclusions. Rules of engagement define the “how”: legal clearance, methods, timing, communication, data handling, and incident protocol.

Scoping sits as step zero, before the five-step penetration testing lifecycle: reconnaissance, scanning, exploitation, post-exploitation, and reporting. Testers who start reconnaissance without a signed boundary create legal, operational, and evidence problems that no later report can repair. Under the Penetration Testing Execution Standard (PTES), this work belongs in pre-engagement interactions, not in intelligence gathering.

Teams often treat “scope”, “rules of engagement”, and “methodology” as one document. They are three contracts. Mixing them leaves gaps that only appear when a tester hits an undocumented asset or a production outage. PTES, OWASP testing guides, and NIST pentest guidance can shape methodology. They do not replace a signed target list.

Term	What it means	What it includes	Who defines it
Scope	The authorised target boundary	Assets in scope, assets out of scope, environments, data classes, user roles, test types	Client asset owners with tester challenge; both parties sign
Rules of engagement (ROE)	The operational contract for how testing is conducted	Legal authority, windows, methods, contacts, data handling, incident protocol, reporting, success criteria	Client legal/security leads and the testing provider, jointly
Methodology	The technical approach used inside the agreed boundary	Reconnaissance depth, exploitation limits, tooling, evidence capture, retesting approach	Provider, constrained by ROE and the agreed test type

Write scope as a target list with exclusions. Write ROE as operating rules. Keep methodology in the statement of work so testers cannot expand the attack surface by “following the method”. Neither party should own the document alone: the provider should challenge incomplete inventories; the client should supply business context, legal entities, and authorisation. The signed list is the contract, not the kick-off slides.

To turn that definition into a usable document, work in this order:

Identify in-scope assets from a verified inventory, not from memory.
Name explicit exclusions, including third parties you cannot authorise.
Select test types and the information level (black, grey, or white box).
Set testing windows, time zones, and production blackout dates.
Define communication, escalation, and critical-finding contacts.
Set data handling, evidence location, and retention rules.
Agree deliverables, success criteria, and whether retesting is in the original statement of work.

How to Define In-Scope and Out-of-Scope Assets

To define in-scope and out-of-scope assets, include systems that handle sensitive data, are internet-facing, or support critical business functions, then name every exclusion in writing. Unnamed assets are not “probably out of scope”. They are undefined, which is the highest-risk state for both parties.

Prioritise in this order: internet-facing attack surface, systems that store or process sensitive data, systems that can halt operations, then connected systems that can be used as a pivot. Exclude only what you can justify to an auditor, an insurer, and a board after an incident.

Use these decision rules for the common dilemmas:

Third-party hosted assets

Include them only after you check the contract, obtain written permission, and limit testing to your configuration, tenant, and credentials. You do not own the vendor’s platform.

Legacy or end-of-life systems

Include them if they still hold sensitive data or sit on a path to a critical system, and require a rollback plan. If the box cannot be restored, isolate or decommission it instead of pretending a test will make it safe.

Subsidiaries and newly acquired companies

Verify legal ownership, network connectivity, and who can authorise testing before any IP range goes on the list. Acquisition paperwork is not an authorisation letter. Forgetting a subsidiary CIDR is a classic miss: the report looks complete, the attacker uses the untested range, and the insurer asks why it was never named.

Shadow IT and undocumented systems

Do not guess. Authorise a time-boxed discovery phase, treat newly found assets as out of scope until written into the list, then decide include or exclude.

Under-scoping misses the asset an attacker will actually use. Over-scoping spends tester days on low-risk internal printers while the forgotten subdomain stays untouched. The expensive error is usually under-scoping dressed up as budget control. Scoping a production environment without a rollback plan is the other failure mode: a fragile service is “in scope”, testers have no restore owner, and a crash becomes an unplanned incident rather than a controlled test.

Good vs bad scope statements

Network: Good: “In scope: 198.51.100.0/24 and 10.20.0.0/16 excluding 10.20.9.0/24 (OT). Out of scope: 192.0.2.0/24 (partner MPLS).” Bad: “The corporate network.”
Web application: Good: “In scope: https://app.example.com and https://api.example.com (prod and staging). Out of scope: the marketing CMS on https://www.example.com.” Bad: “The website.”
Cloud: Good: “In scope: AWS account 123456789012, eu-west-2, VPC vpc-0abc, excluding RDS snapshots in the backup account.” Bad: “Our AWS.”
Third party: Good: “In scope: our Okta tenant configuration and SSO mappings. Out of scope: Okta corporate infrastructure.” Bad: “Identity provider included.”
Physical / people: Good: “Social engineering limited to 50 staff in Finance, excluding executives and the SOC. Physical testing excluded.” Bad: “People and buildings as needed.”

When stakeholders push back

Expect pushback. Operations will want production excluded. Application owners will want “everything” included without providing credentials. Legal will stall on third-party letters. Treat each objection as a scoping decision, not as a reason to leave the line blank.

If production cannot be touched, name the production hosts as out of scope and put an equivalent staging environment in scope, or limit production to non-destructive tests in a defined window with a rollback owner.
If an owner cannot list assets, do not accept “test the estate”. Time-box discovery, then freeze a written list.
If a vendor will not authorise testing, exclude the vendor platform and keep your configuration, credentials, and egress paths in scope.
Justify inclusions with business impact (sensitive data, internet exposure, audit mandate), not with “the testers asked for it”.

Provider-led scoping without your inventory misses business-critical systems the CMDB never listed. Client-led scoping without tester challenge misses technical neighbours such as management planes and identity stores. Use both: questionnaire from the provider, asset and risk context from you, signatures from both.

Scoping Cloud Environments and Third-Party Dependencies

Cloud and third-party scoping is limited to the configuration, identities, data, and workloads you control under the shared responsibility model, not the provider’s underlying infrastructure. If the scope names “AWS” or “Salesforce” without account IDs, regions, and tenant boundaries, testers have no lawful target.

Shared responsibility and what you may authorise

The shared responsibility model assigns the provider the physical facilities, hypervisor, and managed-service internals, and assigns you accounts, IAM, network controls, data, and application configuration. You may authorise testing of your side. You may not authorise testers to attack the provider’s control plane, other tenants, or undocumented managed internals.

Layer	Typically in your scope	Typically out of your scope
IaaS (VMs, VPC, NSGs)	Your instances, security groups, IAM, storage buckets, images you built	Hypervisor, data centre, provider management APIs you do not own
PaaS / serverless	Your functions, app services, IAM roles, event triggers, secrets you store	The runtime platform and other customers’ functions
SaaS	Your tenant configuration, users, integrations, custom code you added	The vendor’s multi-tenant application core, unless the vendor permits it in writing

Cloud parameters that must appear in the scope

Cloud scope parameters are account IDs (AWS), subscription and tenant IDs (Azure), project IDs (GCP), regions, VPCs or VNets, resource groups, serverless functions, container clusters, and the identities testers may assume. Name the organisation unit or management group only if testers are authorised to walk it. State whether production, non-production, or both are included. “The EKS cluster” is not a target. Name the cluster, namespace, and whether node compromise is permitted.

Confirm provider permission programmes before kick-off. Several cloud vendors require advance notice or prohibit certain techniques (for example denial-of-service, intensive port floods, or testing of services outside your accounts). Put those prohibitions in the ROE so a tester cannot “discover” a ban mid-scan. If testers will assume IAM roles, list the role ARNs or equivalent identifiers. Organisation-wide read is a different authorisation from a single workload account.

SaaS, APIs, and supply chain dependencies

Third-party SaaS belongs in scope only when the contract allows security testing, the vendor has granted written permission, or the test is limited to your tenant configuration, SSO mappings, and the data you place in the service. Many SaaS contracts prohibit testing. Ignore that clause and you convert an authorised test into an unauthorised attack on someone else’s system. Ask for permission in the name of the legal entity that holds the tenant, and keep the vendor’s reply with the authorisation pack.

API scope must name base URLs, authentication mechanisms (API keys, OAuth, mTLS), rate limits, and whether third-party APIs consumed by your app are included. If a payment, identity, or mapping API is third-party, treat it as a dependency: test your calls, tokens, and error handling, not the vendor’s production API farm, unless they agree in writing. Supply-chain software you host (payment terminals, partner portals, CI runners) is in scope only when you can authorise the host and isolate partner data.

Multi-tenant and UK/EU residency constraints

Multi-tenant testing must be fenced to your tenant IDs, namespaces, and data partitions so testers cannot read or disrupt other customers. State the isolation boundary in the scope (account, subscription, Kubernetes namespace, SaaS org ID) and forbid cross-tenant enumeration beyond proving a control failure.

UK and EU data residency affects cloud scoping when personal data must remain in named regions. If testers copy evidence, logs, or database extracts, name allowed regions and forbid export to tester laptops or tickets outside those regions. A scope that authorises “GCP” without “europe-west2 only” can create a transfer the organisation never intended.

Compliance-Driven Scoping: PCI DSS, ISO 27001, and SOC 2

Compliance-driven scoping starts from the systems the framework treats as in-scope, then adds connected systems and the controls that claim to isolate everything else. A test that misses the regulated environment may still find vulnerabilities and still fail the audit. When budget is tight, start with mandated targets, then add business-critical systems the frameworks do not name.

PCI DSS

PCI DSS requires penetration testing of the cardholder data environment (CDE). In PCI DSS v3.2.1 this sat under Requirement 11.3. In PCI DSS v4.0 it sits under Requirement 11.4. Scope must include CDE systems, systems connected to the CDE, and the segmentation controls you rely on to keep other networks out. If segmentation is the reason a subnet is “out of scope”, that segmentation must itself be tested. Record the test date against the requirement’s frequency so the auditor can see the window, not only the asset list.

ISO 27001

ISO 27001:2022 Annex A.8.8 addresses management of technical vulnerabilities and is commonly satisfied, in part, through planned security testing. Scope should follow the information security management system (ISMS) statement of applicability: the assets, processes, and locations the ISMS claims to cover. Testing a single web app while the SoA names three data centres will not evidence the ISMS you wrote.

SOC 2

SOC 2 Security (Common Criteria) expects the organisation to identify and address vulnerabilities on systems that support the in-scope trust services criteria. Independent penetration testing is the usual evidence type auditors look for. Scope the systems that produce, process, or protect the data and controls described in the system description, not an unrelated lab network.

Framework	What must be in scope	Scoping implication	What to give the auditor
PCI DSS	CDE, connected systems, segmentation	Do not exclude a network on trust. Prove isolation or test it.	Signed scope, network diagram, segmentation test results, dates
ISO 27001	Assets and processes in the SoA / ISMS	Align test objects to the ISMS boundary, not a convenient subset.	SoA mapping table: control, asset, test coverage, exceptions
SOC 2	Systems relevant to the in-scope TSC	Match the system description. Orphans in the description stay in the test.	Scope vs system description matrix and the final report

Document compliance-driven decisions in the scope itself: “Included because it stores CHD”, “Excluded because segmentation test X dated [date] demonstrated isolation”, “Included because listed in SoA asset A-17”. Auditors read the scope document. Informal chat in a kick-off call is not evidence. Vague exclusions also weaken the report: an auditor can treat an unnamed connected system as untested, even if testers never saw it.

UK GDPR and the Data Protection Act 2018 affect scoping when testers will access personal data. Name the data categories, the lawful basis for the tester’s access, retention of evidence, and whether special category data is present. If it is present, decide whether production data is in scope or whether a masked environment must be used instead.

Rules of Engagement: The Operational Contract for Your Test

Rules of engagement are the operational contract that states how testers may work inside the agreed scope, including legal authority, timing, methods, communication, data handling, incidents, reporting, and success criteria. Scope without ROE tells testers what to touch. It does not tell them when to stop.

ROE is not the statement of work (SOW) and not the master services agreement (MSA). The MSA is the overarching commercial contract. The SOW names deliverables, fees, and the high-level scope. ROE is the day-to-day operating rulebook testers carry during the window. If a rule lives only in an email, it will be missing at 02:00 when a critical finding appears.

Legal clearance and authorisation

Legal clearance is a signed authorisation pack: SOW, MSA, and letters for every third party whose systems sit in scope. If this is missing, testers may be indistinguishable from attackers under the Computer Misuse Act 1990, and a hosting provider can treat the test as an incident. Example: “Company X authorises [provider] to test the assets listed in Schedule A from [tester IPs] between [dates], on behalf of [legal entity].”

Scheduling and testing windows

Testing windows are the agreed hours, time zones, and blackout dates when intrusive activity is allowed. If this is missing, a scan can hit peak trading or a batch window and the test is blamed for an outage it was never scheduled to risk. Example: “Active exploitation against production is limited to 22:00–06:00 Europe/London, Monday–Thursday, excluding month-end.” Name a rollback owner and a restore path for each production system in the window. Social engineering and physical tests need their own calendar: phishing cannot share a silent weekend change freeze if the SOC will treat it as a real incident.

Methods and tools

Methods and tools are the approved techniques and the explicit bans (denial-of-service, ransomware simulation, password spraying volume, physical lock picking). If this is missing, one party will call a technique “standard” and the other will call it reckless. Example: “SQL injection exploitation is permitted in staging. Production exploitation requires written approval from [role]. Denial-of-service is prohibited.”

Communication protocols

Communication protocols name who is contacted, on which channel, and within what time. If this is missing, a critical finding sits in a mailbox while the only contact is on leave. Example: “Daily standup via [channel] at 09:30. Critical findings: phone [primary] within 30 minutes, then email [security@] with ticket ID.”

Data handling rules

Data handling rules state how findings, screenshots, and extracted records are stored, transmitted, and destroyed. If this is missing, testers may copy live personal data to unmanaged laptops or unmanaged tickets. Example: “Evidence containing personal data stays in [region] on [named platform]. Testers will not exfiltrate more than the minimum record needed to prove the issue, and will redact after verification.”

Incident protocol

Incident protocol states what happens if testers cause or find a critical issue mid-engagement. If this is missing, testers either keep exploiting a live breach path or silently stop, and the client learns from customers. Example: “On confirmed critical impact, testers pause exploitation, notify [roles] within 30 minutes, preserve evidence, and wait for written instruction before continuing.”

Reporting cadence and deliverables

Reporting cadence names interim updates, the final report structure, evidence format, and who receives them. If this is missing, you discover at the end that you paid for a PDF dump with no reproduction steps. Example: “Interim high/critical summary within 24 hours of confirmation. Final report within 10 working days of the test close, including CVSS, reproduction, business impact, and retest notes.” Scope decisions show up in the report: unnamed assets cannot be evidenced, and broad “corporate network” wording makes remediation owners impossible to assign. Write the boundary so each finding can point at a named host, application, or account.

Success criteria

Success criteria define what constitutes a completed test, including coverage of listed assets, attempted attack paths, and deliverables accepted. If this is missing, “we ran out of time” and “the test is done” become the same sentence. Example: “The engagement is complete when every in-scope application has been tested to the agreed information level, all critical/high findings are reported, and the debrief is held.”

Test Types and Information Levels: Black Box, Grey Box, and White Box

Black box, grey box, and white box describe how much information and access testers receive before they start, and that choice changes both the scope document and the time required. Pick the information level from the objective, then write the credentials, diagrams, and discovery rights that level demands.

Attribute	Black box	Grey box	White box
Information provided	Targets only, no credentials or diagrams	Partial access: user roles, some architecture, selected secrets	Full diagrams, source or config, admin credentials as agreed
Realism vs thoroughness	Highest external realism, lowest completeness in a fixed window	Balance of attacker path and coverage	Highest coverage of known attack surface, lower “unknown attacker” realism
Time and cost implications	More days spent on discovery inside the same calendar window	Mid-range, fewer dead ends	Less discovery, more deep review per asset; still costly if the estate is large
Choose this if	You need to test detection and what an unauthenticated outsider can do	You want authenticated abuse paths without handing over the keys to everything	You need comprehensive vulnerability identification for a release or audit

Black box scope must still name the boundary, then authorise discovery inside it. Testers will spend the window finding hosts you already knew about. White box scope must attach asset lists, data-flow diagrams, and credential packs or the “white” test is a black box with extra meetings. Grey box scope must list each role under test, because “a user account” is not a privilege model.

External testing

Covers what is reachable from untrusted networks. External scope is CIDRs, domains, and published apps.

Internal testing

Covers what a user, malware, or breached host can reach once inside. Internal scope adds VLANs, identity stores, jump hosts, and the starting position (standard laptop, VPN user, compromised server).

Most organisations need both. One external scan of the firewall does not test Active Directory.

Test type also changes provider requirements. White box needs testers who can read architecture and configuration, plus a secure channel for source and secrets. Black box needs a written right to enumerate and a detection-and-response contact so blue-team alerts are expected, not treated as an incident against the testers. Web application work is often executed against an OWASP-aligned method, but that method still cannot reach hosts you did not authorise. If social engineering is in scope, name the population, the pretext limits, and whether credentials captured may be reused in the technical test.

Managing Scope Changes Mid-Engagement

To manage a scope change mid-engagement, raise a written request, get named approval, record the impact on time and cost, then update the signed boundary before testers touch the new asset. Verbal “go ahead” on a chat channel is how out-of-scope production systems get exploited. “While you are there” is not approval.

Initiator (tester or client) describes the asset, why it matters, and the proposed test activity.
Named approver (asset owner plus security lead) accepts, rejects, or defers.
Provider states impact on remaining days, report date, and fees.
Both parties sign or ticket-approve the change. Testers only then proceed.
The final report lists original scope, changes, and anything still excluded.

Common triggers are new hosts found in reconnaissance, a critical finding that points at an adjacent system, a business owner adding a go-live app, or a stakeholder asking for “a quick look” at a subsidiary. Discovery is expected. Exploitation of the discovered thing is not automatic.

Broader scope consumes remaining tester days or extends the window. Narrowing scope mid-test wastes the days already spent on setup. Under-scoping at the start often costs more than a planned discovery add-on, because the missed asset returns as an emergency test after an incident or a failed audit.

Template language: “Scope change request SCR-[n]. Asset: [name, URL, CIDR, account ID]. Reason: [discovery / critical path / stakeholder]. Proposed activity: [scan / authenticated test / excluded]. Impact: [+X tester days / report date / none]. Approver: [name, role, datetime]. Testers must not proceed until this record is approved.”

Notify the ROE contact list the same day: security lead, asset owner, and the provider project lead. Do not wait for the next standup if the change involves production. For critical findings, most providers notify immediately and pause further exploitation on that path. Have a response owner ready who can patch, take the service down, or accept risk in writing. That response plan belongs in ROE. The scope change process only covers whether adjacent systems may be tested next.

How Scoping Decisions Affect Your Budget

Broader scope increases tester days, tooling, and reporting effort, while under-scoping often costs more later through missed vulnerabilities, failed audits, and emergency retests. Budget is a function of authorised surface, not of the word “penetration test”.

The main cost drivers are number of distinct assets, mix of test types, duration of the window, complexity (cloud accounts, third parties, fragile legacy, OT adjacency), information level, and reporting requirements such as executive plus technical plus retest. A single large web app with ten roles can cost more than twenty static brochure hosts. Scope also drives report usefulness: a narrow, named boundary produces findings owners can fix. A vague estate-wide sentence produces a document auditors discount and engineers cannot action.

Mid-engagement scope changes add setup, extra testing time, retesting, and administrative overhead. They are cheaper when anticipated as a discovery allowance than when they arrive as an undocumented “while you are there”.

When the budget cannot cover the estate, keep internet-facing assets, systems that handle sensitive data, and compliance-mandated targets in the first window. Move low-risk internal tools to a later cycle. Do not “save” budget by dropping the CDE, the identity provider, or the segmentation you claim exists. Those cuts transfer cost to the audit and to incident response.

Pay for named, verified assets rather than a round number of “IPs”.
Fund authenticated (grey or white) testing on the applications that hold data. Unauthenticated-only tests look cheaper and miss the abuse path.
Reserve a small discovery and change allowance so new hosts do not force a full re-scoping exercise.
Include retesting of agreed findings in the original SOW so fix verification is not a surprise second project.

Questions to Ask Your Provider Before Signing

Ask your provider how they handle scope changes, critical findings, third-party and cloud assets, reporting, data protection, methods, false positives, and retesting before you sign, and treat vague answers as a scoping failure. A capable partner will work from a questionnaire, challenge your inventory, and write exclusions down. If they offer to “just start scanning” without a signed boundary, they are asking you to accept their legal risk as well as yours.

How do you handle scope changes mid-engagement? A good answer names a written change request, an approver, and a time/cost impact before testers proceed. A bad answer is “we just include it if it looks important”.
What happens if you find a critical vulnerability during the test? A good answer is immediate named-person notification, pause on further exploitation of that path, and evidence preservation. A bad answer is “it will be in the report next week”.
How do you handle third-party assets and cloud environments? A good answer cites shared responsibility, provider permission programmes, account IDs, and written vendor authorisation. A bad answer is “cloud is fine, we will scan whatever we find”.
What is your reporting cadence and deliverable structure? A good answer includes interim critical alerts, a technical report with reproduction steps, and a debrief. A bad answer is a single unmarked PDF at some unspecified date.
How do you handle data protection and confidentiality? A good answer names evidence storage location, encryption, retention, and UK/EU transfer rules. A bad answer is “we are careful with screenshots”.
What testing methods and tools do you use? A good answer maps methods to your ROE bans and says which activities need extra approval. A bad answer is an unbounded tool list with no prohibited techniques.
How do you handle false positives? A good answer is manual verification before a finding is reported, with evidence attached. A bad answer is raw scanner output as the deliverable.
What is your retesting policy? A good answer states what is retested, within what window, and whether it is in the original SOW. A bad answer leaves retesting as an unpriced favour.

Look for a collaborative scoping partner: they issue a questionnaire, they refuse to start on an unverified asset list, they document exclusions, and they can explain how your test type maps to the boundary. When the checklist and ROE are ready, request a quote for the engagement from Pentesting Company so the signed scope, not a vague estate size, drives the work. TEST. FIND. FIX. PROTECT.

Frequently Asked Questions

What is the difference between scope and rules of engagement?

Scope is the authorised target boundary (what may be tested). Rules of engagement are the operating rules (how testing is conducted: legal authority, windows, methods, contacts, data handling, incidents, and reporting). Methodology sits underneath both and describes the technical approach inside those limits. Put targets in the scope schedule. Put hours, bans, and contacts in the ROE. Mixing the three is how an undocumented host gets exploited “because the method required follow-on testing”.

How do I define what's in scope for a penetration test?

To define what is in scope, list verified assets that are internet-facing, that handle sensitive data, or that support critical operations, then write explicit exclusions for everything testers must not touch. Check contracts before adding third-party or cloud-provider infrastructure, and verify the inventory against live DNS and account lists before you freeze the document. If stakeholders disagree, record the decision and the business reason. Do not leave the asset unnamed.

What should be included in a penetration testing scope document?

A penetration testing scope document should include IP ranges and CIDR blocks, domains and subdomains, web applications and APIs, mobile apps, cloud account IDs and regions, third-party dependencies, physical sites if relevant, user roles, data classifications, authorised test types, named exclusions, testing windows, and emergency contacts. Add the authorising legal entity, environments (production versus staging), tester source IPs, and template wording that testers may only exploit newly discovered assets after a written change approval.

How do I handle third-party or cloud assets in my scope?

Handle third-party and cloud assets by scoping only the accounts, tenants, regions, and configuration you control, after you confirm the contract and any provider testing rules. Name account IDs, VPCs or resource groups, and isolation boundaries so testers cannot affect other tenants or the vendor’s platform. If permission is refused, keep the vendor infrastructure out of scope and test your side of the integration only. Store the vendor’s written reply with the authorisation pack.

What are the 5 steps of penetration testing?

The five steps of penetration testing are reconnaissance, scanning, exploitation, post-exploitation, and reporting. Scoping is not one of the five steps. It is the pre-engagement step zero that must be signed before reconnaissance begins. Some teams split scanning from vulnerability analysis. That does not move scoping into the technical phases.

What are the 7 phases of PTES?

The seven phases of the Penetration Testing Execution Standard (PTES) are pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. Scoping, authorisation, and ROE are completed in pre-engagement interactions, which is the phase this checklist is built to support. Intelligence gathering should not be used to invent new targets without a written scope change.

Ready to freeze a defensible scope?

Use the checklist and rules of engagement in this guide so the signed boundary, not a vague estate size, drives the work. TEST. FIND. FIX. PROTECT.