ISO 14971 Risk Management: What a real risk file looks like

ISO 14971 is the foundation standard for risk management across the medical device industry. ISO 13485:2016 references it. IEC 62304 references it. IEC 62366-1 references it. IEC 81001-5-1 references it. FDA’s QMSR references it. If you build medical devices, you are working within a framework that assumes you have a functioning ISO 14971 process — whether or not you have read the standard.

The 2019 third edition made substantial changes from the 2007 second edition: replacing ALARP with AFAP, adding explicit benefit-risk analysis requirements, expanding post-production obligations into four sub-clauses, and introducing the new concepts of benefit, reasonably foreseeable misuse, and state of the art as defined terms. Manufacturers who updated from 2007 without revising their risk management processes are systematically out of conformance with the current standard, even when their files look complete.

This guide walks the process from planning through post-market feedback, identifies the gaps that auditors from BSI and TÜV SÜD consistently find, and gives you a practical picture of what a complete risk management file actually contains — not what a compliant-looking checklist says it contains.

Clause references in this guide are from ISO 14971:2019. Implementation guidance cites ISO/TR 24971:2020 where that technical report provides worked examples or interpretive detail that the normative standard does not supply.

Is ISO 14971 required for your device?

ISO 14971 applies to all medical devices — hardware devices, software as a medical device (SaMD), in vitro diagnostic devices (IVDs), and combination products — across all risk classes. Clause 1 (Scope) states this explicitly: the process described in the standard applies to risks related to biocompatibility, data and systems security, electricity, moving parts, radiation, and usability. There is no device type that is categorically out of scope.

What regulatory frameworks require ISO 14971?

ISO 14971:2019 is a harmonized standard under EU MDR 2017/745 and EU IVDR 2017/746, creating a presumption of conformity with the general safety and performance requirements related to risk management. In the United States, FDA’s Quality Management System Regulation (QMSR, 21 CFR Part 820, effective February 2024) cross-references ISO 14971 throughout — most directly at 820.30(g), which requires risk management as part of design controls. Japan’s MHLW Ordinance 169 and Health Canada’s Medical Devices Regulations similarly expect ISO 14971 compliance. If you are pursuing MDSAP certification, auditors from any MDSAP member country will expect a conformant ISO 14971 process.

What does the 2019 edition change for manufacturers upgrading from 2007?

The 2019 third edition introduced changes that require substantive process updates, not just document re-references. The most impactful changes: (1) ALARP is replaced by AFAP — economic cost alone cannot justify not reducing an acceptable-zone risk further; (2) benefit-risk analysis is now an explicit requirement with three new defined terms (benefit, reasonably foreseeable misuse, state of the art); (3) the required conclusion in the Risk Management Report shifted from “risks are acceptable” to “benefits outweigh residual risks”; (4) Clause 10 (Production and post-production activities) was restructured into four sub-clauses requiring active collection and review, not passive complaint handling; (5) risk acceptability criteria must now be established before risk analysis begins — the 2019 edition makes this sequencing explicit. Manufacturers who simply added “:2019” to their standard references without updating their risk management plan, risk table, or report templates are nonconforming.

The standards landscape

ISO 14971:2019 is the normative standard — it contains the requirements your risk management process must satisfy. ISO/TR 24971:2020 is its companion technical report — informative, not normative, but the practical guidance source for implementation. They were developed in parallel and revised together. The technical report uses the same clause numbering as the standard, so guidance in ISO/TR 24971:2020 Clause 4.4 corresponds to requirements in ISO 14971:2019 Clause 4.4.

What does ISO/TR 24971:2020 add beyond the standard?

ISO/TR 24971:2020 contains the worked examples and interpretive guidance that the normative standard intentionally excludes. Key additions include: Annex A (identification of hazards and characteristics related to safety — a hazard checklist covering energy, biological, environmental, and information hazards), Annex B (risk analysis techniques — FMEA, FTA, Preliminary Hazard Analysis, and others with guidance on when each is appropriate), Annex C (relationship between risk acceptability policy, risk evaluation, and risk control — diagrams and criteria discussion), Annex D (information for safety and residual risk disclosure), Annex E (role of international standards in risk management — how standards satisfy specific risk control obligations), and Annex F (guidance on security risks). If you are building your first risk management file or reviewing an existing one for 2019 compliance, ISO/TR 24971:2020 is the practical reference that shows what “good” looks like.

How do ISO 13485, IEC 62304, IEC 62366-1, and IEC 81001-5-1 connect to ISO 14971?

ISO 13485:2016 Clause 7.1 (Planning of product realization) explicitly requires risk management per ISO 14971. This makes a conformant ISO 14971 process a prerequisite for ISO 13485 certification, not an optional add-on. IEC 62304:2006+AMD1:2015 Clause 4.3 requires software safety class assignment — Class A (no injury or damage possible), Class B (non-serious injury possible), Class C (death or serious injury possible) — which is derived directly from your ISO 14971 severity categories. IEC 62366-1:2015 Clause 5.1 requires an intended use specification that serves as the structured input to ISO 14971 Clause 5.2 hazard identification. IEC 81001-5-1:2021 Clause 7.3 (Estimate and evaluate security risk) references ISO 14971’s risk management process explicitly as the framework within which security risks are assessed, with the distinction that security risk uses exploitability rather than probability of harm as the risk dimension.

The practical consequence: if you maintain a complete ISO 14971 risk management file, you satisfy the risk-related requirements that each of these other standards cross-references. You do not need parallel risk management systems for safety, software safety, and cybersecurity. One integrated Risk Table — with appropriate columns for each risk type — satisfies all of them.

The risk management process

ISO 14971:2019 Clause 4.1 (Risk management process) establishes the core requirement: “The manufacturer shall establish, implement, document and maintain an ongoing process” for identifying hazards and hazardous situations, estimating and evaluating the associated risks, controlling these risks, and monitoring the effectiveness of the risk control measures. This process shall apply throughout the life cycle of the medical device.

What does “lifecycle-integrated” actually mean in practice?

