The Compliance Industrial Complex
Why does ISO 27001 certification take 12 to 18 months when the standard itself isn’t that complicated?
I’ve been quiet for two months. I owe you an explanation, but not the one you’d expect. I didn’t run out of things to say. I went looking for answers to a question that has been bothering me for years, and what I found made me uncomfortable enough to sit with it before writing about it.
The question was simple:
Why does ISO 27001 certification take 12 to 18 months when the standard itself isn’t that complicated?
93 controls. That’s it. 93 things you need to demonstrate you’re managing. Some of them are technical. Some are governance. Some are about people. None of them is unreasonable. The standard reads like a sensible checklist written by people who’ve actually managed information security. So why does the surrounding industry behave as though certification is a multi-year endeavour requiring a small army of specialists?
I think I know. And most people in the compliance industry don’t want to hear it.
From Compliance Theatre to Engineered Assurance
The theatre
Here’s what ISO 27001 certification looks like in most organisations: You hire a consultant. The consultant writes policies. Then an auditor reads those policies. Sounds reasonable, except for one detail: the consultant’s business model often relies on the complexity of the problem, not the speed of the solution.
If they can solve your compliance in a month by querying your M365 tenant, they lose twelve months of billable advisory hours. This is why the industry prefers “Policy Theatre.” They focus on the document because it is easy to bill for and difficult for a non-technical auditor to refute. We are building paper cathedrals while the actual servers are on fire.
They’ve never opened your Entra ID admin centre. They’ve never looked at your Conditional Access policies. They’ve never checked whether the MFA enforcement they documented actually applies to the accounts they listed. They wrote a 40-page access control policy by adapting a template they’ve used for dozens of other clients, with your company name in the header and your logo on the cover page.
The auditor then asks: “How do you manage access control?”
And the answer is that policy. Not a demonstration. Not a live walkthrough. A document. Written by someone outside the organisation, describing systems they’ve never operated, reviewed by an auditor who may or may not verify whether any of it is true.
This is not compliance. This is theatre. And it is becoming dangerous. Modern auditors have a name for checking whether reality matches the paperwork: the “Hallway Test.” They stop a random employee and ask, “How do you report a phishing email?” If the answer doesn’t match the policy, it’s not just embarrassing—it’s a Major Non-Conformity that can stop certification dead in its tracks. The theatre is no longer just expensive; it is a liability.
Five stakeholders, zero ownership
Count the people involved in a typical ISO 27001 programme:
The MSP manages the tenant, deploys the security configurations, and operates the technology day to day
Internal IT — caught between operational demands and security mandates, they didn’t write
The security team, responsible for threat detection, incident response, and security posture, is often understaffed
The compliance officer owns the ISMS on paper, coordinates evidence gathering, and prepares for audits
The consultant drafts policies, advises on standards, and bridges the gap between what exists and what should exist in practice.
Five groups. Each is doing a fraction of the work. None of them sees the whole picture.
The MSP knows the technology but not the standard. The consultant knows the standard but not the technology. The compliance officer knows the process but can’t verify the technical claims. Internal IT understands the operational reality but lacks authority over the compliance programme. The security team knows the threats but isn’t consulted on the policy language.
This fragmentation creates a structural conflict of interest, particularly for MSPs offering “Compliance-as-a-Service.” If the MSP both builds and inspects the firewall for compliance, they are effectively marking their own homework. Unless duties are clearly segregated, this model collapses under scrutiny.
Now ask yourself: who in that chain can log into the tenant and verify a single claim in the Statement of Applicability?
In most organisations, the answer is the MSP. And in most organisations, the MSP is the group least involved in writing the policies that describe what they’ve built.
The perverse incentive
There’s a structural problem nobody talks about: the people who help you get certified profit from complexity, not simplicity.
A consultant who reduces your time to certification from 18 months to 3 is a consultant who just cut their own revenue by 80%. A compliance platform that makes evidence collection trivial undermines the need for the advisory services sold alongside it. An auditor who finds a major non-conformity risks delaying the certification their client is paying for — and nobody wants to be the auditor who costs the client another quarter.
This isn’t a conspiracy. It’s an incentive structure. I’ve worked with excellent consultants who genuinely simplify the process — they exist, and they’re good at what they do. But the system as a whole rewards friction, not efficiency. It rewards documentation over demonstration. It rewards the appearance of rigour over the reality of security.
The result is an industry in which organisations spend more time preparing for audits than on improving their security posture. Where “evidence gathering” means a frantic two-week sprint before the auditor arrives. Where the Statement of Applicability — the single most important document in the ISMS — is a spreadsheet that was filled in once and hasn’t been meaningfully reviewed since.
Measuring what’s easy, not what matters
Here’s something I’ve learned the hard way: the compliance industry measures what’s quantifiable, not what’s important.
Secure Score is easy to query. Dashboard metrics are easy to screenshot. Licence counts are easy to extract from the Graph API. So that’s what gets measured.
But ISO 27001 Clause 5.1 asks whether top management demonstrates commitment to information security. And leadership commitment is behavioural, not technical. A CEO can buy M365 E5 licences and have no idea what an ISMS is. A CTO can delegate PIM roles without actually empowering anyone.
Don’t get me wrong—tools like Microsoft Secure Score are powerful. But their value lies in the trend line, not the snapshot. Showing an auditor, a 12-month trajectory of improvement is evidence of “Continual Improvement” (Clause 10.2). Showing them a static 85% is just vanity.
Clause 4.1 asks organisations to determine external and internal issues relevant to their ISMS. This is a strategic question—concerning market changes, regulatory shifts, staffing challenges, and technological transitions. Things that affect how you manage information security at a strategic level.
What do I see across the tenants I manage? A Secure Score dashboard. A threat intelligence feed. A compliance posture overview. These are operational metrics, not strategic context. A 15-point drop in Secure Score due to a policy misconfiguration is not an “internal issue affecting ISMS outcomes.” However, it is documented as one because it’s measurable, and it meets the evidence requirement.
The standard asks excellent questions. We respond with incorrect data because the correct data are difficult to collect and even more difficult to quantify.
The standard isn’t the problem.
I want to be clear about something: ISO 27001 is a good standard. The 2022 revision is genuinely well-structured. It didn’t just cut controls; it reorganised them from 14 siloed domains into 4 integrated themes: Organisational, People, Physical, and Technological.
This shift was a deliberate move to break down the silos I mentioned earlier. It requires collaboration among legal, HR, IT, and facilities. The management system clauses (4 through 10) ask the right questions about leadership, planning, support, operation, evaluation, and improvement.
The problem is not what the standard asks. The problem is how the industry answers.
The standard asks: “How do you manage access control?” The industry answers with a policy document.
The standard asks: “How do you determine context?” The industry answers with a dashboard screenshot.
The standard asks: “How does top management demonstrate commitment?” The industry answers with a licence count.
The standard asks: “Can you demonstrate that your controls are effective?” The industry answers with a point-in-time evidence pack assembled two weeks before the audit, containing screenshots that were stale before the auditor opened them.
Every one of those answers satisfies the letter of the requirement. None of them satisfies the intent.
What if?
I’ve spent two months thinking about a different question: What if compliance were an outcome of how you run your technology, not a project bolted on top?
Not compliance as a destination you arrive at after 18 months of policy writing and evidence gathering. Compliance as a continuous, observable state — like uptime, or availability, or mean time to recovery. Something you can measure at any moment, not something you perform when the auditor books a date.
This concept isn’t science fiction. The industry refers to it as “Compliance as Code” or “Continuous Controls Monitoring.” It is the shift from gathering artefacts to monitoring streams.
What if, instead of five stakeholders each doing a fraction, the technology itself produced the evidence? What if the MSP’s operational work—configuring Conditional Access, deploying compliance policies, managing Defender, and onboarding devices—were the compliance programme, measured and reported automatically?
What if the evidence was never more than 24 hours old? What if non-compliance generated a remediation ticket the moment it was detected, not six months later when someone noticed during audit prep? What if the compliance programme made the business more agile, not more rigid?
What if you actually looked forward to audits?
I know how that sounds. But I’ve been pulling at this thread, and the current model isn’t the only model. I think we’ve accepted a level of friction that doesn’t need to exist, because the industry that grew up around the standard has no incentive to remove it.
Over the coming weeks, I’m going to explore this idea in detail. I want to challenge some orthodoxies about how compliance works, examine the standard from first principles, and ask whether the implementation model we’ve all accepted is actually the only option—or merely the one the incumbents have the least incentive to change.
I expect to be wrong about some of it. That’s fine. Tell me where.
The question I’ll leave you with
How many people are involved in your ISO 27001 programme?
Now ask: how many of them can log into your tenant and verify a single claim in your Statement of Applicability?
If those two numbers are very different, you might have a compliance programme that looks impressive on paper but can’t survive a probing auditor having a bad day. And if that makes you uncomfortable, good. It should.
More soon.