On this page
- Annex I expects the risk assessment to inform the whole lifecycle.
- Scope it per product and version: assets, trust boundaries, foreseeable use.
- Map each risk to security requirements, controls, and the tests that check them.
- Residual risk needs a recorded acceptance decision - a human one.
What the regulation actually requires
Article 13(2)-(4) and Annex I require a documented cybersecurity risk assessment that informs the product lifecycle. It must address intended purpose, reasonably foreseeable use, conditions of use and expected use time; explain how product-security requirements apply and are implemented; and explain vulnerability handling. An inapplicable requirement needs a clear justification in the technical documentation.
Nothing mandates a particular method or template. What reviewers and notified bodies look for is coherence: the same risks appear in the analysis, the requirements, the test results, and the release notes - with versions attached.
Make it engineering input, not a PDF
A risk assessment that lives in a slide deck ages badly. Tie it to the artefacts engineering already maintains: threat models beside the architecture docs they describe, security requirements in the tracker beside the code they gate, test results stored with the release they ran against.
Residual risk is a recorded decision
Some risks survive mitigation and get accepted - that is normal. What the process owes the file is the record: who accepted the residual risk, on what rationale, against which version, and when the decision comes up for review. Acceptance is a manufacturer decision; automation can surface the risk but must never tick the box on its behalf.
Risk acceptance does not waive an essential requirement. A management signature cannot make a missing control or a known exploitable vulnerability conformant. Distinguish a reasoned residual-risk decision from an unresolved requirement that still needs work.
Frequently asked questions
Do we need a formal framework like ISO/IEC 27005?
The CRA does not prescribe a single risk-assessment framework. Under Article 27, a harmonised standard gives a presumption only for the requirements it covers and when its reference has been published in the Official Journal. An ISO method or certificate is not automatically a CRA harmonised standard.
Is a vulnerability scan a risk assessment?
No. Scans are one input. The assessment weighs findings against the product’s exposure, reachability, and use - a critical CVE in an unreachable library and one in the authentication path are not the same risk.