31 October 2026 · 12 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
How to prepare for a penetration test: the scoping and readiness checklist for the weeks before testing starts
You have selected a testing firm and signed the proposal. What happens in the next two to four weeks decides whether the testers spend their days finding vulnerabilities or waiting for accounts, firewall exceptions and sign-offs. This guide covers everything your organisation should define, prepare and communicate before day one. It starts where the vendor selection ends; if you are still comparing proposals, read our penetration testing RFP checklist first.
Why preparation decides the value of the test
A penetration test is bought in consultant-days. Every hour the tester spends chasing a VPN account, asking which IP ranges are actually in scope, or waiting for the WAF team to add an exception is an hour not spent on the systems you are paying to have examined. In our experience of 10+ years of engagements, the single largest difference between a test that finds the critical path and one that returns a thin report is not the tester's skill. It is whether the client had scope, access and authorisation ready when the engagement window opened.
Preparation also protects you. A test without a signed authorisation letter, a defined scope and an emergency contact is a test that can take down a production system without anyone knowing who to call, or probe a third-party host you had no right to include. The checklist below is organised in the order a mature security team works through it: decide what and why, decide how, arrange access, arrange protection, arrange people, then hold the kickoff.
This article assumes the commercial decision is made. Choosing between firms, comparing methodologies and reading quotes is covered in our penetration testing RFP checklist and in our guide to choosing a penetration testing company. Here we deal with what you owe the engagement once the contract is signed.
Step one: define objectives, scope and test positions
Scope is a written list, not a conversation. The tester should be able to read it and know, for every address and application, whether it is in or out.
1. Write down the objective in one sentence
Compliance evidence for ISO 27001 A.8.8 or PCI DSS Req. 11.4, assurance before a product launch, validation after a migration, or a specific question such as 'can an internet attacker reach customer data'. The objective determines which test positions matter and how the tester prioritises time. A test with no stated objective defaults to breadth, which is rarely what the sponsor wanted.
2. Enumerate the assets explicitly
External IP ranges and hostnames, internal subnets, web applications with their URLs per environment, APIs with their specifications, mobile builds, cloud accounts and subscriptions with account IDs, and the identity provider. Include the things you are unsure about and mark them as questions. The most dangerous scope is the one that says 'our web application' and leaves the tester to guess which of the fourteen subdomains that means.
3. Name the exclusions and the reasons
Third-party SaaS you do not own, systems under a change freeze, shared hosting where a test would hit other tenants, legacy equipment that cannot tolerate a port scan. Exclusions are legitimate, but they must be written down so the report can state what was not tested and why. Auditors read the exclusion list as closely as the findings.
4. Decide the test positions
External unauthenticated (internet attacker), external authenticated (a customer or partner), internal unauthenticated (a device plugged into the office network), internal authenticated (a standard employee, the assumed-breach position), and privileged (a developer or administrator, for white-box depth). Each position answers a different question; a scope with one position answers one question.
5. Agree the rules of engagement
Testing hours (business hours only, or 24 hours), whether denial-of-service techniques are excluded (they almost always are), whether social engineering is in or out, whether the tester may pivot from one in-scope system to another, what happens if the tester finds a path into an out-of-scope system, and how far exploitation goes once a vulnerability is confirmed. These rules go into the statement of work and are repeated at the kickoff.
Black box, grey box or white box: what you must prepare for each
The knowledge level you grant the tester sets what you need to hand over. Grey box is the default for most first and annual tests because it buys the most findings per day; black box is for a specific question about an unassisted attacker; white box is for depth on a critical application.
| Aspect | Black box | Grey box | White box |
|---|---|---|---|
| What the tester starts with | Company name, target list, nothing else | Target list, architecture overview, test accounts per role, API documentation | Everything in grey box plus source code, configuration, infrastructure-as-code, design documents |
| What you must prepare | Authorisation letter, scope list, contacts | Accounts and roles, documentation, environment access, whitelisting | Repository access, build instructions, read access to cloud consoles, developer contact |
| Time spent on discovery | High (one to three days of a typical engagement) | Low | Minimal |
| Best suited to | Validating what an outsider sees; red-team-adjacent questions | Annual tests, compliance evidence, most web and internal tests | Critical applications, pre-release security review, logic flaws, cryptography |
| Typical risk | Shallow coverage of authenticated functionality | Account provisioning delays eat the window | Access requests through security review take weeks; start early |
Step two: arrange access, environment and protection
These six items account for most lost testing days. Each has an owner in your organisation who is usually not the person who commissioned the test.
Test accounts and roles
Two accounts per role, so the tester can check horizontal privilege separation (user A reading user B's data), plus one account per privilege tier (user, manager, administrator). Accounts must be created, verified as working, and have MFA enrolled or an agreed MFA bypass for the test identity. Name the data in each account realistic but synthetic.
Test versus production environment
The industry debate on this is real. Testing production gives the truest picture of configuration and exposure; testing acceptance protects availability and customer data. The honest answer is that an acceptance environment is only a valid proxy if it is a faithful copy: same code version, same configuration, same integrations, same authentication. If it is not, test production with agreed hours, rate limits and an exclusion list. Decide, document, and tell the tester which it is.
WAF, IDS and rate limiting
Decide whether the tester's source addresses are whitelisted through the web application firewall and intrusion prevention, or whether those controls stay in the path. Whitelisting tests the application; leaving the controls in tests the controls. Most programmes whitelist for the application test and run a short separate exercise against the WAF. Either way, inform the SOC so the tester's traffic is not escalated as an incident, unless detection is explicitly part of the test.
Network access for internal tests
A VPN account with the same network position as a standard employee, or a physical device shipped to the office and plugged into a user-facing port, or a jump host in the target segment. Each has to be requested, approved and tested before day one. Confirm which VLANs the test position can see and whether 802.1X network access control is in scope or bypassed for the test device.
Change freeze on the tested systems
A deployment in the middle of the test window invalidates findings, creates false negatives and wastes retest effort. Agree a freeze on the in-scope systems for the duration of the test, or if that is impossible, a notification protocol so the tester knows what changed and when. Record the version or build identifier tested in the report.
Data handling and confidentiality
Confirm the NDA is signed and covers the testing firm's individual testers. Agree what the tester may do with data encountered: screenshot a sample as evidence, never exfiltrate full records, never copy personal data off the test machine. Agree how the report is delivered (encrypted, to named recipients) and how long the firm retains evidence. Under GDPR Article 28, the testing firm acts as your processor and that needs a processing agreement.
Step three: legal authorisation, in writing, before anyone connects
Unauthorised access to a computer system is a criminal offence in every jurisdiction a penetration tester works in. In the Netherlands it is computervredebreuk under Article 138ab of the Wetboek van Strafrecht; in the United States it is the Computer Fraud and Abuse Act (18 U.S.C. § 1030); in the United Kingdom it is the Computer Misuse Act 1990. The only thing that separates a penetration test from an offence is the owner's consent, and the only form of consent that protects both parties is a written authorisation signed by someone with the authority to grant it.
The authorisation letter (sometimes called a permission-to-test or get-out-of-jail letter) should name the testing firm and the individual testers, list the exact scope by address and hostname, state the testing window, name the client signatory and their role, and confirm the client owns or has the right to authorise testing of every listed asset. That last point catches a common problem: systems hosted by a third party. A cloud provider's customer agreement generally permits testing of your own workloads, but a managed service provider's contract may not, and a SaaS vendor's almost never does without their own consent. Check before you include them.
Keep the signed letter with the tester for the duration of the engagement. For on-site and physical components it should be carried in print. Where an engagement touches systems in several countries, confirm that the authorisation is valid under each jurisdiction's law and that data from the test may lawfully be moved to where the testers analyse it.
Step four: people, contacts and communication
The tester will need a human several times during the engagement. Decide who, and tell them, before it starts.
- A single engagement owner on your side who can make scope decisions during the test and who is reachable during testing hours
- A technical contact per in-scope system (application owner, network engineer, cloud administrator) for access issues and for triage of findings
- An emergency contact with a phone number, available 24 hours if testing is 24 hours, who can authorise stopping the test and who the tester calls if a system becomes unstable or a critical finding is confirmed
- The escalation path for critical findings before the report: the tester should know who hears about a confirmed remote code execution within the hour, and how (phone, encrypted message, ticket)
- A briefing for the SOC, the managed detection and response provider or the MSSP: dates, source IP addresses, test positions, and whether detection is being evaluated or should stand down
- A note to the hosting provider or cloud account owner if their acceptable-use policy requires notification of testing
- An internal communication to the teams whose systems are in scope, so a developer seeing unusual requests in the logs does not start an incident, unless that reaction is itself what you want to measure
- A decision on whether the help desk and HR need to know, which they do if social engineering or physical testing is part of the scope
Day-one readiness: what to have on the table at the kickoff call
The kickoff call, usually 45 to 60 minutes a few days before testing, is where the tester confirms everything above. Walk in with these items complete and the first testing day is a testing day.
- Signed statement of work, NDA or processing agreement, and authorisation letter, with the tester names filled in
- Final scope document: addresses, hostnames, applications per environment, cloud account identifiers, exclusions with reasons
- Test accounts created and verified by logging in once from a clean browser, credentials delivered through the agreed secure channel
- VPN or network access tested end to end, or the test device shipped and confirmed received
- WAF, IDS and rate-limit decisions implemented and verified for the tester's source addresses
- Architecture overview, API specifications (OpenAPI or similar), and for white box the repository access, all shared in advance
- Testing window, hours and change freeze confirmed with the teams that own deployments
- Contact sheet with the engagement owner, technical contacts and emergency contact, including out-of-hours numbers
- Agreed format and cadence for status updates during the test (daily summary, immediate notification of criticals) and the delivery date of the report
What slows a penetration test down, and how HackersHub prevents it
The recurring delays are predictable. Accounts that were created but never tested, so the first login fails on a mandatory password reset nobody can complete. MFA on test accounts with the authenticator enrolled on an employee's phone who is on leave. A VPN that places the tester in a guest segment with no route to the targets. A WAF exception that was requested but not deployed. A scope email that says 'the usual production ranges' from a predecessor who has left. A deployment on day two that changes the authentication flow. Each of these costs between half a day and two days of a window that is typically five to ten.
HackersHub addresses this with a structured pre-engagement phase. After the proposal is signed you receive a scoping questionnaire and a readiness checklist with named owners and dates, followed by a scoping session with the lead tester, who is the same OSCP-certified consultant named in the report. We verify accounts and network access with you two working days before the window opens, so that an access issue is fixed before it costs testing time, not during it. The rules of engagement, test positions, exclusions and contact sheet are written into the statement of work and read back at the kickoff.
During the test you receive a short status note at the end of each testing day and an immediate call for any critical finding. At the end, the report records exactly what was tested, from which positions, at which version, and what was excluded, so that your auditor, your customer or your board can read the scope statement and trust the findings that follow. Preparation is not administration around the test; it is what makes the test's result worth relying on.
Frequently asked questions
Related guides
Ready to scope your penetration test?
Our lead tester runs the scoping session with you, sends the readiness checklist with named owners, and verifies access before the window opens. Talk to an expert.