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, technical file controls come from each product's assessment, and policy controls come from the documents you adopted in the policy library. 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.
A policy control is not a duplicate of the obligation it discharges, which is why both appear. The obligation asks whether the box is ticked. The policy control, marked (adopted document) and filtered under Policy, asks whether that document is still published, still within its review date and still acknowledged by the people who were asked. A tick cannot go stale; a document can.
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 and FprEN 40000-1-2 normative requirement codes (
RMA-01toRMA-09for Clause 6 risk management,CLA-01toCLA-10for Clause 7 lifecycle activities) that reference it, so searching forPRE-2orCLA-04finds everything that requirement 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
Fifteen checks run on a schedule against your live setup. They cover the published security.txt, its expiry and whether it advertises an encryption key, the reachability of your CVD policy page, whether an SBOM is on file and has been refreshed in the last 90 days, critical and known-exploited components in it, Annex I checklist deadlines, acknowledgement SLAs, documentation review cadence, support period expiry, evidence past its validity date and Article 14 filing deadlines.
Some obligations are ones the Portal answers on your behalf, so they show as satisfied without anyone ticking them. Your software component inventory is the clearest case: five obligations are reported straight out of the SBOM you upload. For those, the automated check is the only thing that can contradict the Portal, so it fails outright when no SBOM is on file rather than staying quiet. An obligation reported from a file that does not exist is not satisfied.
The SBOM freshness check is worth understanding, because it changes how you read the two component checks next to it. Advisory matching runs against the versions your stored SBOM pins, so a component you upgraded months ago keeps matching its old advisories until you re-upload. Without a freshness signal that backlog reads as a live supply chain exposure. If the freshness check is failing, treat the critical and known-exploited counts beside it as questions about an old snapshot rather than as findings about what you ship today, and re-upload before working through them. See Managing the SBOM Registry.
The two component checks count only findings that are open. Once a scan sees that a component no longer matches its advisory, the finding is marked resolved and drops out of both counts, so these checks return to passing after an upgrade without anyone clearing them by hand. The resolved findings stay on record as evidence that the exposure was handled.
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 a security.txt check with no monitored domain set. |
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.
Every check reports something, including the ones that do not apply to you. A check with no data to work on records "not applicable" with a reason naming what would switch it on, rather than staying silent. So a product with no Annex I assessment says so on its deadline check, and a check that needs a higher plan says that instead of leaving a blank. This matters because a silent check and a passing check used to be indistinguishable on the card, and the first one is not evidence of anything.
Read those deliberately. They are the opposite of a pass: a pass means we looked and your setup holds, and "not applicable" means there was nothing to look at yet. A register full of them is not a register full of green.
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.
Organizational roles determine which controls apply to your account. When you select non-manufacturing roles such as distributor or open-source software steward, controls for obligations that belong only to manufacturers are marked not applicable and drop from the denominator.
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.
Getting the work done
Nothing in the register changes a control's status, because the register does not own it. The obligations checklist, each product's technical file and the policy library do. So every control's drawer carries a Next step button that opens the screen that does own it, scrolled to that exact row.
Where it takes you depends on the control.
| Control | Next step opens |
|---|---|
| A company obligation | The obligations checklist on Readiness, with the article expanded and the artifact highlighted, ready to tick, note and attach evidence. |
| A clause 6.2 product context input | The product's Assess tab, at that input. |
| Any other technical file artifact | The product's Requirements tab, at that artifact, where you can draft it. |
| A policy | The policy library, at that document's card, to adopt, edit, publish or request acknowledgement. |
Controls the Portal satisfies on your behalf have a next step too, worded See what the Portal produced. There is nothing to tick on those, but a failing check still turns one red, and the checklist row it opens links to whatever the Portal generated so you can see what the check is objecting to.
If the section you land in was collapsed the last time you were there, the link opens it anyway. Collapsing a section is a standing preference; asking to see one specific row is a direct request, and the direct request wins.
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.
Assigning several at once
A new account has hundreds of unassigned controls, and setting them one at a time is not a real option. Tick the checkbox on any row and a bar appears above the table with an owner list and a due date.
The intended path is to filter first and select second. Set the owner filter to Unassigned, narrow to one pillar or one product, then use the checkbox in the table header to take everything left. That header checkbox covers exactly the rows the filters left in view, and the bar always shows how many are selected.
- Both fields default to No change, because there is no single current value across a selection. Only the fields you actually move are sent, so setting an owner for forty controls will not quietly clear forty due dates.
- Up to 200 controls in one go. Beyond that, narrow the filters and apply in passes.
- Controls the Portal satisfies on your behalf are skipped rather than assigned, and the confirmation says how many. Putting a person's name against work no person does only adds noise to their list.
- The whole action is one entry in the audit log, not one per control.
A selection survives changing the filters, so you can gather rows from more than one view before applying.
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.