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, review triggers left unactioned, support period expiry, evidence past its validity date and Article 14 filing deadlines. Ten more checks cover the policy library, two for each of the five policies. Policy checks names them and says what makes each one pass or fail.
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. |
One check is advisory. The security.txt encryption check tests a recommended practice that no obligation requires. RFC 9116 makes the Encryption field optional, the CRA names no encryption, and your reporting form already reaches you over HTTPS. When it finds no key, its badge says Advice and the control keeps its status. The drawer shows the advice under Advice, below the next step.
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.
Reading the Checks column
The Checks column shows two things. The badge is the worst result among the control's checks. The text next to it counts the checks with that result, out of all the checks on the control. So "Failing 1 of 2" means that one of the two checks fails and the other does not. "Passing 3 of 3" means that all three checks pass. Hover over the cell to read the full sentence, for example "1 of 2 checks failing".
In the grouped view, the count covers every product in the row. "Failing 3 of 12" means that 3 of the 12 checks across those products fail.
A failing row also shows when its failing checks run next, for example "Next run in 11h". Hover over the cell to see the time in UTC. If you fixed the cause, that is when the row can turn green.
"None" means that no automated check runs against the control. Its status comes from what was recorded by hand.
Sometimes the text shows only a total, such as "2 checks". That means a check changed state after the last hourly status update. The next update corrects it.
To find the check that fails, click the row. The drawer lists each check by its ID, for example policy.incident_response.accepted, with its own result and the reason from its last run.
When checks run
Each check runs on its own schedule. A change you make does not run the check again. The control keeps its last result until the next run. For example, if two people acknowledge a policy in the evening, the acknowledgement check shows "Fail" until it runs the next morning. Then it passes and the control turns green.
| Checks | Schedule |
|---|---|
| Open SLA breaches, missed Article 14 deadlines | Every hour |
| SBOM on file, SBOM freshness, critical and known-exploited components | Every day at 06:30 UTC |
| Annex I checklist deadlines | Every day at 06:50 UTC |
| Documentation review cadence, unactioned review triggers, support period expiry, evidence validity | Every day at 07:10 UTC |
| The ten policy checks | Every day at 07:35 UTC |
| The three security.txt checks | Every Tuesday at 07:15 UTC |
| CVD policy reachable | Every Monday at 02:00 UTC |
The drawer shows the last run and the next run of each check, for example "Last run 13h ago · next run in 11h (26 Oct 07:35 UTC)". The next run is the last run plus the time between runs. If that time passes by more than 15 minutes and the check has not run, the drawer says "next run was due" with the time. That means the check missed its run.
When a check misses two runs in a row, its result shows "Stale".
Policy checks
Each of the five policies in the policy library has its own control in the register. The control has the name of the document followed by "(adopted document)", for example "Incident response plan (adopted document)". Two checks run against each of these controls.
| Check | ID in the drawer | Passes when | Fails when |
|---|---|---|---|
| Published and in review | policy.<policy>.published | The policy is published and its review date has not passed. | The policy was published and is not published now, or its review date has passed. |
| Acknowledged by the people asked | policy.<policy>.accepted | Every person asked has acknowledged the current revision, or is still inside their deadline. | A person asked is past their deadline and has not acknowledged. It also fails when the policy requires acknowledgement and nobody was asked. |
In the ID, <policy> is one of incident_response, vulnerability_handling, secure_development, sbom_management and support_period.
Both checks show "Not applicable" for a policy that you have not adopted or not published yet. The acknowledgement check also shows "Not applicable" for a policy that does not require acknowledgement.
The published check also runs against each company obligation that the policy discharges, so a lapsed review turns those obligations red too. The acknowledgement check runs against the policy control only.
Neither check reads uploaded evidence. To fix one, click "Next step" in the drawer. It opens the policy library at the policy's card.
- Published and in review fails. Review the text and publish it again. Publishing sets a new review date. It also starts a new round of acknowledgements.
- Acknowledged by the people asked fails. Ask each person who is late to acknowledge the policy. If a person signed on paper, record the acknowledgement from the policy page. A late acknowledgement counts, so the check passes at its next run. If nobody was asked, add people under "Settings → Personnel".
The summary strip
The strip at the top of the page shows your readiness percentage, a small trend line, and the change in percentage points since recording started. Next to it is one card for each of the five obligation pillars: Risk, Secure by design, Vulnerability management, Reporting and Conformity. Each card shows the percentage of the pillar's controls that are satisfied, then splits the work in two. Company counts the controls that belong to your company, such as obligations and policies, for example "49 of 82 met". Products counts products, not controls, for example "0 of 6 ready". A product is ready when every control of that pillar that applies to it is met. "None" means the pillar has no controls of that kind: Reporting (Article 14) is a company duty, and Conformity is per product. Below the split, the card shows how many controls are open and the date from which the pillar applies ("Applies now" for Reporting). No figure counts a control marked not applicable. An archived product has only not applicable controls, so it is not counted. These figures count register controls only. Article 14 filings and conformity state are not controls, so a card at 100% does not mean the pillar is complete. The dashboard pillar cards show the full state. Only Reporting (Article 14) applies now. The other four apply from 11 December 2027.
Click a card to show only that pillar's controls. Click it again to show all pillars.
The readiness trend
Click Show trend in the strip to open the full chart. It 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".
Grouping
By default the register shows one row for each control and product, with no grouping. The "Group by" menu on the toolbar has two more choices, Control and Scope.
Grouped by control
A technical file control is stored once for each product, so with six products the same requirement shows six times. Set "Group by" to Control to show one row for each control instead. The grouped row shows the worst status across your products, the count of each status (for example "4 in progress · 2 not started"), and the number of products.
Click a row that covers more than one product to see each product with its status, owner and due date. Click a product to open the drawer for that one control. A control that covers only one scope opens the drawer at once.
The list shows 50 rows at a time. Use Show 50 more or Show all at the bottom.
Grouped by scope
Set "Group by" to Scope to put the rows under one heading for each scope. Company obligations come first, then policies, then each product by name. Each heading shows how many rows are under it. The Scope column is not shown, because every row under a heading has the same scope.
Click a heading to fold its rows away. Fold every heading to see the open work for each product in one short list. A sort on a column applies inside each heading. Each heading shows 50 rows at a time, with its own "Show more" and "Show all".
Filtering
The search field, the Scope filter and the status tabs are on one toolbar. Scope shows one product, or Company-wide for company obligations and policies. A status tab with no controls is hidden unless you select it. The Filters link opens Type, Owner and the NIS2 or SSDF filter. It shows how many of these are in use, and it stays open while one is in use. All filters combine freely, and Reset clears them.
Applies now, Applies later and Any date split the list by the date from which the obligation applies (Article 71(2)). Only Article 14 reporting applies now, from 11 September 2026. All other obligations apply from 11 December 2027. The counts on these three tabs respect the other filters, so "Applies now 1" means one row is left when you click it. With any date selected, the controls that apply now sort first.
Sharing a filtered list
The address bar always holds the filters on screen, so you can copy it and send it. For example, /controls?status=failing&pillar=risk opens the failing Risk controls. A link also keeps its filters through sign-in. One filter is not in the link: a filter on a named owner. A link can travel to chat tools and logs, so it never carries a colleague's email address. The Unassigned owner filter does travel.
The register remembers your "Group by" choice in your browser for a year. A link that names a view (view=grouped or view=scope) wins over your choice. Search covers the control title, its key, its clause, its article codes and its NIS2 and SSDF references. 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 check runs for that control, 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.
Each check in the drawer shows its own result. A control with three checks and one failure shows one Fail and two Pass, so you can see which check turned the control red. A check whose result is too old shows Stale.
NIS2 and SSDF references
Each company obligation and technical file control shows the NIS2 provisions and NIST SSDF practices that its evidence can also support. Use the NIS2 or SSDF filter to list the controls that relate to one reference, for example NIS2 Art. 21(2)(d) for supply chain security or SSDF PS.3.2 for SBOM provenance. The control drawer lists each CRA requirement the control evidences, with its NIS2 and SSDF references.
The references come from the published CRA, NIS2 and NIST SSDF crosswalk. Porta Regulus B.V. made the mapping. No authority has published an official one. Read the references as places where one piece of evidence can serve more than one framework. They do not mean that a CRA control meets NIS2. The CRA applies to a product. NIS2 Article 21 applies to the measures an entity takes for its own network and information systems.
Policy controls show no references, because the obligation that a policy discharges already carries them. The references are calculated each time the register loads. They do not change a control's status or your readiness percentage.
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 Context and risk 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. |
A control that is red because of a check can need a different screen. Then the next step opens the screen that fixes the check.
| Failing check | Next step opens |
|---|---|
| A policy check on a company obligation, for example the incident response plan on "Article 14 notification contacts on file" | The policy library, at that document's card. |
| The security.txt checks and the CVD policy check | Reporting channel, which runs the same check on your website and shows what it found. |
| The four SBOM checks | The SBOM registry, to upload a current SBOM or work through its findings. |
| No open SLA breaches | Submissions, showing only the reports past their resolution target. |
| No missed Article 14 deadline | Submissions, showing only the reports with an overdue Article 14 stage. Record each stage on its report when you file it. |
The five Article 14 obligations that have no article behind them open the readiness page that records them. "Article 14 notification contacts on file", the RACI, the awareness procedure and SRP readiness open Procedure. "Reporting channel on your own website" opens Reporting channel.
Controls the Portal satisfies on your behalf have a next step too, worded See what the Portal produced. The checklist row it opens links to whatever the Portal generated.
A member or an auditor cannot open the Requirements tab, the Keep compliant tab or the admin forms. When the next step is on one of them, the drawer says that an admin of your account does the step, and shows no button.
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
Owners appear once a second person joins your account. With one member, every control is already that person's work, so the register hides the Owner column, the Owner filter and the checkboxes for bulk assignment. The drawer then shows only the due date. Due dates work the same for a team of one.
When a second person joins and no open control has an owner yet, a note at the top of the register says so. An admin can click Show unassigned work to list the open controls with no owner, then tick rows to assign them together. The note goes away as soon as one open control has an owner.
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.
- A control with no due date shows the CRA date in grey with the label CRA. That is 11 September 2026 for Article 14 reporting and 11 December 2027 for everything else. It only fills the gap. It never makes a control overdue, and a date you set replaces it. Satisfied and not applicable controls show no date.
- 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 every row the filters leave, also the rows below Show more, and the bar always shows how many are selected. In the grouped view, a row's checkbox selects that control for every product in the row.
- 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.