The most useful CRA gap assessment begins with product scope and classification, then evaluates the cybersecurity risk assessment, Annex I requirement coverage, third-party component and SBOM readiness, vulnerability handling, Article 14 reporting readiness, Annex VII technical documentation, conformity-route preparation and support-period operations. Each finding should state what is missing, why it matters, what evidence will close it and who owns the remediation.
Define the Product Boundary Before Scoring Any Gaps
A gap assessment should begin with a defined product or product family. If the assessment boundary is vague, the team can score organisation-level policies while missing product-specific software, remote processing or versions that actually require evidence. Record the intended purpose, product architecture, remote dependencies and versions included in the assessment before assigning readiness scores.
- Identify the product or product family.
- Identify assessed versions.
- Record intended purpose.
- Record remote data processing.
- Record relevant external dependencies.
Separate Legal Decision Gaps From Technical Implementation Gaps
Not all gaps are missing security controls. A team can have strong engineering controls but still lack a documented CRA scope decision or classification conclusion. Conversely, the legal analysis can be complete while technical evidence is missing. Separate legal decision gaps, technical control gaps, process gaps and evidence gaps so remediation goes to the correct owner.
- Legal decision gap.
- Technical control gap.
- Process gap.
- Evidence gap.
- Ownership gap.
Assess Product Inventory and CRA Scope First
Check whether all relevant products have been inventoried and whether CRA scope decisions are documented with reasoning. A missing product is a structural gap because every later assessment can appear complete while the omitted product receives no risk assessment, documentation or conformity planning. Scope uncertainty should be treated as an open decision rather than silently scored as partially ready.
- Complete product inventory.
- Document CRA scope conclusion.
- Document exclusions or special rules.
- Identify scope uncertainty explicitly.
Assess Product Classification and Conformity Dependencies
Determine whether product classification is complete and whether the conformity plan reflects that classification. An unresolved important or critical product decision can affect whether manufacturer self-assessment remains available. Treat classification uncertainty as a high-priority gap where it blocks the Article 32 conformity-route decision.
- Confirm default, important or critical classification.
- Retain classification reasoning.
- Identify blocked conformity decisions.
- Escalate material classification uncertainty.
Evaluate the Cybersecurity Risk Assessment as a Core Dependency
Article 13 places the cybersecurity risk assessment at the centre of product design, development, production, delivery and maintenance. The gap review should therefore test whether a product-specific assessment exists, whether it reflects the actual architecture and threats, whether treatment decisions are documented and whether it is updated when relevant facts change. A generic corporate risk register is not automatically a substitute for the required product assessment.
- Product-specific assessment exists.
- Architecture and threats are represented.
- Treatment decisions are documented.
- Controls trace to risks.
- Update triggers exist.
Map Annex I Requirements and Identify Three Different Failure Modes
For each applicable Annex I requirement, distinguish among a control that does not exist, a control that exists but is inadequate for the identified risk and a control that appears adequate but lacks evidence. Those findings require different remediation. Also identify requirements marked not applicable without the clear justification expected in technical documentation.
- Missing control.
- Insufficient control.
- Missing evidence.
- Unsupported not-applicable conclusion.
- Unassigned requirement owner.
Assess Third-Party Component and SBOM Gaps
Review whether third-party components are known, whether due diligence exists and whether the SBOM can be generated and maintained with the component information needed for vulnerability handling. A useful gap finding should distinguish missing component visibility from missing supplier evidence or missing vulnerability linkage. Simply possessing an SBOM file does not prove the component-management process is ready.
- Component inventory completeness.
- Supplier or maintainer information.
- SBOM generation and maintenance.
- Vulnerability-to-component linkage.
- Third-party due-diligence evidence.
Assess Vulnerability Handling Across the Support Period
Review vulnerability intake, triage, remediation, testing, disclosure, update distribution and record keeping. Test whether the process actually connects findings to supported products and versions. A policy saying vulnerabilities are managed is not enough if teams cannot identify which product versions are affected or whether the product remains within its support period.
- Vulnerability intake works.
- Affected products can be identified.
- Risk-based remediation exists.
- Security updates can be distributed securely.
- Support-period coverage is known.
- Remediation evidence is retained.
Test Article 14 Reporting Readiness With a Scenario
Reporting readiness is easier to evaluate through a scenario than through policy review alone. Give the relevant teams a plausible actively exploited vulnerability or severe product-security incident and ask them to identify the affected product, awareness time, escalation path, required information and reporting workflow. Record where the process slows down or relies on one person who is not always available.
- Recognition of a possible trigger.
- Awareness-time capture.
- Product and version identification.
- Internal escalation.
- Reporting-system access.
- Decision and evidence retention.
Review Annex VII Technical Documentation for Evidence Quality
Do not score technical documentation only by whether files exist. Assess whether the documents describe the actual product and versions, reflect the current architecture, include the cybersecurity risk assessment, explain vulnerability handling, contain the required SBOM information and preserve relevant test evidence. Stale or generic documents can be an evidence-quality gap even when the folder appears complete.
- Product description is accurate.
- Versions are current.
- Architecture matches the product.
- Risk assessment is included.
- Vulnerability processes are documented.
- SBOM evidence exists.
- Test reports support the conformity case.
Assess Conformity-Route Readiness Separately From Technical Readiness
A technically mature product can still be unready if the manufacturer has not selected the applicable Article 32 conformity route or has not planned required third-party assessment. Confirm that classification and the conformity procedure are connected, that the evidence package matches the selected route and that external assessment dependencies are scheduled where necessary.
- Conformity route selected.
- Route rationale documented.
- Notified-body dependency identified where applicable.
- Evidence package aligned to the route.
- Open assessment findings tracked.
Assess Support Period and Post-Market Operating Gaps
Check whether the support-period decision has been made, documented and reflected in product operations. Verify that vulnerability handling, security-update planning, user information and end-of-support processes can operate for the stated period. A long support commitment without engineering and security resources behind it is an operational readiness gap even if the date itself has been documented.
- Support period determined.
- Reasoning documented.
- End date disclosed appropriately.
- Security maintenance resourced.
- End-of-support process defined.
Score Gaps by Consequence and Dependency, Not Only by Completion
A missing low-level document should not automatically receive the same priority as an unresolved product-classification decision or a missing vulnerability-management process. Score findings according to the cybersecurity or conformity consequence and whether other work depends on the decision. This produces a remediation order that reflects actual programme risk instead of rewarding easy administrative closure.
- Regulatory dependency.
- Cybersecurity consequence.
- Product exposure.
- Evidence dependency.
- Time needed to remediate.
- External dependency such as notified-body availability.
Give Every Gap a Closure Condition
A finding such as improve SBOM process is too vague to close consistently. Define the evidence that will demonstrate closure, the owner, target date and reviewer. Closure can require a document, technical control, test, approved decision or operating process depending on the gap. This makes reassessment objective and supports future dashboard automation.
- Clear remediation action.
- Named owner.
- Target date.
- Required closure evidence.
- Reviewer or approver.
Reassess After Material Remediation and Product Change
A gap assessment is a point-in-time diagnostic. Reassess major findings after remediation and revisit the assessment when product architecture, classification, suppliers, risk assumptions or applicable guidance changes. The objective is not to preserve a historical score. It is to keep the product's readiness record aligned with its current cybersecurity and conformity position.
- Verify closed findings.
- Retest technical remediation where appropriate.
- Review changed legal decisions.
- Update evidence links.
- Record the new assessment date.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.