The three templates ISO 14971:2019 actually asks for
The Risk Management Plan governs the framework. The Hazard Log is the operational register. The FMEA is the bottom-up analysis technique that feeds the Hazard Log. All three are free downloads — no account, no email gate.
What ISO 14971 requires for risk traceability
ISO 14971:2019 is the risk management standard for medical devices. ISO 14971:2007 has been superseded; this page addresses the 2019 edition currently required by EU MDR Annex I §3 and the FDA QMSR (21 CFR Part 820, effective February 2026). Notified bodies and FDA inspectors expect a complete risk management file containing — at minimum — a Risk Management Plan, hazard analysis records, evidence of risk control and verification, an evaluation of overall residual risk, and a Risk Management Report. Gaps in any of these are major findings.
§4.4 Risk Management Plan is the governing document that defines how risk management will be conducted before any analysis begins. It must specify the scope of activities, assignment of responsibilities, personnel competence requirements (Clause 4.4(e), assignment of staff with the necessary knowledge, experience, and training — frequently missed in audits), risk acceptability criteria including the severity and probability scales and the risk evaluation matrix, criteria for situations where probability of harm cannot be estimated (Clause 4.4(f)), the method for evaluating overall residual risk (Clause 4.4(g)), requirements for verifying risk control measures, review milestones, and the method for collecting production and post-production information (Clause 4.4(i)). Without an approved plan, every downstream risk score is unanchored.
§5 Risk Analysis requires identification of intended use and reasonably foreseeable misuse (Clause 5.2 — including use error and characteristics related to safety), identification of hazards and hazardous situations (Clause 5.4 — distinguishing the hazard, the sequence of events, and the hazardous situation in which someone is exposed to harm), and risk estimation (Clause 5.5). The 2019 revision sharpened the foreseeable-misuse obligation: analysis must consider how users will actually behave, not how documentation says they should behave.
§6 Risk Evaluation requires that each estimated risk be evaluated against the acceptability criteria defined in §4.4. Risks above the Acceptable threshold trigger risk control under §7.
§7 Risk Control requires risk control option analysis (§7.2) in this priority order: inherent safety by design, protective measures in the device or in manufacturing, and information for safety. The standard’s language is “risk control option analysis” against documented “acceptability criteria” — not the older industry shorthand “ALARP.” For devices marketed in the EU, EU MDR Annex I §1 requires risks be reduced as far as possible (AFAP) without regard to economic considerations, which is stricter than ALARP. §7.3 covers implementation of risk control measures including verification of effectiveness. §7.5 requires a benefit-risk analysis when residual risk cannot be reduced to acceptable levels. §7.6 requires evaluation of new hazards introduced by risk controls themselves — a frequently missed obligation.
§8 Evaluation of Overall Residual Risk is a standalone result-level check, distinct from evaluating individual risks. The cumulative effect of all residual risks must be judged against the clinical benefit of the device using the method defined in §4.4(g) of the Plan. Many manufacturers evaluate individual risks correctly but never document the aggregate evaluation.
§9 Risk Management Review must occur before commercial release. The output is the Risk Management Report, which confirms that the Risk Management Plan was implemented, that overall residual risk is acceptable, and that methods are in place to collect and review production and post-production information. The Report is a separate, signed artifact from the Hazard Log.
§10 Production and Post-Production was significantly expanded in 2019. Manufacturers must collect and act on field data — complaints, adverse events, literature, similar device data, service records — throughout device lifetime. The data-collection method itself must be defined in the Risk Management Plan per Clause 4.4(i); §10 governs the operational process of executing it.
How the templates cover ISO 14971
| Template | ISO 14971 coverage |
|---|---|
| Risk Management Plan (.docx) | §4.4 plan requirements: scope, responsibilities, competence (4.4(e)), 5×5 acceptability matrix, criteria for unestimable probability (4.4(f)), overall residual risk method (4.4(g)), control verification, review milestones, post-production data collection (4.4(i)) |
| Hazard Log (.xlsx) | §5 hazard identification with explicit columns for Hazard → Sequence of Events → Hazardous Situation → Harm per §5.4, §6 risk evaluation (initial and residual scoring by Severity × Probability only), §7 risk control measures with type classification, verification status, and benefit-risk justification |
| FMEA (.xlsx) | §5 bottom-up risk analysis technique per ISO/TR 24971: failure modes, Severity × Occurrence × Detection scoring, RPN. Note: Detection and RPN are FMEA-specific reliability concepts and are not recognized by ISO 14971 — they must not be used to lower Hazard Log scores or determine acceptability. FMEA findings feed the Hazard Log; the Hazard Log scores risk strictly by Severity × Probability. |
| RTM Risks tab | §7 risk control linkage: each risk control measure becomes a requirement (REQ-xxx) traced through verification (VER-xxx) to test report (TR-xxx) |
The four artifacts together form the operational core of an ISO 14971 risk management file. The Plan defines the framework; the Hazard Log and FMEA execute analysis under it; the RTM closes the trace from each risk control to verification evidence. The Risk Management Report (§9) is generated from these inputs at release.
Common ISO 14971 audit gaps
- Acceptability criteria adjusted after scoring. The most common — and most damaging — finding. If risks were scored against one set of thresholds and the matrix was later changed to make them “Acceptable,” the entire analysis is compromised. §4.4(d) requires criteria to be approved before analysis begins.
- No method for overall residual risk. Clause 4.4(g) requires the Risk Management Plan to define how the cumulative effect of all residual risks is evaluated against clinical benefit. Many plans address individual risk acceptability but never define how the aggregate gets judged. The corresponding §8 evaluation result is then also missing.
- FMEA Detection used to lower Hazard Log scores. ISO 14971 defines risk as Severity × Probability only; FMEA’s Detection score addresses manufacturing/design reliability and is not recognized by the standard. Auditors specifically check that Hazard Log acceptability is determined without reference to Detection or RPN.
- Hazard, hazardous situation, and harm conflated. §5.4 distinguishes the hazard (source of potential harm), the sequence of events, the hazardous situation (exposure), and the harm itself. Hazard Logs that merge these into a single “risk description” column lose the analytical structure auditors expect.
- “Reasonably foreseeable misuse” not analyzed. §5.2 requires analysis of how users will actually use the device, including off-label use, environmental misuse, and use error per IEC 62366-1. Routinely missed.
- Risk controls not verified. §7.3 requires implementation of each risk control measure to include verification of its effectiveness. The Hazard Log lists controls but the verification column is blank or links to nothing concrete. Auditors specifically check this column for VER-xxx / TR-xxx references.
- New hazards introduced by risk controls not evaluated. §7.6 obligation. When a risk control adds complexity (a new alarm, a software guard, a redundant sensor), it can introduce new failure modes. The Hazard Log needs rows for these.
- Personnel competence not documented. Clause 4.4(e) requires the Plan to assign personnel with appropriate knowledge, experience, and training to risk management activities. Often absent or referenced only by job title.
- Post-production monitoring undocumented in the Plan. Clause 4.4(i) requires the Plan to define information sources, review frequencies, and update-trigger criteria; §10 governs executing it. A vague “we monitor field complaints” is not §4.4(i) evidence.
- Risk Management Report missing or generic. §9 requires the Report to confirm — explicitly — that the Plan was appropriately implemented, that overall residual risk is acceptable, and that post-production methods are in place. Generic boilerplate without these three statements is a finding.
ISO 14971 specific guidance
Lock the Risk Management Plan first. §4.4 is non-negotiable: criteria approved before analysis. Use the Risk Management Plan template to establish severity and probability scales, the 5×5 matrix, acceptability thresholds, the criteria for unestimable probability (4.4(f)), the overall residual risk method (4.4(g)), competence assignments (4.4(e)), and post-production data collection (4.4(i)). Approve it. Then start populating the Hazard Log.
FMEA feeds the Hazard Log, not the other way around. FMEA is a bottom-up technique that identifies failure modes for specific components or functions. Each FMEA-identified hazard with a non-trivial residual risk gets a row in the Hazard Log. The Hazard Log is the top-level register; the FMEA is one input technique. The RTMify FMEA template includes a Linked Hazard Log ID column to make this trace explicit. Do not use Detection or RPN to score Hazard Log entries — score them only by Severity × Probability per ISO 14971’s definition of risk.
Distinguish hazard from hazardous situation. Per §3.3 and §5.4: a hazard is the source of potential harm (e.g., excessive RF energy); a hazardous situation is the circumstance in which a person, property, or environment is exposed to one or more hazards via a sequence of events (e.g., patient in MRI scanner during scan). The Hazard Log should have separate columns for each so the auditor can read the analytical chain.
Software risk controls live in the RTM too. When a risk control is implemented in software (an alarm, a limit check, a redundant computation), it becomes a software requirement under IEC 62304 §5.2. Assign it a REQ-xxx identifier, mark its software safety class (A/B/C), and trace it through verification. The Risks tab of the RTMify template, the Hazard Log, and IEC 62304 §5 all reference the same REQ-xxx.
Document the Risk Management Report against the Plan. §9 review must produce a Report that confirms three things explicitly: that the Plan was implemented, that overall residual risk is acceptable per the §8 evaluation, and that §10 post-production methods are in place. A Report that summarizes findings without these explicit statements is a §9 finding.
Post-production triggers an RTM impact analysis. When §10 monitoring surfaces new information that changes a risk score (e.g., field complaints reveal a higher occurrence rate than estimated), the affected Hazard Log rows get updated, and any linked REQ-xxx / VER-xxx may need re-evaluation. RTMify Trace flags requirements whose linked risk has changed since last verification — use this as your post-production change-control trigger.
EU MDR and FDA QMSR alignment. EU MDR Annex I §3 requires a risk management system conforming to ISO 14971. EU MDR Annex I §1 additionally requires risks be reduced as far as possible (AFAP) without regard to economic feasibility — stricter than the older “ALARP” convention. The FDA QMSR (effective February 2026) incorporates ISO 13485 by reference, which in turn requires ISO 14971. Your single risk management file — Plan + Hazard Log + FMEA + RTM Risks linkage + Risk Management Report — serves both regulators.