Penetration Test Scoping Checklist

Most penetration tests that disappoint were lost at scoping: the wrong systems were listed, a fragile server was hit in business hours, a cloud provider rule was broken, or nobody could say afterwards which test accounts still existed. This template is a pre-engagement checklist and scope of work to send to a testing provider or internal team and get back completed and signed. It covers objectives, targets and exclusions, windows, rules of engagement, cloud provider policies, test credentials, contacts, data handling, reporting, retest and written authorisation, drawing on NIST SP 800-115, NCSC penetration testing guidance, PCI DSS v4.0.1 requirement 11.4 and the PCI SSC penetration testing guidance supplement, CIS Control 18 and the AWS, Microsoft Azure and Google Cloud testing policies. It is for security managers commissioning tests, testers and the system owners who sign.

How to use this template

• Replace text in square brackets, such as [Organisation], [Testing provider] and [X days], with your own terms and values.
• "Must" is mandatory; "should" is recommended, with exceptions agreed in writing by the [Engagement sponsor].
• Complete one copy per engagement. Send sections 2 to 13 to the tester as the pre-engagement questionnaire, agree them in a scoping call, then sign section 14. No testing starts before both parties sign. Anything not listed in section 4 is out of scope.
• For test types, methodologies and running a testing programme, see the Penetration Testing Guide; for objective-led adversary emulation, see the Red Teaming Guide. Choosing the provider is covered in our companion Penetration Testing Provider Buyer's Guide.

1. Purpose

This document defines the scope, rules and authorisation for the penetration test of [System or environment name] by [Testing provider] on behalf of [Organisation], so that the test answers [Organisation]'s questions, stays within systems it can authorise, avoids harm to production and produces an actionable report. NIST SP 800-115 advises that "A security assessment should be treated as any other project", with defined goals, scope, roles, limitations, assumptions, resources, timeline and deliverables; this document is that project definition.

2. Objectives and drivers

Tick every driver that applies and state the question the test must answer.

Primary question the test must answer: [one sentence]. Scenarios, chosen from previous incidents and threat intelligence as NCSC advises (for example "Lost laptop, unauthorised device connected to internal network, and compromised DMZ host"): [list].

3. Test types and approach

• Knowledge level: [Open box / Closed box / Grey box]. Open box finds more per tester day; closed box shows what an outsider can learn.
• Visibility: [Overt: IT and the SOC are told / Covert: only named senior managers know]. NIST SP 800-115 describes covert testing "with the full knowledge and permission of upper management", with a trusted third party to confirm activity is the test.
• Effort: [X] tester days, [start date] to [end date], plus [X] days for reporting.
• Inputs shared: your current vulnerability assessment (NCSC advises sharing it with the testers), network and data flow diagrams, and the previous report.

4. In-scope assets

List every target explicitly. The [Asset owner] confirms [Organisation] owns or may authorise testing of each entry; a released IP address now belongs to someone else.

Tester source IPs (a rules of engagement item in the PCI SSC supplement): [list]. [Allowlisted in WAF and IPS / not allowlisted]; record the choice in the report, because it changes what the result means.

5. Out-of-scope and fragile systems

