Fictitious example. ACME Embedded GmbH, its products, records and document IDs are invented for illustration. Use this as a structural model, not as a template to adopt unchanged — and not as legal advice.
SDL-TMP-010 — Risk Assessment Method & Template
| Document ID | SDL-TMP-010, rev. 3.0 |
| Owner | Product Security Lead (PSL) |
| Approved by | Managing Director, 2026-07-18 |
| Reference | CRA Annex I Part I(1) (risk-based security by design), Annex VII (technical documentation); SDL-POL-001 Phase 1; SDL-PROC-001 activities 1.3, 3.2; output feeds the threat model template SDL-TMP-011 |
| Applies to | Every ACME product with digital elements, at every stage from pre-development to release |
| Review | Annually, and whenever a risk assessment turns up a case the scales cannot express |
1. Purpose
This document holds the method: the scales, the acceptance thresholds, the workshop procedure, and the format of the two artifacts a risk assessment produces. Product risk assessments (SEC-RA-*) apply it and are the records; this document is why their numbers mean anything.
The scales are deliberately coarse. A four-by-four matrix is defensible in a two-hour workshop with four people; a ten-point scale invites an hour of arguing about whether something is a 6 or a 7, which is time not spent on the two risks that actually change the hardware selection.
2. Scales
Risk = Likelihood × Impact, each scored 1–4, giving 1–16.
Impact is assessed against the security properties of CRA Annex I Part I — confidentiality, integrity, availability, access control, and the protection of the product's own security functions — not against commercial loss. Commercial consequences are a business decision downstream; they must not silently deflate a security score.
2.1 Likelihood
| L | Anchor |
|---|---|
| 1 | Requires specialised equipment and physical access and knowledge not publicly available |
| 2 | A skilled attacker with a specific motive; targeted effort, no published technique |
| 3 | Documented technique with tooling available; plausible opportunistically, no insider knowledge |
| 4 | Trivially automatable, or already observed against comparable products in the field |
Likelihood describes the attacker's effort and opportunity, not how much ACME would dislike the outcome. Score it before looking at the impact column — scoring the pair together is how a team talks itself into a comfortable product of the two.
2.2 Impact
| I | Anchor |
|---|---|
| 1 | Negligible: no security property meaningfully affected |
| 2 | Limited: one device or one user, recoverable, no key material exposed |
| 3 | Significant: a security property lost for one installation, or device compromise without spread |
| 4 | Severe: compromise spreads (fleet, mesh, backend), or key material is exposed enabling further compromise, or availability or safety is affected at the customer |
The key-material rule in I = 4 is the one that matters most for embedded products. A stolen device is one device; a stolen device that yields the network key is the whole installation. Score the consequence, not the component.
3. Acceptance thresholds
| Risk | Treatment |
|---|---|
| ≥ 9 | A design measure is required. Acceptance is not available. The measure is recorded as a derived security requirement and, where it constrains hardware, as an input to component selection |
| 4–8 | A documented decision is required: mitigate, accept, or transfer — with a reason, an owner and a date. Recorded as D-YYYY-NN |
| ≤ 3 | Acceptable; recorded without further treatment |
A risk of 9 or above that cannot be given a design measure is escalated to the Managing Director as a product-scope question, not resolved by re-scoring it. Re-scoring a risk downward after the treatment discussion has begun is the single most common way a risk assessment becomes fiction, and reviewers are instructed to look for it.
4. When the assessment is performed
| Version | When | Purpose |
|---|---|---|
| v0.1 | Pre-development, before architecture decisions are frozen | The only version that can still change hardware selection and system design |
| v0.2 | After architecture freeze | Re-assessed against the concrete design |
| v1.0 | At the release gate | The as-built assessment; residual risks accepted by the PSL; goes into the Declaration of Conformity dossier |
All versions are retained in the QM repository. v0.1 is a fixed part of the Annex VII technical documentation and is never overwritten — the record that the risk assessment happened before the design was fixed is itself the evidence of security by design. Updates create a new version.
An additional version is created on substantial modification, which may re-open classification and conformity assessment (SDL-PROC-001 #4.6).
5. Workshop procedure
- Participants: PSL (chairs), firmware lead, QA, product manager. Four people is the working minimum — three of them will otherwise share one mental model of the product.
- Duration: two hours, timeboxed. A second session is better than a tired first one.
- Inputs: intended purpose and foreseeable misuse, deployment environment, data processed, interfaces and trust boundaries, and the product classification (REG-REC-*).
- Sequence: establish the security context and assumptions first (§6.2 of the template) — an unstated assumption is a risk nobody scored. Then enumerate threat scenarios, score L and I independently, then treat.
- Output: the risk register, the derived security requirements, and the documented decisions. Handover to the threat model (SDL-TMP-011), which decomposes the accepted design against STRIDE per element.
6. Template — SEC-RA-\<product\>
6.1 Header
Document ID · product and project number · reference (CRA anchor, method, downstream threat model) · prepared by and date · reviewed by · versioning rule.
6.2 Security context and assumptions
Deployment environment and network position · physical accessibility · data processed and its sensitivity · foreseeable misuse. Written as statements that could be falsified, because a later version will test them.
6.3 Risk register
| ID | Threat scenario | L | I | Risk | Decision / derived requirement |
|---|---|---|---|---|---|
| R-01 | One scenario per row: actor, path, consequence | 1–4 | 1–4 | L × I | Design measure, D-YYYY-NN, or "acceptable" |
Scenarios are written as a path to a consequence — "network key extracted from a stolen node's flash → mesh compromise" — not as a missing control. "No encryption at rest" is a finding; it is not a risk, and it cannot be scored.
6.4 Derived security requirements
SR-<product>-NN, one per requirement, each traceable to the risk that produced it, collected into the Security Requirements Sheet. The sheet must cover every applicable Annex I Part I property; properties with no requirement are marked not applicable with a justification, never left blank.
6.5 Conclusions
What is constrained as a result: hardware selection, mandatory requirements before architecture freeze, blocking pre-development tasks, and the support-period horizon that component decisions must hold against.
6.6 Version history
Version · date · stage · note. Every version retained.
7. Records
Risk assessments at every version, the Security Requirements Sheet, and the documented decisions D-YYYY-NN. Quality records, part of the technical documentation, retained 10 years after the last unit is placed on the market.
Revision history
| Rev | Date | Change | Approved |
|---|---|---|---|
| 2.0 | 2025-06-11 | 4×4 scales introduced, replacing the three-point scheme | MD |
| 3.0 | 2026-07-18 | Impact anchored to Annex I Part I properties; key-material rule added to I = 4; v0.1 retention rule made explicit; not-applicable justification required in the requirements sheet | MD |