A penetration test is only as good as its scope. Before kickoff, agree the goal, the exact targets, what is off limits, the rules of engagement, how data and credentials are handled, the testing window and what the report must contain. Write it down and have both sides sign.
This is practical guidance. It is not drawn from one standard, though NIST SP 800-115 covers the planning and execution of security testing at a high level.
1. The goal
Say why you are testing. Common reasons are a customer requirement, a new release, an audit input or a check on a specific worry such as an exposed admin panel. The goal decides depth and method.
2. Targets
List the domains, IP ranges, apps, APIs and environments in scope. Name the ones out of scope, especially third party services you do not own, because testing them may need the provider's permission. Say whether production or a staging copy is used.
3. Rules of engagement
Agree what is allowed:
- types of attack, such as social engineering, denial of service or physical access
- whether the tester may move laterally after gaining access
- how far they may go with data they reach, for example proof of access without copying records
4. Accounts and access
Decide whether the test is black box, with no knowledge, or uses test accounts at each role. Role based test accounts let the tester check authorization between roles. Share them over a safe channel.
5. Data handling
State where findings and evidence are stored, who sees them and how long they are kept. Agree what happens if the tester sees real personal data. Make sure contracts reflect the answer.
6. Window and contacts
Set dates and hours. Name an emergency contact on each side, and a rule to stop the test if something breaks. Tell your operations team, or decide deliberately not to, and tell your hosting provider if their policy requires it.
7. Reporting and retest
Ask for an executive summary, reproducible findings with evidence, severity with reasoning and fix advice. Agree on a retest after fixes, and on how critical findings are reported during the test rather than at the end.
8. Qualifications and independence
Ask who will do the work, their relevant experience and whether they are independent of the systems tested. If an auditor or customer will read the report, ask them what they expect.
Pentest and scanning are different
NIST's guide covers techniques for finding vulnerabilities or verifying policy compliance. A scanner reports known issues. A pentest tries to chain them. See pentest versus vulnerability scan.
Quick check
How often should we test?
After major changes and on a regular cycle your risk and customers justify. Annual is common but not a rule.
Can we test a cloud provider's systems?
Check the provider's testing policy first. Your account's resources and the provider's own systems are different things.
Sources
Last reviewed: 19 October 2026.
