Cybersecurity Cannot Remain a Compliance Exercise

We wrote in the founding letter that a control which does not change how the system behaves on the day of the incident is paperwork. The sentence is easy to applaud and hard to apply, because almost no control in a real company is obviously false. They exist. They are licensed, configured, they appear in the report, and they have a named owner. The question is not whether they are there.

The difference between a control that operates and one that merely exists is not visible in documentary evidence. A screenshot of a configuration proves existence; it does not prove that the control has ever refused anything, that the refusal was noticed by a person, or that the person did something about it. This piece is about telling the two apart — and about why that distinction is not an audit problem but an engineering one.

Existence, configuration and operation

A control passes through three distinct states, and most programmes measure only the first. It exists: it was procured and deployed. It is configured: the rules match the intent of whoever wrote them. And it operates: it interferes with the real flow, and the interference reaches someone with authority to act. Between the second state and the third sits most of the risk companies believe they have handled — the tool left in observation mode since deployment because blocking felt frightening, the correct rule applied to an environment that stopped being the main one, the alert firing into a shared mailbox nobody has read since the last reorganisation.

The decay is structural rather than negligent. Systems change continuously, and controls stay attached to the description of the system that was true on the day they were installed. A new environment, a new deployment path, a new integration: each is a legitimate change made by competent people, and each may quietly step around a control nobody remembered to extend. Nobody switched anything off. The system simply moved, and the control stayed where it was.

The exception register is the real configuration

Every serious policy has exceptions, and exceptions are legitimate: sometimes the business really does need the thing, and a policy with no valve is a policy that will be quietly bypassed. The problem is elsewhere. Exceptions are born with an expiry date and die without one. After a few years the policy in force is the document minus the accumulated exceptions, and that list rarely exists consolidated anywhere — it is scattered across approval notes, messages, and the memory of whoever was present.

A company's policy is not the document. It is the document minus the list of exceptions nobody reviews.

An exception with no expiry is a permanent amendment to the policy, made by whoever asked for it rather than by whoever answers for it. The fix is cheap in mechanism and expensive in discipline: exceptions expire by construction, and renewal is a decision someone has to take again with their name attached. The side effect is the valuable part — when renewal costs a signature, the organisation finds out how many exceptions are still genuinely needed, and the answer is usually far shorter than the list.

Four questions that separate paperwork from control

No programme is required to make the distinction. Four questions are enough, they take an afternoon per control, and what they cost is not money:

• —When did this control last refuse something, and to whom? A control that has never refused anything is either protecting something nobody attempts, or it is not in the path.
• —Is there a legitimate route that goes around it? An emergency access, an automation with its own credential, an environment that was never included in the rollout.
• —Who receives the output, and what is that person authorised to do alone? An alert with no authorised recipient is a historical record, not a control.
• —How will we know it is still there next month? A control that depends on nobody changing anything is a photograph, not a mechanism.

What those four replace is a silent assumption: that a control observed once carries on operating. No system holds that property by itself, and no documentary evidence tests it. They also change the kind of conversation, because one of them forces the system to be looked at the way an adversary would look at it — along the route that was not covered, rather than down the list of what was.

What compliance does well, and where it stops

It is worth being fair to the subject. A compliance framework supplies a shared vocabulary, sets a floor, makes organisations comparable, and forces a conversation the business would otherwise defer indefinitely. That is real value, and arguing against having a floor is not a defensible position. What has to stay clear is where it stops: a framework asks whether a control exists in the expected form, and cannot ask what your particular system, with its particular history, does on the bad day. Its cadence is annual while the system changes weekly — and the gap between those two rates is exactly where incidents live.

Compliance answers whether the control exists in the expected form. Engineering answers what it does on the day someone tries.

The reason we press on this is economic before it is moral. Paperwork is expensive: it consumes the budget that would have bought a real control and, worse, it delivers confidence along with the invoice. An organisation that knows it is exposed behaves prudently — it restricts, it verifies, it rehearses. An organisation that believes it is covered does none of that, and learns the difference through the only channel left. So the test we apply is behavioural and always the same: what changes, in the behaviour of this system, on the day someone tries. If the answer is nothing, the control is a document, however well written.