• Explicitly excluded: [systems, ranges, third-party services, other customers' tenants, shared infrastructure]. NIST SP 800-115 warns assessors not to "inadvertently scan devices owned or operated by neighboring organizations".
• Fragile systems: [legacy, OT, medical or mainframe systems], tested only with [passive discovery / named safe checks / not at all]; state known failures, for example "crashes under full port scan".
• Third-party hosted assets: need the supplier's written permission (section 14) or stay out of scope. The PCI SSC supplement notes scope "may not include the infrastructure provided by the third party", nor its management portals.
• Production data: records the tester must not alter or extract, for example [cardholder data, patient records].

Verify the final target list against the asset inventory before testing starts. In the Meta Muse Spark evaluation incident, a misconfigured cyber test pointed an AI model at a real website.

6. Testing windows

7. Rules of engagement

7.1 Permitted and prohibited activities

7.2 Stop conditions

The tester must stop and call the technical contact immediately if: a service degrades or fails; evidence of a real attacker or prior compromise is found; a critical vulnerability with immediate exposure is confirmed; data outside scope, including another customer's data, is reached; or the tester is unsure whether an action is in scope.

7.3 Tooling

The tester must declare tools likely to have side effects, disable denial of service capability in any tool (the AWS policy requires this for tools used against AWS), and keep timestamped activity logs to reconcile against [Organisation]'s security monitoring.

7.4 Scope changes

Any change to targets, techniques or windows must be requested in writing and approved by the [Engagement sponsor] before it is acted on; NCSC places that decision with the risk owner.

8. Cloud provider and hosting policies

[Organisation] authorises cloud testing within the provider's terms. Reconfirm each policy per test; the lists change.

AWS makes the customer responsible for damage caused by testing and for contracted third parties following its policy, so flow these rules down into the tester's contract.

9. Test accounts and credentials

Test credentials are real credentials into production. Manage them as temporary privileged identities with a full lifecycle.

Forgotten test identities are an attacker's way in: the Midnight Blizzard breach started with a forgotten test tenant account and an OAuth app. See the Service Account Security Guide and the API Key Management Guide.

10. Contacts and escalation

Deconfliction: the SOC calls the tester lead with source IP and time; activity not in the tester's log is a real incident under [incident response procedure]. Critical findings are phoned through within [4 hours], not held for the report.

11. Data handling

1. NIST SP 800-115 asks organisations to "Appropriately handle technical data (collection, storage, transmission, and destruction)". Classify test data (credentials, hashes, screenshots, network maps) as [Confidential] at minimum.
2. Collect the minimum evidence needed to prove a finding, mask personal data in screenshots and never copy bulk records.
3. Store evidence encrypted on tester-controlled systems in [jurisdiction], accessible only to the named test team, and transfer it only through [secure portal / encrypted archive with key sent separately].
4. Cracked passwords are reported as counts and account names, not plaintext.
5. The tester must securely delete [Organisation] data within [30 days] of report acceptance and confirm deletion in writing. [Organisation] retains the report and remediation evidence for at least 12 months (PCI DSS 11.4.1) or [retention period].

12. Reporting requirements and severity scheme

• Executive summary: answer to the primary question in section 2, overall risk, top issues.
• Scope, methodology and limitations: what was and was not tested, constraints (allowlisting, fragile systems skipped), dates, source IPs and tools used, matching the statements of scope, methodology and limitations in the PCI SSC supplement's report outline.
• Findings: description, affected assets, evidence, reproduction steps, risk rating, and "a method of resolving" each issue (NCSC); map to CWE where applicable.
• Attack narrative: chained path for any escalation, including which credentials and identities were used or created.
• Vulnerability assessment opinion: NCSC recommends the report gives "an opinion on the accuracy of your organisation's vulnerability assessment".
• Clean-up record: artefacts, accounts and keys created and confirmation of removal.

Ask for CVSS-BTE scores where the tester has the context: FIRST describes Threat and Environmental metrics as "a more comprehensive input to risk assessment". UK CHECK reports must rate risk as "HIGH, MEDIUM, LOW or INFORMATIONAL", with CVSS "in addition to (but not in place of)" that rating. Remediation decisions remain [Organisation]'s: NCSC says "risk assessment and decisions on the application of fixes are your responsibility" and should not be wholly outsourced to the test team.

13. Remediation and retest

1. Findings are logged in [ticketing system] within [5 working days], with an owner and section 12 due date.
2. PCI DSS 11.4.4 requires exploitable findings to be corrected per the entity's risk assessment and "Penetration testing is repeated to verify the corrections."
3. Retest scope: all Critical and High findings, plus [Medium findings on in-scope PCI systems], within [X days] of remediation, at [included / additional] cost.
4. After each test, the SOC reviews whether it detected the tester's techniques and adds detections where it did not (CIS Safeguard 18.4).

14. Legal authorisation and sign-off

Unauthorised access to computer material is a criminal offence in many jurisdictions, for example under section 1 of the UK Computer Misuse Act 1990 and, in the US, the Computer Fraud and Abuse Act (18 U.S.C. 1030). The US Department of Justice's 2022 policy on good-faith security research binds federal prosecutors only and is no substitute for permission. This signed section is the tester's written authorisation (the "get out of jail" letter), carried by the tester throughout. It is not legal advice; have [Legal] review it.

15. Framework mapping

16. Source references

1. NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment
2. NCSC: Penetration testing
3. PCI SSC: Information Supplement, Penetration Testing Guidance
4. PCI DSS v4.0.1 requirement 11.4.1 (requirement text as published by Cloudaware)
5. CIS: Controls v8 Assessment Specification, Control 18 Penetration Testing
6. AWS: Penetration Testing policy
7. Microsoft: Microsoft Cloud Unified Penetration Testing Rules of Engagement
8. Microsoft Learn: Penetration testing (Azure)
9. Google Cloud: Cloud Security FAQ
10. FIRST: CVSS v4.0 Specification Document
11. UK legislation: Computer Misuse Act 1990, section 1
12. US Department of Justice: New policy for charging cases under the Computer Fraud and Abuse Act

Implementation guidance

1. Scope from risk, not from last year's list: start with the question in section 2, then pick targets that answer it. Involve "all relevant risk owners" and technical staff in the scoping call, as NCSC advises.
2. Reconcile the target list: check every IP, domain and cloud account in section 4 against the asset inventory and DNS the day before testing; remove anything [Organisation] cannot prove it owns. See the Attack Surface Management Guide.
3. Pilot fragile targets: run safe checks against one fragile host with its owner watching before scanning the group; if it degrades, fall back to passive discovery for that group.
4. Close the identity loop: run section 9 revocation as a tracked change with evidence, then check cloud audit logs for any use of test identities after the end date.
5. Feed results forward: load findings into vulnerability management (see the Vulnerability Management Guide), and turn the attack paths into breach and attack simulation scenarios so the controls are rechecked between annual tests. A point-in-time test does not replace a standing disclosure route for flaws found by outsiders; see the Bug Bounty and Vulnerability Disclosure Guide.

Small and large organisations: small organisations can use sections 2, 4, 7, 9 and 14 as a short scope letter for a single application test. Large or regulated estates should keep this document as a master scope per environment, version it each year and reuse sections 8 to 11 across providers.

Common failure patterns: vague scope ("the website") with no identifiers; hosted assets tested without the supplier's permission; testers allowlisted without anyone recording it; credentials emailed and test accounts and keys left active after the report; findings never retested, so the next annual report repeats them. Track these measures:

• Scope accuracy: targets found to be out of [Organisation]'s ownership at reconciliation (target zero reaching the tester).
• Test identity hygiene: test accounts, keys and roles still active [2 days] after test end (target zero).
• Remediation: Critical and High findings closed and retested within target.
• Repeat findings: findings that recur from the previous test.
• Detection: share of tester techniques detected by the SOC.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Penetration Testing Guide · Red Teaming Guide · Exposure Management and CTEM Guide · PCI DSS 4.0 Guide · Breach and Attack Simulation (BAS) Guide