A Security Policy Does Not Prove a Control Is Operating

A security policy is a statement of intent: it records what the organization requires, who is responsible, and what the consequences of noncompliance are. An operating control is a different thing entirely. It is the requirement actually enforced on the systems in scope, producing evidence that it works: configuration, enforcement records, activity showing the control in use, documented exceptions, and remediation when something falls short. Most organizations can produce the policy on request. Far fewer can produce the evidence, and the distance between the two is where the most expensive security failures of the last few years actually happened.

There is a short way to say this, and it is the rule the rest of this article hangs on: security is graded on the minimum, not the average. A control enforced on 39 of 40 access paths is not 97.5 percent coverage. It is one open door, and attackers do not pick doors at random.

The Minimum, Not the Average

The reason the minimum decides the outcome is arithmetic, not philosophy. A well-enforced control stops attacks where it operates, so the remaining risk concentrates in the paths where it does not. Compromises never distribute themselves evenly across a coverage dashboard. They pile up in the unenforced remainder, because that is where attacks succeed. High average coverage and high residual risk coexist comfortably, which is exactly what makes the average such a dangerous number to put in front of a board. If your board reporting shows coverage percentages without an exception list, it is reporting the average and hiding the minimum. Chris Carter, a CFO turned CISO, put the funding version of this plainly on episode two of The Blind Spot: "The CFO tends to fund clarity before they fund anxiety." An enforcement map with a short exception list is clarity. A coverage percentage is anxiety with a decimal point.

One Portal at Change Healthcare

The clearest recent proof is the 2024 Change Healthcare breach. UnitedHealth's policy required MFA on all external-facing systems, but one Citrix remote-access portal did not have it enforced. Attackers logged in with stolen credentials, moved through the network for nine days, and deployed ransomware that disrupted claims for much of American healthcare. When CEO Andrew Witty testified before Congress, his answer about that portal was this article's thesis under oath:

"We're trying to dig through exactly why that server had not been protected by MFA."

The policy existed. The enforcement map did not, and the chief executive learned which systems were actually covered at a congressional hearing.

The Attestation Trap

The paper version of the same mistake is the attestation. In 2022, the CEO of an Illinois manufacturer signed a cyber insurance application stating that MFA was in use across the enterprise. Ransomware hit weeks later, and the insurer went to federal court arguing the statement was false. The result, in Travelers v. International Control Services: the parties stipulated to rescind the policy, void from inception. Not a denied claim. The entire policy, erased, after the incident.

This is not a story about one unlucky manufacturer. Brian Herr, a security advisor who runs programs across a portfolio of companies, put it flatly on episode three of The Blind Spot:

"Every company I go into, I end up having to redo their insurance. It's never right."

Every company that buys cyber coverage now signs some version of the MFA question, and the question underneath the checkbox is never whether you have a policy. It is whether you can prove where the policy is enforced. Those are different questions, and the difference is now priced in court. If your renewal is coming up, our cyber insurance readiness guide walks through what carriers actually check. The one-line summary of this section: a policy you cannot evidence is a representation you cannot defend.

Policy, Control, Evidence: The Five Layers

None of this means policies are worthless. A policy establishes intent and assigns responsibility, and a well-governed one is itself a working administrative control. The failure is treating the document as proof of everything written inside it. NIST draws this line cleanly in the assessment step of the Risk Management Framework: determine whether controls are implemented correctly, operating as intended, and producing the intended outcome. Three tests. A document passes none of them by itself.

The gap between the document and the outcome has five layers, and each establishes something different. Most programs stop at the first two and report as if they had all five.

Layer	MFA example	What it establishes
Policy	MFA is required	Organizational intent
Control	Identity rules enforce MFA	Implementation mechanism
Evidence	Configuration, scope, and sign-in records	Whether it operates
Exception	Emergency account excluded	Remaining exposure
Remediation	Add or govern the exception	What happens next

The vendors apply the same reading. Microsoft's own certification guidance requires evidence that MFA is enabled, applied to the intended users, and in use. A policy statement does not qualify there either, and the same layered logic runs through every framework worth holding: our NIST CSF 2.0 checklist is, at bottom, a list of requirements waiting for their evidence layer.

Why Gaps Persist in Mature Programs

Three reasons, and none of them is negligence. Programs measure documents, because documents are what questionnaires ask about and what auditors historically sampled. Scope drifts, because every system, acquisition, and access path added after the policy was written is a chance for enforcement to lag intent, which is precisely how one portal ends up uncovered at a company with a serious security organization. And exceptions accumulate: the emergency account, the legacy app that cannot do modern authentication, the vendor login approved in a hurry. Each was reasonable on the day it was granted. Ungoverned, they quietly become the attack surface.