Lifecycle-integrated means risk management activities are embedded in each phase of product development, not performed once at design freeze. ISO 14971:2019 Figure 1 (a schematic representation of the risk management process) shows risk management as a continuous loop: risk analysis feeds into risk evaluation, which feeds into risk control, which feeds back through evaluation of overall residual risk and the risk management review, with production and post-production information feeding back into the loop throughout the product’s market life. In practice, this means: hazard identification happens at design input; risk estimation is updated when design changes are made; risk control verification is part of design verification; and post-market surveillance data feeds back into risk re-assessment. A risk management file written in week 47 of a 50-week development program, after all design decisions are final, is not lifecycle-integrated and will not survive a critical audit review.

What is in the risk management file vs. the risk management report?

ISO 14971:2019 Clause 4.5 (Risk management file) defines the file as the set of records and other documents produced by risk management activities. The risk management file is the container — it holds or references all risk management records across the device lifecycle: the risk management plan, all risk analysis records, all risk evaluation records, risk control measure implementation and verification records, the overall residual risk evaluation, and the risk management report. The risk management report is one specific document within the file — it is the record of the Clause 9 (Risk management review) performed prior to commercial release, confirming that the plan was implemented, the overall residual risk is acceptable, and appropriate post-production monitoring is in place. The file is the complete dossier; the report is the release gate conclusion.

Building a real risk management file

ISO 14971:2019 Clause 4.4 (Risk management plan) sets out what the plan must contain before risk analysis begins. This sequencing is deliberate and auditable: the 2019 edition makes explicit that risk acceptability criteria must be defined before risk analysis results are known. Writing the plan after seeing the results and calibrating the matrix to make results look acceptable is a nonconformity.

What must the risk management plan contain?

Clause 4.4 requires the plan to include at minimum: (a) the scope of planned risk management activities, identifying the device and the lifecycle phases covered; (b) assignment of responsibilities and authorities; (c) requirements for review of risk management activities; (d) criteria for risk acceptability, including severity categories, probability categories, and the risk acceptability matrix — and criteria for accepting risks when probability of harm cannot be estimated; (e) the method to evaluate overall residual risk, and the criteria for acceptability of the overall residual risk; (f) activities for verification of the implementation and effectiveness of risk control measures; and (g) activities related to collection and review of production and post-production information. A plan that covers (a) through (d) but omits (e) (overall residual risk method) or (g) (post-production activities) is incomplete under the 2019 standard. These two items — (e) and (g) — were substantially strengthened in 2019.

How do you define usage estimates for calibrating probability scales?

ISO/TR 24971:2020 Clause 4.4 provides guidance on establishing probability categories. The practical approach: estimate the total number of times the device will be used across all devices in its lifetime market. For example, if your device is expected to be in service across 500 devices each used 100 times per year over a 5-year lifecycle, total uses equal 250,000. You can then anchor your probability scale to this estimate: the highest probability category represents harms occurring many times across that population; the lowest represents a harm so rare it is unlikely to occur even once. Without this anchoring, probability estimates are arbitrary and inconsistent between assessors — and auditors will ask how your probability scale was calibrated.

The risk management file can be a single document or a collection of documents referenced together. ISO 14971:2019 Clause 4.5 Note 1 states that the file need not physically contain all records — it needs to contain at minimum references or pointers to all required documentation, so the manufacturer can assemble the information in a timely manner. In a Google Drive or SharePoint-based QMS, a single Risk Management File index document that links to the plan, risk table, and report satisfies this requirement provided the links are maintained and accessible.

Identifying hazards without fooling yourself

ISO 14971:2019 Clause 5.2 requires the manufacturer to document the intended use of the device and, separately, to document reasonably foreseeable misuse scenarios. Clause 5.4 then requires systematic identification of hazards based on the intended use, the reasonably foreseeable misuse scenarios, and the characteristics related to safety identified in Clause 5.3. The standard requires coverage of both normal condition and fault condition hazards.

What counts as a reasonably foreseeable misuse scenario?

ISO 14971:2019 Clause 3.15 defines reasonably foreseeable misuseas “use of a product in a way not intended by the manufacturer, but which can result from readily predictable human behaviour.” Note 1 clarifies that this includes the behaviour of all types of users — lay users and professional users. Note 2 states that reasonably foreseeable misuse can be intentional or unintentional. The key test is whether the misuse is predictable given knowledge of how users actually behave, not whether the manufacturer intended it. Examples: a clinician using a device setting outside its validated range because the clinical situation seems to warrant it; a lay user calibrating a home monitoring device incorrectly because the instructions for use are ambiguous; a technician performing maintenance without disconnecting the device from a patient because the procedure is inconvenient. ISO/TR 24971:2020 Clause 5.2 provides a structured approach to identifying foreseeable misuse, noting that post-market data from similar devices, usability study observations, and regulatory incident databases are productive sources.

What hazard categories are commonly missed in hazard identification?

Engineering-focused teams identify failure modes well and identify normal-condition hazards poorly. A failure mode analysis asks: what happens when this component fails? A hazard analysis asks: what could cause harm under any condition, including intended operation? ISO/TR 24971:2020 Annex A provides a structured hazard identification checklist covering: energy hazards (electrical, thermal, mechanical, radiation, acoustic), biological and chemical hazards (biocompatibility, toxicity, sterility), operational hazards (incorrect output, software failure, user interface errors, information hazards), and environmental hazards (temperature, humidity, electromagnetic interference). Working through Annex A systematically is more reliable than a free-form brainstorm because it covers categories that are easy to overlook — particularly information hazards in SaMD and environmental hazards in devices that operate in variable clinical environments.

The critical discipline is separating hazard identification from risk estimation. Clause 5.4 requires identifying hazards and hazardous situations without filtering by probability or severity. Teams that informally discard low-probability hazards during identification are not conformant — every identified hazard must be documented, with its probability and severity formally estimated in the Risk Table, before any risk is classified as acceptable and set aside.

Estimating risk when you don’t have data

ISO 14971:2019 Clause 5.5 (Risk estimation) requires the manufacturer to estimate the risk for each identified hazardous situation using available information or data. The standard recognizes that for some hazardous situations, the probability of occurrence of harm cannot be estimated — in those cases, the plan must include criteria for accepting such risks, and the possible consequences shall be listed for use in risk evaluation and risk control.

What are defensible approaches to probability estimation for novel devices?

