Documented Defence That Doesn't Exist — Anti-Patterns: Governance

Many organisations are protected by controls that sound precise in a policy, look convincing in an audit pack, and fail silently in the real world. The danger is not that the document is wrong in a literary sense. The danger is that people make decisions as if the defence exists: they accept risk, connect systems, approve vendors, reduce monitoring, or tell customers they are safe. A documented defence that does not exist is worse than an empty page because it creates confidence in the place where curiosity should be.

Start with the simplest question

A defence is a change to the world that makes an unwanted event less likely, less damaging, or easier to detect and recover from. A locked door is a defence because it changes who can enter a room. A backup is a defence because it changes what happens after data is lost. Multi-factor authentication, often shortened to MFA, is a defence because a stolen password alone is no longer enough to sign in.

A document is not that change. A document can describe the change, assign responsibility for it, explain why it matters, and show how it should be checked. But the document is only a map. The defence is the terrain. Confusing the two is the root error.

The hard part is that modern systems are mostly invisible. A firewall rule, an identity policy, a log pipeline, or a recovery procedure cannot be judged by looking at a door or a cable. Because the machinery is abstract, the paperwork can begin to feel like the thing itself. That is how a defence can exist in language while being absent in operation.

📌

First principle. A control exists only if it changes system behaviour under the conditions it was meant to handle.

How paper controls are born

Most nonexistent defences are not created by fraud. They are created by reasonable people under pressure. A customer asks whether data is encrypted. A regulator asks whether access is reviewed. A board asks whether backups are tested. Someone writes the expected answer, often based on a design intention, a partial deployment, a tool feature, or a memory of how things used to work.

Over time, the sentence travels farther than the mechanism. It is copied into a policy, a risk register, a vendor questionnaire, an audit response, or a security architecture diagram. Each copy gives it more authority. Meanwhile the real system changes: a new cloud account appears, a team bypasses the standard process to meet a deadline, an exception becomes permanent, or a tool is disabled during an outage and never re-enabled.

This is not merely a documentation problem. It is a feedback problem. The organisation has lost the link between claim, implementation, and proof.

Why the gap is dangerous

A missing defence is dangerous. A believed-in missing defence is more dangerous. When people trust a control that is not working, they stop looking for the failure it was meant to prevent. They may approve a risky integration because the network is said to be segmented. They may store more sensitive data because encryption is said to be universal. They may relax manual checks because monitoring is said to be automatic.

Attackers, accidents, and outages do not read policy. They interact with the actual system. If a privileged account can still sign in without MFA, the policy requiring MFA provides no resistance. If backups exist but cannot be restored, the backup policy does not shorten recovery. If logs are collected but never reviewed or alerted on, the logging standard does not detect misuse.

The gap also damages trust inside the organisation. Engineers learn that documents are ceremonial. Auditors learn to ask for screenshots instead of understanding. Leaders receive assurance that is shaped by what is easy to report rather than what is true. Once that pattern sets in, even real controls become harder to manage because the organisation has trained itself to accept weak evidence.

⚠️

False assurance. The worst control is not the one marked absent; it is the one marked present without proof.

A control trusted on paper provides no resistance when the real system behaves differently.

Evidence is the bridge between claim and reality

Evidence is information that shows a control is implemented and operating as intended. It is stronger than a statement of intent and weaker than certainty. Good evidence is close to the system, recent enough to matter, and specific enough to test the claim.

For example, a policy that says all administrators use MFA is a claim. A list of administrator accounts with their MFA status is better evidence. A sign-in log showing that administrator sessions were challenged for MFA is stronger still. A controlled test in which a password-only sign-in is blocked is stronger again, because it exercises the defence rather than merely inspecting its settings.

Evidence also needs scope. If the claim says all production databases are encrypted, evidence from one database proves only one database. If the claim says access is reviewed quarterly, last year’s review is historical context, not current proof. Scope and freshness are what prevent evidence from becoming decorative.

A configuration export can show how a control is set.
A log can show whether the control actually fired.
A test result can show whether the expected block, alert, or recovery happened.
An exception register can show where the control does not apply.
A control owner’s attestation can help, but it should not be the only evidence.

Evidence grows stronger from a stated claim, to configuration and logs, to a control tested when challenged.

The common shapes of a defence that is not there

Nonexistent documented defences tend to appear in familiar patterns. One is the tool-feature fallacy: the organisation owns a product that can provide the defence, so people assume the defence is in use. A security tool on the invoice is not the same as a security control in production.

Another pattern is the partial-control fallacy. The defence works in one environment, team, region, or application, but the document describes it as universal. This is common after mergers, cloud migrations, and urgent product launches, where standard patterns do not reach every corner at the same speed.

