The single biggest factor you control in a penetration test isn't the vendor — it's preparation. Testers who spend the first two days waiting for VPN access, chasing locked accounts or testing a broken staging environment deliver less, no matter how skilled they are. Use this checklist to make sure every paid tester-day goes into finding real issues.
1. Lock down scope and authorisation
- Written list of in-scope assets: URLs, API base paths, IP ranges, cloud account IDs, mobile app versions
- Explicit out-of-scope list (third-party services you don't own, fragile systems, payment processors)
- Signed authorisation from someone with authority over every in-scope asset
- Third-party permissions where needed (hosting providers, managed service providers, SaaS vendors with testing policies)
- Agreed testing windows and time zone
2. Prepare accounts and access
- Two accounts per user role (so testers can check whether one user can reach another's data)
- For SaaS: accounts in two separate tenants/organisations
- MFA configured in a way testers can use (shared authenticator, test phone numbers or temporary exemptions)
- VPN or bastion access for internal or cloud testing, tested before day one
- Read-only cloud console/API credentials for cloud configuration review
- Test payment methods, sandbox modes or test data for transactional flows
3. Prepare the environment
- A stable environment that mirrors production — same code version, same configuration
- Seed realistic test data, especially for multi-step workflows
- Pause or coordinate deployments during the test window
- Back up anything that might be affected by write operations
- Decide on WAF and rate limits: allow-list tester IPs for depth, or leave protections on to test them — ideally test both
4. Share documentation
- Architecture diagram and data-flow overview
- API documentation (OpenAPI/Swagger, Postman, GraphQL schema)
- Description of user roles and what each should and shouldn't be able to do
- Known issues already being fixed (so testers don't spend time re-reporting them)
- Previous pentest reports, so testers can verify old findings stay fixed
5. Brief your people
- Name a technical point of contact available throughout the test
- Agree an emergency contact and process for critical findings or outages
- Decide whether the SOC/IT team is informed. If yes, share tester IPs; if not, nominate someone to de-conflict alerts
- Tell customer support if testing may trigger visible emails or notifications
6. During the test
- Respond quickly to tester questions — unanswered questions waste paid time
- Don't fix things mid-test without telling testers (it invalidates their work)
- Ask for a short mid-point update on progress and coverage
- Act immediately on critical findings reported in real time
7. After the test
- Attend the debrief with engineering leads present
- Triage and assign every finding within a week
- Fix root causes and add regression tests
- Book the retest and request an attestation letter if customers or auditors need one
- Revoke all test accounts, VPN access and credentials, and remove any test device
Read our guide to reading a penetration test report for a remediation framework.
Frequently asked questions
Should we test in production or staging?
A staging environment that mirrors production is safest. If production must be tested, agree testing windows, exclusions and safe test data.
Should we tell our IT/SOC team about the test?
It depends on your goal. Informing them avoids false incident escalations; not informing them tests detection. Either way, nominate someone who knows and can de-conflict alerts.
Ready to book? Get a fixed-price quote. We'll send a preparation checklist tailored to your scope.