ISO 14971:2019 Clause 5.5 Note 3 lists sources from which data for estimating risks can be obtained: published standards; scientific or technical investigations; field data from similar medical devices already in use, including publicly available reports of incidents; usability tests employing typical users; clinical evidence; results of relevant investigations or simulations; expert opinion. For novel devices with no field history, the most defensible approach combines: (1) analogous device data from similar devices on the market (FDA MAUDE database, MHRA adverse event reports, TGA database); (2) usability study observations from formative studies; and (3) expert panel estimation using structured techniques such as those described in ISO/TR 24971:2020 Clause 5.5. What you cannot do is leave the probability field blank or enter “unknown” without following up with the plan’s criteria for accepting risks with unknown probability. An auditor who sees blank probability fields in a risk table will ask what criteria from the risk management plan were applied.

What does a calibrated 5×5 risk matrix with written anchors look like?

ISO/TR 24971:2020 Annex C illustrates a five-probability by five-severity risk matrix as an example framework. What the TR does not supply — and what most teams need — are written anchors that make each cell defensible during an audit. The matrix below is an example only; your Risk Management Plan must define its own calibrated anchors before risk analysis begins. Anchors are statements a second assessor can apply independently and reach the same score. Qualitative labels alone (“minor,” “probable”) are not anchors.

Severity anchors follow the same principle. “Negligible” should be defined as harm not requiring medical intervention; “Minor” as temporary injury resolved without sequelae; “Serious/Major” as injury requiring medical intervention; “Critical” as permanent impairment or significant disability; “Catastrophic/Fatal” as death or permanent life-altering harm. ISO/TR 24971:2020 Annex C Section 5.5.4 provides this structure. When you define these anchors in the Risk Management Plan before analysis begins, the Risk Table becomes reproducible — a second reviewer applying the same anchors reaches the same score. Without written anchors, probability and severity assignments are personal judgments that cannot survive independent audit review.

How does risk estimation differ from risk evaluation?

Risk estimation (Clause 5.5) is the process of assigning values to probability and severity — it produces a risk score. Risk evaluation (Clause 6) is the process of comparing that score against the acceptability criteria in the risk management plan to determine whether the risk is acceptable or not. They are sequential, distinct activities. A common nonconformity is combining them in a single step — estimating risk in the context of existing controls and then treating the result as both the risk score and the acceptability determination. ISO 14971 requires you to estimate the inherent risk before controls are applied, then evaluate whether controls are needed based on that inherent risk score, then apply controls, then re-estimate the residual risk after controls. The Risk Table should have separate columns for pre-control risk score, control measures, and post-control (residual) risk score.

Risk control and residual risk

ISO 14971:2019 Clause 7.1 (Risk control option analysis) requires the manufacturer to determine risk control measures appropriate for reducing risks to an acceptable level. The manufacturer shall use one or more of the following risk control options in the priority order listed: (a) inherently safe design and manufacture; (b) protective measures in the medical device itself or in the manufacturing process; (c) information for safety and, where appropriate, training to users. This priority order is not a preference — it is a sequence that the standard requires. Jumping to warning labels without documenting why design-level and protective-measure controls were not feasible is a nonconformity.

What does verification of risk control effectiveness require?

ISO 14971:2019 Clause 7.2 (Implementation of risk control measures) distinguishes two separate verification requirements: first, verification that each risk control measure has been implemented — the control exists in the design; second, verification that the effectiveness of the risk control measures has been verified — the control actually reduces the risk as intended. These are different activities with different evidence. A protective interlock that is present in the design satisfies the first; a test demonstrating that the interlock reduces the probability of the hazardous situation reaching the patient to an acceptable level satisfies the second. Risk tables that record only “control implemented: yes” without referencing effectiveness verification test records are incomplete under Clause 7.2. Both records must be in the risk management file.

What happens when a risk control measure introduces a new hazard?

ISO 14971:2019 Clause 7.5 (Risks arising from risk control measures) requires the manufacturer to review whether risk control measures themselves introduce new hazards or hazardous situations, or change the estimated risks for previously identified hazardous situations. Any new or increased risks must be managed per Clauses 5.5 through 7.4 — in practice, this means new rows in your Risk Table. Examples: a software interlock that prevents device activation when sensors are out of range may introduce an alarm fatigue hazard if it triggers frequently; a labeling change that warns users to check device calibration before use introduces a use-error hazard if users skip calibration because the warning is poorly placed. Document the Clause 7.5 review explicitly in the risk table, even when the conclusion is that no new hazards are introduced.

How ISO 14971’s AFAP principle resolves the EU MDR “reduce as far as possible” requirement

EU MDR 2017/745 Annex I (General Safety and Performance Requirements) uses the phrase “reduced as far as possible” when describing risk reduction obligations. ISO 14971:2019 uses AFAP — “as far as possible” — as the replacement for the earlier ALARP (As Low As Reasonably Practicable) principle. These are the same concept expressed in different regulatory documents. The practical resolution: ISO 14971:2019 Clause 6 and Clause 7 operationalize the EU MDR’s requirement through the risk control hierarchy and the AFAP obligation to document that further reduction was considered and found not practicable. ISO/TR 24971:2020 Annex C (Table C.1) confirms that compliance with relevant international product safety standards — which are developed to represent the state of the art — constitutes evidence that the AFAP obligation is met for the hazardous situations those standards address. The key documentation requirement for EU MDR compliance: for every residual risk you accept as within the acceptable zone, the Risk Table or a linked rationale note must state why further reduction is not practicable given the current state of the art. “Cost was too high” or “no engineering solution was identified” (without explaining why) are not sufficient. “Inherent safe design and protective measures have been evaluated; the residual risk is at or below the level achievable by current state-of-the-art devices for this hazard type, as demonstrated by [reference]” is.

After all controls are implemented and verified, Clause 7.3 (Residual risk evaluation) requires evaluation of the residual risk for each hazardous situation using the same acceptance criteria as the initial evaluation. If the residual risk remains unacceptable after all practicable controls, Clause 7.4 (Benefit-risk analysis) applies. If residual risk is judged acceptable, the result is recorded in the risk management file. ISO 14971:2019 Clause 8 provides that if the overall residual risk is judged acceptable, the manufacturer shall inform users of significant residual risks and include the necessary information in the accompanying documentation.

