TL;DR: Most policy failures aren’t about the policy — they’re about who owns it the moment something goes wrong.
Almost every organisation has policies. They sit in a shared drive, they get signed off once a year, and they look reassuring in an audit. The real test isn’t whether the document exists — it’s what happens at 2am when a supplier is breached, a laptop goes missing, or a member of staff downloads something they shouldn’t. In that moment, the only question that matters is a human one: who owns this, and what are they supposed to do next?
A policy is only useful if it changes behaviour at the point of decision. Too often it doesn’t. Someone notices a problem, pings a colleague, and an informal scramble begins — no defined severity, no clock, no record of who decided what. The policy that was meant to govern the moment never actually enters it.
A well-run governance model flips that. When an event occurs, the policy attached to it should automatically define the severity, the owner, the deadline and the evidence that needs capturing — before anyone has to remember where the runbook lives. The difference between a controlled response and a chaotic one is rarely the quality of the writing. It’s whether the policy does anything when it’s needed.
Part of why policies fail to govern the moment is brutally simple: nobody can find them, and when they do, they can’t make sense of them. A 40-page document buried three folders deep, last opened at the audit and written in language only its author understands, isn’t governance — it’s decoration. Under pressure, people fall back on memory and instinct rather than the policy.
The fix isn’t writing more. It’s making policy easy to reach and easy to read at the exact point a decision is made. This is where a compliance platform earns its place — one central home for every policy, in plain language, version-controlled so everyone sees the current version rather than a stale copy, and linked directly to the action it governs. A policy someone can find in seconds and understand in a sentence is one they’ll actually follow.
Ownership is where most governance quietly breaks. Ask who owns a given asset, who approves a security exception, or who is accountable for closing an incident, and you’ll often get a pause. Everyone assumes someone else has it.
This is the part regulators, boards and insurers probe hardest, because it’s where accountability lives. Clear governance means every asset, control and incident has a named owner, and every exception has a defined approver — not a verbal “yeah, that’s fine” lost in a chat thread.
Exceptions are normal — businesses can’t operate on absolutes. The risk isn’t the exception itself; it’s the undocumented one. A governed approach forces an exception through a defined route: who requested it, who approved it, when it expires, and what happens if it’s never revisited. An expired exception that nobody re-reviewed is exactly the kind of gap that turns a minor finding into a serious one.
“Annually” is the standard answer, and it’s the wrong one. A policy reviewed on a calendar date drifts out of step with how the business actually operates the other 364 days. The events that should prompt a review — a major incident, a significant system change, a new supplier, a failed integration — almost never line up with the diary.
The stronger model is event-driven: real operational change triggers a review, so written policy and actual behaviour don’t quietly diverge. It keeps governance honest without slowing teams down, and it’s far easier to defend when someone external asks why a control looks the way it does.
Here’s the test that catches people out. If the ICO, a major client or your insurer asked you to evidence how a specific incident was handled — who was notified, what was decided, when — could you produce it without a frantic week of reconstruction?
According to the UK Government’s Cyber Security Breaches Survey 2025/2026, only around a quarter of businesses have a formal incident response plan — and far fewer can show a defensible, time-stamped record of how past incidents were actually run. Audit-readiness isn’t an event you prepare for; it’s a state you’re either in or you’re not. When evidence is captured as the work happens, the audit pack is a by-product of doing the job properly — not a project in its own right.
If your leadership team can answer “who owns it, who approves it, when does it get reviewed, and can we prove it?” clearly and consistently, you have governance. If the answers wobble, you have documents. Pulling these threads into one governed system — where policies, roles, evidence and outcomes share the same place — is exactly the kind of resilience our managed cyber security work is built around, and it sits naturally alongside structured baselines like Cyber Essentials certification.
The first time many organisations confront these questions is mid-incident, when the answers are expensive. It’s a far better conversation to have on a quiet Tuesday.