ISO 14971 risk management for medical devices is a closed loop that runs from a written plan to post-market monitoring, for the whole life of the device. Short answer: ISO 14971:2019 asks you to plan the work and set your risk acceptability criteria (clause 4.4), analyse hazards and hazardous situations (5), evaluate each risk against those criteria (6), control the risks that are not acceptable and verify each control works (7), judge the overall residual risk (8), review the whole process before commercial release (9), then feed production and post-production information back in (10). Everything is kept in a risk management file (4.5). Matrix Req is the tool we build to keep that file traced to requirements and tests.

We work at Matrix One, the company that builds Matrix Req, so read every product reference on this page as our view. Statements about the standard cite clause numbers, and the regulatory points link to the FDA and EUR-Lex pages they come from, so you can check each one.

What is ISO 14971, and why does it matter more in 2026?

ISO 14971, Medical devices: Application of risk management to medical devices, is the standard regulators expect you to use to identify hazards, estimate and evaluate the associated risks, control them and monitor whether the controls keep working. The current edition is ISO 14971:2019, with its guidance moved into a separate technical report, ISO/TR 24971:2020. For a shorter introduction, see what ISO 14971 risk management is.

In the US, the Quality Management System Regulation became effective on 2 February 2026. It incorporates ISO 13485:2016 by reference, and FDA's own QMSR page says that framework now specifically requires risk management. The same day FDA stopped using QSIT for device inspections and moved to the updated compliance program 7382.850 (FDA QMSR page, read 6 November 2026). The old design control citation, 21 CFR 820.30, no longer describes how inspectors approach your risk file.

In the EU, Commission Implementing Decision (EU) 2022/757 of 11 May 2022 added EN ISO 14971:2019 with amendment A11:2021 to the list of harmonised standards under the MDR, Regulation (EU) 2017/745 (EUR-Lex, read 6 November 2026). Following a harmonised standard gives a presumption of conformity with the MDR requirements it covers, which is why notified bodies read your risk file against it.

What are the steps of the ISO 14971 risk management process?

The standard is written as clauses, not numbered steps, but the clauses run in a sequence that most teams treat as seven stages. The process is iterative: a design change, a new complaint trend or a new use environment sends you back into analysis and control.

What goes in the risk management plan (4.4)?

The plan sets the scope (which device and which life cycle phases), assigns responsibilities and authorities, defines how verification of risk controls will be done, and states how production and post-production information will be collected and reviewed. Most important, it holds the criteria for risk acceptability, based on the manufacturer's policy under clause 4.2. The criteria are yours to set and justify; the standard does not supply a risk matrix.

How do you run risk analysis (clause 5)?

Start with the intended use and the reasonably foreseeable misuse (5.2), then list the characteristics that could affect safety (5.3). From those you identify hazards and the sequences of events that turn each hazard into a hazardous situation (5.4), and estimate the probability and severity of the resulting harm (5.5). A sharp edge is a hazard; a clinician's glove catching on it during normal handling is the hazardous situation; a cut is the harm. FMEA, fault tree analysis, HAZOP and PHA are all accepted ways to do this work, and our guide to five risk analysis methods under ISO 14971 compares them.

How do you evaluate each risk (clause 6)?

For every hazardous situation, compare the estimated risk with the acceptability criteria in the plan. If the risk is acceptable, record that decision and move on. If it is not, it goes to risk control. Estimate the risk as it stands before any control you have not yet verified; scoring severity down because you expect a control to work is one of the commonest errors auditors find.

How do you choose and verify risk controls (clause 7)?

Clause 7.1 sets the order of preference: inherent safety by design and manufacture first, then protective measures in the device or the manufacturing process, then information for safety and, where appropriate, training. You then implement each control and verify both that it was implemented and that it is effective (7.2), evaluate the residual risk (7.3), run a benefit-risk analysis where a residual risk is still not acceptable (7.4), check whether a control created new hazards (7.5), and confirm every hazardous situation has been addressed (7.6).