There is a fourth reason that deserves its own picture: the annual assessment rhythm itself. Evidence collected for an audit is current during audit week and decays for the eleven months after, while the environment keeps changing underneath it.

The auditor samples at the peaks. The attacker operates in the troughs. Both are looking at the same program and reaching different conclusions, and both are right.

And MFA only makes this easy to draw. The same pattern repeats anywhere a document stands in for a working control: the backup policy exists but restoration has never been tested against a real recovery scenario, the incident response plan exists but the people named in it changed roles since the last exercise, vendor reviews are required annually but the evidence for the most critical vendors expired months ago. In each case the organization would answer yes on a questionnaire. In each case the honest answer is: we have the document.

Five Questions That Find the Gap

For any control you care about, ask these in order. A defensible program can answer all five without assembling anything by hand:

1. What does the policy require?
2. Which systems and accounts are in scope?
3. How is the control enforced?
4. What evidence shows it is operating?
5. What exceptions or gaps remain, and what happens next?

The evidence in question four has a quality bar of its own: current, tied to the correct systems and scope, traceable to the requirement, explicit about exceptions, owned by a named person with a review date, and connected to remediation when a gap appears. Anything less is a screenshot with a shelf life.

How Z Cyber Closes the Evidence Gap

Everything above describes a gap between what organizations say about their controls and what they can prove. Closing that gap is the operating problem Z Cyber is built around, and it takes two things working together: a system that holds the truth continuously, and senior judgment that knows what the truth means.

The system is Glance, our AI-native GRC platform. Glance holds the five layers from the table above as one connected program record: the policy requirement, the control that implements it, the evidence behind it, the exceptions that limit it, and the remediation work that closes what the evidence exposed. Because those records stay connected to the systems that produce the evidence, the freshness curve stops looking like the sawtooth. When a customer review, an insurance application, or a board question arrives, the answer comes from current records rather than a reconstruction from memory and screenshots. That is the difference between preparing for an audit and being able to prove the program any day of the year. Glance's AI briefs the executive on what changed and what needs a decision, and it is deliberately read-only: it explains posture, it never changes it, and your data stays isolated to your organization.

The judgment is the Executive Security Advisor, a senior practitioner who operates the program record with you. Software can show that the admin console sits outside MFA enforcement. It takes a human who has run programs to weigh whether the evidence actually supports the assessment, to recognize that one unreviewed emergency account outweighs a hundred low-severity findings, to explain that distinction in the language your board and your insurer use, and to recommend what should move first. The ESA prepares the reporting, surfaces what matters, and makes a clear recommendation on every call. The decisions stay where governance requires them to stay: risk ownership, approvals, exceptions, and the board relationship remain yours.

This is also what boards are actually asking for. As Brian Herr put it on The Blind Spot, boards do not want the technical dashboards, but:

"You do have to give a little bit of receipts. It makes them feel good."

Receipts is exactly the right word. Not activity metrics, not coverage averages: evidence that the named controls are operating, with the exceptions on the table and a plan attached. Antonio Bovoso, the 25 year CISO from episode one of The Blind Spot, put a sharper edge on the same instinct: "I will pay you to not use AI for your board presentation." His point was that a polished deck is not proof of anything, and a board cannot govern polish. Substance for that room is exactly what the evidence layer supplies, and it is what Glance produces and the ESA prepares you to deliver.

The structured way in is the Controls Effectiveness Assessment, which runs the five-question method across your control set: requirement, scope, enforcement, evidence, exceptions. The output is not a pass-fail certificate. It is a defensible map of where each control is enforced, where it is not, what exposure remains, and a recommended order of work, the same view a cyber insurance application effectively asks you to sign for and the foundation that a NIST CSF 2.0 assessment has to stand on. Policies establish intent. The program's job is to find the minimum, fix it, and prove it, on any day of the year rather than one audit week. From risk to remediation, that is what a cyber operating partner is for.

Three Things to Do This Week

1. Run the five questions against your MFA policy. If question two produces a debate instead of a list, that is the Change Healthcare lesson. If question four takes more than a day, or question five has no owner, you have found your open door.

2. Pull your last cyber insurance application. Read every security attestation your company signed and ask, for each one: what evidence do we hold, today, that this statement is true across its full scope? Travelers v. ICS is what the gap between the signature and the evidence costs.

3. List your exceptions. Emergency accounts, legacy apps, vendor logins, anything excluded from a control's scope, each with its grant date, owner, and last review. The entries with no owner and no review date are your minimum, and your minimum is your grade.