Coverage and AI

Governance → Coverage & AI

Coverage answers one question: which parts of our frameworks have no governing document behind them?

It is the fastest way to find where the policy library is thin, and the right time to look is before an audit rather than during one. A framework domain with no policy behind it will keep producing findings in every assessment until somebody writes the document.

How coverage is calculated

The page reads a framework's control tree and your organisation's policy ↔ control mappings, then counts.

Control reference numbers are read as a tree: 1 is a domain, 1-1 (or 1.1) a sub-domain, 1-1-1 a control. Both separators are understood, which is what lets the Saudi NCA catalogues — ECC-1:2021, ECC-2:2024 and CSCC-1:2019, all of which number with dashes — group the same way ISO and NIST do.

• Only assessable controls count — the leaves of the tree. Domain and sub-domain headers are structure, not requirements, and are not scored.
• A control is covered if at least one of your policies is mapped to it, at any strength.
• An uncovered control is an orphan.
• Coverage is covered ÷ total, per domain and for the framework as a whole.

The scan is deterministic. No model is involved, it sends nothing outside your network, and it produces the same answer every time from the same data.

Coverage and scaffold currently need governance AI switched on

Neither action uses AI, but both sit behind the governance AI-assistance consent switch. With that switch off, Re-scan and Generate scaffold are refused and the card stays empty — no percentage, no domains — which looks like a page that failed to load. An administrator can turn governance AI on in Settings → AI assistance.

Coverage measures mapping, not quality

A domain shows as covered the moment a document is mapped to its controls — including a document still in draft with an empty body. Coverage tells you whether something is claimed to govern the control. Whether it does is what assessments and audits are for.

Reading the page

Pick a framework; the scan runs automatically and re-runs when you change the selection, or on Re-scan.

You get the framework-wide percentage, covered-of-total assessable controls and the orphan count, then every domain with its ref-id, name, a progress bar and its covered/total. A domain with no mapped controls at all is flagged no policy — those are where to start.

Generate scaffold

Generate scaffold proposes the document structure a framework needs: one governing policy for the framework, with one procedure per sub-domain, each pre-mapped to the controls it covers.

• The policy is mapped secondary across every assessable control.
• Each procedure is mapped primary to its own sub-domain's controls.
• Each procedure is created as a child of the policy, so the hierarchy is right from the start.
• Categories are inferred from the framework's own domain names.

This is deterministic too — no model required.

What that looks like on NCA ECC-1:2021, whose 87 assessable controls sit in 5 domains and 24 sub-domains:

Governing policy	NCA Essential Cybersecurity Controls (ECC-1:2021) Policy
Procedures	24 — one per sub-domain, e.g. Cybersecurity Strategy Procedure for 1-1
Mappings created on accept	174 — 87 secondary on the policy, 87 primary across the procedures

Accepting it takes the framework from 0 to fully mapped in one decision. Every document lands in draft with an empty body: the structure is proposed, the content is still yours to write or draft.

The result is a proposal, not a document tree. Nothing exists until a manager accepts it on the review panel below; acceptance is what creates the policy and its procedures, all in draft.

Two things it will not do:

• If the framework already has coverage, it skips rather than proposing a second parallel structure — "this framework already has a governing policy".
• If a scaffold proposal is already open, it does not raise another. Concurrent runs are serialised, so clicking twice or running a readiness run alongside it cannot produce duplicates.

Draft all with AI

Batch-authors every empty draft document mapped to the selected framework — the natural next step after accepting a scaffold, which creates documents with titles and mappings but no body.

Each document is drafted by the same authoring agent used one at a time on a document page, run sequentially to stay inside provider rate limits and capped at 12 documents per run. Run it again for the next batch; the toast tells you when it capped.

Needs an AI provider and governance AI consent.

AI readiness run

The orchestrator. Give it a framework and an optional intent — "Get us audit-ready for this framework" — and it runs the whole sequence:

1. Assess — compute coverage.
2. Propose the scaffold for uncovered domains.
3. Draft content for any existing empty draft documents, if a model is configured.
4. Re-assess, count the open review queue, and return a plan.

You get coverage before → after, what was proposed, how many documents were drafted, how many proposals are waiting, and a list of recommended next actions.

The orchestrator generates. It never ratifies.

It does not accept a proposal, approve a document or publish anything. Every proposal it raises still needs a human decision, and every document it drafts still goes through review, approval and publication. The coverage number moving is the plan improving, not the policy library.

The review panel

Below the coverage and readiness cards sits the proposal review panel filtered to the selected framework — every pending suggestion, with Accept, Reject and Dismiss. Accepting one re-runs the scan, so the coverage figure above updates as you work through the queue.