Use the template as a structured evidence record, not a scoring shortcut. The assessment should explain which cybersecurity risks matter for the product, how those risks informed Annex I requirements and design decisions, and how the assessment will be updated during the support period. It should remain linked to product architecture, controls, tests, vulnerabilities and changes over time.
Article 13 Requires the Assessment, Not a Particular Template
Article 13(2) requires manufacturers to undertake an assessment of the cybersecurity risks associated with the product and to take the outcome into account across planning, design, development, production, delivery and maintenance. The Regulation specifies content and lifecycle expectations but does not prescribe one official table or worksheet. A template is therefore an internal structure for satisfying and evidencing those requirements.
Section 1: Product Identification and Assessment Scope
Start with the product name, model or version, legal manufacturer, intended purpose, assessment owner, assessment date and the product boundary being assessed. Link the record to the controlled product inventory so that the assessment cannot become detached from the release or product family to which it applies.
Section 2: Intended Purpose and Reasonably Foreseeable Use
Article 13(3) requires the analysis to be based on intended purpose and reasonably foreseeable use. Record normal users, expected deployment patterns, likely misuse or configuration patterns that can reasonably be anticipated, and any assumptions that materially affect cybersecurity risk.
Section 3: Conditions of Use and Operational Environment
Record the environments in which the product is expected to operate, such as enterprise networks, consumer networks, industrial environments, mobile devices or cloud-connected settings. Article 13 specifically refers to conditions of use and gives the operational environment as an example of relevant context.
Section 4: Assets to Be Protected
Identify the assets whose confidentiality, integrity, availability or other security properties matter. Depending on the product, these can include credentials, configuration, personal or operational data, cryptographic material, update channels, device control, safety-related functions and services relied upon by other systems.
Section 5: Threats and Attack Scenarios
Describe plausible threat sources and attack scenarios that could affect the product in its intended and reasonably foreseeable conditions of use. The CRA does not mandate one threat-modelling methodology, so the template should preserve the reasoning used rather than forcing every product into the same threat taxonomy.
Section 6: Risk Analysis and Treatment
For each material scenario, record the potential impact, likelihood or other risk basis used by the manufacturer, the resulting risk conclusion, the selected treatment and the evidence expected to demonstrate implementation. The method should be internally consistent and appropriate for the product rather than designed only to produce a low numerical score.
Section 7: Annex I Part I Applicability
Article 13(3) requires the assessment to indicate whether and how the security requirements in Annex I Part I point 2 are applicable and implemented, informed by the cybersecurity risk assessment. The record should therefore map material risks to applicable product-security requirements and explain any requirement treated as not applicable.
Section 8: Secure-by-Design and Vulnerability-Handling Approach
The assessment must also indicate how the manufacturer is to apply Annex I Part I point 1 and the vulnerability-handling requirements in Part II. Record the product-level approach to secure design, vulnerability intake, remediation, security updates, dependency monitoring and related lifecycle processes that address identified risks.
Section 9: Expected Duration of Use and Support Period
Article 13(3) requires the assessment to take account of the length of time the product is expected to be in use. Connect that expectation to support-period planning, component support assumptions and the period over which risk, vulnerability and update processes need to remain effective.
Section 10: Residual Risk, Open Actions and Evidence
Record risks that remain after treatment, unresolved design or testing actions, evidence still required and the decision owner for accepting or further reducing residual risk. The template should distinguish incomplete evidence from an accepted technical risk so that both are not hidden behind one status field.
Section 11: Review Triggers and Change History
Article 13(3) requires the cybersecurity risk assessment to be documented and updated as appropriate during the support period. Define review triggers such as architecture changes, new core functionality, new deployment environments, serious vulnerabilities, important component changes, substantial modifications or significant changes in threat information. Preserve the assessment history instead of overwriting earlier reasoning.
Include the Assessment in the Technical Documentation
Article 13(4) requires the cybersecurity risk assessment to be included in the technical documentation required by Article 31 and Annex VII. The readiness template should therefore be managed as controlled compliance evidence and linked to the architecture, tests, standards, component and vulnerability records that support its conclusions.
Do Not Confuse the Risk Assessment With Conformity Assessment
The Article 13 cybersecurity risk assessment informs product design and the application of Annex I requirements. It is not the same as the conformity assessment procedure selected under Article 32. A readiness system should connect the two while keeping their purposes and evidence records distinct.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.