Information for safety vs. disclosure of residual risk

Two separate obligations in ISO 14971:2019 address labeling and user communication, and they are frequently conflated. Conflating them produces both a documentation gap and a regulatory exposure. The first obligation — “information for safety” under Clause 7.1(c) — is a risk control measure. The second obligation — “disclosure of residual risk” under Clause 8 — is an informed-consent requirement. ISO/TR 24971:2020 Annex D opens with this exact statement: “The purpose of this annex is to clarify the differences between ‘information for safety’ and ‘disclosure of residual risk.’”

Information for safety (Clause 7.1(c)) — a risk control

Information for safety is the third tier in the Clause 7.1 risk control hierarchy — used only after inherently safe design and protective measures have been evaluated and found not to fully eliminate the risk. It is instructive: it tells users what actions to take or avoid to prevent a hazardous situation or harm from occurring. Examples: “Do not use haemolyzed serum samples — these can interfere with the measurement and affect the accuracy of the result.” The ISO/TR 24971:2020 Annex D standard makes explicit that information for safety must be verified for effectiveness (for example through usability testing) and must be traceable back to a specific hazardous situation in the risk management file. A warning label that has not been verified for comprehension and effectiveness does not satisfy the control verification requirement of Clause 7.2.

Disclosure of residual risk (Clause 8) — an informed-consent requirement

Disclosure of residual risk is a separate obligation triggered by Clause 8 (Evaluation of overall residual risk). ISO 14971:2019 Clause 8 provides that if the overall residual risk is judged acceptable, the manufacturer shall inform users of significant residual risks and shall include the necessary information in the accompanying documentation in order to disclose those residual risks. This obligation is conditional on an acceptability determination — it applies only when the overall residual risk has been found acceptable for the device’s intended use. ISO/TR 24971:2020 Annex D Section D.3 describes this as descriptiveinformation — it enables the user and patient to make an informed decision about whether to use the device given the remaining risks. It does not need to direct behavior; it needs to accurately describe the residual risk level so the user can weigh it against the intended benefit.

The practical difference: a warning in the IFU that says “Calibrate the device before each use to ensure accurate readings” is information for safety — it is a behavioral instruction that controls the probability of a hazardous situation. A statement in the IFU that says “This device has a residual probability of false-negative results estimated at less than 2% in the validated clinical population; this device should not be used as the sole basis for a treatment decision” is a residual risk disclosure. Both may appear in the same instructions for use, but they are different obligations from different clauses.

Writing defensible residual-risk disclosure statements

Vague disclosures — “use with caution,” “results may vary,” “not intended to replace clinical judgment” — do not satisfy the Clause 8 obligation because they do not convey a specific, quantified (or characterized) residual risk. ISO/TR 24971:2020 Annex D notes that disclosure should be commensurate with the residual risk and the knowledge of the intended recipient. Specific, auditable disclosure statements name the hazardous situation, characterize the residual probability or rate, and state what the user should do with that information. Examples of the difference:

Not defensible:“Use with caution in patients with abnormal baseline values.”

Defensible:“In patients with baseline values outside the validated range of [X to Y], the device’s measurement accuracy has not been established. For these patients, the residual risk of a clinically significant measurement error is uncharacterized. Do not use as the sole basis for a treatment decision in this population.”

Not defensible:“This device does not replace clinical judgment.”

Defensible:“Validation studies demonstrated a false-negative rate of less than 1% in the intended patient population under the conditions described in Appendix A. A false negative in this device leads to delayed diagnosis. This device is intended to support, not replace, diagnostic confirmation by a qualified clinician.”

The risk management file must document the decisions about which residual risks are significant enough to require disclosure, who the information is directed to, and in what form it will be provided. These decisions are part of the Clause 8 evaluation and belong in the risk management file alongside the overall residual risk assessment.

Benefit-risk analysis

ISO 14971:2019 Clause 7.4 (Benefit-risk analysis) requires the manufacturer to gather and review data and literature to determine if the benefits of the intended use outweigh a residual risk that is not judged acceptable and where further risk control is not practicable. Clause 8 (Evaluation of overall residual risk) further requires that after all risk control measures have been implemented and verified, the manufacturer evaluate the overall residual risk — the combined effect of all residual risks — in relation to the benefits of the intended use.

When is a benefit-risk analysis mandatory vs. good practice?

Under ISO 14971:2019, benefit-risk analysis at the individual hazardous situation level (Clause 7.4) is triggered only when residual risk remains unacceptable after all practicable controls have been applied. Benefit-risk analysis at the overall device level (Clause 8) is mandatory for every device before commercial release — it is part of the risk management review, not an optional supplement. The shift in the 2019 edition is that the required conclusion in the Risk Management Report is no longer “individual risks are acceptable” but “the overall residual risk is acceptable in relation to the benefits of the intended use.” This is a meaningful change: a device can have multiple individual residual risks, each within the acceptable zone, but whose combined effect creates an overall residual risk that requires benefit-risk justification. ISO/TR 24971:2020 Clause 8 provides guidance on how to assess this aggregate, including worked examples of devices where interactions between residual risks create new risk scenarios.

What evidence does a benefit-risk analysis require?

ISO 14971:2019 Clause 7.4 requires gathering and reviewing “data and literature” — the analysis must reference clinical evidence, not only engineering judgment. In practice, your benefit-risk section in the Risk Management Report should cite: clinical evaluation data (literature review of similar devices, clinical investigation results if available), state-of-the-art comparators (other devices for the same indication, alternative therapies), and patient-specific benefit factors (improved diagnostic accuracy, reduced procedure time, reduced hospitalization). For a Class II SaMD, clinical literature on similar algorithms or diagnostic tools is usually sufficient, provided the device’s intended clinical population and benefit scenario are clearly stated. ISO 14971:2019 Clause 3.2 defines benefitas “positive impact or desirable outcome of the use of a medical device on the health of an individual, or a positive impact on patient management or public health.” Your benefit-risk conclusion must address this definition specifically.

Individual benefit-risk vs. overall residual risk: two separate required analyses

