How it is created — SDL-TMP-010 Risk Assessment Method & Template

1. Why this artifact exists

The CRA requires the product's security to follow from a risk assessment. An assessor reading one will ask what a "3" means, why 9 is the line, and who decided. If those answers live only in the assessment itself, every assessment answers them slightly differently and none of them is evidence of a method.

There is a second, less obvious reason. Risk scores are where inconvenient findings go to be quietly softened. A risk of 12 forces a design measure and possibly a different MCU; the same scenario at 8 needs a paragraph. Without anchored scales and a threshold fixed in advance, the difference between those two outcomes is a conversation held by people who would prefer the cheaper one — usually without anyone noticing that is what happened.

The method document is what makes that conversation visible. It is short by design: scales, thresholds, when to assess, and what the output looks like.

2. Inputs

• Your CRA classification and the Annex I Part I security properties — impact is scored against those, not against revenue.
• Whatever risk vocabulary the organisation already uses, so the security method does not contradict the functional-safety or quality one.
• One or two real past assessments, if you have them, to test the scales against. Scales that cannot reproduce a decision you already believe are wrong.
• The product lifecycle model, because when you assess turns out to matter more than how precisely.

3. Steps

1. Choose a coarse scale and commit to it. Four by four is enough for a two-hour workshop with four people. Larger scales buy apparent precision and spend real time arguing about whether something is a 6 or a 7.
2. Anchor every point on both scales with a sentence. Not "medium" — a description someone can check a scenario against. Unanchored scales produce numbers that cannot be defended six months later by the people who wrote them.
3. Define likelihood as attacker effort and opportunity, and say explicitly that it is not "how bad would this be". Teams conflate the two, then produce a comfortable product of them.
4. Put the key-material rule into the top impact band. For embedded products this single sentence does most of the work: a compromised device is one device, a compromised device that yields the network key is the whole installation. Without it, a stolen-node scenario scores as a local problem.
5. Fix the thresholds before the first assessment, and make the top band non-negotiable — a design measure, no acceptance available. A threshold agreed after the scores exist is not a threshold.
6. Say what happens when a high risk has no available measure: it escalates as a product-scope question. Otherwise it gets re-scored, and re-scoring after the treatment discussion has started is the most common way an assessment becomes fiction. Tell reviewers to look for exactly that.
7. Define the versions and their timing. A pre-development version that can still change the hardware, one after architecture freeze, one at the release gate. Then require that all of them are retained — the evidence of security by design is that the first one is dated before the design was fixed.
8. Specify the workshop: who, how long, what inputs, and the order — context and assumptions first, then scenarios, then scoring, then treatment. An unstated assumption is a risk nobody scored.
9. Require scenarios to be written as a path to a consequence. "No encryption at rest" is a finding and cannot be scored; "key extracted from a stolen node's flash, leading to mesh compromise" can.
10. Define the output formats: the register columns, the requirement ID scheme, and the documented-decision ID scheme. Then require that requirements not applicable to the product are marked with a justification rather than left blank — blanks are indistinguishable from oversights, and an assessor treats them as such.

4. Done when

• Every scale point has an anchor sentence someone can check a scenario against.
• Impact is defined against the essential security properties, not against commercial loss.
• Thresholds exist, the top band forbids plain acceptance, and the escalation path is named.
• The version timing makes it structurally clear that the first assessment preceded the design freeze.
• The output formats are specified, including how a not-applicable item is justified.
• A trial run reproduces the conclusions of an assessment you already trust.

5. Common mistakes

Scales without anchors. Scoring likelihood and impact together. Assessing after the architecture is frozen, which produces a document that can only ratify decisions already taken. Thresholds set once the scores are visible. Overwriting the pre-development version so the only surviving assessment is the one that agrees with the finished product. And listing missing controls as risks, which reads as diligence and cannot be scored, ranked or closed.

6. In TRA Studio

This is the document that decides whether risk scores mean the same thing across your products. The tool applies scales and thresholds consistently once configured; what it cannot supply is the anchor sentences or the judgement about where the design-measure line sits. Write those here, then check that the requirements your assessments derive actually land on activities in your lifecycle — a derived requirement with no activity behind it is a measure you decided on and never assigned to anyone.