Part 1: The Trap
There's a moment in every growing organisation when someone says: "We need to document this properly."
It sounds reasonable. ISO standards require it. Auditors expect it. And there's genuine value in capturing how things work so knowledge doesn't walk out the door when people leave. But something happens between that reasonable intention and the outcome. Documentation breeds more documentation. Each process spawns sub-processes. Sign-offs multiply. Before long, you've built a system that assumes people will do the wrong thing unless watched.
This is the trap. The more rules you write, the more you signal distrust. And the more distrust you signal, the more people behave in ways that justify the rules. They follow the letter, not the spirit. They optimise for compliance, not outcomes. They ask permission instead of using judgement.
The irony is sharp: management systems designed to ensure quality often erode the conditions that produce it. When organisations treat documentation as proof of control, they create governance theatre. Policies exist to satisfy auditors, not to guide work. Evidence is manufactured after the fact, disconnected from the activity it's meant to represent. The ISMS becomes a parallel universe, maintained but not inhabited.
And here's what's rarely said aloud: most people inside these organisations know it. They know the procedures don't reflect reality. They know the records are performative. But they keep the system running because that's what compliance looks like. Or so they've been told.
Part 2: The Inversion
What if the goal of a management system isn't more process, but less need for process?
This sounds counterintuitive. ISO 27001 and ISO 9001 are built on documented procedures, defined responsibilities, and auditable evidence. How can you have less process while meeting those requirements?
The answer lies in a distinction that's easy to miss: there's a difference between codifying intent and codifying actions.
Codifying actions means prescribing exactly how work should be done. Step one, step two, step three. It assumes the person doing the work can't be trusted to navigate ambiguity. It removes judgement from the equation.
Codifying intent means making the purpose clear and trusting people to find the right path. It assumes competence. It treats context as something to share, not something to hide behind rules.
High-trust teams operate this way. They don't need dashboards to prove people are doing the right thing, because doing the right thing is the default. Accountability exists, but it's relational, not transactional. When something goes wrong, the response is curiosity, not blame. This isn't naive optimism. It's a design choice. You can build systems that make good behaviour easy and bad behaviour hard. Three examples of what this looks like:
Access defaults that protect without obstructing. Instead of relying on people to remember security protocols, design systems where sensitive data is only accessible to those who need it, automatically. No forms to fill. No requests to escalate. The system assumes least privilege by default, so people don't have to think about what they shouldn't touch.
Approval flows that follow risk, not hierarchy. Rather than routing every decision through management, build workflows where low-risk actions proceed immediately and only genuine exceptions require sign-off. People move fast on routine work. Oversight concentrates where it matters.
Checklists that appear in context, not in binders. Instead of training people to consult a procedure manual, surface the relevant guidance inside the tools they already use, at the moment they need it. The checklist isn't a separate compliance task. It's part of doing the work.
The shift is subtle but profound. Instead of asking "how do we ensure compliance?" you ask "how do we make compliance the natural byproduct of well-designed work?"
When trust is present, metrics become less important. As one conversation I was part of recently put it: KPIs often exist because trust is lacking. They're a substitute for confidence in the system. When confidence is high, the need for constant measurement fades. You check in rather than check up.
Part 3: The Design Principle
So what does this look like in practice? How do you build a management system that assumes competence rather than compensating for its absence?
Three principles stand out.
First: document the why, not just the what. Most procedures describe steps without explaining purpose. This makes them brittle. When circumstances change, people either follow outdated instructions or abandon the process entirely. But when they understand the intent, they can adapt. They can handle situations the procedure never anticipated.
Second: let evidence emerge from work. The worst compliance systems require people to stop working in order to prove they're working. Separate logs, manual records, retrospective documentation. This creates friction and resentment. Better systems capture evidence as a byproduct of activity. The work itself leaves a trail. Nothing extra required.
Third: minimise the distance between decision and context. Centralised approval processes exist because organisations don't trust local judgement. But centralisation creates bottlenecks, delays, and decisions made by people furthest from the situation. Pushing context outward, giving people the information they need to decide well, is more effective than pulling decisions inward.
These principles don't eliminate documentation. They change its purpose. Documentation becomes a tool for enabling autonomy, not restricting it. A living reference, not a static archive.
This is where we see modern ISO compliance heading. The organisations doing it well aren't adding more controls. They're designing systems where compliance is woven into how work already happens. Where the management system isn't a separate burden but an expression of how the organisation actually operates.
We believe the technology now exists to support this shift. Automation can handle the repetitive, low-judgement compliance tasks. It can surface the right information at the right moment. It can generate evidence without interrupting flow. What it can't do is replace the underlying philosophy. Tools amplify intent. If the intent is control, you get sophisticated surveillance. If the intent is enablement, you get something genuinely useful.
The paradox resolves when you stop treating process and trust as opposites. Process, done well, builds trust. It creates shared understanding. It makes implicit knowledge explicit. It lets people move fast because they're not guessing at expectations.
But process done poorly, process that assumes the worst, destroys the trust it claims to protect.
The question for any organisation building a management system is simple: are we designing for people we trust, or people we don't?
The answer shapes everything that follows.