A penetration test is paid for in tester time. Every hour spent waiting for an account to be created, a firewall rule to be changed or a question to be answered is an hour not spent finding real issues. Good preparation also makes testing safer, and makes the report far more useful afterwards. This checklist covers what to sort out before testing starts.
1. Be clear about why you are testing
The objective shapes everything else. “A customer asked for a VAPT report on our platform” leads to a different scope from “we want to know what an attacker could reach after phishing one of our staff”. Write down the reason, any deadline, and who the report is for: your engineers, your leadership, a customer or an auditor. Share this with your testing provider at the start.
2. Define the scope precisely
- List every target: IP addresses and ranges, hostnames, application URLs, API base URLs, mobile app builds or cloud accounts.
- State explicitly what is out of scope, such as a legacy system that must not be touched or a third-party payment page.
- Check ownership. For anything hosted by a third party, confirm that their terms allow testing. Major cloud providers allow customers to test their own resources within published policies; many shared hosting and SaaS providers do not.
- For applications, list the user roles and the workflows that matter most, such as payments, approvals or data exports.
3. Choose the testing approach
In a black-box test the tester starts with no information. In grey-box testing they receive some information and normal user access. In white-box testing they have full documentation and sometimes source code. Grey-box usually gives the best value: it reflects a realistic attacker without spending paid time rediscovering things your team could simply share.
4. Choose the environment
For applications, a staging environment that closely mirrors production is usually best. Testers can then create, change and delete data freely without affecting customers. Make sure staging runs the same code and configuration as production, otherwise the results may not apply. If you must test production, agree testing windows and limits in advance.
5. Prepare access and accounts
- Create test accounts for each user role, ideally two per role, so the tester can check whether one user can reach another user’s data.
- For internal tests, arrange a VPN account, a jump host or a network port on site, and a standard domain user if the test is grey-box.
- Decide whether to allow-list the tester’s IP addresses on your web application firewall and rate limiting. If you want the application tested rather than the firewall, allow-list them.
- Share API documentation, such as an OpenAPI specification or Postman collection, and any test data the tester will need, such as payment sandbox details.
- Test that everything works before day one. Expired accounts and blocked VPNs are the most common causes of lost testing time.
6. Sign the authorisation and rules of engagement
No reputable tester will start without written authorisation. The rules of engagement should cover scope, testing windows, permitted and excluded techniques (denial of service is normally excluded), the tester’s source IP addresses, contacts and escalation, and the conditions under which testing stops. Make sure the person signing has the authority to approve testing of every system in scope.
7. Tell the right people
Decide who needs to know. Your hosting provider, managed security provider or internal security operations team may see the test as an attack. You can tell them in advance, or keep the test unannounced to see whether they notice, but make that decision deliberately and have an escalation route ready either way. Make sure the contacts named in the rules of engagement are reachable throughout the testing window.
8. Take sensible precautions
- Confirm recent backups of critical systems exist.
- Avoid deploying major changes to in-scope systems during testing, so results reflect a stable target.
- Keep your normal monitoring running. It is useful to know whether the test was detected.
9. Plan for the findings before they arrive
The value of a test lies in what gets fixed. Before testing starts, decide who will own remediation, set aside engineering time for the weeks after the report, and agree whether retesting is in scope. A report that arrives with nobody available to act on it quickly becomes out of date.
10. After the test
- Attend the debrief with the people who will fix the issues, not just the people who commissioned the test.
- Fix critical and high-severity findings first, using the remediation priorities in the report.
- Disable or rotate every test account and credential you created for the tester.
- Ask for a retest of fixed findings, so you have evidence that issues were resolved, not just found.
- Record recurring causes, such as missing authorisation checks, and fix them at the source so they do not reappear.
Summary checklist
- Objective, deadline and report audience written down
- Targets listed, exclusions stated, third-party permissions confirmed
- Approach chosen: black-box, grey-box or white-box
- Environment chosen and checked to mirror production
- Accounts, VPN and allow-listing set up and tested
- Authorisation and rules of engagement signed
- Providers and internal teams informed, or deliberately not
- Backups confirmed and changes frozen
- Remediation owners and time allocated, retest agreed
We send a version of this checklist at the start of every penetration testing engagement. If you are planning a test and want help with scope, get in touch.