Why a Weak Penetration Testing Scope of Work Costs You Later

Most disputes over a penetration test have nothing to do with the testing itself. They come from a penetration testing scope of work that was too thin. It couldn’t answer a simple question: did the test cover what the client thought it covered? A scope of work should make that question impossible to ask. It spells out the target systems, the access level and the timing. It also spells out the exclusions and what lands in your inbox when it’s finished.

Write it properly and the test becomes a clear, defensible piece of assurance. Write it loosely, or let a provider write it for you without much input, and gaps creep in. Those gaps usually only surface once something in them gets breached.

What a Penetration Testing Scope of Work Actually Is

Strip away the legal language and a scope of work answers five questions: what’s being tested, how thoroughly, when, by whom, and what you get at the end. It sits alongside your commercial proposal. Once both sides sign it, it becomes the yardstick for whether the engagement delivered what was promised.

The National Cyber Security Centre frames good scoping as a three-way conversation. Its guidance on penetration testing calls for input from risk owners, technical staff and the testers themselves. Risk owners know what actually matters to the business. Technical staff understand the real system boundaries. Testers can judge what’s needed for complete visibility of the target. Skip any one voice and the resulting scope tends to reflect whoever was left in the room.

Why Vague Scoping Costs More Than It Saves

A one-line scope, “test our external systems”, feels efficient. It rarely is. Testers left to interpret a vague brief will make reasonable assumptions, and reasonable assumptions from two different people rarely match. The client assumes the mobile app was covered because it’s technically external. The tester assumes it wasn’t, because nobody named it, and mobile apps need different tooling anyway.

Neither side is wrong. The scope simply never settled the question. That’s exactly the kind of gap that shows up during a board review after an incident, not before one.

The Seven Things a Proper Scope of Work Should Pin Down

Once you move past “test everything”, a good scope of work needs to cover seven areas properly.

Target systems. Every IP range, domain, application and cloud account that’s in scope, named specifically rather than described loosely.

Access level. Whether the test runs with no prior knowledge, partial knowledge, or full visibility into source code and architecture. This single decision changes cost, duration and depth more than almost anything else in the document. We’ve covered how to choose between them in our separate guide to black box vs white box testing.

Timing. Start and end dates, permitted testing hours, and any periods where testing simply can’t happen: month-end finance runs, a product launch, seasonal trading peaks.

Exclusions. Third-party systems you don’t own, anything where an outage would cause real harm, and denial-of-service testing unless you’ve specifically asked for it and understand the risk.

Deliverables. A named list: technical report, executive summary, a findings spreadsheet for tracking fixes. Decide this before the test, not after the report arrives and turns out to be the wrong format for your board.

Retesting. Whether a retest of fixed issues is included in the price, and the window in which it can happen. This is one of the most common sources of a second, unplanned invoice.

Escalation. Named contacts on both sides for anything urgent, including what happens if testers stumble onto evidence of an active, unrelated compromise.

Scope of Work and Rules of Engagement Are Not the Same Document

These two get merged in people’s heads constantly, but they’re not the same thing. The scope of work is the contract: what’s being tested and what you’ll receive. The rules of engagement is the operating manual underneath it. It covers the permitted techniques, the tester’s source IP addresses, the stop conditions, and the exact escalation chain if something needs an immediate decision mid-test.

You need both, written separately, and they should never quietly contradict each other. CREST’s own guidance exists partly because so many engagement disputes trace back to one of these two documents being thin. Its procurement and implementation guidance sets a minimum bar for how a penetration testing scope of work should be delivered and signed off. That way both sides start from the same expectations.

What Happens When Scoping Is Rushed

A rushed scope tends to fail in one of a few predictable ways. Testing runs out of days halfway through a system nobody prioritised, because everything was in scope and nothing was ranked. A legacy system gets tested and falls over, because it was reachable and nobody thought to name it as an exclusion. A report lands that satisfies a compliance tick box but says nothing useful to the board, because deliverables were never specified. Then, weeks later, someone asks for a retest and discovers it was never included in the price.

None of this reflects badly on the testers. It reflects a scope that never forced anyone to make the decisions upfront. Those decisions got made by default instead, usually in whatever direction suited the person under time pressure that week.

Who Needs to Sign Off the Scope Before Testing Starts

NCSC’s position is clear on this: scoping works best with risk owners, technical staff and the testing provider all involved, not just one of them handed the pen. A technical team working alone can write a scope that’s accurate but misses a business-critical system nobody flagged. Procurement working alone can write a scope shaped entirely by budget, with test types trimmed to fit a number rather than a risk.

The scope of work also gives your testers legal authorisation to do what they’re about to do. Testing a system without clear, signed permission can meet the definition of an offence under the Computer Misuse Act. We go into that in more detail in is penetration testing legal in the UK. That’s one more reason the scope needs proper sign-off, not a quick nod over email.

Frequently Asked Questions

What’s the difference between a scope of work and a quote?

A quote is the price. A penetration testing scope of work is what that price actually buys: the assets covered, the access level, the deliverables and the exclusions. Without a matching scope of work, a quote tells you almost nothing.

Can you add systems to the scope after signing?

Yes, through a formal change request rather than an email thread. This protects both sides if the addition changes the price, the timeline, or what the final report is entitled to claim it covers.

Who decides what’s excluded from testing?

You do, with input from the provider on what an exclusion actually means for the test’s value. A system excluded because it’s fragile is a reasonable business call. A system excluded because nobody mentioned it is a gap.

Does every penetration test need a fresh scope of work?

Yes, even for an annual retest of systems that seem unchanged. New applications go live, old ones get retired, and infrastructure shifts more in a year than most people assume. A penetration testing scope of work written twelve months ago is a starting point for the conversation, not a document to reuse as is.

How much detail is too much detail in a scope of work?

In practice, there’s no such thing. A precise scope of work protects you if a dispute ever arises about what was or wasn’t tested. The risk sits entirely on the side of being too vague, not too thorough.

Getting Your Scope Right Before You Sign

A penetration testing scope of work is worth getting right the first time, because a weak one is expensive in ways that only show up later. If you’re preparing to commission a test, Aardwolf Security’s penetration testing team will work through your systems and objectives with you and build a scope that actually holds up. Contact us to talk through what needs covering before you sign anything.