ISO/IEC 27001:2022 has 93 controls in its Annex A. We have 27 automated compliance checks running against our own system. Between them they cover 18 of those controls.
Not quite a fifth. And most of the gap is not laziness.
What is actually being counted
Every check in our compliance module declares which control it evidences. That declaration is the measurement: read all 27, collect the control identifiers, count the distinct ones. No judgement, no mapping exercise, no interpretation of what a control "really means".
This is not a compliance score. Nor is it a claim that the other 78 controls are unmet. It is just the share of the standard a machine can check on a schedule. Everything else rests on policies, contracts, reviews, and someone remembering to do them.
Why a sixth is the honest ceiling, roughly
The 2022 revision sorts its controls into four themes, and our coverage falls across them very unevenly: 10 technological, 7 organisational, 1 people, 0 physical.
The zero for physical controls is the clearest case. Those controls are about premises: building entry, clear desks, equipment siting, secure disposal of media you can hold. We rent a virtual server. There is no door for a script to test, and writing one that returned "pass" would be theatre.
The single people control is nearly as structural. That theme covers screening, terms of employment, disciplinary process, awareness training. Those are things you do to and with employees, and evidence of them lives in signed documents, not in a database a cron job can query.
Most of our checks land in the technological theme, where automation belongs. Their coverage reflects what is machine-visible, not what matters most.
The asymmetry nobody designed
Each check can also cite a SOC 2 Trust Services criterion. When we counted the pairings, one result surprised us.
14 checks cite both an ISO control and a SOC 2 criterion. 13 cite ISO alone. And 0 cite SOC 2 alone.
No check exists solely for SOC 2. It appears only where an ISO control already required one.
This says nothing about the two frameworks themselves, only about the order we adopted them. The module was built around ISO; SOC 2 was annotated on afterwards. The overlap looks like agreement between standards. It is actually a record of which one we read first.
The four that cited nothing — and what happened next
UPDATED 18 August 2026. When this guide was published, four of the 27 checks named no framework at all — anonymisation patterns, consent records, data retention and email suppression. Today 0 of the 27 cite nothing, and the explanation this guide originally gave for those four was wrong.
The original argument was that those four existed because of GDPR and the PDPA — laws rather than certifiable frameworks — and so had no Annex A control available to cite. That reasoning was tidy and incorrect. ISO/IEC 27001:2022 contains A.5.34, "Privacy and protection of PII", alongside A.5.33 for protection of records and A.8.11 for data masking. Controls to cite existed the whole time. The four were unmapped because nobody had mapped them, which is a duller explanation and the true one.
They have since been mapped to exactly those three controls, which is most of why the coverage figure moved from 15 controls to 18. The guide's own count is what surfaced them.
The substantive point survives the correction, and it is worth separating from the mistake. A compliance percentage still only moves when you add a check that maps to something. Work that keeps you lawful but cites nothing is still invisible to the score. What changed is that this module no longer has any such work — not because the category is impossible to map, but because the mapping was done.
Which leaves a sharper version of the original warning. If your dashboard shows checks citing no control, the first question is not "are these unmappable?" but "has anyone tried?" We assumed the former in print and were wrong.
What the measuring found in the thing being measured
Running this over our own code turned up something the code had been getting wrong: 2 checks cited control identifiers that do not exist in the standard we say we follow.
The 2022 revision restructured Annex A. The old 2013 edition ran from A.5 to A.18 with four-level numbering; the current one has four themes, A.5 to A.8, and numbers every control with two parts. Both of our stragglers were 2013 identifiers that had never been updated, and the compliance dashboard had been counting both as coverage.
They are both corrected now, and a test fails the build if either style reappears. How they were found is more interesting than what was found.
The first check for retired identifiers tested the theme number: anything outside A.5 to A.8 is from the old edition. That caught one. The second one sat in theme 6 — inside the valid range — and sailed straight past, because what marked it as obsolete was not its theme but its depth: four levels where the current standard uses three. A test that asked the obvious question found half the problem and reported success.
Correcting them also nudged the coverage figure upward, which is the right direction for an unintuitive reason. An identifier that names a control the standard no longer contains covers nothing at all, so fixing the citation converted two phantom controls into two real ones.
Reading someone else's compliance page
Our specific number is not the point. The useful part is the set of questions this exercise suggests.
How much of it is automated rather than attested? Dashboards rarely separate the two, and they are very different claims. Which themes does the automation cover? Concentration in the technological theme is what honesty looks like here, while broad coverage claimed across physical and people controls is worth a question. And are the citations current? A retired identifier looks exactly like a live one until somebody checks, which is how ours sat there being counted.
A sixth is not a bad score. It is roughly what "we automated the automatable" looks like when you count it honestly rather than reporting a percentage that was designed to be reassuring.
Our 27 automated compliance checks cover 15 of ISO/IEC 27001:2022's 93 Annex A controls — a sixth — and the shortfall is mostly structural: 9 of the 15 are technological, and the physical theme reads zero because a rented server has no premises to inspect. Two findings came out of the counting rather than the count. Every check that cites SOC 2 also cites ISO, and not one exists for SOC 2 alone, which records the order we adopted the two frameworks rather than any agreement between them. And 4 checks cite no framework at all — every one of them privacy work driven by law rather than by a certifiable standard, which means the most legally consequential checks in the module are invisible to any percentage. A compliance score inventories what a machine can see. It does not grade anyone's security.
Related reading
On what a certificate does and does not prove, what AI companies do with your data covers reading a SOC 2 report's scope and validating an ISO certificate — the badge certifies a management system, not a product. What our own security audit found reports the findings from red-teaming this same admin surface, and what the padlock actually proves applies the same "read what it certifies" habit to TLS. For a control you can test on your own domain in a minute, our DMARC and SPF checker reads your published mail-sender policy.
- Every figure is produced by a script committed alongside this guide, which reads the framework declarations of every check in our own compliance module and counts them. It re-runs rather than reading a stored copy, so the guide goes red when the module changes rather than quietly ageing.
- ⚠️ THIS MEASURES OUR IMPLEMENTATION, NOT THE STANDARD, and not our security. A control no check cites may still be satisfied by a policy, a contract or a review. Coverage here is coverage BY AUTOMATION and nothing else, and a low share is not a finding against anyone.
- ⚠️ A CHECK CITING A CONTROL IS A CLAIM BY WHOEVER WROTE IT. No external auditor has verified that any of these checks evidences the control it names, and this guide is not an audit result, a certification, or evidence toward one.
- ⚠️ NO CONTROL TEXT IS REPRODUCED ANYWHERE. ISO/IEC 27001 is a paywalled copyrighted standard. This guide cites control IDENTIFIERS, which are references, and the count of 93 controls, which is a single published number. The control set itself is not tabulated here and should not be added.
- ⚠️ ZERO PHYSICAL CONTROLS IS EXPECTED, NOT A GAP. Theme A.7 covers premises, and the scope here is a rented virtual server with no offices in it. Reading that zero as a deficiency would be a misreading of the measurement.
- ⚠️ THE MEASUREMENT'S FIRST VERSION WAS WRONG TWICE, and the guide reports it rather than quietly fixing it. It matched control identifiers anywhere in a file, so once the first correction landed with a comment naming the old identifier, it counted the identifier it was reporting as fixed. It also tested only a control's theme number, which let a 2013-era identifier inside the valid range pass as current; depth, not theme, was the tell.
- An abstract parent class in the same directory is excluded from the 27: it implements the check interface but is never registered and never runs. Counting it inflated the total and added a phantom to the "cites no framework" column.
This describes a measurement of our own compliance tooling against a published standard's structure. It is not an audit, not a certification, not legal or compliance advice, and not a statement that this or any system is secure.
View author profile → · Editorial policy
