A little preparation is the difference between a penetration test that spends ten days finding real vulnerabilities and one that burns the first three waiting on credentials and firewall changes. You are paying for skilled testing days — here is the checklist that makes sure they are spent testing.
1. Get the scope right
Scope is the foundation of the whole engagement. Before testing starts, agree in writing:
- Exactly what is in scope — application URLs, API endpoints, IP ranges, cloud accounts, and which user roles will be tested.
- What is explicitly out of scope — production databases you cannot risk, third-party services, legacy systems awaiting decommission.
- Whose permission you need. If any in-scope asset is hosted or operated by a third party, check their terms. Most major cloud providers permit customer-authorised testing, but some SaaS platforms and hosting providers require notice.
A vague scope produces a vague test. If you are unsure what to include, say so on the scoping call — working that out together is what the call is for. (New to the process? Start with what a penetration test actually involves.)
2. Choose the right environment
Production versus staging is a genuine trade-off:
- Production is maximally realistic, but higher-risk checks may need to be constrained, and testing traffic mixes with real users.
- Staging allows aggressive testing with zero customer impact — but only if it is genuinely representative. A staging environment running old code, missing integrations, or empty of data will produce a report about an application you do not actually run.
If you test staging, make sure it mirrors production configuration and is seeded with realistic data — multiple tenants, multiple user roles, records to actually find. Decide this early: standing up a proper staging environment the week before testing rarely goes well.
3. Provision access and test accounts
Missing credentials are the single most common cause of lost testing days. Before day one:
- Create at least two accounts per user role. Testing authorisation — whether user A can reach user B's data — requires two of everything. For a multi-tenant product, that means accounts in at least two separate tenants. This is where the highest-impact findings in a web application pentest usually live.
- Sort out MFA and SSO. Decide how testers will authenticate: real MFA enrolment, a conditional exception for tester accounts, or SSO test identities. Verify the login flow works before testing starts.
- Provide VPN or network access if anything in scope is not internet-facing, and test it end to end beforehand.
- Share documentation. API specifications (OpenAPI/Swagger), Postman collections, architecture diagrams and a short product walkthrough all convert directly into deeper testing. Every hour testers do not spend reverse-engineering your app is an hour spent attacking it.
4. Agree the rules of engagement
The rules of engagement (RoE) document is your safety net. It should cover:
- Testing windows — business hours only, or anytime? Any change freezes or blackout dates?
- Out-of-bounds actions — commonly denial-of-service, social engineering (unless scoped), and destructive actions against production data.
- Source IP addresses the testers will use, so their traffic is identifiable in your logs.
- WAF and rate-limit allowlisting. For application tests, we recommend allowlisting tester IPs: you are paying to test your application, not your WAF vendor's product. Note the caveat in the report, or leave protections on for a portion of testing if you want both answers.
- Emergency stop — who on either side can pause testing, and how.
- Data handling — how evidence and any accessed data will be stored, transmitted and destroyed.
5. Set up communication channels
Agree these before the first packet is sent:
- A shared channel (Slack, Teams or similar) with the testers for quick questions — an environment issue resolved in ten minutes instead of a day of email is testing time saved.
- A named technical contact on your side with authority to fix access problems fast.
- An escalation path for critical findings, because anything severe should reach you immediately, not in the report.
6. Tell the right people
A penetration test is not a surprise drill — that is a red team exercise, which is a different engagement with different rules. For a standard pentest:
- Notify your engineering and operations teams so alerts are triaged calmly rather than treated as a live incident at 2 am.
- If you use a managed SOC or MDR provider, tell them the testing window and source IPs.
- Resist the urge to specially harden things beforehand. You want the report to describe your real posture, not a costume.
It is worth fixing known criticals before the test, though — paying testers to rediscover issues already in your backlog is poor value.
Day-one checklist
- Scope and RoE signed by both parties
- Test accounts created, two per role, logins verified
- VPN/network access tested end to end
- API docs, walkthrough and diagrams shared
- Tester source IPs allowlisted where agreed
- Shared comms channel live, contacts and escalation confirmed
- Internal teams and SOC notified of the window
- Recent backups confirmed for anything in scope
FAQ
Should we fix known issues before the test?
Fix known critical and high-severity issues, yes — rediscovering your own backlog is a waste of testing budget. But do not delay testing for months chasing a perfect posture. The point of the test is to find what you do not know about.
Should developers know the test is happening?
For a standard penetration test, yes. Informing your team avoids false-alarm incident response and lets access issues get fixed quickly. Testing your detection and response without warning is a legitimate goal, but that is an assumed-breach or red team engagement, scoped deliberately as such.
What happens if testers find something critical mid-test?
Anything critical should be escalated to you out of band immediately — that is what the escalation path in your RoE is for. You can start remediating the same day rather than waiting for the report, and we retest fixed issues free within 90 days.
Booked a test, or about to? Get in touch and we will run the scoping call, confirm exactly what to prepare, and have a fixed quote to you within one business day.
Need cybersecurity expertise?
Drop your email and we'll be in touch within one business day.