To prepare for a penetration test, give the testing team a written scope. Add working access too: test accounts, VPN details, and any firewall allowlisting they need. Name a contact who’s available during the engagement, and take a recent backup of anything in scope. Do that and most of the friction that slows a test down simply doesn’t happen.
Ask any experienced tester what eats into engagement time. The answer is rarely a hard technical problem. Usually it’s an access request that takes two days to action. Sometimes it’s a scope document that means one thing to the client and another to the tester. Other times there’s simply nobody around to confirm whether a finding is a real bug or just how the system works. Here’s what actually needs to be ready, from the perspective of the people doing the testing.
Table of Contents
Start here: how to prepare for a penetration test
A scope agreed by email thread or a phone call tends to drift once testing starts. Put it in writing instead, covering:
- Every in-scope asset, named clearly: domains, IP ranges, applications, APIs and mobile builds.
- What’s clearly out of scope, including any third-party systems you don’t own and can’t allow testing against.
- The testing approach: black box, grey box or white box, and what access level each role gets tested at.
- Rules of engagement: permitted testing hours, any techniques that are off the table (load testing that mimics a denial-of-service attack, for example, is almost always excluded), and an emergency contact if something goes wrong.
The UK’s National Cyber Security Centre puts it plainly. A penetration test only proves your systems weren’t vulnerable to known issues on the day of the test. A poorly scoped test that misses half your real attack surface gives you false confidence, not genuine assurance.
If drafting this alone feels like a lot to get right first time, Aardwolf Security’s penetration testing team will work through scope with you before a start date is set. Nothing gets agreed that doesn’t reflect what you actually need tested.
What testers actually need on day one
Before the engagement starts, have the following ready to hand over:
- Test accounts at every privilege level in scope. Reused personal accounts create confusion about whose actions triggered which alert.
- VPN or network access, checked and working, if the scope includes anything internal.
- Source IP addresses allowlisted on firewalls, WAFs and any bot-protection service that might otherwise silently block the testers.
- API specs (Swagger, OpenAPI, Postman collections) so testers spend time on logic flaws, not on mapping endpoints from scratch.
- A system overview, especially for internal or cloud work, so testers understand what they’re looking at before they start poking it.
None of this is unusual to ask for. Any credible provider sends a pre-engagement questionnaire covering exactly this list, well before the start date. Use it as your own checklist even if nobody’s asked yet.
Cloud infrastructure has its own rules
If any in-scope system sits with a major cloud provider, its testing policy sits above your own scope document. The three big providers each handle this differently.
| Provider | Approval needed first? | What’s restricted |
|---|---|---|
| AWS | No, for most permitted services (EC2, RDS, Lambda, CloudFront and others) | Red team exercises, DDoS simulation and command-and-control testing need explicit sign-off through AWS Support. |
| Microsoft Azure | No, but the Microsoft Cloud Unified Penetration Testing Rules of Engagement still apply | Breaking out of a shared container (Azure Websites, Azure Functions) or touching another tenant’s data is a hard line. |
| Google Cloud | No, for resources you own | Anything that could affect other tenants, or resembles a denial-of-service attempt, is prohibited outright. |
Check the current policy on the provider’s own site before the engagement starts. These policies get reviewed and updated often. An assumption based on last year’s rules can trigger a genuine abuse investigation on your account mid-test, and that stalls everything while it gets sorted out.
Protect your data before testing begins
Penetration testing is deliberately intrusive by design. Before day one, back up everything in scope. Confirm the backup actually restores, not just that a job ran successfully overnight. Where the architecture allows it, point testing at a staging environment that mirrors production closely. Use synthetic or anonymised data there, not real customer records.
External-facing tests often have to include production. That’s genuinely what an outside attacker would be looking at. When that’s the case, agree a lower-risk testing window with your operations team. Make sure whoever watches the monitoring dashboards knows testing is under way.
One contact, available throughout
Nominate a single technical point of contact who can be reached for the full engagement window, not just checked in with at the start and end. That person handles scope clarifications and approves anything that needs a quick decision. They’re also the first call if testing surfaces something serious, like an active compromise that predates the engagement itself.
Compliance-driven tests need their own checklist
A test run for Cyber Essentials Plus, PCI DSS, ISO 27001 or a cyber insurance renewal often has requirements baked into the standard itself. That might be a minimum tester qualification (CREST accreditation is commonly specified), a defined scope boundary, or a set retest frequency. Read the actual requirement before booking the test, not just the summary your compliance team was given. That way, the engagement you commission genuinely satisfies what the auditor will ask to see. Unsure which of these applies to you? Talk to our team before you scope anything and we’ll confirm what the standard actually asks for.
Frequently asked questions
What’s the single most common cause of delay?
Access, by a wide margin. Firewalls blocking tester IP addresses and VPN credentials that don’t work on day one are the most common reason testing time gets eaten up on admin rather than testing.
Do we need to warn our hosting provider or SOC?
Tell your internal SOC or managed detection provider, so genuine testing traffic isn’t escalated as an incident. Formal notification usually isn’t required by cloud infrastructure providers for standard testing. Check the specific provider’s current policy though, for anything approaching a red team exercise or load test.
Can penetration testing be done without any downtime?
Usually yes. A competent tester works carefully. They avoid destructive actions unless those are agreed in advance as part of the rules. Brief service disruption is still possible on fragile legacy systems, which is exactly why flagging anything fragile during scoping matters.
How much internal documentation should we hand over?
As much as matches the testing approach you’ve agreed. A black-box test deliberately withholds documentation, to simulate an attacker with no inside knowledge. A grey-box or white-box test benefits from architecture diagrams and API specs. White-box work also benefits from source code access.
What if testing uncovers something serious mid-engagement?
A credible provider has a process for reporting critical findings immediately, rather than waiting for the final report. Your named point of contact should be reachable to take that call and decide on next steps straight away.
How long does a typical engagement take?
It depends entirely on scope. A single web application is a much smaller job than a full internal and external network test across a mid-sized estate. Treat any headline duration with suspicion until you’ve seen it broken down. Ask for a day-by-day plan at the quoting stage, so you can see where the time actually goes and judge whether it matches the scope you’ve agreed.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
