How to Prepare for a Penetration Test: A Checklist

List every application, address range, API and environment you want tested, and everything that must be left alone. Be specific: a domain name is clearer than "our website", and a list of IP ranges is clearer than "the network". Anything unclear tends to be left out or argued about later.

Testing a staging or pre-production copy with realistic data is usually the safest and fastest option, because heavy tests can run without touching live customers. If production must be tested, agree the hours, the stop conditions and who watches it.

Authorization flaws, for instance a customer who can open someone else's records, can only be found with credentials. Create a test account for each role, and two accounts in each role if the system has several customers or tenants. Make sure the accounts work before testing starts, including any second factor.

• Your security or operations team, so that test traffic is not mistaken for an attack.
• Your hosting or cloud provider, if its rules ask for notice of security testing. Check the provider's current policy.
• Any third party whose systems the application calls. Their servers are out of scope unless they agree.

Ask the vendor for the fixed IP addresses that testing will come from, and allow them through your firewall, web application firewall and rate limits. If you want to see whether your defenses notice an attack, say so in advance; otherwise they will slow the test down.

Make sure you can recover. Take a backup before testing starts, and avoid releasing major changes during the test window, because a moving target makes findings harder to reproduce.

Give the tester one person who can answer questions during testing and one who can be reached in an emergency, with phone numbers. Agree the hours in which testing may run.

The rules of engagement should state the scope, the exclusions, the testing windows, what the tester may do if they find a serious flaw and when they must stop and call you. Both sides should sign them before any testing starts.

• Scope and exclusions written down.
• Staging environment ready, or production windows agreed.
• Test accounts for every role, checked.
• Security team, provider and third parties informed.
• Tester's addresses allowed.
• Backups taken.
• Contacts and hours named.
• Rules of engagement signed.

If you would like help setting the scope, our VAPT methodology page shows how each engagement starts.

Prefer paper? Download this checklist as a one-page PDF to hand to your team and your tester.