The Standards Trap
Standards were designed to help. In practice, they’ve become the problem — creating duplicate work, conflicting language, and an industry that profits from the complexity rather than reducing it.
You manage access to your production environment. You do it well. There’s a working process: joiners get access approved by their manager and provisioned by IT, movers get their access reviewed when they change roles, leavers get deprovisioned on their last day. The whole thing is reviewed quarterly. Evidence is collected — who approved what and when, with what justification. The control works.
Now look at how you document it.
For ISO 27001, it’s mapped to Annex A controls A.5.15 (access control), A.5.17 (authentication information), and A.5.18 (access rights). You need to maintain evidence against each of these controls, because the auditor can sample them individually.
For SOC 2, it’s mapped to CC6.1 (logical and physical access controls) and CC6.2 (access credentials management). Different language, different structure, because it’s a different audit with a different framework.
For NIS2, it falls under Article 21(2)(i) — human resources security, access control policies and asset management. The regulatory requirement is phrased differently again, and your compliance team maintains a separate mapping document to demonstrate coverage.
A customer sends their annual security questionnaire. Question 47: “How do you manage access to the systems we use?” You answer it by pulling from all three of the above, reformulating it in the customer’s preferred format, and attaching evidence from whichever source seems most likely not to generate more questions.
One control. Four documentation trails. Four evidence packages. Four review cycles. The control itself takes maybe two hours per quarter to operate. The documentation and approvals take at least twice that — if you’re lucky. You’re spending more time proving you manage access than actually managing it.
And the documentation doesn’t make you more secure. Not even slightly. The same review, the same process, the same evidence — just reformatted, re-filed, and re-presented for four different audiences. This is the standards trap.
The overlap tax
Every major compliance framework asks you to do roughly the same things. Manage access. Handle vulnerabilities. Respond to incidents. Assess risks. Control changes. Manage vendors. Protect data. Train staff.
They just say it differently.
Six frameworks can now compete for a European company’s attention — ISO 27001, SOC 2, NIS2, DORA, GDPR’s Article 32, the EU AI Act.
The overlap between these frameworks is large. The industry’s own estimate puts the overlap between SOC 2 and ISO 27001 at around 80%. NIS2 and ISO 27001 overlap by a similar amount — NIS2 was partly designed with ISO 27001 in mind. DORA and NIS2 share so much common ground that the European Commission published guidelines on which one applies when both do — for financial entities, DORA wins.
But the overlap doesn’t reduce work. It multiplies it.
Each framework uses its own language. ISO talks about “controls.” SOC 2 talks about “criteria.” NIS2 talks about “measures.” DORA talks about “requirements.” They mean approximately the same thing, described in terminology specific enough to require translation between frameworks.
Each framework has its own audit cycle. ISO 27001 runs annual surveillance audits and triennial recertification; SOC 2 expects an annual assessment; NIS2 supervision varies by member state; DORA brings its own supervisory regime. You’re not audited once against a unified standard — you’re audited multiple times against overlapping-but-distinct standards, each time producing its own evidence trail.
This is the overlap tax. One security activity generates multiple compliance workstreams. The activity is the same. The work to prove it — to each framework, in each framework’s language, on each framework’s schedule — is multiplied.
For an organisation managing two frameworks, the tax is noticeable but manageable. For an organisation managing three or four — which is increasingly common for European companies serving international customers — the tax becomes the dominant cost of the programme. You spend more time on compliance documentation than on actual security.
There’s a person in the middle of this. Chapters 1 through 3 each described the human cost of a structural problem — the security lead who knows but can’t say, the person who’s quietly terrified, the individual who gets blamed for a system failure. The standards trap has its own version.
It’s the compliance manager who maintains four parallel evidence packages for the same access review. They know the documentation is duplicative. They know the same control is being evidenced four slightly different ways for four slightly different audiences. They also know that each auditor expects their own format, that each framework mapping needs maintaining, and that suggesting “can we just do this once?” will produce a conversation about risk that ends with “better safe than sorry.” So they do it four times, every quarter, and the overhead consumes time that could go toward actually improving the controls they’re documenting.
They’re not overwhelmed by security. They’re overwhelmed by compliance about security. That distinction matters, because the solution to each is different.
The industry’s answer to the overlap tax is framework mapping — cross-reference spreadsheets that show which ISO control maps to which SOC 2 criterion maps to which NIS2 measure. Every consultancy has one. Some GRC tools build them in. Framework mapping acknowledges the problem. It doesn’t solve it. The mapping tells you that A.5.15 and CC6.1 address the same thing — useful to know — but you still evidence them separately, audit them on different cycles, and explain the mapping to each auditor.
The consultant economy
I want to name something that people in the compliance industry know but rarely say out loud, because it implicates their livelihood: complexity is a business model.
The compliance ecosystem — standards bodies, certification bodies, auditors, consultants, GRC tool vendors — is large and profitable. It exists because security and compliance are complex, and organisations need help navigating that complexity. This is legitimate. The complexity is real. The help is often necessary.
But the ecosystem also benefits from the complexity continuing. Every new regulation creates demand for consultants to interpret it; every framework revision for gap assessments; every overlap for mapping exercises; every audit cycle for preparation support. The more complex the landscape, the more valuable the expertise.
The structural incentives are clear. Everyone in the chain — standards bodies, auditors, consultants, tool vendors — benefits from more: more controls, more detail, more complexity, more frameworks.
Nobody in this chain is structurally incentivised to simplify. Nobody’s business model improves when an organisation manages three frameworks with the effort of one.
This isn’t some sort of conspiracy — many consultants, auditors, and standards professionals are genuinely trying to help, and many do good work. But the system they operate in rewards complexity, and that’s worth calling out. When you’re being sold a six-month framework implementation project, it helps to understand that the scope of that project is partly determined by structural incentives, not just by your actual security needs.
The proportionality gap
There’s one more thing frameworks fail to do — tell you how much is enough.
ISO 27001 says manage access control. It doesn’t say whether quarterly reviews are sufficient for your systems or whether you need monthly reviews for the production database and annual ones for the internal wiki. It can’t — because the answer depends on your context.
Without guidance on “how much,” organisations default to one of two failure modes.
The first is over-investment from fear. A 35-person startup running quarterly business continuity exercises for a team that sits in one room. A three-person engineering team maintaining a formal change advisory board because the framework lists change management as a control. Every system reviewed at the same depth, every risk assessed at the same frequency, regardless of what’s actually at stake. This is a real effort, and the risk reduction is marginal. But nobody wants to be the person who suggested doing less and was wrong.
The second is under-investment from pragmatism. Every system gets the same light-touch review — the production database holding customer data, the key management system, and the wiki with internal training materials all get the same quarterly glance. The risk register is updated uniformly, without distinguishing between risks that could end the business and risks that would barely register. The effort is spread evenly, which means it’s concentrated nowhere — least of all where it matters most.
Both are rational responses. Both are wrong. The framework gives you a map of everything that could matter, with no indication of what actually matters for you. Chapter 8 addresses proportionality in depth. But the gap starts here, because the frameworks themselves create it — and the compliance ecosystem has no incentive to fill it.
The deeper issue
The overlap tax. The mapping bandage. The consultant economy. The proportionality gap. These aren’t separate problems — they’re symptoms of a single structural choice: organising your security programme around frameworks rather than around your reality.
When the framework is the organising principle, every new framework is a new programme. ISO 27001 produces an ISO-shaped programme; SOC 2 a SOC-shaped one; and so on. Each one is internally consistent but externally disconnected. The overlaps are invisible, because the data is structured around the framework, not around the underlying security reality. You can’t see what you actually have (clarity), you can’t tell whether it’s working (feedback), and you can’t judge whether the effort is right (proportionality) — because the picture is fragmented across four separate views of the same reality.
When your reality is the organising principle — your assets, your risks, your controls, your evidence — the frameworks become what they were designed to be: lenses. You have one access management control. It’s evidenced once, in one place. When ISO 27001 asks about it, you show the evidence through an ISO lens. When SOC 2 asks, you show the same evidence through a SOC 2 lens. When the customer questionnaire arrives, you show it again, in their format.
The overlap stops multiplying the work, because the work isn’t organised around the overlap — it’s organised around the control.
Here’s what that looks like concretely. You look up your access management control. One place. You can see it satisfies ISO 27001 A.5.15, SOC 2 CC6.1, and NIS2 Article 21(2)(i). The evidence trail is the same for all three — last quarter’s review, the access list, the decisions, the changes actioned. A customer security questionnaire arrives asking how you manage access to production. The answer assembles itself: here’s the control, here’s the evidence, here’s the last review date, here are the frameworks it satisfies. You respond in twenty minutes. Not because you rushed — because the work was already done. The questionnaire is just a lens on a reality you already maintain.
One control. One evidence trail. Multiple views. Not less work — but the same work serving every audience, instead of being repeated for each one.
If your compliance team spends more time translating security work into framework language than your security team spends doing the work, the programme has inverted. It exists to feed audits, not to protect the business. That’s the standards trap. The solution is to stop organising around the standards.
What to do Monday morning
Pick one control and count how many times you document it. Your access review, your vulnerability management process, your incident response procedure — whichever you maintain for multiple frameworks. Count the separate policies and processes that exist in different business contexts, the separate mapping entries, the separate audit responses. The number is your overlap tax.
Ask your auditor: “Would you accept the same evidence for this control that we provided for our other audit?” You might be surprised. Combined ISO 27001 + SOC 2 audits run on a single evidence set could be a lot cheaper than two separate audits. The assumption that each audit needs its own evidence package is inherited, not required. Test it.
Map one security activity to every framework that references it. Take vulnerability management. Find the ISO 27001 control, the SOC 2 criterion, the NIS2 measure, the DORA requirement. Write them on one page, side by side. Then use the page: at the next audit or questionnaire, answer from it and attach the same evidence for each. You’ve just operated “one control, multiple views” for a single control — and the next time someone says a new framework means a whole new compliance workstream, you’ll know exactly how much of it is duplication.