Design the dashboard around product-level exceptions and decisions. Show unresolved scope or classification as blockers, distinguish missing evidence from incomplete controls, surface supported products with overdue vulnerabilities or upcoming support milestones, and keep Article 14 deadlines visible where a reporting workflow is active. Executive summaries can aggregate the portfolio, but reviewers should always be able to drill down to the product facts behind the status.
Do Not Use One Compliance Percentage as the Legal Conclusion
A single percentage can be useful for programme management, but it can hide the difference between an uploaded document, a completed engineering control and a resolved legal decision. The dashboard should label scores as internal readiness indicators and keep legal conformity separate from workflow completion.
Make the Product the Primary Dashboard Unit
CRA work is product-specific. Start with a portfolio view that shows each product or controlled product family, current versions, market status, support status and responsible owner. Allow users to drill from the portfolio into the product's scope, classification, risk and evidence records.
Show Scope and Classification Decisions Separately
A product can be in scope while its important or critical classification remains unresolved. Display these decisions as separate states with the reviewer, date and reasoning available. Unresolved scope or classification should be visible as a blocker rather than converted into a partial percentage.
Surface Cybersecurity Risk Assessment Status
Show whether a current Article 13 cybersecurity risk assessment exists, when it was last reviewed, whether high-priority treatments remain open and whether reassessment triggers have occurred. Avoid displaying only an overall risk number without the underlying attack scenarios, controls and residual-risk decisions.
Separate Annex I Applicability, Control and Evidence Status
For each applicable Annex I requirement, the dashboard can distinguish whether applicability has been decided, whether the required design or process control exists and whether supporting evidence is current. This avoids treating a checked requirement as complete when the implementation or evidence is still missing.
Show SBOM and Third-Party Component Readiness
Useful component indicators include SBOM availability for current supported releases, stale component data, unsupported core dependencies, open supplier-security questions and component vulnerabilities awaiting applicability decisions. The dashboard should link to the underlying component and supplier records.
Track Vulnerability Handling by Supported Product
Display open vulnerabilities by affected product and version, remediation state, age, security-update status and support period. Prioritisation should reflect product risk rather than only raw ticket count. A product with one actively exploited vulnerability can require more attention than a product with many low-impact findings.
Create a Dedicated Article 14 Reporting View
When a potential Article 14 trigger is under assessment, show awareness time, affected products, reporting owner, 24-hour early-warning deadline, 72-hour notification deadline, submission state and final-report milestone. Keep this urgent workflow distinct from ordinary vulnerability and incident queues.
Measure Technical Documentation Quality, Not File Count
A folder can contain many files and still be weak. Dashboard status should reflect whether Annex VII evidence is current for the product version, whether the risk assessment and SBOM are linked, whether test reports support the relevant requirements and whether key records are stale or missing.
Track the Conformity Route and Assessment Findings
Show the product classification, selected Article 32 route, route rationale, notified-body involvement where applicable, assessment stage, open findings and declaration status. Do not label a product legally conforming merely because preparation tasks are complete.
Surface Support-Period Milestones
Track the approved support period, disclosed end date, supported versions, upcoming end-of-support milestones and products whose core dependencies lose support earlier than expected. This helps product and security teams plan vulnerability-handling capacity rather than discovering lifecycle conflicts late.
Show Owners, Due Dates and Blockers
Every open decision or remediation item should have an owner and due date. Flag structural blockers such as missing product scope, unresolved classification, missing risk assessment, unavailable conformity route evidence or unsupported critical dependencies separately from routine administrative tasks.
Use Different Views for Executives and Reviewers
Executives need portfolio risk, blockers, deadlines and trends. Product and compliance reviewers need the underlying evidence and decisions. Use role-specific views without creating separate sources of truth. Both views should derive from the same product records.
Keep Every Metric Explainable and Auditable
A reviewer should be able to click from a dashboard indicator to the product fact, requirement, evidence or decision that generated it. Preserve status history, reviewer actions and changes to calculations. Explainable metrics make the dashboard useful for governance without turning it into a black-box conformity engine.
Use Trends to Improve the Programme
Trend views can show whether evidence is becoming stale, remediation is slowing, reporting exercises are improving, support milestones are accumulating or conformity findings remain open longer. Use trends to allocate resources and improve processes, not to claim that an upward chart proves legal conformity.
A Practical Minimum CRA Dashboard
A minimum useful dashboard can show product count, unresolved scope and classification decisions, risk-assessment freshness, Annex I evidence gaps, open high-priority vulnerabilities, active Article 14 workflows, technical-documentation gaps, conformity stage and support-period milestones. Add metrics only when they lead to a clear review or operational action.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.