The Risk Assessment

What the assessment must actually contain

Article 13(3) is unusually specific for a regulation, and it reads as a checklist. The assessment must be documented, updated as appropriate during the support period, and comprise at least:

• An analysis of cybersecurity risks based on the product's intended purpose and its reasonably foreseeable use.
• The conditions of use — the regulation names the operational environment and the assets to be protected as examples.
• The length of time the product is expected to be in use, taken into account explicitly.
• Whether — and if so how — each Annex I, Part I, point (2) security requirement applies to the product, and how it is implemented as informed by the assessment.
• How the manufacturer applies Annex I, Part I, point (1) and the Part II vulnerability-handling requirements.

Two of these are where most drafts fail review. The first is reasonably foreseeable use: not how you intend the product to be deployed, but how a customer plausibly will. The second is the requirement-by-requirement applicability statement — a risk assessment that ends at a heat map, without mapping back to each Annex I property, does not meet the text.

For OT and ICS products the phrase "the assets to be protected" carries real weight. For an industrial gateway the assets are not only the device and its configuration; they include the downstream process, the equipment it controls, and — as Article 13(2) puts it — the health and safety of users.

Source: Reg (EU) 2024/2847 — Article 13(2)–(4).

Product risk is not organisational risk

Manufacturers with an ISO/IEC 27001 programme often reach for the risk register they already have. It is the wrong instrument.

Organisational risk management is the structured process by which an organisation identifies, assesses and addresses risks to its own business objectives. Product security risk management is about the products the organisation places on the market: how a malicious actor might exploit vulnerabilities in the product, and what that would mean for customers, downstream systems, or safety.

The CRA asks for the second. An enterprise risk register that lists "supply chain disruption" and "ransomware on corporate IT" answers a different question and will not survive a technical-documentation review.

Done properly, product risk management is what makes security built in — secure by design — and keeps the product resilient as new threats and vulnerabilities emerge, through updates and patches over the support period.

Source: CRACY (CRA Made Easy) — Risk Management Methodologies, deliverable D2.2, LSEC.

Six triggers for reassessment

Risk management under the CRA is not a one-time exercise. Article 13(3) requires the assessment to be updated as appropriate during the support period, and Article 13(7) requires manufacturers to document cybersecurity aspects systematically — including vulnerabilities they become aware of — and, where applicable, to update the risk assessment of the product.

CRACY translates that duty into six practical triggers across the product lifecycle:

• Design changes — features added or removed, architecture changes, refactoring.
• Software updates — new versions, patches, firmware changes.
• New threat intelligence — disclosure of vulnerabilities or attack techniques.
• Third-party component changes — new SBOM entries or library updates.
• Incident occurrence — failures or security events in the field.
• Regulatory updates — changes in harmonised standards or certification.

The practical consequence: the assessment needs a version history, and the trigger list belongs in your procedure, not in someone's memory. A reviewer who sees a risk assessment dated once, at release, is looking at evidence that the process is not running.

Source: CRACY (CRA Made Easy) — Risk Management Methodologies (trigger list); Reg (EU) 2024/2847 — Article 13(3) and 13(7).

Choosing a method that will survive review

The CRA names no methodology. That freedom is the trap: any method you pick has to produce what Article 13(3) and Annex VII demand, and most enterprise frameworks were not built for a product file.

The EU-funded CRACY project set out six criteria for judging whether a methodology fits a manufacturer of products with digital elements — three mandatory, three preferences:

Against those criteria CRACY recommends two methodologies as the most suitable foundations for SMEs: Adam Shostack's Four-Question Framework and OCTAVE Allegro. Everything heavier remains available, and relevant for organisations with more maturity or stricter regulatory demands — but is not the starting point.

Source: CRACY (CRA Made Easy) — Risk Management Methodologies, deliverable D2.2, LSEC. Criteria labelled MUST/SHOULD are CRACY's, not terms of the regulation.

The Four-Question Framework

Adam Shostack's framework ties naturally into STRIDE-based threat modelling and centres on four questions a team asks during design and development:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

It is a bare-bones approach, deliberately stripped of bureaucracy: short, repeatable risk discussions that fit an agile workflow and can be kept current as the product changes. Teams can adopt it in a matter of hours with some guidance, and it scales across software applications, embedded IoT devices and cloud services because the questions stay generic.