There are two distinct benefit-risk obligations in ISO 14971:2019 that teams routinely conflate or omit one of. The first — Clause 7.4 (Benefit-risk analysis) — applies to individual residual risks that remain unacceptable after all practicable controls. You perform a per-hazard benefit-risk determination to justify why the device should remain in use despite that specific residual risk. This is triggered only when individual residual risk is unacceptable. The second — Clause 8 (Evaluation of overall residual risk) — is mandatory for every device before commercial release regardless of whether any individual risk is unacceptable. It asks: considering all residual risks in aggregate, including any synergistic effects, do the benefits of the intended use outweigh the combined residual risk burden? A device where all individual risks are within the acceptable zone can still fail the Clause 8 assessment if the cumulative residual risk burden, or interactions between residual risks, creates an overall picture that does not support a net benefit conclusion. Teams that complete Clause 7.4 analyses but have no Clause 8 overall assessment in their Risk Management Report are nonconforming — and the inverse is also true.

A structural template for a Clause 7.4 individual benefit-risk analysis

A benefit-risk analysis for an individual residual risk has four necessary components. Each must be documented in the Risk Management File for the analysis to be auditable:

Step 1 — Clinical benefit definition.State the specific benefit the device provides that is relevant to this risk comparison. The benefit must connect to ISO 14971:2019 Clause 3.2’s definition — a positive impact on the health of an individual, or on patient management or public health. Not “the device provides accurate measurements” but “the device reduces time to diagnosis of [condition] from [X] to [Y] in the intended patient population, enabling earlier initiation of treatment.” Cite the clinical source (literature reference, clinical evaluation report, or clinical investigation data).

Step 2 — Residual risk characterization. State the specific residual risk being weighed: hazardous situation, estimated residual probability (post-control), and severity. Reference the Risk Table row. This must be the post-control estimate, not the inherent risk.

Step 3 — State-of-the-art comparison.Compare the residual risk level to the state of the art for alternative approaches. ISO 14971:2019 Clause 3.28 defines state of the art as “developed stage of technical capability at a given time as regards products, processes and services, based on the relevant consolidated findings of science, technology and experience.” In practice: can a patient get the same clinical benefit from an alternative device, procedure, or no intervention, at a lower residual risk level? If the residual risk of the device is comparable to or lower than alternatives, that supports the analysis. If alternatives carry significantly lower residual risk, a stronger justification is required.

Step 4 — Conclusion with justification.State the conclusion explicitly: the benefits of the intended use outweigh this residual risk, and the basis for that conclusion. A single sentence that says “benefit outweighs risk because the device is clinically valuable” is not sufficient. The conclusion must engage with Steps 1 through 3.

A worked micro-example for a Class II SaMD

Hazard: Incorrect algorithm output (false negative) leading to delayed diagnosis of a serious condition.

A structural template for the Clause 8 overall residual risk justification

The Risk Management Report must include an explicit overall residual risk section. The following 3–4 sentence structure satisfies the Clause 8 documentation requirement and gives auditors a clear record of the analysis:

“Following implementation and verification of all risk control measures, [n] residual risks remain identified for [device name] (Risk Table Rev. [X]). All individual residual risks have been evaluated against the acceptability criteria in the Risk Management Plan and found to be within the acceptable zone [or: except for [list], for which individual benefit-risk analyses are documented in Section [X]]. The combined effect of all residual risks, including interactions between identified hazardous situations [specifically: [describe any identified synergistic risks or state ‘no synergistic effects were identified’]], has been evaluated per the method defined in the Risk Management Plan Section [X]. The overall residual risk is judged acceptable in relation to the clinical benefits of the intended use as documented in the Clinical Evaluation Report [Rev./date], and the device is determined suitable for commercial release.”

This template addresses the two most common audit deficiencies in Clause 8 assessments: the absence of a combined-effects evaluation, and an overall conclusion stated as “all individual risks are acceptable” (which does not satisfy the aggregate assessment requirement).

Production and post-production activities

ISO 14971:2019 Clause 10 (Production and post-production activities) was significantly restructured in the 2019 edition into four sub-clauses: 10.1 General (establish the system), 10.2 Information collection (define what data to collect), 10.3 Information review (define how to assess relevance to safety), and 10.4 Actions (define what to do when the collected information is safety-relevant). Clause 10.1 requires the manufacturer to “actively collect and review information relevant to the medical device in the production and post-production phases.”

What information must you actively collect under Clause 10.2?

ISO 14971:2019 Clause 10.2 requires collection, where applicable, of: (a) information generated during production and monitoring of the production process; (b) information generated by the user; (c) information generated by those accountable for installation, use, and maintenance; (d) information generated by the supply chain; (e) publicly available information; and (f) information related to the generally acknowledged state of the art. Item (f) is the most commonly missed: “state of the art” includes new or revised standards, published validated data for similar devices, and the availability of alternative therapies. A post-market surveillance plan that only collects complaint and adverse event data from your own customers is not collecting state-of-the-art information and does not satisfy item (f).

What triggers a risk management file update from post-market data?

ISO 14971:2019 Clause 10.3 (Information review) requires review of collected information for whether: previously unrecognised hazards or hazardous situations are present; an estimated risk arising from a hazardous situation is no longer acceptable; the overall residual risk is no longer acceptable in relation to the benefits of the intended use; or the generally acknowledged state of the art has changed. Any of these four conditions triggers Clause 10.4 (Actions), which requires the manufacturer to review the risk management file, determine whether reassessment of risks is necessary, and if a residual risk is no longer acceptable, evaluate the impact on previously implemented risk control measures. ISO/TR 24971:2020 Clause 10 provides worked examples including how to process complaint trending data, how to assess literature reports of adverse events for similar devices, and how to determine whether a state-of-the-art change makes a previously acceptable residual risk unacceptable.

The connection between post-market surveillance and risk management is the most consistently cited gap in external audits. BSI and TÜV SÜD both list “lack of connection between PMS and risk management” as a top-three major nonconformity. The failure pattern is organizational: the complaint and PMS team uses one system, the risk management team uses another, and there is no defined trigger that moves a PMS finding into a risk re-assessment. Your PMS procedure must explicitly define the criteria that require a risk management file update and the timeframe for completing it.

Conducting a periodic SOTA Review for Clause 10.2(f)

