ISO 14971 is the international standard for medical device risk management, and FDA recognizes the complete 2019 edition as recognition number 5-125. A declaration of conformity alone may not be enough, because FDA may need to review your underlying risk documentation.
Key takeaways
- FDA recognized ISO 14971:2019 in full on December 23, 2019. The standard does not set acceptable risk levels; your own criteria do.
- FDA's 2018 standards guidance names ISO 14971 as a standard whose declaration of conformity may need supporting documentation.
- Since February 2, 2026, the QMSR requires risk management throughout the quality system. It works through ISO 13485 and does not incorporate ISO 14971 itself.
- We counted FDA's inspection data: investigators cited inadequate risk analysis at least 47 times in fiscal year 2025, the 13th most frequent of 185 device citation types.
- FDA's February 2026 cybersecurity guidance treats security risk management as a process distinct from ISO 14971 safety risk management.
What is ISO 14971, and does FDA require it?
ISO 14971 sets out a process to identify hazards, estimate and evaluate risks, and control them [1]. It also covers checking that the controls work, across a device's whole life cycle [1]. FDA recognizes the complete standard, ISO 14971:2019, and its identical US adoption, ANSI/AAMI ISO 14971:2019 [1].
Two limits are easy to miss. The standard does not specify acceptable risk levels, and it does not require a quality management system [1]. You set the acceptability criteria yourself.
Conformity is voluntary. Risk management is not. Using a recognized standard is a choice. But for devices subject to the Quality Management System Regulation (QMSR), effective February 2, 2026, risk management is required [3]. The QMSR incorporates ISO 13485 [3]. FDA says the QMSR explicitly emphasizes risk management activities and risk-based decision making [3]. FDA did not incorporate ISO 14971 in the QMSR [3]. It says such standards may still help in applying ISO 13485 [3].
FDA also rejected the view that ISO 13485 falls short of a full risk management system. In its words, it "disagrees that ISO 13485 does not require a complete risk management system" [3]. Our QMSR guide explains the regulation.
What goes in a risk management file?
Three documents form the core. FDA's software guidance, final since June 14, 2023, says the file should be part of the premarket submission [5]:
| Document | What FDA's review focuses on |
|---|---|
| Risk management plan | Your criteria for accepting each risk, and your method for weighing overall residual risk against the benefits |
| Risk assessment | Risk analysis, risk evaluation, risk control and, where applicable, benefit-risk analysis |
| Risk management report | Proof that the plan was followed, that overall residual risk is acceptable, and that you collect production and post-production information |
Source: FDA, Content of Premarket Submissions for Device Software Functions, June 14, 2023 [5].
That guidance covers device software, and FDA points submitters to a recognized version of ISO 14971 for building the file [5]. It spells out what a risk file should contain. Our guide to IEC 62304 and ISO 14971 for software covers the software side.
What do FDA reviewers look for in your risk file?
They look for a file that shows its reasoning. FDA's software guidance sets out these expectations for device software [5]. They are also a sound model for any device's risk file.
- Criteria set before evaluation. Write your criteria for accepting risk into the plan before the first risk evaluation.
- Foreseeable misuse, not just intended use. Identify hazards from intended use and from reasonably foreseeable misuse, intentional or not.
- The whole system. For software that runs on hardware, assess the software with its whole hardware environment.
- Controls in priority order. Use design first, protective measures such as alarms second, and information for safety, such as warnings and training, last.
- Verified controls. Show that each control was implemented and that it actually reduces the risk.
- Traceability. Trace each hazard to its control and its test. For example, link a hazard ID to a requirement ID and to a test with pass or fail results.
Do not assume software rarely fails. FDA warns that unrealistically low probability estimates for software failures can lead to unrealistic risk evaluation [5]. Where probability cannot be estimated well, FDA says a worst case applies: set the probability of the software failure to 1 [5].
Your risk analysis also sets your software documentation level. FDA asks for Enhanced documentation when a software failure could present a hazardous situation with a probable risk of death or serious injury [5]. Judge this before counting your risk controls [5].
A declaration of conformity may not be enough. FDA's 2018 guidance on consensus standards uses ISO 14971 as its example of a process-oriented standard [2]. Such standards typically do not list all the detailed acceptance criteria [2]. For such standards, FDA may need to review the underlying data, and it recommends supporting documentation under ISO/IEC 17050-2 [2].
How do you build a risk management file, step by step?
Work in this order. Each step reflects FDA's software guidance [5], which is also a sound model for other devices.
- Write the plan first. Set your criteria for accepting risk, and how you will weigh overall residual risk against the benefits [5].
- Identify hazards from the intended use and from reasonably foreseeable misuse [5]. Add known problems with similar devices, such as adverse event reports and recalls.
- Trace each hazard to harm. Map the sequences of events that lead to a hazardous situation, and the harm that could follow [5].
- Estimate each risk from its severity and probability. For a software failure you cannot estimate well, set the probability to 1 [5].
- Evaluate each risk against the criteria in your plan [5].
- Control risks in priority order: design first, then protective measures, then information for safety [5].
- Verify every control. Show it was implemented and that it reduces the risk, and trace hazard to control to test [5].
- Judge overall residual risk against the benefits, and write the risk management report [5].
- Keep the file current as complaints, corrective actions and adverse event reports come in [3].
What does a traceable risk file entry look like?
One row per hazard, linked to its evidence. Here is an example entry for an endosseous dental implant (FDA product code DZE). The IDs and wording are examples, not data from a real file.
| Field | Example entry |
|---|---|
| Hazard ID | HAZ-012 |
| Hazardous situation | Repeated chewing loads fatigue the implant and abutment connection |
| Harm | The implant or abutment fractures, and the restoration fails |
| Initial risk | Not acceptable under the plan's criteria |
| Control 1 (design) | Connection geometry set from fatigue analysis, in design specification DS-044 |
| Verification | Dynamic loading test to ISO 14801, report TR-118, passed |
| Control 2 (information for safety) | Instructions for use warn on narrow implants in high-load positions |
| Residual risk | Acceptable under the plan's criteria, and included in the overall residual risk evaluation |
Use recognized test standards where they exist. FDA recognizes ISO 14801, the dynamic loading test for endosseous dental implants [1]. Its recognition number is 4-259, and two parts are not recognized, including Annex B on worst-case conditions [1].
Cover production and packaging, not just design. We ran FDA's recall data for dental implants (DZE) on September 25, 2026, and found 11 recall events started from 2020 to 2025 [10]. Of the 8 with a known cause, none was a design problem. Three were process control, two packaging change control, and one each environmental control, process change control and labeling change control [10].
Across all devices, design matters more. In 2025, device design (101) and software design (91) were the second and third most common known causes of recall events, after process control (167) [10]. Together they made up 27% of the 707 events with a known cause [10].
Seed your hazard list from real problems. FDA's adverse event data for similar devices is a direct source of hazards. Our guide to FDA's medical device databases shows how to search it. Complizen's Risk Management workspace seeds a hazard list from your device type's MAUDE history, with severity and probability pre-filled for your review. It then links each hazard to its controls and verification. If you use AI tools to draft parts of the file, our guide to AI and ISO 14971 explains when that use belongs in the risk file.
How does risk management connect to the rest of your submission?
Several FDA guidances build on the same risk file.
| Area | How it connects |
|---|---|
| Human factors | Your use-related risk analysis should draw on methods such as failure mode and effects analysis (FMEA), known use problems and formative evaluation [7] |
| Biocompatibility | FDA's guidance on ISO 10993-1 covers biological evaluation and testing within a risk management process [4] |
| Cybersecurity | Security risk management is a separate process that should link into safety risk management [6] |
| Software | The risk management file is part of the software documentation [5] |
| Labeling | Warnings are information for safety, the lowest-priority type of control [5] |
| Device changes | A risk-based assessment of all new and changed risks helps decide whether a change needs a new 510(k) [9] |
Security risk uses different factors. FDA's cybersecurity guidance, issued February 3, 2026, recommends a safety risk assessment and a separate, accompanying security risk assessment [6]. It says the two are distinct but connected processes, and that your security risk management report should be included in your premarket submission [6]. FDA's note on its recognition of ISO 14971 goes further. It says the standard's probability model does not apply to cybersecurity, where exploitability takes its place [1]. Our cybersecurity guide covers the premarket expectations.
Our human factors testing guide explains use-related risk analysis and critical tasks. Our guide to when a device change needs a new 510(k) covers change decisions.
What do FDA investigators find?
Risk analysis is a common inspection finding, and the count has risen. We measured this in FDA's own inspection data for fiscal years 2022 to 2025. In fiscal year 2025, FDA's system recorded 791 Form 483s issued in its devices program [8]. Investigators cited "risk analysis not performed/inadequate" under design validation 47 times, the 13th most frequent of 185 different device citations [8].
| Fiscal year | Device 483s issued | Risk analysis not performed or inadequate | Rank among device citations |
|---|---|---|---|
| 2022 | 538 | 30 | 13th of 163 |
| 2023 | 720 | 26 | 27th of 179 |
| 2024 | 672 | 42 | 12th of 174 |
| 2025 | 791 | 47 | 13th of 185 |
Source: our analysis of FDA's inspection observations data, fiscal years 2022 to 2025 [8].
Treat these counts as a floor. FDA says its spreadsheets do not list every observation, because some Form 483s are prepared by hand [8].
The most cited problems feed the risk file too. The top two device citations in fiscal year 2025 were corrective and preventive action procedures (279) and complaint handling procedures (211) [8]. Both handle production and post-production information of the kind your risk management report should show you collect [5].
Expect new citation codes. These counts cite the former 21 CFR 820.30(g), which ended when the QMSR took effect on February 2, 2026 [3]. FDA says its expectations for risk management remain consistent [3]. FDA now places risk management throughout ISO 13485, including clauses 4.1, 7.1, 7.3, 7.4, 7.5, 7.6 and 8.2 [3].
How do you keep the risk file current after launch?
Update it whenever new information changes the picture. FDA expects risk documentation to be reviewed and updated when you learn of previously unforeseen risks [3]. The same applies to new information showing that known risks need updating [3].
Useful sources include complaints, corrective and preventive actions, adverse event reports and recalls. Under FDA's reporting rule, some events must also be reported to FDA [11]. Our guide to FDA medical device reporting explains when.
Can one risk file serve both FDA and the EU MDR?
It can share one process, but check the EU's own risk-reduction rule. The EU Medical Device Regulation requires risks to be reduced "as far as possible without adversely affecting the benefit-risk ratio" [12]. It also requires a risk management system run as a continuous process throughout the device's life [12].
Either way, check a file built for the EU MDR against FDA's own expectations:
- criteria for accepting risk, written before the first risk evaluation [5]
- a worst-case probability for software failures you cannot estimate well [5]
- controls in priority order, each verified and traced to its test [5]
- a separate security risk assessment based on exploitability [1, 6]
- supporting risk documentation, not only a declaration of conformity [2]
The QMSR applies to manufacturers outside the US too. Under 21 CFR 820.1(c), an imported device that appears to be adulterated can be refused entry to the US [3].
What changed in 2026?
Three changes date older guides.
The QMSR took effect on February 2, 2026. Risk management now sits throughout ISO 13485 [3]. The old risk analysis clause, 21 CFR 820.30(g), is gone [3].
FDA reissued its cybersecurity guidance on February 3, 2026. It keeps security risk management distinct from ISO 14971 safety risk management [6].
FDA finalized its human factors content guidance on May 29, 2026. Use-related risk analysis now helps decide what human factors information your submission needs [7].
Frequently asked questions
Is ISO 14971 mandatory for FDA?
Not by itself. ISO 14971 is a voluntary consensus standard that FDA recognizes. However, the QMSR incorporates ISO 13485, and FDA says ISO 13485 requires a complete risk management system. So devices subject to the QMSR need a risk management system either way. ISO 14971 is the standard FDA recognizes for building one.
Which version of ISO 14971 does FDA recognize?
FDA recognizes ISO 14971:2019, the third edition, as recognition number 5-125, entered on December 23, 2019. The recognition covers the complete standard and its identical US adoption, ANSI/AAMI ISO 14971:2019. FDA also lists ISO/TR 24971:2020 as supporting guidance on applying it.
Is a declaration of conformity to ISO 14971 enough for a 510(k)?
It may not be. FDA's 2018 guidance on consensus standards names ISO 14971 as an example of a process-oriented standard without detailed acceptance criteria. For such standards, FDA may need to review your underlying data, so plan to provide supporting risk documentation.
What goes in a risk management file for FDA?
A risk management plan, a risk assessment and a risk management report. FDA's software guidance says the plan should set criteria for accepting risk before evaluation. The assessment should trace each hazard to verified controls, and the report should confirm overall residual risk is acceptable.
What is the order of risk control measures?
Design comes first, such as removing unnecessary features. Protective measures come second, such as alarms or automatic shutdown. Information for safety, such as warnings and training, comes last. FDA lists them in this descending order of priority in its software guidance.
How should I estimate the probability of a software failure?
Carefully. FDA warns that unrealistically low probability estimates for software failures can lead to unrealistic risk evaluation. Where the probability cannot be estimated well, FDA says to assume the worst case and set the probability of the software failure to 1.
Does the QMSR incorporate ISO 14971?
No. FDA states that the QMSR does not incorporate ISO 14971. It incorporates ISO 13485, and FDA says ISO 13485 requires a complete risk management system, with risk management throughout its clauses. FDA adds that standards like ISO 14971 may help in applying ISO 13485.
What is the difference between safety and security risk management?
FDA's February 2026 cybersecurity guidance treats them as distinct processes. Safety risk management under ISO 14971 estimates the probability and severity of harm. Security risk management uses exploitability instead of probability, and FDA says the two processes should link to each other.
How often do FDA inspectors cite risk analysis problems?
In fiscal year 2025, FDA investigators cited inadequate or missing risk analysis at least 47 times on device Form 483s, the 13th most frequent of 185 citation types. It was cited 42 times in 2024. FDA notes its data does not include every Form 483.
When should I update my risk management file?
Whenever new information changes your risk picture. FDA expects risk documentation to be reviewed and updated when you learn of previously unforeseen risks, or of information showing known risks need updating. Complaints, corrective actions and adverse event reports are useful sources.
What is ISO/TR 24971?
ISO/TR 24971 is a technical report with guidance on applying ISO 14971. FDA lists its second edition, from June 2020, and the US version, AAMI/ISO TIR24971:2020, as supporting publications in its recognition of ISO 14971. It is guidance on applying the standard, not a separate standard.
How does ISO 14971 relate to human factors?
Use-related risks are part of your risk analysis. FDA's final human factors content guidance, issued May 29, 2026, bases its submission categories on the use-related risk analysis. That analysis should draw on methods such as FMEA, known use problems and formative evaluation.
References
- FDA. Recognized Consensus Standards database: ISO 14971:2019, recognition number 5-125, entered December 23, 2019; and ISO 14801, recognition number 4-259, entered July 15, 2019. Accessed September 26, 2026.
- FDA. Appropriate Use of Voluntary Consensus Standards in Premarket Submissions for Medical Devices. Issued September 14, 2018.
- Federal Register. Medical Devices; Quality System Regulation Amendments, 89 FR 7496. Published February 2, 2024; effective February 2, 2026.
- FDA. Use of International Standard ISO 10993-1, "Biological evaluation of medical devices - Part 1: Evaluation and testing within a risk management process". Issued September 8, 2023.
- FDA. Content of Premarket Submissions for Device Software Functions. Issued June 14, 2023.
- FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Issued February 3, 2026.
- FDA. Content of Human Factors Information in Medical Device Marketing Submissions. Issued May 29, 2026.
- FDA. Inspection Observations. Fiscal year 2022 to 2025 data files; page current as of December 16, 2025.
- FDA. Deciding When to Submit a 510(k) for a Change to an Existing Device. Issued October 25, 2017.
- FDA. Medical Device Recalls database, analyzed through openFDA's device recall data. Accessed September 25, 2026.
- eCFR. 21 CFR Part 803, Medical Device Reporting. Accessed September 25, 2026.
- EUR-Lex. Regulation (EU) 2017/745 on medical devices, Annex I. Accessed September 25, 2026.