Most buyers see two documents from a penetration test: the quote and the report. The plan in between does more to decide the outcome than either of them, and it’s the one hardly anybody asks to read.
This is the first part of our series on what happens inside a penetration test, stage by stage, from the tester’s side of the table. The methodology behind the stages is set out in our guide to penetration testing methodology, which is the hub for the series. The buyer’s side of scoping (the quote, the preparation, the contract) has its own posts, starting with what a penetration test costs.
By the end of this part you should be able to read a test plan and spot the five gaps that most often turn a test into an expensive scan.
What Goes Into a Penetration Test Plan
A penetration test plan has five working parts, plus the signed permission that lets testing begin. Most of them come straight from the Penetration Testing Execution Standard (PTES), whose Pre-engagement (opens in a new tab) section (last edited 16 August 2014) and Threat Modeling (opens in a new tab) section (last edited 7 December 2015) describe the tester’s preparation in detail.
| Part of the plan | What the tester builds | PTES section | What you check |
|---|---|---|---|
| Goal | The business outcome the test is meant to prove or disprove | Pre-engagement, Goals | It’s your worst case, not “pass the audit” |
| Threat model | Your valuable assets, the processes around them, the likely attackers and what they can do | Threat Modeling | It names things you’d recognise, not just IP addresses |
| Target list | Every system in scope, confirmed as yours, with third parties identified | Pre-engagement, Specify IP Ranges and Domains; Dealing with Third Parties | Nothing is hosted by someone who hasn’t agreed |
| Rules of engagement | How testing runs: timings, limits, what happens after a break-in, how data is handled | Pre-engagement, Rules of Engagement | The awkward decisions are written down, not left to the day |
| Communication plan | Who is called, how, and how often | Pre-engagement, Emergency Contact Information | Someone can always be reached |
| Permission to test | The signed document that authorises the activity | Pre-engagement, Permission to Test | It’s signed before anything starts |
The PTES pages are more than a decade old and written with a US reader in mind, so read them for structure rather than for legal detail. The shape of the plan hasn’t changed much since.
What You Need Before Reading the Plan
To review a test plan properly you need four things to hand, and about an hour.
- Your notes from the scoping call, so you can compare what you asked for with what was planned.
- The quote or statement of work, so the plan and the paperwork describe the same test. Our post on comparing penetration testing quotes covers what the quote itself should say.
- A short list of what matters most to your business: the systems, data and processes you’d least like to lose.
- The name of someone who can make decisions during the test, including stopping it.
No technical background is assumed. If you can explain what your business would least like to lose, you can review a test plan. The practical to-do list (access, accounts, backups) is in our guide to preparing for a penetration test.
Step 1: Check the Plan Starts From a Business Goal
The plan’s first line should say what the test is for, in business terms. PTES is blunt about it: “Every penetration test should be goal-oriented.” It goes on to say the primary goal should not be driven by compliance, because compliance does not equal security.
That doesn’t make a compliance test wrong. Plenty of tests exist because a standard requires one. PTES treats compliance as the secondary goal and the business impact as the primary one: getting to the card data matters for the audit, but what it means for the business is what gets management’s attention.
A useful goal reads something like “Can someone outside the company reach customer payment records?” A weak one reads “Annual penetration test.”
PTES suggests asking a business manager what data “would create the greatest risk to the organization if exposed, corrupted, or deleted”. If nobody asked you that question, the plan is probably working without a goal.
Mistake this prevents: a test that ends with a clean report and no answer to the question the board actually had.
Step 2: Check the Threat Model Names Assets and Attackers
A threat model is the tester’s picture of what an attacker would want from you and how they’d go about getting it. PTES says it rests on two sides, your assets and your likely attackers, split into four elements: business assets, business processes, threat communities and their capabilities. Its instruction is plain: “As a minimum, all four elements should be clearly identified and documented in every penetration test.”
PTES sets out the process in four steps:
- Gather the relevant documentation.
- Identify and categorise primary and secondary assets.
- Identify and categorise threats and threat communities.
- Map the threat communities against the assets.
The secondary assets are where it earns its keep. PTES gives the example of a customer relationship management (CRM) application in scope whose database server also holds the HR database. The customer data is the obvious target. The HR data is the one an attacker reaches next, and once it’s on the map, attackers who looked irrelevant to a CRM system suddenly aren’t.
Think of it the way a football manager watches the opposition before a match. You don’t plan for “eleven players”. You plan for their left winger, and for what happens when he gets past your full back.
There’s one wrinkle in the order. In PTES, threat modelling comes after intelligence gathering, which is the next part of this series. PTES also says the model should be built with the organisation being tested wherever possible, and even in a test where the tester is told nothing, they should build one from an attacker’s view combined with public information. In practice, the first draft is written with you at the planning stage and sharpened once reconnaissance shows what’s actually exposed.
PTES also says the model should be documented and delivered with the final report, so that findings can be ranked against your risks rather than a generic score. Ask to see it early.
Mistake this prevents: a plan that’s really an inventory. PTES’s own phrase for what a threat model avoids is “an inventory list of IT elements”.
Step 3: Check Every Target Has Been Validated as Yours
Every system in the plan should be confirmed as belonging to you, or covered by permission from whoever does own it. PTES tells testers to validate ranges before attacking anything, and warns of the consequences of breaking into a machine that turns out to belong to someone else.
The third parties are where plans most often slip. PTES puts the principle simply: the client can grant permission, but they do not speak for their third party providers. Cloud platforms, hosting companies and managed security providers may each need to agree separately, and some cloud providers have their own request forms and schedules for testing.
The plan should also say whether the equipment between the tester and the target (firewalls, intrusion prevention, web application firewalls) is part of the test or just in the way. PTES treats that as a scoping decision in its own right.
Our post on penetration testing contract terms covers third-party permission from the contract side.
Mistake this prevents: a hosted system dropped from scope on the first morning because nobody asked the hosting company.
Step 4: Check the Rules of Engagement Say How, Not Just What
The scope says what gets tested. The rules of engagement say how. PTES keeps them deliberately separate: “While the scope defines what will be tested, the rules of engagement defines how that testing is to occur.”
The rules are where the awkward decisions live, and a good plan makes them in advance rather than on the phone at 11pm.
| Decision | The question the rules should answer |
|---|---|
| Timing | Which days and hours can testing run, and are there dates to avoid, such as month-end? |
| After a break-in | If the tester gets into a system, do they stop, look around, or try for administrator rights? |
| Password attacks | Can captured password hashes be cracked, and how hard should the tester try? |
| Sensitive data | How does the tester prove access to personal data without copying it? |
| Blocking | If your security tools start blocking the tester, do they carry on or get allow-listed? |
| Fragile systems | Which systems are known to fall over, and how are they handled? |
| Service disruption | Is any denial-of-service testing in scope, and if so, where? |
Most of those questions come directly from PTES’s own scoping questionnaires. On sensitive data it takes the sensible line that a tester can prove the vault door opened without taking the money: a screenshot of a database structure or file permissions rather than the records themselves. On denial of service, it says stress testing, where availability matters, should run in a non-production environment identical to live.
Blocking is the one people forget. PTES points out that if the test is meant to measure your security team as well as your technology, blocking the tester is fair game. If it isn’t, it just wastes the days you’re paying for.
Mistake this prevents: a tester who finds administrator access on day two and either stops dead or goes much further than you’d have agreed.
Step 5: Check Who Gets Called, and When
The plan should name who is called in an emergency, how, and how often everyone talks during the test. PTES recommends an emergency contact list with two forms of round-the-clock contact for each person, covering the testers, their manager, two technical contacts at your organisation and one senior business contact.
The National Cyber Security Centre’s guidance on penetration testing (opens in a new tab) makes the same point from the buyer’s side: “During the test phase, you should ensure that a technical point of contact is available at all times.” CREST’s A Guide to Penetration Testing (opens in a new tab) (December 2022) adds that “On-going communication during tests can take the form of regular updates, which are supported by alerts if a serious vulnerability has been discovered.”
The plan should also say who inside your organisation knows the test is happening. PTES notes that someone at the target needs to know when testing runs, so the incident response team doesn’t wake senior management in the middle of the night thinking it’s under attack.
And the permission to test. PTES calls it one of the most important documents in the engagement: “It is critical that testing does not begin until this document is signed by the customer.” Who can sign it for your organisation is a legal question, so check it with your own adviser.
Mistake this prevents: a critical finding on a Friday afternoon with nobody to tell.
Check Your Work
You’ve read the plan properly if you can answer these six questions from it without asking anyone:
- What is the test trying to prove?
- Which two or three assets matter most, and who would want them?
- Is every target yours, or covered by a named third party’s permission?
- What does the tester do after a successful break-in?
- Who gets called if something critical turns up, and how?
- Is the permission to test signed?
If any answer is “it’s probably in the quote”, it isn’t in the plan.
When a Penetration Test Plan Goes Wrong
Most test plan problems show up later as a complaint about the test itself. Working backwards from the symptom usually leads to a gap in the plan.
| What you notice | Likely gap in the plan | What to ask for next time |
|---|---|---|
| “The report is mostly things a scanner would find.” | No goal and no threat model, so testing had nothing to aim at | A written goal and threat model before testing |
| “Our security team spent a night chasing an attack that was the test.” | Nobody inside was told when testing would run | A named person who knows the schedule |
| “The tester stopped once our firewall blocked them.” | No decision on blocking | A rule on blocking in the rules of engagement |
| “A cloud system was dropped on the first day.” | Third-party permission not sought | Permission from each provider at planning |
| “They got admin access and did nothing with it.” | No post-compromise rules | A written decision on what happens after a break-in |
| “Nobody could reach us when they found something serious.” | No emergency contact list | Names, two contact routes each, and an escalation path |
If the first row sounds familiar, our post on the difference between a vulnerability scan and a penetration test explains why it matters.
Practise on an Illustrative Plan Extract
The extract below is illustrative only. It isn’t from a real engagement or a 2-sec document. It was written for this exercise, with three gaps left in on purpose.
Client: an online retailer. Goal: annual external penetration test. Targets: the company website, the customer login portal and the payment page, all hosted with a cloud provider. Testing window: Monday to Friday, 9am to 5pm, week commencing 3 March. Contact: the IT manager, by email.
Before reading on, find the three gaps.
The answers. First, the goal is a calendar entry, not a business question (Step 1). Something like “Can an outsider reach stored customer or payment data?” would give the test a target. Second, the targets sit with a cloud provider, and nothing says the provider’s testing rules have been checked (Step 3). Third, one contact by email is not an emergency plan (Step 5). A stretch question: what happens if the tester gets into the customer portal as an administrator? The extract doesn’t say, which is a Step 4 gap.
What Comes Next in the Inside a Penetration Test Series
This part covered the plan. The rest of the series follows the test through each stage, in the order the tester works:
- The test plan (this post)
- Reconnaissance, where your public footprint does the talking
- Enumeration and vulnerability analysis
- Exploitation
- Post-exploitation and lateral movement
- Writing the report
- Remediation and the retest
Next is reconnaissance, which is where the threat model from Step 2 meets what an attacker can actually see about you from outside. For the whole method on one page, start at the series hub. If this is your first test, our view on how big your first penetration test should be is a sensible companion.
Penetration Test Plan FAQs
What Is a Penetration Test Plan?
A penetration test plan is the tester’s working document for an engagement. It records the goal, the threat model, the validated targets, the rules of engagement and the communication arrangements, and it’s built after the scoping call and before any testing starts.
What Is the Difference Between Scope and Rules of Engagement?
Scope defines what will be tested: the systems, applications and locations. Rules of engagement define how testing is carried out: timings, limits, what happens after a break-in, how data is handled and who is contacted. PTES treats them as separate, and a good plan covers both.
Is Threat Modelling Part of a Penetration Test?
Yes. PTES treats threat modelling as a stage of every penetration test and says four elements should be documented as a minimum: business assets, business processes, threat communities and their capabilities. The threat model is what lets findings be ranked against your actual risks.
Should You See the Test Plan Before Testing Starts?
Yes. The goal, threat model and rules of engagement are decisions about your business, so you should agree them before testing starts. PTES says the threat model should be built with the organisation wherever possible.
Read the Plan Before the Test, Not the Report After
Before your next test, ask for the plan in writing and check it against the six questions above. If the goal is a date and the threat model is a list of IP addresses, say so before anybody starts.
I say this as someone whose plan for the garden has been “next weekend” since April, so I’m in no position to lecture anyone on planning. But a penetration test without a plan is just a scan with better manners.
If you’d like us to read through a test plan, yours or ours, and tell you what it’s missing, do get in touch.
The scope says what gets tested. The plan says whether it was worth testing.