How it is created — SEC-RA Product Cybersecurity Risk Assessment (pre-development version)

1. Why the first version is written before the architecture

A risk assessment written after the hardware is chosen can only justify decisions already made. Written before, it constrains them — in the worked example, one risk removes a set of candidate microcontrollers from consideration. That is the whole point of the pre-development version, and it is why v0.1 must never be overwritten: it is the evidence that risk drove design rather than following it.

2. Inputs

• Intended purpose, deployment environment and foreseeable misuse (from the classification record).
• The planned system sketch: what talks to what, and over which link.
• The data the product handles, separated by sensitivity — telemetry is not the same as network keys.
• Your scoring method and acceptance thresholds. Fix them before scoring, not while arguing about a number.

3. Steps

1. Write the security context and assumptions before any scoring. Network exposure, physical accessibility, who can plausibly hold a unit in their hands, what data sits on the device and for how long. Every later score depends on these sentences, so they must be explicit enough to be challenged.
2. Run a workshop, not a survey. Two hours with the security lead, firmware lead, QA and product management produces better risks than any individual sitting alone with a template. Record who took part.
3. Enumerate threat scenarios per asset and interface. Keep them concrete — "network key extracted from a stolen node's flash" rather than "loss of confidentiality".
4. Score likelihood and impact against the fixed scale, and let the threshold decide the obligation: high risks require a design measure, mid risks a documented decision, low risks nothing but the record.
5. Derive a requirement or a decision for every scored risk. A risk with no consequence is a note, not a risk. Give each one an ID that the requirements sheet and the threat model can reference.
6. State the conclusions that bind the project: which hardware options are excluded, which requirements are mandatory before architecture freeze, which tasks become blocking pre-development work, and the support-period target every component decision must hold against.
7. Freeze the version. Record the versioning rule in the document itself: v0.1 pre-development, v0.2 after architecture freeze, v1.0 at the release gate — all retained.

4. Done when

• Assumptions are written down and would be recognisable to someone outside the workshop.
• Every risk above the threshold has a design measure or an approved acceptance, with an owner.
• The risk IDs are referenced by the threat model and the requirements sheet.
• The support period appears as an explicit input, because it drives component and update decisions.

5. Common mistakes

Scoring before the assumptions are agreed. Writing risks so abstract that no requirement can follow from them. Overwriting the early version once the design is known — which destroys the evidence that the assessment came first.

6. In TRA Studio

This is the core of the TRA module: product and environment definition, zones and conduits, security controls, threats and mitigations with a risk rating, and a risk summary you can export. Run the workshop against the tool and the record is a by-product rather than a separate writing exercise.