What to decide before a penetration test starts, so the results are useful to engineers, leadership and the customers asking for them.
A penetration test is only as useful as its scope. Most disappointing tests trace back to decisions that were never made before testing started. Use this checklist before you request a proposal from any provider.
1. Why are you testing?
Write down the trigger. A customer security questionnaire, a regulator’s expectation, a product launch and an annual assurance cycle each need different depth, timing and reporting. The reason shapes everything else.
2. Which assets are in scope, exactly?
List hostnames, IP ranges, API base URLs, mobile app builds and cloud accounts. “Our platform” is not a scope. Anything not listed should be treated as out of scope.
3. Which environment?
Production gives the most realistic results but carries operational risk. A production-like staging environment is often the best balance, as long as it really matches production configuration.
4. What level of access will testers have?
- Black box: no credentials, simulating an outside attacker.
- Grey box: standard user accounts for each role, the most common choice for web apps and APIs.
- White box: source code and architecture documents, the most thorough per hour of effort.
5. Which user roles matter?
Broken access control remains the most common serious web application weakness in the OWASP Top 10. Provide at least two accounts per role so testers can check whether one customer can reach another customer’s data.
6. What is off limits?
Agree in writing whether denial-of-service testing, social engineering, physical access or production data modification are excluded. These rules of engagement protect both sides.
7. Who must authorize the test?
Written authorization must come from someone with authority over every system in scope. If you use a cloud provider, payment processor or hosting company, check their testing policies too.
8. When can testing run, and who is on call?
Agree testing windows, time zones and an emergency contact on both sides. If a critical issue is found mid-test, decide in advance how it is reported.
9. What should the report contain?
Ask for an executive summary, risk-rated findings with evidence, clear reproduction steps and specific remediation guidance. A sample report from the provider is the best way to judge quality.
10. Is a retest included?
A retest confirms that fixes actually work and gives you a clean letter to share with customers. Agree its timing and scope up front.
Next step: if you would like a second opinion on a scope, or a proposal for a CyberAssure assessment, contact us.
This article is general information, not professional advice for your specific situation.