The Control Register

The Control Register at Controls in the dashboard is one row per CRA control for your account, with the automated checks that run against it and a daily record of how your readiness has moved.

It is a view over work you have already done elsewhere. Company obligations come from the obligations checklist, and technical file controls come from each product's assessment. Nothing here replaces those screens or changes the numbers they show. What the register adds is a single place where every control can be filtered, sorted and drilled into, and where a machine can mark one red.

What a control is

A control is one requirement, held as a row rather than a checkbox. Each carries:

• A status. Satisfied, failing, overdue, at risk, in progress, not started, or not applicable.
• The CRA articles that reference it, so searching for PRE-2 finds everything that article depends on.
• An owner and a due date, where one exists.
• Zero or more automated checks, with the outcome and reason from the last run.

Company-wide controls appear once no matter how many articles reference them. That is deliberate and matches how the obligations checklist has always counted: a single published CVD policy satisfies six articles at once, and counting it six times would misstate how much work is left.

Automated checks

Twelve checks run on a schedule against your live setup. They cover the published security.txt and its expiry, the reachability of your CVD policy page, SBOM freshness and known-exploited components, Annex I checklist deadlines, acknowledgement SLAs, documentation review cadence, support period expiry and Article 14 filing deadlines.

A failing check turns its control red with nobody logged in. That is the point of the register: if your security.txt expires in September, the control that depends on it stops being satisfied on its own.

Four outcomes, and the differences matter.

Outcome	Meaning
Pass	The check ran and the requirement holds.
Fail	The check ran and the requirement does not hold. The control turns red.
Inconclusive	The check could not reach a verdict, usually an upstream service being unavailable. Your control is not marked failing for somebody else's outage.
Not applicable	The check does not apply to you yet, for instance an SBOM check with no SBOM uploaded.

A control whose check has never run reads as neutral rather than as a problem, and a satisfied control whose check stops reporting becomes at risk rather than failing. "We stopped checking" is a different fact from "the check failed", and the register keeps them apart.

The readiness trend

The chart above the register shows satisfied controls as a share of those in scope, recorded once a day. Controls you have marked not applicable leave the calculation entirely, so scoping something out raises the number rather than capping it.

Two things to know about it.

There is no history before the day the recording started. Readiness is captured once a day going forward and nothing reconstructs the past, so the chart reads "collecting since" until it has two days to draw a line between. This is a deliberate choice: a trend that fills its own gaps is not evidence.

Days the recording missed are stated, not hidden. If the daily job did not run, the chart says how many days in the span were never captured rather than drawing a straight line across them.

The axis is fixed at 0 to 100 percent. Change across the window is reported in percentage points, so a move from 60% to 68% reads as "+8 pts".

Filtering

The status tabs across the top narrow to what needs action, and the filters below combine freely. Search covers the control title, its key, its clause and its article codes. Between them you can answer questions the checklist could not, such as which failing controls a particular colleague owns.

Clicking any row opens a drawer with the control's full description, its owner and due date, and the last thirty runs of every check bound to it, each with its outcome, reason and timestamp. That run log is append-only and is the evidence trail an auditor or notified body would ask for.

Owners and due dates

By default a control's owner and due date are read from the assignments already recorded against the product, and they update whenever those do. From the drawer an account admin can override either one.

The moment you set an owner or a due date by hand, that field stops being updated automatically for that control. This is deliberate. An assignment you made yourself should not disappear overnight because a background job recalculated it.

To hand a field back, pick Tracked from the assignment in the owner list, or use Track this from the assignment instead under the due date. The field is cleared and repopulated from your assignments.

A few details worth knowing.

• An owner must be someone with an account on your workspace, so that whoever owns a control can actually be notified about it.
• Due dates are recorded as calendar dates in UTC, so a control goes overdue on the same day for everyone regardless of where your team sits.
• Setting a past due date marks a control overdue, but it will not override a failing automated check. A machine reporting on your live system takes precedence over any date.
• Every change is written to the audit log with who made it, what changed and when.

Account members with the read-only role can see owners and due dates but cannot change them.

What it does not do yet

The register's own numbers are not yet used in place of the readiness figures on the dashboard and the product pages. Those remain the authoritative ones for now.