​There is nothing wrong with compliance frameworks. That is worth saying clearly, because the conversation around them can quickly slide into dismissiveness. ISO 27001, NIST CSF, PCI DSS — these were built to solve a real problem, and for a significant number of organisations, they still do exactly that.

The issue is not the frameworks themselves. It is what happens when they accumulate, when the machinery built to support them starts to overshadow the thing they were supposed to protect, and when passing an audit becomes indistinguishable from doing the actual work.

​

Getting the Basics Right

At their best, compliance frameworks do something genuinely useful. They bring structure to environments that would otherwise rely on instinct and good intentions. They create a common language across security, risk, and business teams who might otherwise be talking past each other entirely. And for organisations that are earlier in their security maturity, they provide a starting point that would otherwise take years to develop independently, if it got developed at all.

For many organisations, frameworks like ISO 27001 and NIST CSF have been the difference between reactive, ad hoc security and something more structured and repeatable. Security decisions that were previously made informally, based on whoever happened to be in the room, become documented, reviewed, and accountable. Risks that might have been ignored because they were inconvenient get logged, assessed, and assigned to someone. That is not a trivial contribution.

Without frameworks, a significant portion of organisations across all sectors would struggle to know where to begin. The baseline they provide is real, and it would be intellectually dishonest to dismiss it simply because the picture becomes more complicated further down the road.

​

When One Framework Becomes Many

The challenge arrives when organisations are expected to follow several frameworks simultaneously, which is now the norm rather than the exception. A mid-sized financial services firm, for instance, is not choosing between NIST and ISO. It is navigating both, alongside DORA, PCI DSS, FCA expectations, and whatever security questionnaire its three largest clients sent over last quarter.

Most organisations today operate under some combination of regulatory requirements, industry standards, customer driven audits, and internal governance controls. Each one has its own logic. Each one adds something individually. But together, they create a level of complexity that is genuinely difficult to manage without it becoming a substantial function in its own right, one that consumes resources, headcount, and senior attention in ways that were not anticipated when any single framework was adopted.

And here is the frustrating part. In practice, most frameworks are asking for broadly the same things. Strong access controls. Effective risk management. Clear incident response processes. Protection of sensitive data. The underlying outcomes are largely aligned. The security principles one framework asks you to demonstrate are rarely in contradiction with another. What differs, often dramatically, is how those outcomes must be evidenced, structured, and presented.

The result is a pattern that will be immediately recognisable to anyone who has worked inside a security team under compliance pressure. The same control documented multiple times in slightly different formats. The same evidence repackaged to satisfy the particular language of a different audit. The same questions answered again, because this framework phrases them differently to the last one. The workload multiplies. The security posture does not move.

​

Where the Model Starts to Strain

As the compliance burden grows, organisations respond rationally. They build infrastructure around it. Dedicated GRC teams appear. Compliance management platforms get procured. Structured audit calendars, evidence repositories, and reporting cycles become permanent fixtures in the security calendar. None of this is irrational. In many organisations it is genuinely unavoidable given the volume of obligations they are expected to meet.

But it carries a cost that is easy to overlook in the moment. Compliance becomes something that is managed alongside security rather than embedded within it. A parallel track with its own team, its own priorities, and its own definition of success. Security asks whether the organisation is protected. Compliance asks whether the organisation can demonstrate that it meets the standard. Those questions are related, but they pull in different directions more often than people like to admit.

When success is measured primarily by passing audits, behaviour shifts in ways that are subtle but consequential. Teams gravitate towards completing required controls, producing documentation, and demonstrating coverage to the satisfaction of whoever is reviewing it. The harder questions get less airtime. Whether controls actually work under realistic conditions. Whether the organisation is identifying weaknesses that do not map neatly to a framework control. Whether the threat landscape has shifted in ways the audit calendar has not caught up with yet. Security becomes something proved on paper rather than tested in practice, and the two start to feel like the same thing, which is the point at which things get genuinely dangerous.

​

The Rise of Checkbox Security

There is a term that gets used quietly inside security teams, rarely in public: checkbox security. It describes the state an organisation reaches when the primary goal of the security function has become satisfying the audit rather than improving the actual defensive capability of the organisation.

It is not the result of bad intentions. Nobody sets out to build a security programme that prioritises paperwork over protection. It emerges gradually, through entirely understandable decisions. A team under resourced and overcommitted starts triaging ruthlessly. Audit deadlines are fixed and visible. Threat detection improvements are harder to schedule and harder to measure. Over time, the fixed and visible work expands to fill the available capacity, and the harder, less defined work contracts.

The frameworks themselves are not responsible for this dynamic. But the environment they collectively create makes it more likely. When an organisation is simultaneously maintaining evidence for four different compliance programmes, the team that is theoretically responsible for monitoring, detection, and response is often the same team preparing that evidence. Something gives.

​

The Real Risk

The biggest issue here is not inefficiency, though that is real and worth taking seriously on its own terms. It is misalignment between what organisations believe about their security posture and what is actually true.

An organisation can be fully compliant, fully certified, and thoroughly documented, and still be meaningfully vulnerable to a real world attack. This is not a hypothetical risk or a theoretical edge case. It is a pattern that plays out repeatedly, and the post-incident reviews tend to tell a consistent story. The controls existed on paper. The policies were written. The audit was passed. But the controls had not been tested under realistic conditions, the policies did not reflect how people actually behaved, and the risks that mattered most were not the ones the framework had been designed to surface.

Compliance measures presence, not effectiveness. It confirms that a control exists, not that it works. It validates that a process is documented, not that anyone follows it when something goes wrong at two in the morning. That gap, between what is certified and what is operationally true, is where risk actually lives. And because it is invisible to the audit process, it tends to stay invisible until it is not.

​

What High Performing Organisations do Differently

The organisations that navigate this well are not the ones that ignore compliance. They are the ones that have worked out how to stop compliance from becoming the whole job.

In practice, these organisations share a recognisable approach. They use frameworks as a baseline for consistency and a reference point for communication with boards, regulators, and customers. They treat certification as a useful signal rather than a destination. And they maintain a clear internal distinction between what the framework requires and what the threat environment actually demands.

This means prioritising controls based on real risk exposure rather than audit requirements alone. It means testing effectiveness continuously, through exercises, red teaming, and genuine incident simulations, rather than preparing for a point in time assessment and then moving on. It means building security thinking into day to day operations, into how engineering teams deploy code, how access is managed, how incidents are reviewed, rather than treating compliance as a project that runs in parallel to everything else.

The language used inside these organisations tends to be different too. The question is not "are we compliant?" It is "are we protected, and how do we know?" Compliance becomes the evidence base for a broader conversation rather than the conversation itself.

​

The Insight Worth Holding Onto

Frameworks are not designed to make organisations secure. They are designed to make security measurable. Those are related goals, but they are meaningfully different, and conflating them is one of the more consequential mistakes a security leadership team can make.

Measurability matters. Being able to demonstrate a security posture to a regulator, a customer, or a board is not a bureaucratic nicety. It is a legitimate and important capability. But measurement is a means to an end. When it becomes the end itself, the signal and the noise swap places, and the organisation loses sight of what it was measuring in the first place.

The most secure organisations understand this distinction. They invest in compliance because it is necessary and often valuable. But they never mistake it for the work itself.