Business Guide

Preparing Your Organisation for a Penetration Test

> series: business_owners_guide —— part: 06/10 —— topic: preparation —— status: ready_for_engagement<span class="cursor-blink">_</span>_

Hedgehog Security 10 February 2026 10 min read

Preparation is the difference between a smooth engagement and a wasted one.

You have chosen a provider, agreed the scope, and signed the contract. Testing starts in two weeks. What do you need to do between now and then to ensure the engagement runs smoothly, delivers maximum value, and does not catch your team off guard?

The answer is: more than most organisations realise, but less than most organisations fear. Preparation is straightforward once you know what is required. This article provides a practical, step-by-step guide.


Recommended

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

Who needs to know and what do you tell them?

One of the most common sources of disruption during a penetration test is internal confusion. If your IT team does not know testing is happening, they may interpret the tester's activity as a real attack, trigger incident response procedures, block the tester's IP addresses, or reset compromised test accounts — wasting testing time and causing unnecessary alarm.

Stakeholder What to Communicate When
IT Team / IT Manager Full details — testing dates, scope, the provider's source IP addresses (so they are not blocked), emergency contact details for the tester, and what to do if they observe testing activity. Emphasise that the tester should not be blocked or hindered unless specifically requested. At least one week before testing begins. Hold a brief meeting to answer questions.
Senior Management / Board High-level notification — testing is happening, when, and why. Set expectations that vulnerabilities will likely be found (this is the point of the exercise, not a failure). Prepare them for the report and remediation discussion that will follow. Before testing begins. A brief email or agenda item is sufficient.
Managed Service Provider (if applicable) If a third party manages your infrastructure, hosting, or security monitoring, they must be informed. Provide testing dates, source IPs, and scope. They may need to whitelist the tester's IP addresses or adjust alerting thresholds to avoid false alarm escalations. At least one week before testing. Some MSPs require formal notification or a signed authorisation letter.
General Staff For most test types, general staff do not need to know. The exception is social engineering — if phishing simulations or physical access testing is in scope, you must decide whether to inform staff (which reduces realism) or keep it confidential (which is more realistic but may cause concern if discovered). Typically not informed unless social engineering is in scope and you choose a disclosed approach.
Cloud / Hosting Provider AWS, Azure, Google Cloud, and most hosting providers require notification before penetration testing is conducted against systems hosted on their infrastructure. Some require a formal request form. Failure to notify can result in your systems being suspended. At least two weeks before testing. Check your provider's specific notification requirements — AWS requires a penetration testing request form, for example.

What the tester needs from you.

For grey box and white box engagements, the tester will need certain access and information before testing begins. Providing this promptly avoids delays on the first day. For black box engagements, this section may not apply — but even black box tests require some logistical access.

Test Credentials
For web application and internal testing, the tester typically needs user accounts at each privilege level — a standard user, an administrator, and any other roles defined in the application. Create dedicated test accounts rather than sharing real user credentials. This ensures the tester's activity is clearly attributable and real user accounts are not disrupted.
Network Access
For internal testing, the tester needs a connection to your network — either physical (a network port on-site) or remote (VPN access). Ensure this is provisioned and tested before the engagement starts. A tester who spends the first morning troubleshooting VPN connectivity is a tester who is not testing your security.
Documentation
For white box engagements, provide network diagrams, application architecture documents, API documentation, and any other technical documentation available. This does not need to be polished — even informal diagrams and notes help the tester understand your environment and focus their effort effectively.
Emergency Contacts
Provide the tester with a direct contact — someone who can answer questions, escalate issues, and make decisions during the test. If the tester discovers a critical vulnerability, encounters an unexpected system, or inadvertently causes a service disruption, they need someone who can respond quickly.

The agreement that governs the test.

The rules of engagement (RoE) document is a formal agreement between you and the provider that defines the boundaries, permissions, and procedures for the engagement. A professional provider will produce this document as part of the engagement setup. Review it carefully — it is both a protection for you and an authorisation for the tester.

Typical Rules of Engagement Contents
── Scope Definition ───────────────────────────────────────
In-scope IP addresses, domains, and applications
Excluded systems and networks
Testing approach (black/grey/white box)

── Testing Window ─────────────────────────────────────────
Start date and end date
Permitted testing hours
Blackout periods (e.g. month-end processing)

── Permitted Activities ───────────────────────────────────
Exploitation depth — demonstrate or fully exploit?
Social engineering — permitted or excluded?
Denial of service — permitted or excluded?
Data access — can the tester access/exfiltrate data?

── Communication Procedures ───────────────────────────────
Primary contact and emergency contact
Critical finding notification threshold
Daily/weekly status update requirements
Secure communication channel (encrypted email/portal)

── Data Handling ──────────────────────────────────────────
How evidence and findings are stored during the test
Encryption requirements for data in transit and at rest
Data destruction timeline post-engagement
Report distribution restrictions

Written permission is essential.

Before any testing begins, you must provide the penetration testing provider with a signed authorisation letter — sometimes called a 'get out of jail free' letter. This document confirms that you, as the system owner or authorised representative, give explicit permission for the named provider to conduct the agreed testing activities against the specified systems during the specified timeframe.

Without this letter, the tester's activities could technically constitute a criminal offence under the Computer Misuse Act 1990. No reputable provider will begin testing without written authorisation. If a provider does not request one, treat this as a red flag.

Who Can Sign?

The authorisation letter must be signed by someone with the authority to grant permission to test the systems in scope. This is typically a director, CTO, IT director, or equivalent. If the systems are hosted by a third party or owned by a different legal entity, you may need additional authorisation from the hosting provider or system owner. Your penetration testing provider will advise on what is required.


A practical list for the week before.

Task Owner Status
Signed authorisation letter sent to provider Business owner / director Required before testing begins
IT team briefed on testing dates and provider IP addresses IT manager Required before testing begins
Cloud/hosting provider notified IT manager Required before testing begins
Test accounts created and credentials sent securely IT team / application owner Required for grey/white box tests
VPN or network access provisioned and tested IT team / network admin Required for internal tests
Documentation provided (network diagrams, app docs) IT team Required for white box tests
Emergency contact details exchanged Business owner + provider Required for all tests
Rules of engagement reviewed and signed Business owner + provider Required for all tests
MSP / SOC informed (if applicable) IT manager Required if third-party monitoring is in place
Backups verified (for production testing) IT team Recommended for all tests

Part 7 preview.

Everything is in place. Testing is about to begin. Next week, we walk through what actually happens during a penetration test — day by day — so you know exactly what the tester is doing, what to expect, and how to support the process without getting in the way.


Our engagement process is designed to be painless.

We provide authorisation letter templates, pre-engagement checklists, cloud provider notification guides, and a dedicated point of contact who will walk your team through every preparation step. You focus on your business — we handle the logistics.

Next Step

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

Related Articles