Clause 10.2(f) requires collection of information related to the generally acknowledged state of the art. ISO/TR 24971:2020 Clause 10.2 notes that this includes new or revised standards, published validated data for similar medical devices, and the emergence of alternative therapies or medical devices. The mechanism most manufacturers lack is a documented, periodic SOTA Review — a structured search of relevant databases that produces a reviewable record of what was searched, what was found, and what conclusion was drawn about whether the risk management file remains valid. This is not a regulatory requirement with a prescribed cadence; it is good practice. What is required is that the activity be defined in your post-market surveillance plan and executed systematically.

A practical SOTA Review covers four primary sources: (1) MAUDE (FDA Manufacturer and User Facility Device Experience database) — searchable by device type and product code; yields field adverse event and malfunction reports for similar devices that can identify emerging hazardous situations not present in your original risk analysis; (2) Cochrane Library — systematic reviews and meta-analyses of clinical interventions; useful for evaluating whether the clinical benefit claims in your benefit-risk analysis remain supported by current evidence; (3) FDA Total Product Life Cycle (TPLC) database — combines MAUDE, 510(k), PMA, and recall data by product code; gives a lifecycle view of adverse event patterns for device categories related to yours; (4) PubMed— peer-reviewed literature on device performance, new hazard identification, and state-of-the-art comparators. Search terms should be defined in the surveillance plan so searches are reproducible.

The artifact the SOTA Review produces is as important as the search itself. A documented conclusion that states “searched [databases] on [date] using [terms]; reviewed [n] results; no new hazards, changed risk estimates, or state-of-the-art changes identified that require Risk Management File update — RMF reviewed and found still valid” satisfies the Clause 10.3 review obligation. An undocumented review — or a review documented only as “PMS review conducted, no actions required” — does not demonstrate that state-of-the-art information was considered.

One specific area where cybersecurity and safety risk intersect in the SOTA Review: ISO/TR 24971:2020 Annex F (Guidance on risks related to security) establishes that breaches of data and systems security can lead to clinical harm — through corruption of diagnostic data, unauthorized modification of device behavior, or loss of device availability — and that these security hazards belong in the ISO 14971 Risk Table under the same process. A newly published vulnerability affecting software components in your device category, discovered through your SOTA Review, can constitute a new hazardous situation that triggers Clause 10.4 action. For connected devices, the SOTA Review should include review of relevant CVE databases and IEC 81001-5-1-aligned vulnerability disclosures. See our IEC 81001-5-1 + FDA Cybersecurity guide for the integrated security risk management approach.

How ISO 14971 integrates with standards you already use

ISO 14971 is the central standard that all other medical device standards reference for risk. The crosswalk below maps the main clauses of ISO 14971:2019 to the corresponding requirements in the standards most commonly used alongside it. Clause references are from ISO 14971:2019 and current editions of the referenced standards. Cross-references to IEC 62304 and IEC 62366-1 are verified against those standards’ current clause numbering.

Three SaMD-specific risk considerations

For software as a medical device, three areas in the risk analysis require explicit treatment that hardware-only device teams often miss:

Software failure contribution (IEC 62304 Clause 7 / ISO 14971 Clause 5.4).ISO/TR 24971:2020 Section E.3 (quoting IEC 62304) states: “As a basic foundation it is assumed that medical device software is developed and maintained within a quality management system and a risk management process.” A consequence of this for SaMD risk analysis: IEC 62304 Clause 4.3 assigns software safety classes based on the severity of harm that would result from software failure, treating probability of failure as a function of the development process rigor rather than a field-data probability estimate. Your Risk Table must evaluate software hazardous situations with severity-focused analysis, and the IEC 62304 safety class assignments for each software item must be traceable to the relevant hazard rows in the risk table.

Third-party library and SOUP risk (IEC 62304 Clause 8).Software of Unknown Provenance (SOUP) — third-party libraries, frameworks, operating systems, model runtimes — is in scope for ISO 14971 risk analysis. Known anomalies and undocumented behavior in SOUP items are potential hazards that can flow into the Risk Table. IEC 62304 Clause 8 requires a SOUP list with documented known anomalies and an evaluation of each for safety relevance. Any SOUP anomaly with potential to cause a hazardous situation requires an entry in the ISO 14971 Risk Table. The SOTA Review required under Clause 10.2(f) should include periodic review of SOUP vendor issue trackers for safety-relevant anomalies, with findings linked back to the Risk Table.

Model and data drift for AI/ML devices. For machine learning-driven SaMD, the risk analysis must address failure modes that differ fundamentally from deterministic software: model degradation over time as clinical practice evolves, distribution shift between training data and production data that reduces accuracy in real-world populations, and silent failure modes where the model continues to produce outputs without triggering obvious errors. These are not standard FMEA failure modes — they require specific hazardous situations in the Risk Table addressing model accuracy as a function of operating conditions. Post-production monitoring (Clause 10) should define quantitative performance thresholds whose breach triggers risk file re-evaluation, not just adverse event monitoring. See our IEC 62304 software lifecycle guide for the full software development and risk management integration.

Where does FDA QMSR sit relative to ISO 14971?

FDA’s QMSR (21 CFR Part 820, effective February 2024) was written to align with ISO 13485:2016, which itself references ISO 14971. The QMSR at 820.30(g) requires risk management as part of design controls, stating that “risk management activities shall be performed throughout the life cycle.” FDA has explicitly stated that a conformant ISO 14971 process satisfies the QMSR risk management requirements. The practical implication: a risk management file that satisfies ISO 14971:2019 also satisfies FDA’s design control risk requirements. You do not need a separate “FDA risk management” document alongside your ISO 14971 file. Reference the QMSR clause in your plan header to make the regulatory traceability explicit for FDA inspectors.

Common audit findings

The patterns below represent consistent findings from BSI, TÜV SÜD, and FDA inspection observations. Each maps to a specific clause of ISO 14971:2019. They are not theoretical gaps — they are the reasons risk management files receive major nonconformities and 483 observations.

The following additional findings appear frequently in audit reports and 483 observations:

No aggregate overall residual risk assessment (Clause 8). Manufacturers evaluate residual risks individually and record each as acceptable, but never perform the Clause 8 assessment of the combined effect of all residual risks. The 2019 edition made this mandatory; organizations updated from 2007 that did not add this step are consistently cited. The Risk Management Report must include an explicit overall residual risk section, not just a summary table of individual risk scores.

