There is a question that almost no assessment asks, and it is the one that decides whether the answers to all the others mean anything.
Not “do you enforce multi-factor authentication?” — but “on what proportion of the systems a person can actually reach?”
Every answer was true
Consider how an assessment usually goes.
Is multi-factor authentication enforced for remote access? Yes. Is access reviewed periodically? Yes. Is remote access encrypted and logged? Yes. Are privileged accounts subject to additional controls? Yes.
Every one of those answers is true. The control exists, it is documented, it operates, and the evidence is real. Nobody is being evasive, and the person answering is describing the estate accurately as they understand it.
What the questions establish is that a control exists somewhere in the organization. What they do not establish is what it covers.
How the gap opens
No control is deployed everywhere on day one. It goes where it can go.
The modern applications take it easily. The web estate follows. Then the program reaches the systems that were never designed to participate in any of this — an application that expects its environment to have already established who the user is, a thick client, a vendor-supported system where any change to the configuration voids the support agreement, an operational segment where the device opens the session rather than the person.
Those become exceptions. Each one is logged, justified, approved, and given a review date. That is the process working correctly — an exception register exists precisely so that the things which cannot comply are visible rather than hidden.
Then the review date arrives, the underlying reason has not changed, and the exception is renewed. It is renewed again the following year by someone who was not there for the original decision and has no basis to refuse.
The control is real. The exception is real. They are simply recorded in different places, discussed by different people, and never added together.
This is not a criticism of the frameworks
Worth saying plainly, because it would be easy to read this as an argument that compliance is theater. It is not.
Frameworks are scoped deliberately. They assess whether a control is designed appropriately and operating effectively, which is a reasonable thing to assess and a hard thing to do well. Auditors are not architects, they are not commissioned to redesign your access model, and an assessment that attempted it would be worse, not better.
The gap is not a failure of the audit. It is that the audit was never the instrument for this, and organizations quietly treat it as though it were. A clean report becomes the answer to “are we protected?”, when what it answered was a narrower and more specific question.
The test that takes an afternoon
Here is a way to find out where you stand, and it requires no tooling.
Take one control you attest to — multi-factor authentication on remote access is the usual candidate. Now ask for the list of systems it does not cover.
Not the exception register, which records the ones somebody wrote down. The actual list: everything reachable by a person, minus everything behind that control.
Three things tend to happen. The list takes far longer to produce than anyone expected. It is assembled from several sources that disagree. And it is longer than the person who attested to the control believed it would be.
If nobody in the organization can produce that list in an afternoon, then the attestation describes a control rather than an estate — and the difference between those two things is where incidents live.
Why the gap is worse than its size suggests
If the uncovered systems were a random sample, this would be a smaller problem.
They are not random. They are the systems that resisted every modernization attempt, and the reasons they resisted — age, bespoke authentication, vendor constraints, operational sensitivity — are highly correlated with importance. Administrative interfaces. Production and operational systems. Things holding regulated data that nobody was willing to disturb.
The strongest controls end up on the systems that were easiest to protect, and the weakest sit in front of the ones that would matter most. Nothing in an assessment surfaces that inversion, because the assessment examines controls one at a time.
What actually closes it
A control that cannot be deployed everywhere will always produce exceptions, and exceptions will always become permanent. So the question is not how to manage the register better. It is what would remove the need for it.
An enforcement point that sits in front of the whole estate — not the convenient part of it — makes coverage an attribute of the architecture rather than a program to be run. Total Access Control is built for exactly that position: it fronts modern applications and the ones that expect identity presented in an older form, so the systems that generate exceptions stop generating them.
The practical consequence is that attestation gets simpler rather than harder. One enforcement point, one policy model, one record of what was reached — pointed at once, rather than assembled from six systems and a spreadsheet each time somebody asks.
The question to ask before the next assessment
Not: will we pass?
But: when we attest to a control, do we know what it covers — and could we prove it this week without anyone working a weekend?