A Pen Test Scoped to Pass an Audit Only Tells You About the Audit

The scope of a compliance-driven penetration test is written by a control framework. The scope of a security-driven penetration test is written by a threat model. These produce different asset lists, different test depths and different reports, and the difference is not a matter of quality. It is a matter of which question was asked.

Both are legitimate pieces of work. The failure happens when an organisation commissions the first, files the result as an answer to the second, and is then surprised when an incident arrives through a system nobody looked at.

The framework decides what counts as in scope

Read the control text rather than the vendor summary and this becomes obvious. A cardholder data environment is defined by where card data is stored, processed or transmitted. An ISO 27001 scope is bounded by the statement of applicability you declared. A SOC 2 examination covers the systems supporting the trust services criteria you selected. Every one of these draws a boundary, and the boundary exists to make the assessment finite and repeatable, which is a reasonable decision for an audit.

An attacker does not accept the boundary. The interesting property of a segmented environment is not the segment, it is the thing with a foot on both sides: the jump host, the backup agent installed everywhere, the monitoring collector with read access to all of it, the identity provider that authenticates the in-scope and out-of-scope estate alike. Those systems are frequently classified as connected-to rather than in-scope, and connected-to systems get a lighter touch or a documented exclusion.

So the compliance test does what it was paid to do. It examines the declared environment thoroughly and does not examine the marketing site on a legacy host that happens to share a directory service with that environment. The report is accurate. The inference the board draws from it is not.

Where the two scopes actually diverge

The divergence is systematic rather than random, which means you can predict it before commissioning anything.

Decision	Audit-driven scope	Threat-driven scope
Asset selection	Systems named by the control text	Systems reachable from an initial foothold
Boundary treatment	Segmentation asserted, then sampled	Segmentation assumed broken until proven
Identity systems	In scope only if they serve in-scope assets	Always in scope, because they are the objective
Test depth	Sufficient to evidence the control	Sufficient to reach the thing worth stealing
Chained findings	Reported individually against controls	Reported as a route, with the chain as the finding
Out-of-hours behaviour	Rarely relevant	Frequently the whole point
Reporting priority	Anything that would fail the assessment	Anything that would end the company

The chained-findings row is the one that costs organisations most. A compliance report maps findings to controls, because that is the structure the assessor needs. Under that structure a low-severity information disclosure, a medium-severity default credential and a permissive network rule appear as three separate rows with three separate ratings. Composed in sequence, they are a path to domain administrator. Nothing in the control mapping makes the composition visible, and if you want the composition described, you have to ask for it in the statement of work.

The findings you never see, and why

Three categories of finding are reliably absent from a compliance-scoped engagement, not through negligence but by design.

Anything outside the declared boundary, obviously. Also anything the framework has no control for. Business logic abuse is the clearest example: a workflow that lets one authenticated tenant approve a transaction on behalf of another maps to no specific control in most frameworks, so a tester working from a control checklist has no line to write it against. It is also the class of issue that produces the largest single-incident losses in application breaches, because it needs no exploit, only a valid account and an understanding of the workflow.

Then there is anything requiring a technique the engagement rules excluded. Compliance tests are typically announced, in-hours, non-destructive and run against a staging environment that resembles production to a degree nobody has verified. Each of those constraints is individually defensible. Together they remove most of what an adversary would rely on. The guide on what a penetration test cannot find sets out the structural limits, and they apply to well-run tests, not only cheap ones.

The point is not that compliance testing is theatre. Compliance testing catches unpatched services, weak configurations and exposed interfaces, and those cause real breaches every week. The point is narrower: a clean result reduces the space of possible problems by exactly as much as the scope permitted, and by nothing more.

Buying both without paying twice

You do not need two separate programmes. You need the compliance requirement satisfied and the threat question asked, sequenced so the second is not constrained by the first.

1. Write the compliance scope from the control text and keep it deliberately minimal. A scope stretched to satisfy an assessor and answer a threat model at once tends to do neither well.
2. Separately, list every system that authenticates, backs up, monitors or administers the in-scope estate. That list is your real attack surface. Some of it will sit outside the audit boundary, and that is a finding in itself, before any testing starts.
3. Commission the compliance test with an explicit clause requiring attack chains to be reported as chains, with the composed severity stated alongside the individual control mappings.
4. Commission the broader test with objectives instead of an asset list. "Reach the customer database from an unauthenticated position on the internet" is an objective. "Test these fourteen addresses" is a shopping list.
5. Agree the retest terms before the first report arrives, including what evidence closes a finding. Read retesting and what fixed actually means before you sign, because this is the clause most often missing.
6. Give the assessor the compliance report. Give the engineering team both.

Steps two and three cost nothing and change what you learn more than any other decision in the process. Step four is where the money goes, and it is the one most often cut when a budget tightens.

What to do next

Pull your most recent penetration test report and find the scope section. Write down what was excluded, then write down which of those excluded systems can authenticate to, back up, or administer something that was included. If that second list is not empty, you have a gap the report was never asked about, and you now know what to commission next.

Before scoping anything, read what a penetration test is not and how compliance-driven testing differs from security testing, so the boundary decisions are yours rather than inherited from a template. When you are ready to define objectives rather than asset lists, our VAPT and penetration testing services page explains how we structure engagements around what an attacker would try to reach.