Why Compliance Fails to Advance

Every so often I take stock of where compliance actually is as a discipline, compared to where the effort we pour into it says it should be. The honest answer has bothered me for some time, and I want to work through it with you here.

Compliance has never had more resources. More frameworks, more software, more staff, more attention from the board than at any point in my career. By almost any measure of activity, the field has grown enormously.

And yet, measured the only way that really matters, whether obligations are actually being met and not merely documented, I struggle to see the advance. The activity has multiplied. The outcomes have barely moved.

The reason is specific, and I have written about it many times. Most organizations measure conformance, and some measure performance, but almost none measure effectiveness. They can tell you whether the procedure was followed, rarely whether any of it is achieving the outcome the obligation exists to produce. Effectiveness matters most, and it is the measure we most consistently leave on the table. That blind spot is where compliance stalls.

This blind spot rests on a handful of assumptions about what compliance is, most of them absorbed rather than chosen. Each sounds reasonable until you hold it up to the light.

Conformance is not performance, and neither is it effectiveness

Almost every obligation written as a procedure can be read more than one way. One reading asks whether the procedure was followed. That is conformance. Another asks whether it hit its targets. That is performance. A third, the one that matters most, asks whether it produced the outcome the procedure exists to produce. That is effectiveness.

An audit tests conformance. It was never built to test effectiveness. This is not a flaw in auditing, it is simply what auditing is. But it means an organization can conform completely, pass every audit, and still not be effective at meeting the obligation. "But we pass our audits" proves something real. It is just not the thing it gets heard as proving. Audit is not a substitute for the act of compliance.

Compliance is two kinds of work, and we fund one

Meeting an obligation takes two distinct kinds of work, and keeping them separate clarifies almost everything.

There is the work that meets the obligation itself: securing the system, keeping the hazard contained, delivering the quality. I call this promise keeping. And there is the work that gives us confidence the promise is being kept: the controls, the audits, the evidence. This is assurance work.

Compliance is both. But most programs fund the second and assume the first takes care of itself. If you want to know which half your organization truly values, look at what the budget actually pays for.

Even assurance comes in two strengths

There is a further distinction inside assurance, and it explains a great deal about why some domains advanced and others did not.

Audit based assurance offers an opinion, samples evidence and looks backward, attesting to what the sample showed. An engineering demonstration does something different in kind. It verifies the design, tests the performance, and monitors the operation. It builds a case that the system will keep its promise, rather than an opinion that it probably did.

Most compliance functions are staffed and led from the audit tradition, including in industries that plainly need the engineering kind. And so the weaker form of assurance becomes the house standard, not because anyone decided it should, but because it is what the people in the room were trained to produce.

We reward the absence of bad news

"No findings" is a comfortable phrase. But it only tells us the checking caught nothing. It does not tell us the work is being done, and it certainly does not tell us the work is effective.

A clean audit file is cheap, familiar, and reportable this quarter, while real capability is expensive and slow to show its worth. Budgets drift toward what reports well, and then we mistake what reports well for what works. Effort is not the same as results, and compliance of all disciplines should know better than to confuse the two.

An obligation accepted is not a promise made

Watch how a new obligation usually enters an organization. It gets logged, assigned to a function, and a policy gets written for it. At no point in that sequence did anyone with the capability and the resources to deliver actually commit to it.

That is acceptance, not a promise. A real promise has a name attached and a capacity check behind it. Sometimes the name is withheld on purpose, because a clear promise leaves a clear trail if it is not kept. Ask who actually owns the ESG pledge on the website, or the AI principles in the annual report. Where the honest answer is nobody, the obligation was accepted, not promised, and every control built on top of it is standing on nothing.

Implementing controls is not the same as meeting the obligation

Many treat implementing controls as meeting the obligation. That is true, but only up to a point, and the point matters.

The purpose of a control is to deliver a targeted outcome. But most control frameworks in compliance are built from internal controls, not system controls, and the difference is not academic. A system control regulates effort toward an outcome, the way a thermostat regulates temperature or an interlock regulates a hazardous process. It senses, compares against a target, and corrects. An internal control does none of that. It checks that a step occurred, an approval was obtained, a record exists. It is administrative at best, and it regulates nothing.

So when we implement a control framework and call the obligation met, we have usually installed a set of administrative checks and left the actual outcome ungoverned. The obligation was to keep the system secure. What we built was a record that someone was supposed to. When the outcome drifts, nothing in the framework steers it back, because nothing in it was regulating the effort in the first place.

The confusion underneath all of it

The same confusion runs through every one of these. We have let the checking stand in for the keeping, allowed assurance work to become a proxy for the work it was only meant to observe. And because effectiveness is the one thing we rarely measure, the substitution goes unnoticed. Everything looks compliant right up until the obligation is not met.

None of these answers were chosen so much as inherited, from audit practice and from the GRC market. They were reasonable for a different kind of work, and they became standard practice without ever being examined. That, more than any budget line, is what holds compliance in place.

A path forward

What keeps this from being hopeless is that other disciplines have already solved it. Safety and quality faced the same confusion decades ago and worked their way out, not with better paperwork, but by designing the obligation into the facility, the equipment, the systems, and the processes. They made meeting the obligation the point, and treated assurance as evidence that it can rather than a substitute for it.

What they did was stop treating compliance as procedural and start treating it as an operational capability, something designed, resourced, and continuously regulated toward an outcome, the way any critical function is. It is not a new idea. It is only new to compliance domains built on the audit tradition.

Compliance advances when the work of compliance is effective at meeting obligations, and when we can show, with evidence, that it is. Effectiveness is a property of the program, not the paperwork. Everything else, the frameworks, the software, the audits, earns its place only by making that work more effective.

The question I leave you with is the one I keep asking myself.

How much of your compliance program produces outcomes, and how much of it only produces evidence?