The best penetration tests start well before the first scan. When goals, scope and access are clear, testers spend their time finding real problems instead of waiting for accounts or asking which servers they are allowed to touch. Here is what to prepare.
Before the test
1. Decide what you want to learn
Write down why you are testing. Is it to satisfy an auditor, protect a new product launch, answer a customer's security questionnaire, or understand whether an attacker could reach a specific system? Clear goals shape the scope, the approach and how the report is written.
2. Define the scope precisely
- List every application URL, API, IP range, cloud account or device that is in scope.
- List anything explicitly out of scope, such as third-party systems or fragile legacy servers.
- Note the user roles that exist (customer, staff, admin) and which ones should be tested.
3. Choose the testing approach
Black-box testing gives testers no prior information, like an outside attacker. Grey-box testing provides test accounts and basic documentation, and is usually the best balance of realism and efficiency. White-box testing adds source code or architecture details for the deepest coverage.
4. Get the right permissions
- Sign the rules of engagement: scope, dates, testing windows, permitted techniques and emergency contacts.
- Check whether your hosting, cloud or SaaS providers have testing policies that require notice or forbid certain tests.
- If systems are managed by a third party, get their written permission too.
5. Prepare accounts and environments
- Create test accounts for each role, with realistic but non-sensitive data.
- Decide whether to test production or staging. Staging is safer, but it must closely match production.
- Whitelist tester IP addresses on your web application firewall if you want the application itself tested rather than the firewall.
- Share any API documentation, Postman collections or architecture diagrams.
6. Tell the right people
Your IT team, security operations center or managed security provider should know testing is planned, unless the goal is to test their detection. In that case, make sure at least one senior person knows, so a real incident response is not triggered by mistake.
7. Take backups
Professional testers avoid destructive actions, but it is good practice to confirm recent backups exist for systems in scope.
During the test
- Name a single point of contact who can answer questions and fix access issues quickly.
- Agree how critical findings will be reported. Serious issues should be escalated immediately, not held for the final report.
- Avoid major changes to in-scope systems during the testing window, or tell the testers when they happen.
After the test
- Hold a debrief with technical and business stakeholders to understand the findings and their impact.
- Prioritize fixes by risk, not just by severity score: an exploitable medium on your payment flow may matter more than a theoretical high elsewhere.
- Assign owners and deadlines for every finding.
- Book the re-test to confirm fixes actually work.
- Feed lessons back into development and operations, so the same class of issue does not return.
Quick checklist
- Goals written down
- In-scope and out-of-scope assets listed
- Testing approach chosen
- Rules of engagement signed, third-party permissions obtained
- Test accounts and documentation ready
- Environment and testing window agreed
- Internal teams informed, point of contact named
- Backups confirmed
- Remediation owners and re-test date planned
Need help scoping your test?
We walk every client through this process in a free scoping call, then send a fixed-price proposal. Get in touch, or learn more about our penetration testing services.
