Before a penetration test begins, confirm the environment, test accounts, a stable build, emergency contacts, backups and monitoring arrangements, and tell the people who need to know. Preparation decides whether testers spend their days finding flaws or waiting for access. Scope itself is covered in a separate post.
Two weeks out
Freeze a build. Testing a moving target wastes effort and muddies retests. Agree a version and a code freeze window for the target.
Choose the environment. Staging that mirrors production is common. If you test production, say so in writing, and plan for the extra care. Make sure staging has realistic configuration, not default settings that hide real issues.
Create test data. Use synthetic records. Do not load real customer data into a test environment.
Prepare accounts. Create at least two accounts per role, so testers can check whether one user can reach another's data. Include a low privilege user, a standard user and an admin. Remove multi factor blockers for test accounts or give testers a way through them, and document that you did.
List what is out of bounds. Third party services, payment processors, shared infrastructure. Your hosting terms may also require notice before certain tests, so check them.
One week out
Name contacts. One technical contact on your side, available during the window, plus an escalation path. Share phone numbers.
Agree a stop rule. If a tester sees instability or something that looks like a real incident, they stop and call. Write the conditions.
Decide who is told. Operations and your hosting team should know the source addresses and testing dates. If your monitoring vendor or security operations team is not told, agree whether they will respond to alerts or note them as test traffic. This is a deliberate choice, and it should be recorded.
Take backups. Verify a restore works, not only that a backup job ran.
Share documentation. Architecture diagrams, API specifications, a threat model if you have one. The OWASP threat modeling guidance notes that models identify entry points and high risk components, so reviewers can focus. The same logic helps testers.
Day before
Smoke test the environment from outside your network, with the accounts you gave testers.
Confirm allow lists. If a web application firewall or rate limiter would block testers, decide whether to allow their addresses for the test. Testing behind a rule that attackers do not have gives a false sense of safety, so some teams test both ways.
Check logging. You will want to match tester activity to your logs afterwards.
During the test
- Answer questions the same day.
- Do not patch silently in the middle unless agreed. If you must, tell the testers.
- Keep a shared channel for urgent issues.
After the test
Plan the debrief and the retest before the test starts: who attends, when the report arrives, how findings become tickets, and when retesting happens. NIST SP 800-115, a technical guide to security testing and assessment, covers planning, conducting and analysing tests and developing mitigation strategies, and can serve as a general reference for the process.
Quick check
Should we tell our developers about the test?
Usually yes, at least the owners of the target. Surprise tests are for response exercises, not for application testing.
Is staging good enough?
It is when it truly mirrors production in configuration and code. Otherwise findings may not transfer in either direction.
Sources
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- OWASP Threat Modeling Cheat Sheet
Last reviewed: 19 October 2026.
