Risk management is now the top inspection finding
For years, many device companies treated risk management as a file: an ISO 14971 risk management plan, a hazard analysis and an FMEA, updated before a submission and then left alone. Under FDA’s Quality Management System Regulation (QMSR), in effect since February 2, 2026, that approach is failing in inspections.
In May 2026, an FDA official told RAPS that “Risk management is the top observation” in QMSR inspections, ahead of outsourcing, complaint handling, UDI and corrective actions (RAPS). The reason is structural. ISO 13485, now incorporated into Part 820, requires a risk-based approach to controlling QMS processes, and FDA’s revised compliance program evaluates risk management throughout every inspection area rather than as a single checkpoint (FDA CP 7382.850). Investigators follow risk from the design file to the production floor to the complaint log.
The four layers of medical device risk
Modern device risk management covers more than product hazards. Each layer has its own standards and guidance, but they need to connect.
| Layer | Main question | Key references | Typical evidence |
|---|---|---|---|
| Product safety risk | Can the device cause harm to patients, users or others? | ISO 14971:2019, ISO/TR 24971 | Risk management plan, hazard analysis, risk controls, benefit-risk, risk management report |
| QMS process risk | Could a process failure lead to a nonconforming or unsafe device? | ISO 13485 clause 4.1.2 and throughout; QMSR | Risk-based supplier controls, validation depth, audit scheduling |
| Cybersecurity risk | Can a vulnerability be exploited to cause harm or disrupt function? | FD&C Act section 524B; FDA cybersecurity guidance | Threat model, security risk assessment, SBOM, vulnerability management plan |
| AI and software risk | Can the model or software fail, drift or mislead users? | IEC 62304, FDA AI guidance, GMLP principles | Software hazard analysis, performance monitoring, change control plans |
Product safety risk (ISO 14971)
ISO 14971:2019 remains the core standard, recognized by FDA and harmonized under the EU MDR. Its lifecycle is familiar: plan, analyze, evaluate, control, evaluate overall residual risk, review, then collect and review production and postmarket information. The last step is where most programs break. A risk file that is not updated from complaints, nonconformances and field data is exactly what investigators are citing.
QMS process risk
ISO 13485 asks for risk-based decisions across the QMS: how tightly to control a supplier, how deeply to validate a process or software tool, which areas to audit first. FDA’s Computer Software Assurance guidance applies the same thinking to QMS and production software, focusing effort where failure “may result in a quality problem” that foreseeably compromises safety (FDA CSA guidance).
Cybersecurity risk
For devices that meet the definition of a “cyber device,” section 524B of the FD&C Act requires cybersecurity information in premarket submissions. FDA’s final guidance on cybersecurity in medical devices, most recently updated February 3, 2026 and superseding the June 27, 2025 version, describes how to integrate security risk management into the quality system (FDA). Security risk assessment uses different scales than safety risk, but security risks that could lead to patient harm must flow into the ISO 14971 file.
AI and software risk
AI-enabled devices add risks that traditional hazard analysis can miss: performance drift, bias across patient subgroups and changes over time. FDA’s final guidance on predetermined change control plans lets manufacturers pre-authorize certain model changes, provided the risks of those changes are analyzed up front (FDA). The good machine learning practice principles, finalized by the IMDRF in January 2025, frame risk management across the total product lifecycle (FDA).
Connecting risk across the lifecycle
The test an investigator applies is simple: pick one risk and follow it. Can the company show where it was identified, how it was controlled, whether the control was verified, how production protects it, and what field data says about it now? Each handoff below is a place where that trail commonly breaks.
| From | To | What must flow | Common break |
|---|---|---|---|
| Risk analysis | Design inputs | Risk controls become requirements | Controls listed in the FMEA but never written as requirements |
| Design outputs | Verification | Each control is verified for implementation and effectiveness | Tests exist but are not traced to the control |
| Risk file | Purchasing | Critical components and suppliers identified by risk | Supplier controls set by spend, not risk |
| Risk file | Production | Process FMEA, validation depth, inspection points | Process risks not linked to design risks |
| Complaints and nonconformances | Risk file | New hazards, higher occurrence rates | Complaint trending never compared with risk estimates |
| Risk file | Change control | Every change assessed for new or changed risks | Change records say “no risk impact” without analysis |
| Cybersecurity and AI monitoring | Risk file | Vulnerabilities, drift and performance signals | Separate teams with separate files |
| Risk file | Management review | Residual risk trends and benefit-risk status | Risk never reaches management review |
Metrics that show risk management works
- Percentage of complaints and nonconformances evaluated against the risk file within a set time
- Number of risk files updated from postmarket data in the last review period
- Percentage of design and process changes with a documented risk assessment
- Share of risk controls with traced verification evidence
- Time from a new vulnerability disclosure to its risk assessment, for cyber devices
- Number of risk-based decisions (supplier tier, validation depth, audit priority) with documented rationale
Medical device risk management checklist
- Risk management procedure covers product, process, cybersecurity and AI/software risk, with defined links
- Risk acceptability criteria defined in the risk management plan and approved by management
- Every risk control traced to a design requirement and to verification of implementation and effectiveness
- Process FMEA linked to the design risk file and to validation depth
- Supplier controls and audit frequency set by risk
- Complaints, nonconformances, CAPAs and service data reviewed against risk estimates on a schedule
- Change control requires a documented risk assessment, not a checkbox
- Security risk assessment and SBOM maintained for cyber devices; harms flow into the ISO 14971 file
- AI performance monitoring and change plans linked to the risk file
- Overall residual risk and benefit-risk reviewed in management review
- Internal audits trace at least one risk end to end each cycle
For a clause-level checklist, see our ISO 14971 risk management checklist.
Trace risk without rebuilding the spreadsheet
Following a risk across design files, test reports, supplier records, complaints and change records is slow work. AI document assessment can read those documents together, flag controls without verification or complaints that never reached the risk file, and cite the passage behind every finding.
Run a sample regulatory document assessment on one product’s risk file and its linked records. AskDona shows the evidence; your risk team decides.
FAQ
What is medical device risk management? The systematic process of identifying hazards, estimating and evaluating risks, controlling them and monitoring their effectiveness across the device lifecycle, as defined in ISO 14971:2019.
Why is risk management the top QMSR inspection finding? Because QMSR inspections evaluate risk throughout every QMS area, and many companies keep risk in an isolated file (RAPS).
Is cybersecurity part of risk management? Yes. FDA’s cybersecurity guidance, updated February 3, 2026, describes security risk management within the quality system, and safety-relevant security risks belong in the ISO 14971 file (FDA).
How often should the risk file be updated? Whenever new information arrives, such as complaints, nonconformances, design changes or field data, and at planned review intervals.
References
All pages opened and checked by October 13, 2026.
| Source | Type | Date | Used for |
|---|---|---|---|
| RAPS: Top QMSR observations | Professional body | May 14, 2026 | Risk as top observation |
| FDA: CP 7382.850 | Regulator | Feb 2, 2026 | Risk across inspection areas |
| FDA: CSA guidance | Regulator guidance | Feb 3, 2026 | Process risk |
| FDA: Cybersecurity in Medical Devices guidance | Regulator guidance | Feb 3, 2026 | Section 524B, security risk |
| FDA: PCCP guidance for AI | Regulator guidance | Final | AI change risk |
| FDA: Good Machine Learning Practice | Regulator | Jan 2025 (IMDRF final) | AI lifecycle risk |