Drowning in Green Ticks: When Compliance Obscures Risk
Drowning in Green Ticks: When Compliance Obscures Risk
By Julian Brownlow Davies | Meaning In the Signal, Week 6 | 23 April 2026
There is a particular kind of satisfaction that comes from closing the last finding on a compliance audit - the moment when the dashboard turns green, the assessor signs off, and the security team can report to the board that the organisation is, in the relevant framework’s terminology, “compliant.” I have been in those meetings. I have experienced that satisfaction. And I consider it one of the more dangerous feelings in security.
Not because compliance is worthless - it isn’t. Not because the frameworks are poorly designed - many are remarkably thoughtful. But because the green tick has a way of becoming the answer to a question that compliance was never designed to answer: are we actually safe? And the signal that compliance generates to support that answer is, I believe, doing something more insidious than merely providing false comfort. It is actively competing with the signals that matter.
Compliance Measures Process. It Does Not Measure Risk.
This distinction is foundational, and I think the industry struggles to hold it clearly. A compliance framework assesses whether an organisation has implemented a defined set of controls. ISO 27001 asks whether your information security management system meets a specified standard. PCI DSS asks whether your payment card environment has certain protections in place. SOC 2 asks whether your service organisation controls satisfy your auditor’s evaluation criteria. These are process conformance assessments. They tell you whether you have done the things the framework requires. They do not tell you whether those things are sufficient to protect against the threats that are actually relevant to your organisation, in your sector, in this threat environment, right now.
The gap between those two questions is where breaches live. It is well-documented - and if you need examples you can find them in the post-mortems of a dismaying number of major incidents: organisations that were certified, audited, and compliant at the moment they were compromised. Compliance certification is not evidence of safety. It is evidence of process conformance, which is a genuinely different thing, and conflating them is a category error with material consequences.
When Compliance Signal Crowds Out Risk Signal
Here is the argument I want to make that goes beyond the well-rehearsed observation that compliance doesn’t equal security, because I think there is something more specific and more damaging happening.
Compliance programmes generate a very large volume of signal in their own right: audit findings, remediation items, control assessments, exception logs, maturity scores, gap analyses, evidence artefacts. In a large organisation, this signal can be prodigious - hundreds of findings per assessment cycle, thousands of evidence items per year. And that signal competes, directly, for attention and resource with the signal generated by actual risk management: vulnerability findings, threat intelligence, penetration test results, incident analysis, the attack path work and the crown jewel thinking I have been arguing for across the previous weeks in this series.
The problem is that compliance signal is, in most organisations I have encountered, better resourced and more visibly tracked than risk signal. The audit cycle has a deadline. The assessor has a sign-off. The board wants to know whether the certification has been maintained. The finding from a penetration test that identified a credible path to your most valuable systems, by contrast, sits in a remediation backlog that is reviewed quarterly if you are disciplined and annually if you are not.
This is Goldratt applied to governance: when you have two competing measurement systems, resources flow toward the one with clearer consequences. And the consequences of a compliance failure - lost certification, regulatory censure, audit qualification - are, in most organisations, considerably more visible and immediate than the consequences of a risk management failure. Until the breach.
The Strongest Objection, and Why It Has Limits
The objection I anticipate is a reasonable one: compliance frameworks provide a minimum baseline, and a minimum baseline is better than nothing. Without them, many organisations would implement rather less. The regulatory incentive is often what gets the programme funded in the first place, and for organisations at lower levels of security maturity the framework provides genuine structural lift that would not otherwise exist.
I accept this, and I think it is largely true. But I consider it a considerably weaker argument for organisations that have achieved certification, maintained it across multiple cycles, and now use compliance status as a primary lens for security programme management. For those organisations - and they represent the majority of large enterprises I encounter - compliance has migrated from a floor to a ceiling, and the question of whether the framework actually reflects the threat environment relevant to the business has largely stopped being asked.
There is also a subtler problem. Compliance frameworks are, by design, backward-looking: they codify the controls that the community considers necessary based on what has worked and what has failed in the past. The threat environment, by contrast, moves continuously forward. The adversary who is targeting your specific assets this quarter is not constrained by the control set that was determined appropriate when the framework was last revised. Compliance, at its best, is a lagging indicator dressed up as a current one.
What Good Governance Actually Looks Like
What I am arguing for is not less compliance. It is a clearer organisational understanding of what compliance is for and what it cannot do.
Compliance belongs in the operational hygiene layer: the baseline controls, the documented processes, the minimum standards of practice that reduce the probability of preventable failures and satisfy legitimate regulatory obligations. It is necessary infrastructure. It is not a risk management strategy, and it should not be governed as though it were.
Risk management requires things that compliance frameworks do not ask for: a clear hypothesis about which adversaries are relevant to your organisation, a map of which assets carry disproportionate strategic value, an understanding of which attack paths present the most plausible routes to those assets, and a prioritisation discipline that places the meaning generated by that analysis above the signal generated by audit cycles. These are the questions this series has been building toward, and they are, I think not coincidentally, the questions that compliance frameworks are structurally ill-suited to provide answers to.
The organisations I consider genuinely mature are the ones that have separated these two concerns clearly. They run their compliance programme to satisfy obligations and maintain the baseline. They run their risk programme to understand and address the threats that actually matter. The two are connected but distinct, governed by different questions, measured by different outcomes, and reviewed by different audiences. The compliance dashboard is not the risk register. Treating one as a proxy for the other is the category error that the green tick makes so easy to commit.
The signal from the audit is real. The question worth asking is what, precisely, it means.
Which of the following would your board be more troubled by: a qualified finding in your next compliance review, or the knowledge that a credible adversary has a plausible path to your most valuable assets that your current programme would not detect? If the honest answer is the former - and in my experience, for many boards it is - that tells you rather a lot about where the real constraint lies.