FMEA submitted as the complete risk management file (Clauses 4.5, 5.4). A FMEA is one risk analysis tool for one category of failure modes. Submitting a FMEA as the risk management file without a risk management plan, intended use documentation, or risk management report results in a major nonconformity on the first audit. Clause 4.5 defines required file contents that a FMEA alone does not satisfy.

Risk management treated as a post-design checkpoint (Clause 4.1). Risk analysis performed after design is complete, with findings that produced no design changes, is a clear signal to auditors that the process was not lifecycle-integrated. The risk management plan should have dated revision history showing it was established before risk analysis began; the risk table should show iteration as design decisions were made and changed; design reviews should reference risk table entries. When the risk management file has a single creation date close to design freeze, auditors assume it was created retrospectively.

No method defined for evaluating overall residual risk (Clause 4.4(e)).The risk management plan must specify the method for evaluating whether the combined effect of all individual residual risks is acceptable. Plans that state “if all individual risks are acceptable, the overall risk is acceptable” are rejected — this approach cannot detect synergistic effects. ISO/TR 24971:2020 Clause 8 describes possible approaches including aggregate scoring, expert panel review, and comparison against similar devices on the market.

Frequently asked questions

Does ISO 14971 apply to Class I devices?

ISO 14971 applies to all classes of medical devices — Class I, II, and III — without exception. The standard's Clause 1 (Scope) explicitly covers all medical devices, including software as a medical device and IVDs. Risk management requirements scale proportionally: a low-risk Class I device may have a shorter, simpler risk management file than a Class III implant, but the process structure (plan, analysis, evaluation, control, review) is the same. The FDA QMSR (21 CFR Part 820) references ISO 14971 for risk management for all device classes. A Kelsey Review finds that Class I device manufacturers are the most likely to have incomplete risk management files, often because teams assume the standard doesn't apply to them.

Is a Failure Mode and Effects Analysis (FMEA) the same thing as a risk management file?

No. An FMEA is one risk analysis technique you might use to populate part of your risk management file — it is not the file itself, and it is not sufficient as the sole risk analysis tool. ISO 14971 Clause 5.4 requires systematic identification of hazards using available information; Clause 4.5 (Risk management file) defines what the file must contain: the risk management plan, records of hazard identification, risk analyses, risk evaluations, risk control measures and their verification, overall residual risk evaluation, and the risk management report. An FMEA addresses failure modes — it structurally misses hazards that exist under normal conditions (a sharp needle is a hazard even when it functions perfectly). ISO/TR 24971:2020 Annex B describes a range of complementary techniques including Preliminary Hazard Analysis and Fault Tree Analysis. Auditors from BSI and TÜV SÜD consistently cite FMEA-as-sole-tool as a major nonconformity.

How do I integrate IEC 62304 software risk activities with ISO 14971 safety risk?

IEC 62304:2006+AMD1:2015 Clause 4.3 requires you to assign a safety class (A, B, or C) to each software item based on the severity of harm the software could cause if it fails. That safety class determination is an output of your ISO 14971 hazard identification and risk estimation process — specifically, you use the severity categories from your Risk Management Plan to determine the class. The two standards are designed to interoperate: ISO 14971 establishes the safety case; IEC 62304 establishes what development rigor that safety case requires. In practice, maintain one Risk Table that covers both hardware and software hazardous situations, and cross-reference each software hazardous situation to the IEC 62304 software item and safety class assignment. Clause 7.1 of IEC 62304 requires documenting software hazard analysis, which you satisfy by referencing the relevant rows in your ISO 14971 Risk Table.

Is ISO 14971 required for EU MDR submissions?

Yes. ISO 14971:2019 is listed as a harmonized standard under EU MDR 2017/745, meaning conformity to it creates a presumption of conformity with the MDR's general safety and performance requirements for risk management. EU notified bodies consistently expect a complete risk management file per ISO 14971 as part of the technical documentation review. The key difference from the FDA path: the EU MDR does not separately specify which risk management clauses to satisfy — it accepts conformity to the full standard. Your risk management file should cross-reference ISO 14971:2019 clause numbers explicitly in the document header so notified body reviewers can verify coverage without having to reconstruct the mapping.

How does ALARP differ from the AFAP principle in the 2019 edition?

ALARP (As Low As Reasonably Practicable) was the risk reduction principle in the ISO 14971:2007 edition. It allowed manufacturers to cite cost as a reason for not implementing a risk control measure, provided the residual risk was within the acceptable zone. The 2019 edition de-emphasizes ALARP and introduces AFAP (As Far As Possible) terminology, though ALARP remains a permitted risk policy per Clause 4.2 Note 1. AFAP requires risk reduction as far as possible without adversely affecting the benefit-risk ratio. Economic cost alone is no longer a sufficient justification for not reducing an acceptable risk further. In practice, AFAP means you must document for every acceptable risk without a control measure that you actively considered further reduction and it was not practicable — not merely that it was expensive. This change is the most significant compliance gap for manufacturers who updated from the 2007 edition without revising their risk acceptance criteria or AFAP rationale documentation.

Can we reuse our ISO 14971 cybersecurity hazard analysis as a security threat model for IEC 81001-5-1?

Partially. A cybersecurity hazard in your ISO 14971 Risk Table (e.g., unauthorized modification of diagnostic output leading to incorrect treatment recommendation) maps to what IEC 81001-5-1 and ANSI/AAMI SW96:2023 call a threat. The safety consequence you document in your Risk Table is what the security standards require you to connect back to in your threat model. You can structure your security threat analysis as an extension of your Risk Table — add columns for threat agent, attack vector, and exploitability — rather than building a separate document. ISO 14971 Annex A explicitly notes that the standard's process can be applied to risks associated with data and systems security. Auditors accept a combined Risk Table and Threat Model provided the columns and linkages are clear. The one area that does not overlap: IEC 81001-5-1 Clause 7.3 uses exploitability (likelihood of successful attack) rather than probability of harm occurrence as the risk dimension. Keep that distinction documented.

How proportionate can a risk management file be for a small team?

