> engagement_status: T-minus_7_days —— preparation: in_progress —— checklist: loading<span class="cursor-blink">_</span>_
You have commissioned a penetration test, agreed the scope, and signed the contract. Testing starts soon. What happens between now and then determines whether the engagement runs smoothly or whether the first day is spent troubleshooting access issues while your testing time ticks away.
Most preparation tasks are straightforward and take minutes to complete. The challenge is not difficulty — it is remembering to do them all. This article provides a practical, step-by-step checklist that ensures nothing is missed.
Want to know if your environment has the same weakness? Book a free 30-minute scoping call.
Book a Scoping Call| Task | Detail | Owner |
|---|---|---|
| Sign and return the authorisation letter | The provider needs written confirmation that you authorise testing against the specified systems during the agreed timeframe. Without this, testing cannot begin. The letter must be signed by someone with the authority to grant permission — typically a director, CTO, or IT director. | Director / CTO |
| Notify your cloud or hosting provider | AWS, Azure, Google Cloud, and most hosting providers require advance notification before penetration testing. Some require a formal request form. Failure to notify can result in your services being suspended when the provider's abuse detection triggers on testing activity. | IT Manager |
| Notify your managed service provider or SOC | If a third party monitors your infrastructure or provides managed security services, they must be informed. Provide the testing dates, the provider's source IP addresses, and instructions not to block or interfere with testing activity. An overzealous SOC that blocks the tester mid-engagement wastes your testing time. | IT Manager |
| Review and agree the rules of engagement | The rules of engagement document defines the boundaries of the test — what is in scope, what is excluded, testing hours, communication procedures, and escalation paths. Read it carefully and ensure you are comfortable with every clause. | Business Owner / IT Manager |
| Task | Detail | Owner |
|---|---|---|
| Brief your IT team | Inform your IT team of the testing dates, the scope, and the provider's source IP addresses. Emphasise that testing activity should not be blocked. Provide emergency contact details for the tester in case the team observes activity they are concerned about. | IT Manager |
| Create test accounts | For grey box and white box engagements, create dedicated test accounts at each required privilege level. Do not share real user credentials. Label accounts clearly (e.g., 'pentest-user', 'pentest-admin') so activity is easily attributable in logs. | IT Team / App Owner |
| Provision network access | For internal testing, provision VPN access or arrange for an on-site network port. Test the connection before the engagement starts — a tester who arrives on-site to find their network port is not patched or their VPN credentials are expired loses valuable testing time. | Network Admin |
| Provide documentation | For white box testing, share relevant documentation — network diagrams, application architecture, API specifications, user guides. The documentation does not need to be polished; even informal diagrams help the tester understand your environment quickly. | IT Team |
| Verify backups | Although service disruption during testing is rare, it is good practice to verify that current backups exist for systems in scope. This is a sensible precaution, not an indication that testing is dangerous. | IT Team |
| Exchange emergency contacts | Provide the tester with a direct mobile number for someone who can make decisions during the engagement. Obtain the tester's direct contact details in return. This is essential for critical finding notifications and issue resolution. | Business Owner / IT Manager |
| Mistake | Impact | Prevention |
|---|---|---|
| Not informing the IT team | IT team detects 'suspicious activity', triggers incident response, blocks the tester's IPs, and potentially causes organisational alarm. Testing time wasted. | Brief your IT team at least one week before testing begins. Provide the tester's source IP addresses. |
| Not notifying the cloud provider | Cloud provider detects testing activity, suspends your services. You lose both testing time and service availability. | Submit notification forms to your cloud provider at least two weeks before testing. |
| Test credentials not working on day one | Tester spends the first morning troubleshooting access instead of testing. A full day of testing can be lost to credential issues. | Create test accounts at least three days early. Log in with each account to verify they work. Do not let passwords expire before the test. |
| VPN access not provisioned | Internal testing cannot begin until remote access is working. If the tester is remote and cannot connect to your network, the entire engagement stalls. | Provision and test VPN access before the engagement begins. Have your network administrator confirm connectivity. |
Preparation for a penetration test is straightforward if you follow a checklist and complete each item on time. The tasks are not complex, but missing any one of them can cost you valuable testing time. Complete the two-week-out tasks first, then the one-week-out tasks, and you will be ready for a smooth, productive engagement.
We provide authorisation letter templates, cloud provider notification guides, pre-test checklists, and a dedicated engagement manager who walks your team through every step. Preparation should not be stressful — and with us, it is not.
Want to know if your environment has the same weakness? Book a free 30-minute scoping call.
Book a Scoping Call