A contradiction in the wild: implemented, accepted, and being fixed
One control, three of the organisation's own approved registers, three different answers — and the structural reason nobody had noticed.
This is the first in an occasional series. Every instalment is a real finding from a real assessment, anonymised — no organisation, no vendor, no tooling, no internal reference numbers. We publish them because the most useful thing we can show you is not what Frank claims to do. It is what it found in paperwork that had already been approved.
One control, three answers
An organisation loaded its ISO 27001 records: the statement of applicability, the risk assessment, the risk treatment plan, and a separately maintained exception register. Nothing unusual, nothing hand-prepared for us.
One control — logging — appears in three of those documents. Here is what each of them says.
- The statement of applicability marks it implemented.
- The exception register records a formally accepted gap on it: there is no centralised log aggregation. Approved, with a named approver and a date.
- The risk register carries it as an open risk under active mitigation.
All three documents are current. All three are approved. All three are about the same control.
Read one at a time, each is defensible. A control can be marked implemented and still carry known residual gaps. Centralised aggregation is not a precondition for a logging control to operate. Residual risk can be formally accepted while mitigation of it continues. Nothing here is wrong on its face, and that is the point.
What the records do not settle is whether they are describing the same thing. Does the accepted gap sit inside what the statement of applicability calls implemented, or beside it? Is the risk under mitigation the one the exception already accepted, or a different one? No document answers that, because no document was written to be read next to the other two. Somebody has to go and ask — and until they do, the organisation cannot say which of the three its posture rests on.
Then it happens again. A second control — user endpoint devices — shows the same three-way shape via a second accepted exception, with the risk register again describing active mitigation of a control the statement of applicability calls implemented. One is a fluke. Two is how the system works.
Nobody was lying
The obvious reading is the wrong one, and this is the part worth slowing down on.
Nobody drafted a false statement here. Each of those three documents is internally consistent and was produced honestly for its own purpose. The statement of applicability records a control design. The exception register records a decision someone made honestly, in the open, about a gap they could not close this year. The risk register records work in progress. Three authors, three review cadences, three moments in time — and three entirely defensible documents.
The problem does not live inside any of them. It lives in the space between them, and the space between them is nobody’s job.
That is also why it survives review. An auditor samples. A manager reviews their own register. A consultant reads the statement of applicability because that is the document under assessment. Reading ninety-odd controls across four documents against each other, line by line, is rarely scoped and rarely economical — not because the people are careless, but because it is a mechanical job that has only ever been available in human hours.
Note what this is not
This is not drift. Drift is the argument we make about the eleven months after the certificate is issued, during which a true statement quietly stops being true. Drift needs time to happen, and it is at least honest at the moment of signature.
This is different, and in some ways worse. These three documents already needed reconciling on the day they were filed. There is no interval to blame. The assurance was unreconciled at issue, and the certificate references the version that marks the control implemented.
The question this leaves on someone’s desk
Somebody signed for this posture. So the question is not which document is right. It is: which of the three would you have put your name to, if you had been shown all three at once?
You were not shown all three at once. That is the finding. And in the room after an incident — the one with the regulator, the insurer, and your own board in it — all three are yours. All three are approved, dated, and available in your own records. The exception register in particular is your organisation’s own approved record that the gap was known.
Why this one matters to us
Finding it required no expertise. It required comparing the registers against each other exhaustively, and in the same way every time — cheap for a machine, expensive for a person working to a delivery date. That distinction is the point of this series: an experienced auditor can find a great deal in your ISMS, but they cannot be there every quarter, and comparing every control across four documents on every pass is rarely what the engagement is scoped or budgeted for. Frank is not smarter than your assessor. It is just never in a hurry, and it never assumes that two of your own documents agree.
Here is a version you can run yourself this afternoon, no product required. Pick one control you would describe as settled. Look it up in your statement of applicability, then your risk register, then your exception register. If all three agree, that is one control down.
You can see where your own registers fail to line up. Start with obligation visibility. It reads your own documents back to you, together, and marks the places where they do not reconcile.