CRA gap analysis
Sytance · Updated
A CRA gap analysis compares the current product and manufacturer processes with the CRA requirements that apply to that product. The term is an implementation method, not a separate duty named by the Regulation.
Legal basis for the comparison
Use the product’s applicable CRA requirements as the basis for comparison. Articles 6 and 13 establish the product and risk-assessment duties; the annexes specify the security requirements and information to be provided. Include any standards or technical specifications relied on for the assessment.
- Article 6 and Annex I decide the product and vulnerability-handling requirements.
- Article 13 requires the cybersecurity risk assessment and support-period reasoning.
- Annex II lists user information and instructions.
- Annex VII lists technical-documentation content.
- Article 32 decides the conformity assessment route after classification.
- Harmonised standards or other technical specifications can help show how requirements are met, but their legal effect depends on status.
What a gap means
A gap can concern the product, the manufacturer’s process or the evidence supporting a conclusion. For example, an update mechanism may lack signature verification, or the mechanism may exist but have no test result showing that it rejects a modified package. These findings require different actions.
Requirement gap
The product or process does not yet meet an applicable requirement.
Evidence gap
The product may have the measure, but the technical documentation does not show it clearly.
Analysis gap
The risk assessment or applicability reasoning is missing or too broad for the product.
Route gap
The standards, certification, or conformity-assessment route is assumed but not supported by source status or product category.
Example: closing a secure-update gap
A fictional controller already has signed firmware updates, but the team has not tested whether the device rejects an image signed with an untrusted key. The gap starts as missing evidence. If testing shows that the device accepts the image, it also becomes an implementation gap.
- Basis: link the applicable Annex I requirement, the risk assessment, and the secure-update design. State the exact product version and configuration.
- Finding: describe the missing test or observed behaviour. Keep an untested assumption separate from a demonstrated failure.
- Action: assign the firmware team to implement any needed change and the verification team to test the affected update paths. Set a completion date that fits the product release decision.
- Closure evidence: attach the revised design or change reference, test results for the relevant build, and the updated risk assessment. Include a reason if an existing test result remains valid.
- Review: the responsible reviewer checks the original gap against the new evidence. A completed task or an uploaded report alone does not show that the gap has been resolved.
For each gap, identify the requirement and explain what is missing. Assign the work and define the result needed for a reviewer to accept the correction. Record that review with the supporting evidence.
A completion percentage measures the entries in that checklist. It does not show the severity of remaining gaps or prove conformity. An unresolved update-authentication failure can matter more than several finished documentation tasks.
Inputs to the gap analysis
A gap analysis needs a defined product scope and a supported classification and conformity route. Otherwise, it may compare the product with requirements that do not apply or miss requirements that do.
The risk assessment is the main input for deciding which Annex I product requirements apply. The technical documentation is where the result and evidence are collected. See Cybersecurity Risk Assessment and Technical Documentation.