Where it stands against the CRACY criteria

CRACY scores it a pass on five of its six criteria — product and end-user focus, iterative integration of new data such as newly discovered vulnerabilities, low cost, domain-agnosticism, and minimal specialist skill. The one qualified result is documentation: the framework does not prescribe detailed documentation, though threats and mitigations can be captured in a risk register or report.

That gap is the whole caveat. It is not designed to be used standalone: it shifts much of the burden of formal risk assessment onto the accompanying threat-modelling practice, which then has to produce the artefacts the CRA technical documentation requires. Used as a lightweight practice feeding structured threat modelling, it works. Used alone, Article 13(3)'s requirement-by-requirement applicability statement will not be there.

Source: CRACY (CRA Made Easy) — Risk Management Methodologies, deliverable D2.2, LSEC; Adam Shostack, Four-Question Framework.

OCTAVE Allegro

OCTAVE Allegro comes from Carnegie Mellon University's Software Engineering Institute, and was designed specifically to reduce the complexity of the earlier OCTAVE and OCTAVE-S methods. It is qualitative and asset-driven — information assets, threats, vulnerabilities, impacts — and can be run without extensive security expertise or quantitative analysis.

Eight steps, grouped into four phases:

1. Establish risk measurement criteria — define how the organisation will evaluate the impact of risks.Phase 1 · Establish drivers
2. Develop information asset profile — identify and describe the assets critical to the product.Phase 2 · Profile assets
3. Identify asset containers — where those assets are stored, processed and transmitted.Phase 2 · Profile assets
4. Identify threats to assets — what could compromise them.Phase 3 · Identify threats
5. Identify vulnerabilities — weaknesses in the asset containers.Phase 3 · Identify threats
6. Determine impact — the consequences of realised threats.Phase 4 · Identify and mitigate risks
7. Risk mitigation approach — evaluate options and decide treatment strategies.Phase 4 · Identify and mitigate risks
8. Risk profile development — consolidate findings into a comprehensive risk profile.Phase 4 · Identify and mitigate risks

Why it fits the CRA

• It produces tangible outputs — asset profiles, threat lists, risk profiles — that drop straight into the Annex VII technical documentation.
• It is structured without being overly formal: feasible for an SME, yet strong enough to withstand external evaluation for important or critical products.
• Its asset-driven focus matches the CRA's insistence that products be designed and maintained securely across the lifecycle — and matches Article 13(3)'s "assets to be protected" almost word for word.

The OT reading of steps 2 and 3

For industrial products the asset-and-container steps are where an OT team already has the answer. Containers map onto the zone-and-conduit model an IEC 62443 assessment produces; the threat and mitigation steps map onto the threat-modelling and security-requirements practices of IEC 62443-4-1. If that work exists, the Allegro run is a re-cut of existing evidence rather than a fresh study — which is the same reuse the CRA Workbench is built to exploit.

Source: CRACY (CRA Made Easy) — Risk Management Methodologies, deliverable D2.2, LSEC (steps and CRA suitability); CMU SEI OCTAVE Allegro. Phase grouping shown for orientation.

The heavier frameworks, and when to reach for them

CRACY's deliverable also reviewed methodologies it does not recommend as a starting point for SMEs, but which stay relevant depending on organisational maturity or regulatory demands:

• FAIR — Factor Analysis of Information Risk.
• ISO/IEC 27005 and the ISO/IEC 31000 family.
• NIST RMF — SP 800-30, part of SP 800-37.
• CRAMM, EBIOS Risk Manager, MAGERIT, MEHARI.
• COBIT 5 for Risk, BSI IT-Grundschutz, CIS RAM, TARA.

Each offers a structured way to evaluate and treat risk, at varying cost in complexity and documentation. The reason to adopt one is usually external: another regulator already requires it, a customer expects it, or the organisation is large enough that a product-level method would sit oddly beside everything else.

Risk management under the CRA must remain traceable to product design and implementation.

That traceability is the acceptance test, whichever method you pick. A risk that is identified but never lands on a design decision, a requirement, or a documented justification is not evidence of compliance — it is a paragraph.

Source: CRACY (CRA Made Easy) — Risk Management Methodologies, deliverable D2.2, LSEC.