ISO 14971 scales with device complexity and risk, not with company size. A 3-person team building a Class II SaMD can satisfy all requirements with: (1) a 5-page Risk Management Plan defining scope, roles, severity and probability scales, and the risk acceptance matrix; (2) an Intended Use document covering patient population, user profiles, and foreseeable misuse scenarios; (3) a Risk Table (spreadsheet) documenting hazards, hazardous situations, harms, probability estimates, severity estimates, control measures, verification records, and residual risk; (4) a 2-page Risk Management Report confirming overall residual risk acceptability and signed prior to release. Four documents, proportional in depth to the device. What you cannot do is have no file at all, have one document that doubles as plan and report with no traceability, or have a file that was written after design freeze. The process integrity — doing it in the right order — matters as much as the document count.

Is an FMEA the same as ISO 14971 risk analysis?

No. FMEA is a bottom-up component-failure analysis technique that can support ISO 14971 Clause 5 (risk analysis) but does not satisfy it on its own. FMEA asks: what happens if this component fails? ISO 14971 risk analysis asks: what could cause harm to a patient or user under any condition — including intended operation, foreseeable misuse, and environmental factors? The hazard identification required by Clause 5.4 must cover hazards that exist under normal conditions (a sharp needle is a hazard even when it functions perfectly), hazards arising from reasonably foreseeable misuse, and hazards from the use environment — none of which are captured by component-level failure mode analysis. In an integrated audit, a risk file that contains only an FMEA — even a thorough one — will be cited as nonconforming under multiple clauses: Clause 5.2 and 5.4 because the top-down hazard identification from intended use and misuse scenarios is absent; and Clause 5.3 separately because FMEA does not address the identification of characteristics related to safety — the systematic review of device features and properties that can affect patient safety regardless of component failure. These are distinct gaps. FMEA is a useful technique inside the broader 14971 process, particularly for Clause 5.4 hazardous situations arising from fault conditions. ISO/TR 24971:2020 Annex B describes FMEA alongside Preliminary Hazard Analysis, Fault Tree Analysis, and HAZOP, with guidance on when each is appropriate.

When is benefit-risk analysis mandatory under ISO 14971?

Benefit-risk analysis is mandatory under two distinct clauses, each with a different trigger. Per Clause 7.4, a benefit-risk analysis is required for any individual risk that remains unacceptable after all practicable risk control measures have been implemented. This is the per-hazard analysis triggered only when residual risk exceeds the acceptance criteria. Per Clause 8 (Evaluation of overall residual risk), an overall benefit-risk analysis is required for every device before commercial release — it evaluates whether the combined effect of all residual risks is acceptable in relation to the benefits of the intended use. This is mandatory regardless of whether any individual risk was unacceptable. Teams frequently complete Clause 7.4 analyses for specific high-risk hazardous situations and omit the Clause 8 overall assessment, or include a Clause 8 section that simply summarizes individual risk scores without evaluating combined effects. Both gaps are cited as major nonconformities in BSI and TÜV SÜD audits. Both analyses must be documented in the Risk Management Report.

How do we integrate ISO 14971 with our IEC 62304 software risk analysis?

Software risks flow into the same risk management file — not a separate software risk register. IEC 62304 Clause 7 (Software risk management) requires that software hazards be identified and analyzed within the ISO 14971 process, with traceability from software hazardous situations in the Risk Table forward to the software items and safety class assignments in the IEC 62304 records, and from risk controls back to software design specifications and verification records. The most common finding in integrated audits: a team maintains a separate 'software FMEA' or 'software risk register' without traceability links to the ISO 14971 Risk Management File. Auditors from notified bodies conducting combined ISO 13485 + IEC 62304 reviews consistently flag this as a nonconformity — both standards require the risk analysis and risk control records to be part of the ISO 14971 risk management file, not a parallel document set. One Risk Table with hardware, software, and cybersecurity hazardous situations — each linked to the appropriate design output, verification record, and safety class assignment — satisfies both standards. See our IEC 62304 software lifecycle guide (/guides/iec-62304-software-lifecycle) for the full IEC 62304 process.

Further reading

Primary standards (paywalled; consult your standards library or notified body)

ISO 14971:2019 — Medical devices: Application of risk management to medical devices (third edition, December 2019). The normative standard. Available from ISO (iso.org), national standards bodies (ANSI in the US, BSI in the UK, DIN in Germany), and many notified body libraries. ISO/TR 24971:2020 — Medical devices: Guidance on the application of ISO 14971 (second edition, May 2020). The informative companion technical report. Uses the same clause numbering as ISO 14971:2019. Annexes A through H provide implementation examples covering hazard identification, risk analysis techniques, benefit-risk analysis, IVD-specific guidance, and security risk guidance. Strongly recommended reading alongside the normative standard.

Regulatory guidance

FDA Quality Management System Regulation (QMSR) — 21 CFR Part 820 (current at eCFR.gov). Effective February 2, 2024. 820.30(g) contains the risk management requirements referenced to ISO 14971 throughout the product lifecycle.

FDA Guidance: Factors to Consider When Making Benefit-Risk Determinations in Medical Device Premarket Approval and De Novo Classifications (August 2019). Provides FDA’s framework for benefit-risk assessment used in premarket review; informs how to structure the benefit-risk section of your Risk Management Report.

IMDRF N41 — Software as a Medical Device (SaMD): Application of Quality Management System (September 2015). Provides the SaMD risk framework referenced by FDA and international regulators; Annex B maps SaMD risk categories to ISO 14971.

Internal guides

IEC 81001-5-1 + FDA 2023 Cybersecurity: What you actually need to ship — covers how ISO 14971 safety risk and IEC 81001-5-1 security risk integrate in practice, including the combined Risk Table and Threat Model approach.

QMSR Gap Analysis: A Practical Guide — covers the full clause-by-clause gap analysis process for ISO 13485 with QMSR overlay, including how risk management findings from ISO 14971 feed design control records.

Standards placement:ISO 14971:2019 is available from ISO (iso.org), ANSI (ansi.org), BSI (bsigroup.com), and national standards bodies. Approximate cost: USD $180–220. ISO/TR 24971:2020 is available from the same sources at similar cost. Many regulatory consultants and notified bodies maintain copies available for client reference.