> cat /engagements/pre-flight-checklist.md_
Most people picture a penetration test as someone in a dark room typing furiously into a terminal. The reality is far less cinematic — and the most consequential work happens before a single packet is sent.
The pre-engagement phase — scoping, agreeing rules of engagement, documenting assumptions, and aligning on objectives — is where the engagement is won or lost. A brilliantly executed test against the wrong scope is worthless. A mediocre test against a well-defined scope still delivers actionable intelligence. The framing matters more than the tools.
This article walks through everything that happens between "we need a pen test" and the moment testing actually begins — so that when you commission an engagement, you understand what good pre-engagement looks like and can hold your provider to it.
If your pen test provider's first question is "how many IPs do you have?", they're starting with pricing. If their first question is "what are you worried about?", they're starting with risk. The second conversation leads to a better test every time.
Before anything is scoped, a fundamental question needs answering: why are you commissioning this test? The answer determines the type of engagement, the scope, the methodology, the reporting format, and ultimately whether the output is useful or decorative.
This sounds obvious. It isn't. We regularly begin scoping conversations with organisations that haven't articulated what they actually want to learn. "We need a pen test" is a statement of intent, not an objective. Drilling into the why transforms the engagement from a generic assessment into a targeted investigation.
| If the Objective Is... | This Shapes the Engagement By... |
|---|---|
| Satisfy a compliance requirement (PCI DSS, ISO 27001, CE+) | Defining scope strictly around the standard's requirements. Reporting formatted for auditors. Evidence aligned with specific control references. |
| Understand what an external attacker could achieve | Black-box external infrastructure and web application testing. No insider information. Scope is everything internet-facing. Output is an attack narrative. |
| Test a new application before launch | Focused web or mobile application testing, likely grey-box with test accounts and documentation. Tight timeline aligned with the release schedule. |
| Assess internal resilience after a phishing breach | Internal infrastructure test simulating a compromised workstation. Focus on lateral movement, AD security, and path-to-crown-jewels. Social engineering may be combined. |
| Respond to a client or insurer requiring evidence of testing | Scope negotiated to satisfy the third party's requirements. Reporting includes an attestation letter or summary suitable for sharing externally. |
| Validate whether the SOC can detect a real attack | Threat-led testing or red team engagement. Covert, unannounced, with detection metrics as a primary deliverable. Very different scope and rules of engagement. |
The objective also determines who should be involved in the scoping conversation. A compliance-driven test might only need the IT manager. A threat-led assessment might need the CISO, the SOC lead, and someone from the business who understands the crown jewels. Getting the right people in the room early avoids scope gaps and surprises later.
Scoping is the process of agreeing precisely what will be tested, what won't, and why. It's the single most important decision in the entire engagement — because everything downstream flows from it. A well-defined scope leads to focused testing, meaningful findings, and actionable results. A poorly-defined scope leads to wasted effort, missed vulnerabilities, and arguments about what was and wasn't covered.
Scope has two dimensions: breadth (how much of the environment is included) and depth (how thoroughly each element is tested). Budget constraints almost always force a trade-off between the two — and making that trade-off consciously is far better than making it accidentally.
| Scope Element | What Needs to Be Defined | Why It Matters |
|---|---|---|
| Target systems | Specific IP addresses, IP ranges, hostnames, URLs, applications, cloud accounts, wireless SSIDs, or office locations | Ambiguity here is dangerous. "All our servers" is not a scope. 10.0.0.0/24 and portal.acme.co.uk is a scope. |
| Exclusions | Systems, networks, or applications that must not be tested — third-party hosted services, production databases during business hours, specific IP ranges owned by partners | If you don't explicitly exclude it and it's reachable, a thorough tester may probe it. Exclusions protect sensitive systems and prevent unintended impact. |
| Test type | External infrastructure, internal infrastructure, web application, mobile, cloud, wireless, social engineering — or a combination | Each type requires different skills, tools, and time. Combining types in a single engagement is efficient but must be scoped carefully to avoid shallow coverage. |
| Approach | Black box (no information provided), grey box (credentials and documentation shared), or white box (full access including source code) | The approach affects both the realism and the depth of testing. Black box is more realistic; grey/white box finds more vulnerabilities per day of testing. |
| Environments | Production, staging, development, or a dedicated test environment. Each has different risk profiles and constraints. | Testing in production is most realistic but carries risk. Testing in staging avoids disruption but may miss production-specific configurations. This must be agreed upfront. |
| Credentials | For grey/white box tests: how many test accounts, at what privilege levels, in which applications or systems | Providing a standard user account and an admin account allows the tester to check both vertical and horizontal privilege escalation — doubling the coverage of access control testing. |
| Timing | Testing window (dates and times), business hours vs out-of-hours, time zone, blackout periods (month-end, peak trading, etc.) | Testing during peak hours carries more disruption risk. Testing only out-of-hours may miss issues that are only present when the full user population is active. |
Rules of engagement (RoE) are the operating boundaries for the test — the agreed constraints within which the tester works. They define what the tester is permitted to do, what they must avoid, how communication works during the engagement, and what happens if something goes wrong.
The RoE exist to protect both parties. They protect the client by ensuring testing doesn't cause unacceptable disruption. They protect the tester by providing explicit written authorisation for activities that, without permission, would be criminal offences under the Computer Misuse Act 1990.
A properly documented set of rules of engagement covers the following:
| RoE Element | What It Covers | Example |
|---|---|---|
| Authorisation | Written permission from someone with authority to authorise testing. Confirms the client owns or has rights to test the target systems. | A signed letter from the IT Director confirming authorisation to test the specified IP ranges and applications during the agreed window. |
| Permitted activities | Which techniques and tools the tester is allowed to use. Vulnerability scanning, exploitation, credential brute-forcing, social engineering, physical access, etc. | "Exploitation of discovered vulnerabilities is permitted. Brute-force attacks are permitted against test accounts only. Denial-of-service testing is not permitted." |
| Prohibited activities | Hard boundaries the tester must not cross. Typically includes DoS against production, data destruction, modification of live data, and access to specific out-of-scope systems. | "The tester must not modify, delete, or exfiltrate any real customer data. Testing must not cause service disruption to production systems." |
| Communication | Points of contact, escalation procedures, status update frequency, and the process for reporting critical findings in real time. | "Primary contact: Jane Smith (CISO). Emergency contact: NOC on-call (24/7). Critical findings reported by phone within 1 hour of discovery." |
| Critical finding protocol | What happens if the tester discovers a vulnerability so severe that waiting until the final report would be irresponsible. | "Any finding rated Critical (CVSS 9.0+) or any evidence of active compromise by a third party will be reported immediately to the primary contact by phone, followed by a written advisory within 4 hours." |
| Evidence handling | How test data, screenshots, credentials, and other sensitive evidence will be stored, transmitted, and destroyed. | "All evidence encrypted at rest (AES-256) and in transit (TLS 1.2+). Evidence retained for 30 days after report delivery, then securely destroyed. No client data stored on tester personal devices." |
| Legal framework | Jurisdiction, liability limitations, NDA provisions, and confirmation that testing is authorised under the Computer Misuse Act 1990. | "This engagement is authorised under Section 1 of the Computer Misuse Act 1990 by the undersigned, who has the legal authority to grant such permission." |
| Third-party notification | Whether cloud providers, hosting companies, or ISPs need to be notified that testing will occur. | "AWS penetration testing policy does not require pre-approval for tests against owned accounts. The client's hosting provider (Rackspace) has been notified and has acknowledged the testing window." |
A reputable pen test provider will never begin testing without signed written authorisation. If your provider starts testing before paperwork is complete, that's a serious red flag — not just operationally, but legally. Without explicit authorisation, the tester is committing offences under the Computer Misuse Act. This protects you as much as it protects them.
Every penetration test rests on a set of assumptions — about the environment, the threat model, the scope boundaries, and the expected conditions during testing. These assumptions are rarely written down, and when they turn out to be wrong, the test delivers the wrong answers.
Documenting assumptions explicitly — and validating them before testing begins — is the single most underrated step in the pre-engagement process. It's also the one most frequently skipped.
Here are the assumptions that most commonly go wrong, and what happens when they do:
| Assumption | When It's Wrong | The Consequence |
|---|---|---|
| "The staging environment mirrors production" | Staging is two releases behind, uses different authentication, has no WAF, and contains a subset of test data rather than representative real data. | Findings from staging don't translate to production. Vulnerabilities in the production release aren't found. The WAF — which may block (or allow) certain attacks — isn't tested. |
| "We've provided all the IP ranges" | Three forgotten subnets, a legacy /28 from a previous ISP, and a cloud-hosted staging environment weren't included because nobody remembered they existed. | The test covers the known estate. The attacker targets the unknown estate — the forgotten systems that are almost certainly the least patched and least monitored. |
| "The test accounts will be ready on day one" | Test credentials aren't provisioned until day three. The tester spends two days on black-box reconnaissance that should have been one day, and loses two days of authenticated testing. | Reduced authenticated test coverage. The web application's access control model — often where the most critical findings live — gets abbreviated or incomplete testing. |
| "Our WAF / IPS won't interfere with testing" | The WAF aggressively blocks scanning and exploitation attempts. The tester's source IP gets blocklisted on day one. Nobody told the SOC that testing was happening. | The tester wastes time fighting defensive controls rather than testing the application. Alternatively, the SOC responds to the pen test as a real incident, consuming their resources unnecessarily. |
| "The VPN / remote access will work" | For internal tests: the VPN connection drops intermittently, the firewall blocks certain test traffic, or the tester's VM is quarantined by NAC on connection. | Days lost to connectivity troubleshooting instead of testing. The engagement overruns or delivers reduced coverage. In the worst case, testing is postponed entirely. |
| "Nothing has changed since the last test" | A new application was deployed, a cloud migration completed, and three developers pushed code without security review — all since the previous assessment. | The test is scoped against last year's environment. This year's attack surface — which includes all the new, untested components — isn't covered. |
| "We own all the systems in the scope" | Two of the IP addresses in the provided range belong to a co-hosted client, a shared service provider, or a previous tenant. | The tester attacks systems that don't belong to you. This is a legal, reputational, and operational disaster — and it happens more often than anyone admits. |
The fix is simple: write your assumptions down. Share them with the testing provider before the engagement starts. Validate them together. If any assumption turns out to be wrong during testing, communicate immediately and adjust the scope or timeline accordingly.
All of the above — objectives, scope, rules of engagement, assumptions — is formalised in a Statement of Work (SoW). This is the contract between you and the testing provider, and it's the document you'll refer back to if there's ever a dispute about what was and wasn't covered.
A good SoW is specific, complete, and readable. It shouldn't require a lawyer to interpret. Every element that matters to the engagement should be documented — because if it isn't in the SoW, it isn't agreed.
| SoW Section | What It Should Contain |
|---|---|
| Engagement overview | Client name, engagement type (external/internal/web app/etc.), high-level objective, testing methodology (OWASP, PTES, OSSTMM), and CREST/CHECK accreditation reference if applicable |
| Scope definition | Complete, unambiguous list of in-scope targets. Explicit list of exclusions. Environment details (production/staging). Approach (black/grey/white box). |
| Testing window | Start and end dates, permitted testing hours, time zone, blackout periods. Duration in tester-days. |
| Rules of engagement | Permitted and prohibited activities, communication protocols, critical finding procedure, evidence handling. |
| Assumptions and prerequisites | Everything that needs to be true for the test to proceed as planned. Credentials, connectivity, environment readiness, third-party notifications. |
| Deliverables | What the client receives: technical report, executive summary, risk heat map, remediation tracker, debrief presentation. Delivery timeline (e.g. report within 5 business days). |
| Retest policy | Whether remediation retesting is included, how many retest cycles, the window for retesting, and any conditions (e.g. retest within 30 days of report delivery). |
| Commercial terms | Total cost, payment terms, what happens if the engagement overruns due to client-side delays, cancellation policy. |
If a provider is willing to start testing without a signed Statement of Work, walk away. The SoW protects you. It defines what you're paying for, what's in scope, and what the deliverables are. Without one, there's no accountability — and if something goes wrong during testing, there's no reference document to fall back on.
The testing provider prepares their tools and methodology. But there's a set of actions on your side that, if not completed before the engagement starts, will reduce the quality, coverage, or efficiency of the test.
We've conducted hundreds of engagements. The pattern of pre-engagement failures is remarkably consistent — and almost always avoidable with basic preparation.
| Failure | How Often We See It | Impact |
|---|---|---|
| Test credentials not ready on day one | ~40% of engagements | Lost testing time. Authenticated testing starts late. Coverage of access control and business logic is reduced. |
| SOC not notified — tester's IP blocked within hours | ~25% of engagements | Testing halted while the blocklist is cleared. SOC resources consumed responding to a "false" incident. Trust eroded on both sides. |
| VPN / remote access doesn't work as expected | ~30% of internal tests | Hours or days lost to troubleshooting. In the worst case, testing is postponed. On-site travel may need rescheduling. |
| Scope includes systems the client doesn't own | ~10% of engagements | Testing must stop immediately when this is discovered. Legal and reputational risk. Scope must be revised and re-authorised. |
| Staging environment is significantly different from production | ~50% of web app tests | Findings may not apply to production. Critical production-only vulnerabilities are missed. The test provides false assurance. |
| No named contact available during testing | ~15% of engagements | Critical findings can't be reported in real time. Blocklist issues can't be resolved. Questions about scope go unanswered. |
Every one of these is preventable. The assumptions checklist above covers most of them. The rest are solved by basic project management — assigning a named internal contact, validating prerequisites a week before testing, and treating the pen test as a project rather than a thing that happens to you.
Here's a realistic timeline for a well-managed engagement. The exact durations vary, but the sequence is consistent:
| When | What Happens | Who's Involved |
|---|---|---|
| Week 1 | Initial enquiry and scoping call. Understand objectives, discuss approach, agree high-level scope. | Client IT lead / CISO + testing provider |
| Week 1–2 | Provider prepares and delivers the Statement of Work. Client reviews, requests amendments, signs. | Client procurement / legal + testing provider |
| Week 2–3 | Pre-engagement call. Walk through scope, validate assumptions, confirm prerequisites, schedule the testing window. | Client IT / app team + testing provider + SOC lead (if applicable) |
| Week 3 | Client prepares: provisions credentials, notifies SOC, verifies connectivity, confirms backups, briefs stakeholders. | Client IT / app team |
| Week 3–4 | Testing begins. Daily status updates (if agreed). Critical findings reported immediately. | Testing team + client primary contact |
| Week 5 | Report delivered (typically within 5 business days of test completion). Debrief call scheduled. | Testing provider + client stakeholders |
| Week 6+ | Client remediates findings. Retest of fixed vulnerabilities. Updated report issued confirming closures. | Client IT / dev team + testing provider |
Total lead time from first enquiry to test start: typically 2–4 weeks. Rushing this process — skipping the scoping call, starting without credentials, testing without SOC notification — saves days but costs coverage. It's never worth it.
The most important phase of a penetration test is the phase that happens before any testing begins. Defining the objective, agreeing the scope, documenting rules of engagement, and validating assumptions isn't administrative overhead — it's the foundation that determines whether the engagement delivers genuine insight or just produces a report.
A well-scoped test against the right targets, with the right approach, under the right conditions, will always outperform a hastily scoped test that covers more ground but tests nothing thoroughly. Quality of scope beats quantity of scope, every time.
And if your provider doesn't invest time in this phase — if they jump straight from "how many IPs?" to a quote — they're selling you a commodity, not a service. The pre-engagement conversation is where you find out whether your provider understands your business, your risk, and your objectives. If they don't ask the hard questions before testing, they won't find the hard answers during it.
Every engagement begins with a free scoping call. We ask the questions that matter, define the scope around your actual risk, and provide a clear Statement of Work before any testing begins.