To get value from a penetration test, fix the obvious issues first, agree a written scope and rules, prepare test accounts and a staging copy, name contacts on both sides, take backups, and reserve engineering time to fix findings. Testers should spend their days on hard problems, not on missing patches.
Clean up the obvious first
Run your own scanners and fix what they find. Paying for expert time to report an outdated library your scanner would have flagged wastes the engagement. Review authentication settings, exposed admin pages and known vulnerable dependencies. Then tell the testers what you already know about, so they skip it.
Write the scope
- Targets: hosts, applications, APIs, mobile builds, and cloud accounts, named exactly.
- Out of scope: third party systems you do not own, production data stores, specific tests you forbid.
- Dates and hours: when testing runs and when it must not.
- Permission: written authorisation from the owner of every system tested. For cloud and hosted services, check the provider's current testing policy.
- Goals: for example, "can an outsider reach customer data" gives better results than "find everything".
Prepare the environment
- A staging environment that matches production, with realistic but non sensitive data.
- Test accounts at each privilege level, including two ordinary users in separate tenants, so cross account access can be tested.
- Documentation: API specifications, architecture diagram and role descriptions. More information means more depth for the same budget.
- A copy of recent backups, and a restore you have tested.
- Allow lists for tester addresses if you run a web firewall, or agree that the firewall will be tested as part of the exercise.
Agree safety rules
Decide how destructive tests are handled, what happens if testers find live customer data, how critical findings are reported immediately, and who may stop the test. Share an emergency contact on each side. Tell your hosting provider or monitoring team that testing is planned, unless detection is part of the goal.
Plan for the findings
Block engineering time in the two weeks after the report. Decide in advance who triages, how severity maps to deadlines and how fixes are retested. Ask for a retest as part of the contract. Findings without owners and dates tend to sit unfixed.
Safeguard reachability analysis and fix pull requests can help clear dependency issues before and after a test, though they do not replace human testers.
Choose the testers carefully and ask what their report will look like. A good report ranks findings by real impact, shows how each was reproduced, and suggests a fix. Ask who will do the work, and what experience they have with your technology. Agree early how long you will have to ask questions after the report arrives, because clarifying a finding is part of fixing it.
Quick check
Should we test production?
Staging is safer for deep testing. Some issues only show in production, so agree a limited, careful production pass if you need one.
How often should we test?
Commonly yearly and after major changes, though the right rhythm depends on your risk and compliance needs.
Last reviewed: 19 October 2026.