In practice each control becomes a requirement with a test against it, which is why risk files drift when they live apart from requirements. Our guide to linking ISO 14971 risk controls to requirements covers that chain, and design verification versus validation covers how effectiveness is shown.

How do you judge overall residual risk (clause 8)?

Once individual risks are controlled, you look at them together, using the method and criteria for overall residual risk set in the plan. If the overall residual risk is not acceptable on its own terms, you can still accept it when the medical benefits of the intended use outweigh it. Significant residual risks are disclosed to users in the accompanying documentation.

What does the risk management review check (clause 9)?

Before the device is released for commercial distribution, the manufacturer reviews the execution of the risk management plan. The review confirms at least that the plan has been implemented, that the overall residual risk is acceptable, and that methods are in place to collect and review production and post-production information. The result is documented in the risk management report. ISO 14971 does not require the reviewers to be people who took no part in the analysis; it requires the review to happen, to cover those points and to be recorded.

What happens after release (clause 10)?

Clause 10 asks for an active system to collect information about the device in production and use (10.2), including publicly available information about similar devices and changes in the generally acknowledged state of the art. You review that information for relevance to safety (10.3) and act on it (10.4): if a new hazard appears or an estimated risk no longer holds, the loop restarts at analysis and the risk management file is updated.

What must the ISO 14971 risk management file contain (4.5)?

The risk management file holds the records and documents produced by the process, and clause 4.5 requires it to give traceability for each identified hazard: from the risk analysis, through the risk evaluation and the implementation and verification of the risk control measures, to the assessment of residual risk. It does not have to be one physical document; it can point to records held elsewhere in your quality system. A complete file usually holds:

• The risk management plan with its acceptability criteria and the policy behind them.

• The risk analysis: intended use, foreseeable misuse, safety characteristics, hazards, hazardous situations and risk estimates.

• Risk evaluation decisions for each hazardous situation.

• Risk control measures, with evidence of implementation and verification of effectiveness.

• Residual risk and benefit-risk evaluations, individual and overall.

• The risk management report from the clause 9 review.

• Production and post-production information and the actions taken on it.

The file also links into the design history file, since every risk control is a design input; our design control guide explains where the two meet.

Is ALARP part of ISO 14971:2019?

No. ISO 14971:2019 does not use ALARP (as low as reasonably practicable). It leaves the acceptability criteria to the manufacturer's policy and plan, which may or may not use an ALARP approach. The EU is stricter: MDR Annex I section 2 requires risks to be reduced as far as possible without adversely affecting the benefit-risk ratio, so cost alone is not a reason to stop reducing a risk. Amendment A11:2021, the version harmonised under the MDR, adds annexes that set out how the standard relates to the MDR requirements. If you sell in the EU, write the plan's criteria to the MDR wording rather than ALARP.

How does benefit-risk analysis work under ISO 14971?

Benefit-risk analysis is the route for a risk that stays above your criteria after all practicable controls. Clause 7.4 applies it to an individual residual risk and clause 8 to the overall residual risk. You accept the risk only if the medical benefits of the intended use outweigh it, using data and literature to support the benefit claim. A high-risk implant can be acceptable when it treats a condition with no alternative; a moderate risk can be unacceptable where a safer alternative exists.

How does ISO 14971 connect to IEC 62304, ISO 13485 and the EU MDR?

ISO 13485:2016 requires documented risk management in product realisation, which is how ISO 14971 enters both the EU and, since February 2026, the US quality system (see what ISO 13485 requires). IEC 62304 builds on it: its clause 7 adds software risk management, tracing each software cause of a hazardous situation to its risk control and verification, as our IEC 62304 compliance guide explains. The EU MDR ties both to the general safety and performance requirements in Annex I and to post-market surveillance. Our guide to running IEC 62304, ISO 14971 and ISO 13485 together maps the overlaps.

What are the most common ISO 14971 mistakes?

• Building the risk file after the design is finished, when controls can no longer shape it.

• Estimating risk with an unverified control already assumed, so severity or probability is understated.

