Risk treatment documentation should show that the cybersecurity risk assessment actually changed the product or its processes. For each material risk, record the decision, selected control, implementation owner, relevant Annex I requirement, verification method, evidence and residual risk. Where the manufacturer does not select an obvious control, document the technical reasoning rather than leaving the gap unexplained.
Risk Treatment Connects Analysis to Engineering Action
Article 13 requires manufacturers to take the outcome of the cybersecurity risk assessment into account during planning, design, development, production, delivery and maintenance. Risk treatment is the practical bridge between identifying a cybersecurity risk and changing the product or process in response. A risk record that identifies an important scenario but does not show what the manufacturer did about it provides weak evidence that the assessment influenced the product lifecycle.
- Identify the risk requiring action.
- Select a product or process response.
- Assign implementation responsibility.
- Define verification.
- Record the resulting residual risk.
The CRA Does Not Prescribe One Risk-Treatment Template
The Regulation requires a cybersecurity risk assessment and risk-informed product security, but it does not prescribe one universal risk-treatment worksheet, risk-acceptance form or approval hierarchy. Manufacturers can use existing engineering and risk-management systems if those systems provide enough traceability. Internal terminology such as mitigate, avoid, accept or transfer can be useful, but it should not be presented as though the CRA mandates those exact categories.
- Use an organisation-appropriate workflow.
- Keep statutory requirements distinct from internal methodology.
- Maintain traceability regardless of template.
- Do not present internal approval labels as CRA terminology.
Identify the Risk Before Recording the Treatment
Every treatment decision should reference a defined cybersecurity risk or scenario. Use a stable identifier linking the decision to the relevant product version, threat scenario, affected asset and risk assessment. This prevents controls from becoming disconnected security features with no clear purpose. It also allows reviewers to see whether several risks depend on the same control and whether a change to that control requires several risk records to be reassessed.
- Stable risk identifier.
- Affected product version.
- Related threat scenario.
- Affected asset.
- Pre-treatment risk rating.
Describe the Selected Control Precisely
Avoid treatment statements such as improve security or add encryption without defining what the control actually does. A useful record identifies the component, interface, configuration or process being changed and the security outcome expected from that change. For example, require signed update packages validated against a protected manufacturer key is more traceable than secure the update process. Precise control descriptions can later be verified and linked to technical documentation.
- Affected component or process.
- Expected security outcome.
- Implementation mechanism.
- Relevant configuration.
- Dependencies and assumptions.
Map Treatment to Annex I Requirements
A risk treatment can support one or more Annex I requirements. Authentication can support protection from unauthorised access. Signed updates can support integrity and vulnerability remediation. Rate limiting can support resilience against denial-of-service. Record the relevant Annex I mapping so the treatment contributes directly to the Article 13 applicability analysis. Where one control supports several requirements, identify the security outcome associated with each rather than treating one control as automatic proof of all related obligations.
- Identify applicable Annex I requirement.
- Explain the control-to-requirement relationship.
- Allow valid many-to-many mappings.
- Avoid unsupported compliance claims.
Record Why the Treatment Was Selected
The strongest treatment records explain why the selected control is appropriate to the risk. Relevant reasoning can include attack feasibility, impact, architecture, product constraints, state of the art, interoperability, update capability, safety interactions or expected operating conditions. This does not require a lengthy essay for every minor risk. Material decisions should provide enough reasoning that another qualified reviewer can understand why the chosen approach was considered proportionate.
- Risk reduction expected.
- Architecture rationale.
- Product constraints.
- Security trade-offs.
- Relevant standards or technical guidance.
Document Rejected Alternatives Where the Decision Is Material
For important security decisions, recording significant rejected alternatives can strengthen traceability. A team can decide not to expose a remote interface, choose hardware-backed key storage instead of software-only storage or isolate a parser instead of redesigning it immediately. The CRA does not require an alternatives table for every decision, but material trade-offs can help explain why the final design provides an appropriate level of cybersecurity based on the product's risks.
- Alternative considered.
- Reason not selected.
- Security implications.
- Operational or technical constraint.
- Residual risk created by the decision.
Assign an Accountable Owner
Risk treatment often crosses several teams. A security architect may define the requirement, an engineering team may implement it, and a test team may verify it. The treatment record should identify who is accountable for ensuring the control reaches completion. Contributors can be listed separately. Without clear ownership, unresolved security actions can remain open until late in the release process because every team assumes another team owns the final decision.
- Accountable control owner.
- Implementation team.
- Verification owner.
- Target release.
- Current status.
Define Verification Before Declaring the Risk Treated
A control should not be treated as effective merely because code has been merged or a configuration option exists. Define how the control will be verified. Depending on the security property, verification can include architecture review, unit or integration tests, configuration inspection, penetration testing, fuzzing, dependency analysis, update testing, resilience testing or manual process review. The verification method should reflect the original threat scenario and test whether the control interrupts or reduces that scenario as intended.
- Verification method.
- Expected outcome.
- Product and configuration under test.
- Test evidence location.
- Failure and retest process.
Record Residual Risk After Verification
Security controls often reduce rather than eliminate risk. After implementation and verification, reassess the original scenario and record the remaining risk. The residual-risk conclusion should reflect actual product behaviour and verified controls. If the remaining risk is considered unacceptable under the manufacturer's methodology, further treatment is required. If it is accepted internally, record the responsible decision and rationale without implying that internal risk acceptance overrides a mandatory CRA requirement.
- Reassess attack feasibility.
- Reassess impact.
- Record residual risk.
- Record approval where required.
- Do not use risk acceptance to waive mandatory Annex I obligations.
Treat Non-Applicability Differently From Risk Acceptance
A conclusion that an Annex I requirement is not applicable is different from deciding to accept cybersecurity risk. Article 13 requires clear justification in the technical documentation where certain essential cybersecurity requirements are not applicable. A manufacturer should not mark a requirement not applicable merely because implementation would be expensive or the risk has been internally accepted. Applicability should be based on the product, requirement and risk context.
- Assess legal applicability separately.
- Document clear non-applicability reasoning.
- Do not use cost alone as an applicability test.
- Do not confuse residual-risk acceptance with non-applicability.
Use Treatment Records to Build Technical Documentation
Risk treatment records can provide an index into the technical documentation. They can link a risk to architecture decisions, design specifications, software changes, configuration baselines, security tests and Annex I controls. The complete technical documentation remains broader than the treatment register, but well-maintained treatment records make it easier to demonstrate how the Article 13 cybersecurity risk assessment affected the product design and how the selected solution was verified.
- Link to architecture records.
- Link to security design.
- Link to implementation evidence.
- Link to test reports.
- Link to Annex I control mapping.
Review Treatment Decisions After Product Changes
A treatment can become ineffective when the product changes. A new interface can bypass an earlier control. A platform update can remove a security boundary. A new deployment option can invalidate an environmental assumption. Product-change review should therefore identify which treatment records depend on the changed architecture or process. Reassess residual risk and update technical evidence where the previous verification no longer represents the marketed product.
- Architecture changes.
- Interface changes.
- Dependency changes.
- Deployment changes.
- Control implementation changes.
- New vulnerability information.
A Practical Risk Treatment Record
A practical record can contain risk identifier, product version, treatment decision, selected control, relevant Annex I requirement, decision rationale, owner, implementation status, verification method, evidence reference, pre-treatment risk, residual risk, approval status and review trigger. The CRA does not prescribe this exact format. Its value is demonstrating that identified cybersecurity risks resulted in controlled, verified and traceable product-security decisions.
- Risk identifier.
- Treatment decision.
- Selected control.
- Annex I reference.
- Decision rationale.
- Control owner.
- Verification method.
- Evidence reference.
- Residual risk.
- Review trigger.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.