Part 1: The Understanding Deficit
There's a quiet failure mode in most compliance work. It looks like success. The boxes get ticked. The audits pass. The certificates arrive. But ask the people who completed the process what it actually means for their organisation, and you'll often get silence. Or a shrug. Or a rehearsed answer that doesn't quite land.
This is the understanding deficit. Not a lack of compliance, but a lack of comprehension. People complete without understanding. They sign off without grasping. They follow the letter while missing the spirit entirely.
The cost isn't obvious at first. You still get the certificate. You still win the tender. But underneath, the organisation remains just as vulnerable as before. The risk register exists, but nobody really knows what the risks mean. The policies are documented, but nobody could explain them in their own words. The fortress looks sturdy from the outside. Inside, it's scaffolding.
Why does this happen? Because most compliance systems are designed for completion, not comprehension. They're built to generate evidence, not understanding. The implicit assumption is that if you can prove you did it, you must have learned something along the way. But that's not how learning works. Clicking through a process teaches you nothing except how to click.
Consider how a typical ISO 27001 journey unfolds for a small or medium-sized business. Someone gets assigned the task. They inherit a spreadsheet or a template. They're told what outputs are expected: a risk register, a set of policies, evidence of controls. The whole system is oriented around deliverables.
What's missing is the thinking. The process doesn't ask: do you understand why this risk matters? It asks: have you documented the risk? It doesn't ask: can you explain this control to your team? It asks: is the control implemented? The gap between these two questions is enormous, and it's where most compliance value leaks away.
The result is governance theatre. Documentation that satisfies auditors but doesn't guide decisions. Policies that exist in binders but not in behaviour. A management system that runs parallel to the actual organisation, maintained but not inhabited.
And here's the uncomfortable part: most people inside these organisations know it. They know the procedures don't reflect reality. They know they couldn't explain the logic behind the controls. But the system doesn't require them to. It only requires them to finish.
Part 2: The Socratic Turn
What would it look like to design a compliance system around understanding rather than completion?
The first shift is philosophical. Instead of asking "how do we get people through this process?" you ask "how do we ensure people actually understand what they're doing?" These sound similar. They're not. The first optimises for speed and evidence. The second optimises for genuine capability.
One approach that shows promise is what might be called the Socratic turn. Rather than telling people what to do and asking them to confirm they've done it, you ask questions that require them to think. Not quiz questions with right answers. Real questions that demand engagement with the underlying logic.
Consider the difference between "Have you completed your risk assessment?" and "What does this risk mean for your organisation specifically?" The first can be answered with a click. The second requires thought. The first generates evidence. The second generates understanding.
This matters enormously when you introduce AI into the equation. The temptation with automation is to let the system do everything. Feed it your company data, let it generate your risks, have it write your policies. Fast. Efficient. And completely hollow.
The alternative is AI that operates more like a skilled mentor than an answer machine. It gathers information. It does the research. But then it comes back with questions, not conclusions. "Based on what I've found, here's a potential risk. Do you agree this applies to your situation? Why or why not?" The human has to engage. The human has to think. The human has to own the decision.
This is the difference between codifying actions and codifying intent. When you codify actions, you prescribe exactly what to do. Step one, step two, step three. It works, but it produces compliance without competence. When you codify intent, you make the purpose clear and trust people to find the path. It's slower at first, but it builds genuine capability.
There's a useful analogy in how good teachers operate. A poor teacher gives you the answer. A good teacher asks you questions until you discover the answer yourself. Both produce the same immediate result. But only one produces lasting understanding. In a compliance context, this might look like a system that researches your stakeholders automatically, but then asks: "These are the stakeholders I've identified. Are there any I've missed? Which of these actually influence your security posture?" The system does the heavy lifting, but the thinking stays with the human.
The practical benefit is resilience. When people understand the logic behind their controls, they can adapt when circumstances change. They don't need to consult a manual or wait for updated guidance. They can reason from first principles. The compliance isn't brittle. It's alive.
This is also where automation can genuinely help rather than hollow out the process. The parts that don't require human judgement can be handled instantly. What would take weeks of research happens in hours. But the parts that do require judgement remain firmly in human hands. Speed where it's safe to be fast. Deliberation where it matters.
Part 3: Progress That Proves Itself
When people understand what they're doing, something interesting happens to evidence. It stops being a separate burden.
In traditional compliance, you do the work and then you prove you did the work. Two activities. Often with a gap between them. The documentation is created after the fact, sometimes reconstructed from memory, sometimes fabricated to fill gaps. This is where governance theatre thrives.
But when the work itself requires engagement with real questions, the evidence emerges naturally. The decision you made, the reasoning you applied, the risks you considered: all captured as part of the process, not as an afterthought. Evidence becomes a byproduct of thoughtful work, not a parallel bureaucracy.
This changes what progress feels like. Instead of a checklist gradually filling up, you see genuine capability developing. The risk register isn't just a document you created; it's a tool you built and understand. The controls aren't just boxes you ticked; they're decisions you made for reasons you can articulate.
There's a motivational dimension here that's easy to underestimate. People don't like busywork. They don't like processes that feel pointless. But they do respond to visible progress toward meaningful goals. When you can see your security posture improving, when you can explain your risk decisions to your team, when the work you're doing clearly connects to real outcomes: that's engaging. That's a game people actually want to play.
The word "game" might seem strange here. Compliance is serious. Security matters. But the mechanics of engagement aren't frivolous. Clear goals. Visible progress. Meaningful choices. Feedback that tells you how you're doing. These aren't gaming gimmicks. They're the conditions under which humans do their best work.
Think of it this way: the problem with compliance isn't that it's boring. It's that it's been designed as if learning doesn't matter. As if understanding is optional. As if the goal is to get through it rather than to get something from it.
Redesign for understanding, and something else becomes possible. Compliance stops being an imposition and starts being an enabler. Instead of the security team being the department of no, they become the department that helps the business move faster and safer. Instead of compliance being a cost centre, it becomes a contributor to real business value: reduced risk, protected reputation, competitive advantage in markets where trust matters.
There's a head of legal who once described wanting her team to be "yes people." Not pushovers, but enablers. Her lawyers' first answer to any question should be "yes, and here's how we do it safely." Security and compliance could work the same way. Yes, you can pursue that opportunity. Yes, you can work with that vendor. Here's what you need to consider, here are the controls that apply, here's how we manage the risk together.
That's a different posture. It requires genuine understanding of the business, the risks, and the controls. It can't be faked with checkbox compliance. But it's infinitely more valuable.
The Shift
The technology to make this real is finally here. AI can do the research, gather the context, surface the relevant information. Automation can eliminate the tedious parts that don't require judgement. What's needed is intent: a decision to design for understanding rather than completion.
The goal isn't more process. It's less need for process. When people understand what they're doing and why, they need fewer rules and less oversight. Trust becomes possible because competence is real.
This is the shift from compliance as burden to compliance as capability. From governance theatre to genuine security. From systems that assume the worst about people to systems that help them be their best.
The question for anyone building compliance tools, or using them, is simple: are we designing for completion, or for comprehension?
The answer shapes everything that follows.