Treating the risk file as a submission artefact
A risk file written in the month before a submission describes a product nobody designed. The value of 14971 is in the decisions it changes while those decisions are still cheap to change.
ISO 14971Risk Management for Medical Devices
ISO 14971 is the international standard for applying risk management to medical devices. It defines a continuous process — identify hazards, estimate and evaluate risk, implement controls, verify they work, and monitor what happens in the field — that runs across the entire product lifecycle, rather than a document produced once before a submission.
- Full title
- Medical devices — Application of risk management to medical devices
- Edition
- ISO 14971:2019, with ISO/TR 24971:2020 as guidance
- Issued by
- International Organization for Standardization
- Applies
- Recognised internationally; harmonised under EU MDR
What it covers
- A risk management plan and risk management file, maintained for the life of the device
- Identification of hazards, foreseeable sequences of events, and hazardous situations
- Risk estimation as the combination of severity of harm and probability of its occurrence
- Risk control in a required order of priority: inherently safe design, then protective measures, then information for safety
- Verification that each control is both implemented and effective
- Evaluation of overall residual risk against clinical benefit
- Production and post-production information feeding back into the file
In practice
Software has no failure rate in the actuarial sense. A defect is either present or it is not, and if it is, it manifests whenever its triggering conditions occur — so probability estimates borrowed from hardware reliability do not transfer. The accepted approach is to treat the probability of a software failure as reasonably worst-case, and to concentrate the analysis on severity and on control.
ISO 14971:2019 also requires risks to be reduced as far as possible, rather than the older ALARP framing. Under EU MDR, economic considerations do not license leaving a reducible risk in place. ISO/TR 24971 carries the practical guidance the standard itself deliberately omits.
Where teams get it wrong
Merging security risk into safety risk
They run on different logic. Safety risk concerns harm to the patient; security risk assumes a capable adversary choosing the worst moment. They interact, but a single combined matrix usually serves neither. IEC 81001-5-1 exists for the security side.
Scoring probability until the number is acceptable
Sliding a probability estimate down one band until residual risk lands in the green cell is the most recognisable pattern in a weak risk file, and reviewers know it on sight.
Common questions
How do you estimate the probability of a software failure?
Generally you do not. Software has no failure rate in the actuarial sense — a defect is either present or absent, and manifests whenever its trigger occurs. The accepted approach is to treat the probability as reasonably worst case and concentrate the analysis on severity of harm and on risk control instead.
Is an FMEA enough to satisfy ISO 14971?
No. FMEA is a technique; ISO 14971 is a process spanning the product lifecycle. FMEA is also bottom-up, working from component failures, so it systematically misses hazards that arise from correct components combined badly, from foreseeable misuse, or from the absence of a function altogether.
What changed in ISO 14971:2019?
The 2019 revision strengthened benefit-risk analysis, expanded expectations for production and post-production information, and moved the practical guidance into the companion ISO/TR 24971. It also frames risk reduction as far as possible rather than the older ALARP wording — which matters under EU MDR, where cost is not a reason to leave a reducible risk in place.
Working out how ISO 14971 applies to what you are building is usually the first conversation.
Get in touch →