Control status and coverage

Summary

• Coverage is the share of a control's required evidence items that are covered by a Valid, qualifying evidence record or an Approved policy, rounded to a whole percent. A control with no required items reads 100.
• Two automatic paths move status. The coverage check sets Implemented at 100 and drops an Implemented control to Pending review below 100. The linking path moves a control from Not implemented or In progress to In progress or Pending review.
• Those paths fire on evidence link, unlink, and status change, on policy link and unlink, and on privacy-evidence expiry or deletion. They do not fire after a sync or on policy approval, and automatic flips write no entry in the control's log.

Concepts

Required evidence items are the catalog's predefined evidence slots for a control (ids such as E-AM-02). A requirement-level link names one of those slots; a control-level link does not. The same distinction exists for policies, whose links also record whether you made them by hand or Noru generated them.

How it works

Which requirements count as covered

An evidence record covers a requirement when all three hold:

1. It is linked to that exact requirement, not just to the control.
2. Its status is Valid.
3. It qualifies; see Qualification. Uploads, links, notes, and synced evidence always qualify; platform-generated records mostly do not.

An Approved policy covers a requirement when it is linked to that requirement and either the requirement is of policy type, or you linked the policy to that requirement by hand. Control-level links never count, for evidence or for policies.

Coverage is then covered items divided by required items, times 100, rounded to a whole number, and 100 when the control has no required items.

Organization-level coverage

The dashboard figure applies the same per-requirement test across every control of every enabled framework, over the set of unique required items, and reports a per-framework breakdown. Controls with no requirements are excluded from that percentage rather than counted as full. The report count on a control comes from the report types that evidence it; see Risk scoring and reports.

Path one: the coverage check

The coverage check runs after the triggering change and never blocks it.

1. If the organization has no enabled frameworks, stop.
2. If the current status is Archived or Not applicable, stop.
3. Compute coverage as above.
4. If coverage is 100 and the status is not Implemented, set Implemented.
5. If coverage is below 100 and the status is Implemented, set Pending review.
6. Otherwise change nothing.

The change is written directly to the control's status. It does not add an entry to the control's log and does not touch the status reason you may have set earlier.

Path two: the linking path

When evidence or a policy is linked to a control whose status is missing, Not implemented, or In progress:

• If the control is now fully enabled (it has a control-level link, or it has no requirements, or every requirement has at least one link, regardless of status), the status becomes Pending review with the reason "Control fully enabled through evidence linking" (or "policy linking").
• Otherwise it becomes In progress with the reason "Control partially enabled through evidence linking" (or "policy linking").

The same step creates a control implementation record if none exists, with risk level Low, priority Medium, and the linking user as owner. Mappings written by cloud and SOC 2 auto-mapping deliberately skip this path, so they never move status.

What triggers the automatic paths

A sync writes its control mappings without a status side effect. A policy approval changes the policy's status; the next coverage number you see is computed on read, but no control flips until one of the listed events happens.

What gets logged

Statement of Applicability export

Export SoA produces a CSV file named after the export date. For ISO 27002-family frameworks it emits one row per Annex A clause with columns ID, Control Name, Applicability, Implementation Status, and Implementation Details; a clause is "Not Applicable" only when every catalog control mapped to it is Not applicable. For other frameworks it is one row per control with applicability derived from status, a justification taken from the status reason, implementation notes, and the titles of linked evidence. The stock justification for excluded controls is "N.A. - Excluded by scope and risk assessment."

Edge cases and failure modes

• A control flipped to Pending review and nobody touched it. Something reduced coverage: an evidence record left Valid, a policy left Approved, a link was removed, or privacy evidence expired. Look at the control's log for "evidence removed", then at the evidence and policy logs.
• Coverage is 100 but the status did not change. Either the status is Archived or Not applicable, the organization has no enabled frameworks, or the last change was a sync or a policy approval, neither of which triggers the check. The next qualifying event will set it.
• The linking path only moves early statuses. A Planned or Pending review control is left alone by linking; only the coverage check can promote it to Implemented.
• Auto flips leave no log entry. The status changed but the control's log shows nothing. Your status reason from an earlier manual change is left untouched.
• A control-level link does nothing for coverage even when the file is valid and qualifies.
• The check never blocks your action. If the coverage check fails, the triggering action still succeeds and the status is simply not updated.

What you can influence

• Status by hand at any time; a manual status change is logged with your reason, but the next automatic event may move it again unless it is Archived or Not applicable.
• Requirement-level links and evidence status are the two levers that change coverage.
• Policy links: linking an approved policy to a non-policy requirement by hand makes it count there.
• Scope: mark controls Not applicable with a reason; the SoA export uses it as the justification.

Related guides

• Controls
• Control detail
• External audit
• Frameworks
• Statuses
• Evidence lifecycle and integrity