Penetration test scope checklist
The decisions, accounts, boundaries and evidence to agree before testing starts.
Start with the decision the test must support
A penetration test should answer a decision: whether a release can proceed, whether a customer requirement is met, whether a control works, or where remediation money should go. Write that decision first. It determines which assets, user roles and attack paths matter.
A scope that only lists hostnames can be technically valid and still miss the business risk. Add the product functions, sensitive records, privileged actions and trust boundaries that the test must examine.
Build the asset and identity boundary
List production and staging URLs, API gateways, mobile builds, cloud accounts, identity providers, partner integrations and third-party components. Mark which items are in scope, supporting context or explicitly excluded.
Provide representative accounts for ordinary, privileged, support and tenant roles. Authorization testing is weak when the tester receives one administrator account and no way to compare identities.
Agree rules before the first request
Record the testing window, source IPs, rate limits, prohibited techniques, data-handling rule, incident contact and stop conditions. Decide how critical findings are escalated and who can authorise a scope change.
Do not send passwords, API keys or customer data through a public form. Exchange access only through the secure channel agreed after contracting.
Define evidence and closure
A buyer-ready report should include the affected component, preconditions, evidence, realistic impact, severity rationale and specific remediation. Ask how false positives are removed and whether a retest records fixed, partial, accepted and open status.
For assurance purposes, preserve the rules of engagement, tested asset list, dates, methodology, finding register and retest outcome. Those records prove what the test did and did not cover.
A 12-point buyer checklist
1. Business decision. 2. Critical workflows. 3. In-scope assets. 4. Exclusions. 5. User roles. 6. Test environment. 7. Test data. 8. Timing and rate limits. 9. Prohibited actions. 10. Escalation contacts. 11. Report audience. 12. Retest and closure criteria.
If any of these are unknown, make the scoping call solve them. Ambiguity before testing becomes a coverage dispute after testing.