ISO 14971:2019: what it actually requires of your risk management file
Standard & Framework · Medical Device Software
ISO 14971:2019 spreads one risk management file across 7 clauses (4 to 10), and each hazard analysis entry must link to its risk control and its verification record, or an auditor finds the gap first.
What does ISO 14971:2019 require of a risk management file?
ISO 14971:2019 spreads one risk management file across 7 clauses, numbered 4 to 10. Each hazard analysis entry must link to its risk control and its verification record, or an auditor finds the gap first.
ISO 14971 doesn't ask for a single risk document — it asks for a risk management file: a living record spanning risk analysis, risk evaluation, risk control, the overall residual risk evaluation, and production/post-production monitoring, each traceable to the others.
The risk management file is one linked chain, not five documents
For MedTech software, ISO 14971's core requirement is a risk management file that ties five activities together for every hazard identified in the hazard analysis: risk analysis (what could go wrong and how), risk evaluation (is the resulting risk acceptable), risk control (what reduces it), verification that the control actually works, and an overall residual risk evaluation once every individual control is in place. Production and post-production information — real-world incidents and near-misses — feeds back into the same file, not a separate log.
Where the chain most commonly breaks
| Chain link | What "broken" looks like |
|---|---|
| Analysis → Evaluation | A hazard is identified but never assigned a severity/probability estimate, so acceptability was never actually judged. |
| Evaluation → Control | A risk is judged unacceptable, but the control that's supposed to reduce it exists only in a design document, not the risk file itself. |
| Control → Verification | A software risk control (e.g. an input-range check) ships without a linked test record proving it actually fires under the hazardous condition. |
| Verification → Overall residual risk | Every individual control is verified, but no one re-evaluates whether the combination of residual risks is still acceptable. |
| Post-production → Analysis | A field incident is logged in a support ticket but never fed back into the risk management file to check whether it reveals a hazard the original analysis missed. |
Why this is a software-specific problem, not just a documentation one
For software, the control itself is usually code — an input validation, an interlock, an alarm threshold. That means "verification that the control works" is a software test record, not a physical inspection, and the same traceability discipline IEC 62304 requires for safety classification and verification records applies directly to the risk-control side of the file (see IEC 62304: what it actually requires of your software).
Engineering reference only. Not formal regulatory counsel. Consult your own quality system and legal counsel for a specific regulatory determination.
Useful next step
Provenance & review state
- Last reviewed
- Sources
-
- ISO 14971:2019 — International Organization for Standardization
- Ingested from
-