A law isn’t a control set, and a tool being present isn’t a control being met — a single percentage can’t capture either distinction. Here’s what to ask instead.
Why
A compliance coverage percentage is one of the most quoted numbers in governance, risk and compliance (GRC) — the discipline of managing an organisation’s obligations, risk exposure, and controls against the frameworks and laws that apply to it. It’s also one of the least examined. Put plainly: the number you get depends entirely on the lens you’re looking through, and almost nobody asks which lens that is.
Different owners look through different lenses, and each produces a different number from the same underlying reality. A control-focused lens counts implemented controls. A technology lens counts tools deployed, whether or not they’re actually validated. A legal lens counts articles addressed, whether or not those articles were ever controls to begin with. A vendor-capability lens counts whatever that vendor happens to measure. Two organisations, or two vendors, can report wildly different coverage percentages for the exact same framework, against the exact same organisation, and both be technically defensible — because they were never measuring the same thing. 786 Cyber’s own model is built to be lens-agnostic rather than picking one: every provision is tagged consistently, the same way, regardless of which department or vendor is asking.
This isn’t a simple task of copying a framework’s clauses into a checklist and counting what’s ticked. A regulation, a framework, or a law is a large, structurally complex document, and treating all of it as one flat list of equivalent items is where a coverage percentage starts to mislead. Here’s the distinction that actually matters: a law or a framework is not a control set. Every regulation of any real size contains a substantial share of text that cannot be “implemented” as a control, because it isn’t one — definitions, which supervisory authority has jurisdiction, how penalties are calculated, appeals procedure, transitional and final provisions. Nobody “implements” a definitions clause.
786 Cyber’s own canonical control model — the hub of categories every framework’s controls are mapped down to — makes this concrete rather than theoretical. Adding a dedicated privacy and data-protection canonical this year took the hub from 21 categories to 26, specifically to stop privacy provisions being force-fitted into security categories that didn’t actually describe them. The effect on GDPR and UK-GDPR: mapped controls went from 14 (14%) to 40 (40%) once privacy provisions were correctly recognised as controls rather than left unmapped or miscategorised. Separately — and this is the part that matters here — 119 GDPR/UK-GDPR articles remain correctly excluded, because they’re institutional and procedural law: scope and definitions, supervisory-authority constitution and powers, codes of conduct and certification bodies, the EDPB consistency mechanism, remedies and liability, member-state derogations, final provisions. None of that is a gap. None of it was ever a control. And the six GCC PDPL privacy laws, once the same canonical was applied consistently, each reach 29 out of 29 mapped controls — 100%, identically across all six — which means one privacy control can be traced across all six regimes at once. That’s what a coverage number looks like once the lens is applied consistently instead of picked to flatter.
Those 119 excluded GDPR/UK-GDPR articles are not unimportant, and excluding them from a control coverage percentage doesn’t mean ignoring them. Knowing which supervisory authority has jurisdiction, understanding penalty exposure, assigning a data protection officer — these matter to a genuine compliance programme. They’re just not controls an organisation implements and evidences the way access control or breach notification is. They belong to policy ownership and documented awareness, not a met/gap control status — a distinction worth keeping rather than collapsing into one number that pretends everything is the same kind of thing.
This isn’t a theoretical concern outside 786 Cyber’s own catalogue, either. Twice in 2025, the UK’s Information Commissioner’s Office (ICO — the UK’s data protection regulator) issued major fines, and both notices are worth reading closely for what they actually cited. In March 2025, Advanced Computer Software Group was fined £3.07 million after a 2022 ransomware attack on its health and care subsidiary disrupted NHS 111 and patient-record access for 79,404 people. The ICO’s finding was specific: attackers got in through a customer account that simply didn’t have multi-factor authentication (MFA — a login control requiring more than a password) enabled. In October 2025, Capita was fined £14 million over a 2023 breach affecting roughly 6.6 million people — and the ICO’s reasoning named exactly what failed: no tiered separation between ordinary and administrative accounts, letting the attacker move freely across systems once inside; a 58-hour delay before quarantining the compromised device against the company’s own 1-hour target; and security testing that happened once, when systems were first commissioned, with no follow-up reassessment as risk changed. (ICO; Hunton)
Read both notices end to end and notice what’s missing: neither one cites a definitions clause, an appeals-procedure gap, or a supervisory-authority jurisdiction question. Regulators fine organisations for missing controls — MFA, account tiering, response-time discipline, retesting cadence — not for incomplete paperwork on the parts of a law that were never controls to begin with. That’s the whole argument of this piece stated as evidence rather than assertion: a coverage percentage is only meaningful once it’s counting the same thing the regulator actually enforces.
What
A typical coverage percentage is calculated as mapped controls divided by total provisions in a framework. That arithmetic is fine — the problem is what goes into “total provisions,” and, just as importantly, what happens after something is marked mapped. Most GRC tools stop at the map. That’s the checkbox problem: a control gets ticked “met” once, at assessment time, and the percentage never moves again until someone remembers to re-answer the question.
786 Cyber’s platform is built to do more than draw the map correctly, though drawing it correctly is the foundation everything else depends on. The Controls Vault validates controls with AI assistance rather than taking a self-declared answer at face value. The Policy Vault and Policy Generator create and store the actual policy documents a control or a non-mappable provision depends on — not a checkbox saying “we have a policy,” the policy itself, versioned and exportable. The Evidence Vault holds the evidence a control’s status is actually based on, reused automatically across every assessment that needs it rather than re-uploaded per framework. None of this is a one-time exercise: a control’s status reflects what’s currently evidenced, not what was true the day someone filled in a form.
Take MFA, the exact control both ICO fines above turned on. In a checkbox GRC tool, “MFA enabled” is a self-attested answer a person ticks once. In 786 Cyber, MFA status is synced continuously from the identity provider itself — Microsoft 365, Google Workspace — and tracked honestly as enabled, disabled, or genuinely unknown, never assumed either way. That’s not a paperwork answer. It’s a live signal that changes the moment the underlying reality changes, which is exactly the kind of control status a coverage percentage should be built on if it’s going to mean anything at the moment someone actually needs it to be true.
That distinction — evidenced continuously rather than declared once — is the real angle this piece has been building toward, and it’s worth naming properly rather than leaving implicit. It’s three connected, industry-recognised disciplines: Continuous Controls Monitoring (CCM) — compliance status evidenced on an ongoing basis, not re-attested once a year; continuous posture management — technology and asset posture scored on an ongoing basis, not a snapshot from an annual test; and Continuous Threat Exposure Management (CTEM) — external threat and exposure signal continuously watched and prioritised against your actual assets, not a periodic scan. Most vendors sell one of these three. 786 Cyber runs all three off the same canonical control model and the same asset inventory, so a control’s status, a technology posture score, and a threat signal all trace back to one connected picture rather than three separate dashboards that never talk to each other.
Worth being precise about what that does and doesn’t mean. The continuous work described above is discovery, prioritisation, and mobilisation — routing a gap to the right fix, whether that’s an in-platform module, a documentation task, or a third-party recommendation. It runs on its own, without anyone having to ask it to, and that is exactly what the continuous claim above covers.
Active validation — actually testing whether an exposure is exploitable rather than theoretical — exists in the platform too, but as a deliberate action rather than part of that continuous loop. Testing & Validation runs consented, admin-gated active security testing: an active web scan against a target you authorise, plus DNS, IP and application-layer validation tools. That is genuine coverage of CTEM’s validation stage for web-application exposure, and it’s worth saying plainly. It is also deliberately fenced off — an administrator authorises each run, and the results never feed the automatic posture score, because a score you’re going to rely on shouldn’t move on the strength of a test somebody happened to run this week and didn’t run last week.
What the platform doesn’t claim is the rest of that stage: breach-and-attack simulation and live exploit testing across the whole estate. Naming the category honestly means being just as clear about the part that isn’t there as the part that is.
How
Three questions turn a vague coverage percentage into something you can actually trust, whether it’s coming from a vendor, an auditor, or your own internal tracking:
What’s the denominator — total articles, or total controls? If nobody can answer this precisely, the number isn’t measuring anything specific yet.
Can you see which provisions are excluded, and why? A trustworthy coverage claim can show its work: here are the provisions we excluded, and here’s the one-line reason each is non-mappable. 786 Cyber’s canonical model does exactly this for GDPR’s 119 excluded articles — each one is named and categorised, not waved away. The same discipline runs across every framework in the catalogue.
Is the answer behind that percentage current, or was it declared once and never rechecked? This is the question a checkbox tool can’t survive. A control marked “met” eleven months ago on a self-attested answer and a control whose MFA status was synced from the identity provider this morning wear the same green tick in most dashboards — and they are not the same claim.
786 Cyber’s Capability Gap Analysis applies the same discipline at the capability level that the canonical model applies at the framework level: every underlying capability is marked Evidenced, Unknown, or Declared, never assumed, and continuously — not a status frozen at assessment time.
The takeaway
A law is not a control set, a tool being present is not a control being met, and a single percentage can’t hold either distinction — so the right response to a coverage number isn’t to ask whether it’s high, it’s to ask what lens produced it and whether it’s still true today. Two ICO fines in 2025, worth £17 million combined, both turned on named, specific, mappable controls that had been true once and stopped being true — not on a definitions clause, because that isn’t what regulators enforce. Continuous Controls Monitoring, continuous posture management, and Continuous Threat Exposure Management are the three disciplines that keep a coverage percentage honest after the day it was first calculated. Most tools give you one. 786 Cyber connects all three to the same evidence.
Know what your coverage percentage counts — and whether it’s still true
See how Capability Gap Analysis marks every capability Evidenced, Unknown, or Declared, continuously — or start free and see your own framework coverage measured against what’s actually mappable.
Explore Capability Gap Analysis → · Start free — no card required →