Risk
ISO 14971 risk on the thread: not a sidecar spreadsheet
How ISO 14971 risk management should connect to requirements, tests, and SBOM — so mitigations and residual risk stay tied to the design they describe.
ISO 14971 is the medical-device standard for applying risk management to a product. Most teams know the vocabulary — hazards, harms, P1/P2, mitigations, residual risk, ALARP. The failure mode is architectural: the risk file lives in a sidecar (spreadsheet, separate eQMS module, or disconnected tool) while requirements and tests live elsewhere. The moment either side changes, the risk picture is stale.
“Risk on the thread” means each risk is a governed record linked to the requirements, tests, architecture, and components it touches — in the same system of record. That is the model behind traceunified Risk.
What ISO 14971 expects you to show
At a practical level, an auditor wants a path you can defend:
- Hazards identified in context of the device / software
- Risks scored (severity × probability, or your documented scheme)
- Mitigations defined and implemented
- Verification that mitigations work (often tests or design evidence)
- Residual risk evaluated and accepted with rationale
- Production and post-production information feeding back into the file
None of that requires a particular brand of software. It does require that the links between those steps are current.
Sidecar risk vs risk on the thread
| Pattern | What works | What breaks |
|---|---|---|
| Spreadsheet / disconnected RM tool | Familiar; flexible columns | No automatic suspect when requirements or CVEs change |
| Risk module in an ALM, unlinked | Better retention | Still a parallel document if links are optional |
| Risk as first-class links on the graph | Impact and coverage stay live | Requires discipline to author links, not just scores |
What to connect
- Requirements that implement or constrain mitigations
- Tests that verify mitigations and safety requirements
- Architecture / software items that realize hazardous situations
- SBOM components that introduce cybersecurity or supplier risk (see SBOM and FDA 524B)
When a linked requirement changes, or a new vulnerability lands on a component, suspect links should surface re-assessment work — not a quarterly spreadsheet reconcile.
Evaluation questions
- Show a hazard → mitigation → requirement → test path in one model.
- Change a mitigation requirement — what flags in the risk file?
- Can residual-risk acceptance be signed under Part 11 when you need it?
- Can you import an existing risk register and then link it, rather than only attach a file?
Related reading
See traceability work as one connected system.
Requirements, architecture, tests, risk, and SBOM on a single thread — audit-ready when you need it.