• Treating FMEA alone as the risk analysis, which misses use errors and hazards that arise in normal use with no failure.

• Leaving the file unchanged when the design changes or complaints reveal a new hazardous situation.

• Handing risk management to one person instead of the clinical, engineering, quality and regulatory people who see different hazards.

• Keeping risk controls in a spreadsheet with no link to the requirements and tests that prove them.

The last one is the mistake a tool can fix. When a requirement changes, someone has to find every risk and test it touches; our change impact analysis guide shows how that works in practice.

Screenshot: a risk record in the Matrix Req risk module, taken from the product video on the risk management page. It shows the hazardous situation, the probability of harm and severity, the risk score before mitigation, a system requirement linked as the risk control, and the score after mitigation.

How does Matrix Req support the ISO 14971 process?

Matrix Req is design control and risk management software for medical device and regulated product teams. Its risk module lets you define your own risk parameters, formula and acceptability criteria, with several risk layers per device and risk category; assess each risk before controls and again after them; and link any design item as the risk control measure (risk management page, read 6 November 2026). Live Risk Matrix and Risk Stats dashboards export into your documents, and AI-generated risk assessments are validated by a person before they are applied.

The product page FAQ says the risk module supports FMEA, DFMEA, ISO 14971 and hazard analysis methodologies, with custom risk scoring matrices and risks linked to requirements and mitigations (Matrix Req product page, read 6 November 2026). The Matrix Req 3.1 Traceability Checker finds risks with no mitigation and mitigations with no verification, which is the clause 4.5 traceability gap auditors look for first.

The Compliance Checker imports a standard you hold, ISO 14971 included, as a PDF and turns it into a checklist evaluated against your project evidence. It finds documentation gaps; it does not certify anything. Documents such as the risk management report come out of the same project data as PDF, Word or HTML (technical documentation page, read 6 November 2026).

Our own data shows why this matters. In real feedback from technical buyers at medical device companies, the pains raised most often were traceability kept in Excel and change impact worked out by hand (Matrix One technical buyer study, October 2026). Both hit the risk file first, because every control is a link between a risk, a requirement and a test.

What do you need in place before Matrix Req works?

• A risk management policy and acceptability criteria agreed by top management (clause 4.2); Matrix Req applies your criteria, it does not set them.

• A named owner for the requirements and risk structure.

• A decision on which items live in Jira and which in Matrix Req.

• Your existing risk and trace matrix spreadsheets exported, so links can be mapped on import.

• The onboarding sessions booked; the onboarding page says teams that know an ALM tool are often productive within a few days, and most are running in under two months with a full migration package (read 6 November 2026).

Where can you read more on ISO 14971?

• Linking ISO 14971 risk controls to requirements

• Strengthen ISO 14971 risk management with traceability

• The main changes in the new ISO 14971 version

• 5 risk analysis methods under ISO 14971: HAZOP, FMEA, FTA, PHA and Bowtie

• Requirements management and the traceability matrix for medical devices

• EU MDR: the top 10 questions answered

Summary: how do you run ISO 14971 risk management for a medical device?

You run ISO 14971 risk management by writing a plan with your acceptability criteria (4.4), analysing and evaluating every hazardous situation (5 and 6), controlling and verifying the risks that are not acceptable (7), judging the overall residual risk (8), reviewing the process before release (9) and feeding post-market information back in (10), with all of it traceable in the risk management file (4.5). Under the QMSR since 2 February 2026 and under the MDR through the harmonised EN ISO 14971:2019/A11:2021, that file is what inspectors and notified bodies read. Matrix Req keeps risks, controls, requirements and tests linked so the file stays current when the design changes.

1. Set acceptability criteria you can defend in the plan, written to the MDR wording if you sell in the EU.

2. Trace every hazardous situation to its control and the verification of that control (4.5, 7.2).

3. Keep clause 10 running after release, so field data reopens the analysis.

To compare tools for this work, see our ranking of the best ISO 14971 risk management software, where Matrix Req ranks first.

Last updated: 6 November 2026.