A third pattern is the stale-control fallacy. The defence was once real, but drift has eroded it. Drift is the gradual movement of a system away from its intended state. It happens through exceptions, emergency changes, renamed assets, expired certificates, departed owners, and quiet changes in business process.

Policy says access is removed when staff leave, but no one checks shared accounts.
Architecture says services are isolated, but a temporary network rule now allows broad access.
Procedure says backups are tested, but the test restores a sample file, not the critical application.
Standard says sensitive data is encrypted, but old storage volumes were never migrated.
Monitoring says alerts go to an on-call team, but the mailbox is unowned or ignored.

Nonexistent defences appear as owned-but-unused tools, partial coverage, and controls that have drifted stale.

Test for existence, then test for quality

A common mistake is to debate whether a control is mature before proving it exists. Maturity matters, but sequence matters more. First ask: is there a mechanism in place? Then ask: does it cover the promised scope? Then ask: does it behave correctly when challenged? Only after those questions should you ask whether it is efficient, automated, well documented, or optimised.

Testing for existence should include negative tests. A positive test shows that a permitted action works. A negative test shows that a forbidden action fails. If a control is supposed to block public storage, try to create public storage in a safe test setting. If a control is supposed to alert on privilege escalation, perform an approved simulation and watch the alert path end to end.

The test must include the human and operational parts of the defence. A backup that restores only when one specialist is available is fragile. An alert that reaches a queue no one owns is not detection. A quarterly access review completed by rubber-stamping every account is activity, not control.

Prove a control exists, covers its scope, and behaves when challenged before asking whether it is mature.

The real decisions this changes

For leaders, the issue is not whether to demand more documents. It is whether to base decisions on claims, evidence, or tested outcomes. A risk committee deciding whether to launch a product needs to know which defences are real today, which are partial, which are compensating controls, and which are aspirations. A compensating control is an alternative safeguard used when the preferred control is not yet possible or complete.

For practitioners, the issue is how to avoid becoming either cynical or ceremonial. The useful posture is disciplined curiosity. If a standard says all production systems send logs to a central platform, ask which asset inventory defines all production systems. Ask how new systems are enrolled. Ask what proves logs arrived yesterday. Ask what happens if logging stops.

These questions are not bureaucracy. They are design inputs. They shape budgets, staffing, deadlines, acceptance criteria, and incident response plans. If a control is absent, the honest options are to build it, reduce the risky activity, add a temporary compensating control, accept the risk explicitly, or change the claim. What is not honest is to leave the claim untouched and hope the system catches up.

⚠️

Leadership test. If a launch, merger, or audit depends on a control, ask what would change your mind about whether that control exists.

Documentation still matters

The answer is not to despise documentation. Good documentation is part of the defence system. It names the control owner, describes the threat model, defines the scope, records exceptions, links to evidence, and explains how failures are handled. A threat model is a structured way to describe what could go wrong, who or what might cause it, and which defences are expected to reduce the risk.

The difference is that good documentation is connected to operation. It does not merely say, 'Backups are tested.' It says which systems are backed up, how often restore tests occur, what counts as a successful restore, where the last results are stored, who reviews failures, and what deadline applies to fixing them.

A documented defence that does not exist is a broken promise. A documented defence tied to evidence is an operating agreement with reality. The goal is not perfect paperwork. The goal is to make every important claim traceable to a mechanism, every mechanism traceable to evidence, and every gap visible enough to be managed.

✅

Good documentation. The best control document helps someone prove, operate, and improve the defence without guessing.

Key takeaways

A defence exists only when it changes system behaviour, not when it is described in a policy.
False assurance is dangerous because people make risk decisions as if a missing control is real.
Good evidence is close to the system, recent, scoped, and tied to a testable claim.
Verify existence before debating maturity, automation, or elegance.
Leaders should decide using tested reality, known gaps, and explicit risk choices.
Documentation is valuable when it connects claims, owners, mechanisms, evidence, and exceptions.

Glossary

Control: A safeguard or process that reduces the likelihood, impact, or duration of an unwanted event.
Evidence: Information that helps prove whether a control is implemented and operating as intended.
Multi-factor authentication: A sign-in method that requires more than one type of proof, such as a password plus a device or biometric check.
Drift: The gradual movement of a system away from its intended or documented state.
Control owner: The person or team accountable for keeping a control defined, operating, evidenced, and improved.
Compensating control: An alternative safeguard used to reduce risk when the preferred control is unavailable, incomplete, or delayed.
Threat model: A structured description of what could go wrong, how it might happen, and which defences are expected to help.
Audit: An independent or structured review that checks whether stated requirements are being met.