Guide
ISO 14971: A Risk File That Lives From Concept to Post-Market
ISO 14971:2019 is the global standard for risk management of medical devices and the methodology every notified body and regulator expects to see behind your design controls, your CER, your PMS plan, and your CAPA. The 2019 revision tightened the language around benefit-risk analysis, residual risk acceptability, and the production-and-post-production feedback loop — the parts of risk management most companies historically did badly. This guide walks through the standard's structure, the artefacts that make up a defensible Risk Management File (RMF), and a practical path to a risk process that actually changes design decisions and post-market actions. It is written for risk managers, design engineers, QA leads, and regulatory affairs at device manufacturers.
Start free trial Free trial, no credit card, onboard in days, not months.
Vocabulary that auditors will hold you to
ISO 14971 separates terms that companies routinely mix up, and notified body reviewers test the distinctions. A hazard is a potential source of harm. A hazardous situation is the circumstance in which people, property, or the environment are exposed to one or more hazards. Harm is the actual injury, damage, or loss. Risk is the combination of the probability of occurrence of harm and the severity of that harm. A risk control measure reduces probability, severity, or both. Residual risk is the risk remaining after risk control measures have been taken. Using these terms loosely in the RMF is the easiest way to lose credibility — a hazard analysis that lists 'patient injury' as the hazard, or a control that targets a harm rather than a hazardous situation, signals an immature process.
The Risk Management Plan and File
Clause 4.4 requires a Risk Management Plan per device or device family, signed by top management, covering the scope, the risk acceptability criteria, the methods of risk analysis and evaluation, the responsibilities, and the post-production information feedback. Clause 4.5 requires a Risk Management File that contains, or references, all records and documents produced by the risk management process. The RMF is the auditor's single source for risk — fragmented files across SharePoint folders and project trackers are a perennial finding. Build the RMF as the live aggregation of plan, analysis, evaluation, control evidence, residual risk justification, and post-market data — not as a Word document that someone updates quarterly.
Risk analysis and the foreseeable misuse trap
Clauses 5.1 to 5.5 require systematic identification of hazards across the device's intended use and reasonably foreseeable misuse, throughout the device lifecycle including normal and fault conditions. The 'reasonably foreseeable misuse' part trips most teams up — it is not 'every conceivable abuse', but it is broader than 'misuse we have observed'. The standard expects you to consider use errors from human factors data, off-label use observed in the market, and predictable workarounds. A risk analysis that lists only intended-use hazards and ignores foreseeable misuse will get challenged by any competent reviewer in 2026.
Risk evaluation and the acceptability matrix
Clause 6 requires evaluation of each estimated risk against the acceptability criteria defined in the plan. Most manufacturers use a probability-by-severity matrix with three bands (acceptable, ALARP / further reduction required, unacceptable). The 2019 revision deliberately removed the term 'ALARP' from the normative text to discourage tick-box use of the middle band — every risk in the middle band still needs explicit benefit-risk justification, not a shrug. Common failure modes: severity scales that conflate harm with hazardous situation, probability scales not calibrated to the device's real-world exposure, and a matrix where almost everything lands in the middle band so no real prioritisation happens.
Risk control: inherent safety, protective measures, information for safety
Clause 7 prescribes the order of priority for risk control: first, inherent safety by design; second, protective measures in the device or manufacturing process; third, information for safety (labelling, IFU, training). The order is not optional, and an RMF that jumps straight to 'add a warning in the IFU' without showing why inherent design changes or protective measures weren't feasible will not pass review. Each control must be verified for implementation and validated for effectiveness, and the residual risk after the control must be re-evaluated. Controls that introduce new hazards (a common phenomenon, e.g. an alarm that contributes to alarm fatigue) must themselves be evaluated under the same process.
Production and post-production information
Clause 10 is the clause that turned 14971 from a design-time exercise into a lifecycle process, and it is the clause notified bodies have sharpened on most aggressively. The standard requires a documented system to collect and review production and post-production information relevant to the safety of the device — complaints, vigilance, PMS data, PMCF, scientific literature, similar-device information from the market. The information must be evaluated for impact on the existing risk analysis, and the RMF must be updated as warranted. The most common finding: complaints data exists, the risk file exists, but no documented evidence that the one ever changes the other.
A 60-day implementation path
Days 1 to 10: gap assessment of the existing risk process against ISO 14971:2019; identify weak vocabulary, missing foreseeable-misuse coverage, light residual-risk justification, broken post-production feedback. Days 11 to 30: rebuild the RMF for one priority device family as a pilot — populated hazard analysis with the right vocabulary, an evaluation matrix from a documented plan, controls in priority order with verification and validation linked. Days 31 to 45: wire the post-production feedback queue into complaints and PMS; run the first cycle of risk-file updates from real signals. Days 46 to 60: roll the pattern across the remaining device families; run a 14971-focused internal audit. Treat the 60 days as a methodology shift, not a paperwork exercise.
Where this lives in V5 Ultimate
The clauses above aren't theoretical — every one maps to a shipped module and an industry profile. Jump to the parts of the product that turn this guide into evidence on a Monday morning.
Modules that do the work
Quality management
14971 risk file at the centre of the QMS — not a side artefact.
Complaints & CAPA
Post-market signals routed into the risk file with structured evaluation.
eDHR per serial
Production information from every unit feeding the risk feedback loop.
Document control
Risk Management Plan and File as live, versioned, controlled records.
Compliance self-assessment
Score your risk process against the 14971:2019 clauses on demand.
Industries this hits hardest
Frequently asked
Is ISO 14971:2019 harmonised under MDR and IVDR?
Yes — ISO 14971:2019 is harmonised under both Regulation (EU) 2017/745 (MDR) and Regulation (EU) 2017/746 (IVDR), and conformance with it gives presumption of conformity to the corresponding GSPR clauses on risk management. The accompanying Technical Report ISO/TR 24971:2020 provides guidance on application but is not itself harmonised.
What's the relationship between ISO 14971 and IEC 62366 usability engineering?
IEC 62366-1 covers usability engineering; ISO 14971 covers risk management. The two are designed to interoperate: use errors identified by the IEC 62366 process feed the ISO 14971 hazard analysis, and risk controls addressing use errors feed back into the usability engineering file. A clean implementation runs them as a coordinated pair, not two separate exercises.
Can we still use ALARP language in the risk file?
Strictly, the 2019 revision removed ALARP from the normative text. You can use the term informally in your plan, but the underlying expectation is that every residual risk has a documented benefit-risk justification — not a shrug to ALARP. Notified bodies and FDA both look for explicit reasoning when a risk sits between 'broadly acceptable' and 'unacceptable'.
How often should the risk management file be updated?
Whenever production or post-production information indicates a change is warranted, plus a periodic review at a cadence defined in the plan (typically annually for active devices, more frequently for higher-risk implantables). The trigger-driven updates are the ones that matter most to inspectors — they show the file is alive, not just on a calendar.
See it on your shop floor.
Free trial, no credit card, onboard in days, not months.