Risk Management Under QMSR: Why ISO 14971 Is Now the Center of FDA Inspections
When FDA's Quality Management System Regulation (QMSR) took effect on 2 February 2026, one of the most significant shifts was not a new requirement but a new emphasis. The old Quality System Regulation mentioned risk analysis once, in the design validation provision at 21 CFR 820.30(g). The QMSR incorporates ISO 13485:2016 by reference, and ISO 13485 embeds risk-based thinking throughout the quality management system: in design, purchasing, production, software validation, feedback and CAPA.
FDA has been explicit about where it expects problems. In public remarks reported by RAPS earlier this year, an FDA official described risk management as the most frequent area of Form 483 observations in the early months of QMSR inspections. For regulatory affairs and quality professionals, that makes risk management the single most important area to get right in 2026.
This article explains how the QMSR treats risk management, the relationship between ISO 13485 and ISO 14971, where manufacturers are most exposed, and a practical approach to making risk management a living system rather than a design-phase deliverable.
How the QMSR Handles Risk Management
The QMSR, codified at 21 CFR Part 820, incorporates ISO 13485:2016 by reference in 820.7 and requires manufacturers to comply with it through 820.10. ISO 13485 refers to risk management in several clauses, most importantly:
Clause 4.1.2(b): apply a risk-based approach to the control of the appropriate processes needed for the QMS.
Clause 4.1.5 and 7.4.1: control outsourced processes and purchased product proportionately to the associated risk.
Clause 4.1.6 and 7.5.6: validate computer software used in the QMS and production proportionately to the risk associated with its use.
Clause 7.1: document one or more processes for risk management in product realization, and maintain records of risk management activities.
Clause 7.3.3(c): include outputs of risk management as design and development inputs.
Clause 8.2.1: use feedback as a potential input into risk management for monitoring and maintaining product requirements and product realization.
ISO 13485 clause 7.1 carries a note referencing ISO 14971 for guidance. The QMSR itself does not incorporate ISO 14971 by reference. However, in the QMSR final rule preamble, FDA explained that it considers ISO 14971 a useful standard for meeting risk management requirements, and ISO 14971:2019 is on FDA's list of recognized consensus standards. In practice, investigators and reviewers expect manufacturers to use ISO 14971 or be able to justify an equivalent approach.
The QMSR also defines "risk" consistently with ISO 14971: the combination of the probability of occurrence of harm and the severity of that harm. This matters because ISO 13485 uses "risk" to mean risk related to safety and performance of the device and meeting regulatory requirements, not business risk.
What ISO 14971:2019 Requires
ISO 14971:2019, supported by the guidance in ISO/TR 24971:2020, defines a lifecycle process with these main elements:
Risk management plan for the specific device, including scope, lifecycle phases, responsibilities, requirements for review, criteria for risk acceptability (based on the manufacturer's policy), the method for evaluating overall residual risk, verification activities, and activities for collecting and reviewing production and post-production information.
Risk analysis: intended use and reasonably foreseeable misuse, identification of characteristics related to safety, identification of hazards and hazardous situations, and estimation of risk for each hazardous situation.
Risk evaluation against the acceptability criteria in the plan.
Risk control, with options applied in priority order: inherently safe design and manufacture, protective measures in the device or manufacturing process, and information for safety (and, where appropriate, training of users). Each risk control must be implemented and verified for both implementation and effectiveness.
Evaluation of overall residual risk against the criteria in the plan, and a benefit-risk analysis where overall residual risk is not acceptable.
Risk management review before commercial release, documented in a risk management report.
Production and post-production activities: actively collecting and reviewing information, and feeding it back into the risk management process.
The 2019 edition introduced several changes that manufacturers still struggle to apply: an explicit requirement to define the method for evaluating overall residual risk, a stronger emphasis on benefit, the inclusion of risks related to data and systems security in the scope of hazards, and more detailed requirements for post-production information collection.
Where Manufacturers Are Most Exposed
Common weaknesses observed in risk management files, and the ones most likely to generate inspection observations under the QMSR, fall into six categories.
1. Risk management that stops at design transfer
The most common weakness is a risk management file that was completed for design release and has not changed since. Complaints, service records, nonconforming product data and CAPAs accumulate without anyone checking whether they change the probability estimates, reveal new hazards, or show that a risk control is less effective than assumed. Under ISO 13485 clause 8.2.1 and ISO 14971 clause 10, this is a direct gap.
2. Probability estimates without a basis
Probability of occurrence of harm is often assigned by team judgment without reference to any data. When a complaint trend later shows that a hazardous situation happens more often than estimated, the file has no documented basis to revise. Each probability estimate should reference its source: field data from predecessor devices, published literature, reliability testing, or clearly documented expert judgment.
3. Confusing risk control with labeling
ISO 14971 requires manufacturers to apply risk control options in priority order. Files that rely on warnings in the instructions for use where a design change was feasible are a recurring concern. Information for safety is a valid control only when inherently safe design and protective measures are not practicable or have been applied as far as possible, and its effectiveness must still be verified, typically through usability evaluation under IEC 62366-1.
4. Risk management disconnected from purchasing and production
ISO 13485 requires risk to drive the level of control over suppliers and outsourced processes, and the extent of software validation. Many manufacturers maintain a device risk file but cannot show how that file determined which suppliers are critical, what incoming inspection is performed, or which production processes require validation. Investigators under the QMSR follow those links.
5. Inconsistent acceptability criteria
Risk acceptability criteria should flow from a management-approved policy and be applied consistently across products. Using different matrices for different product lines, without justification, or changing criteria between revisions to make residual risks acceptable, undermines the credibility of the file.
6. Weak overall residual risk evaluation
Many files conclude "overall residual risk is acceptable" with a single sentence. ISO 14971:2019 requires a defined method, and the evaluation should consider the combined contribution of individual residual risks, comparison with similar devices on the market, and the device's clinical benefit.
Making Risk Management a Living System
Link feedback processes to specific risk file entries
Every complaint and nonconformity investigation should include a step that identifies the relevant hazardous situation in the risk file, or records that the event represents a new hazard. This creates the data needed to verify probability estimates and detect emerging risks. Many electronic QMS tools support this linkage; if yours does not, a controlled reference field is a workable alternative.
Define triggers for risk file review
Set objective triggers in the risk management plan: a complaint rate for a hazardous situation that exceeds the rate implied by the probability estimate; a new hazard identified in complaint or literature review; a serious injury or death report; a design, supplier or process change; publication of a relevant recall or safety communication for a similar device; or a periodic review interval (for example, annually). Document each review, including those that result in no change.
Integrate risk management into management review
Under the QMSR, management review records are no longer exempt from FDA inspection. Management review inputs under ISO 13485 clause 5.6.2 include feedback, complaint handling, reporting to regulatory authorities, CAPA and new or revised regulatory requirements. Presenting a summary of risk file reviews, triggers activated and resulting actions as a standing agenda item gives top management visibility and creates a documented record that risk management is operating.
Use risk to scale every downstream process
Create a simple, controlled mapping from risk classes in your device risk files to process controls: which suppliers are critical, what level of incoming inspection applies, which processes require validation, the depth of software validation for production and QMS software, and the priority of CAPAs. This makes the "risk-based approach" in ISO 13485 clause 4.1.2 visible and auditable.
Connect security risk and safety risk
For connected devices, maintain a security risk assessment that uses exploitability rather than probability (as FDA's cybersecurity guidance recommends) but links to the safety risk file wherever a security threat could lead to patient harm. Both files should reference each other, and changes in one should trigger review of the other.
Preparing for a QMSR Inspection
FDA's new inspection approach under the QMSR, replacing the Quality System Inspection Technique (QSIT), is designed to follow risk through the QMS. Before an inspection, test your system by selecting two or three devices and tracing:
A significant hazardous situation in the risk file, to its design input, risk control and verification evidence.
The same hazardous situation to relevant complaints and nonconformities from the last two years, and whether the probability estimate still holds.
The risk controls that depend on a supplier, to the supplier's classification and the controls applied.
Any CAPA related to that hazardous situation, to the updated risk file.
The management review record where the outcome was discussed.
If any step in that trace is missing or relies on verbal explanation, it is likely to become an observation.
Common Questions
Does FDA require ISO 14971 certification?
No. ISO 14971 is not a certification standard, and the QMSR does not incorporate it by reference. But FDA recognizes it, reviewers expect risk management documentation consistent with it, and ISO 13485 clause 7.1 requires a documented risk management process that ISO 14971 is designed to satisfy.
Do we need separate risk files for the EU and the U.S.?
Not necessarily. A single ISO 14971-compliant risk management file can support both MDR and FDA requirements, provided it addresses the MDR's expectations that risks be reduced "as far as possible" without adversely affecting the benefit-risk ratio, as described in the European harmonized version EN ISO 14971:2019+A11:2021 Annex Z.
How often should the risk file be reviewed?
ISO 14971 does not set a fixed interval. It requires review when production and post-production information indicates the need. Most manufacturers combine event-driven triggers with a periodic review, often aligned with the PSUR or annual report cycle.
Worked Example: Following One Hazard Through the System
Consider an ambulatory infusion pump and one hazardous situation in its risk file: an undetected downstream occlusion leading to under-infusion of a critical medication. At design release, the team estimated the probability of harm as "remote," based on bench testing of the occlusion sensor and field data from a predecessor model. The risk controls were an occlusion pressure sensor with an alarm (protective measure) and instructions to check the line periodically (information for safety).
Eighteen months after launch, complaint data show a cluster of reports in which the occlusion alarm sounded late when a specific low-flow rate was used with a particular administration set. No serious injury has been reported. Here is what a well-functioning system does with that information:
Complaint investigation links to the risk file. Each complaint is associated with the "undetected downstream occlusion" hazardous situation, making the cluster visible in trending.
A trigger fires. The complaint rate for this hazardous situation exceeds the rate implied by the "remote" probability estimate, which is a defined trigger in the risk management plan.
The risk estimate is revised. The team re-estimates probability for the specific combination of flow rate and administration set, documenting the data used. The revised risk falls into a region requiring further risk reduction.
Risk control options are re-evaluated in priority order. A firmware change to the occlusion detection algorithm at low flow rates (a design change) is feasible and is chosen over a labeling-only change.
Design change control is applied. The change is verified and validated, the risk file is updated, and regulatory affairs assesses whether the change requires a new 510(k).
Field action is assessed. The team evaluates whether devices in the field need a correction and whether that correction is reportable under 21 CFR Part 806, and whether any complaints met MDR reporting criteria as malfunctions.
Management review is informed. The trigger, the revised estimate and the actions taken appear as an input to the next management review.
Each step leaves a record. In an inspection, this chain of evidence demonstrates that the risk management process is operating as ISO 13485 and ISO 14971 intend. The absence of any link in the chain is where observations originate.
Benefit-Risk Analysis: Doing It Properly
ISO 14971:2019 requires a benefit-risk analysis when an individual residual risk, or the overall residual risk, is not judged acceptable using the criteria in the risk management plan. Many files include a benefit-risk statement by default, often a generic paragraph asserting that the benefits of the device outweigh the risks. A defensible benefit-risk analysis instead:
describes the specific clinical benefits in measurable terms, drawn from clinical data or literature;
compares the residual risk with alternative treatments or devices representing the state of the art;
considers the patient population and the severity of the condition being treated or diagnosed; and
explains why further risk reduction is not practicable.
For devices sold in the EU, the benefit-risk analysis must also align with the MDR's requirements and the clinical evaluation report, so consistency between the risk management file and the clinical evaluation is essential.
The Bottom Line
Under the QMSR, risk management is not a document; it is the logic that should explain why every other process is controlled the way it is. The manufacturers that perform best in QMSR inspections are those that can show, with records, how field data changed their understanding of risk and how that understanding changed their design, suppliers, production and CAPA decisions. Making that loop visible is the most valuable quality investment an organization can make in 2026.
Sources
21 CFR Part 820, Quality Management System Regulation (final rule, 89 FR 7496, 2 February 2024; effective 2 February 2026)
ISO 13485:2016, Medical devices – Quality management systems – Requirements for regulatory purposes
ISO 14971:2019, Medical devices – Application of risk management to medical devices; ISO/TR 24971:2020
FDA Recognized Consensus Standards database, ISO 14971:2019
RAPS, reporting on FDA remarks regarding early QMSR inspection findings (2026)
IEC 62366-1:2015+A1:2020, Application of usability engineering to medical devices
Comments