FMEA and risk analysis artifacts from design validation survive; the core hazard-identification discipline transfers.
ISO 14971:2019 lifecycle integration — Risk Management Plan, risk file, residual-risk acceptance, and post-market feedback loop all now mandatory.
Risk Management Plan and Report completeness, and linkage to CAPA and PMS inputs — common gap where legacy risk ends at DHF.
Maps to
QMSR / ISO 13485: §820.30(g) Design validation.
ISO 13485: §7.1 Planning of product realization
ISO 14971: §4 General requirements for risk management system, §5 Risk analysis, §6 Risk evaluation, §7 Risk control, §8 Evaluation of overall residual risk, §9 Risk management review, §10 Production and post-production activities
Requirement text
The organization shall document a risk management process throughout the product lifecycle. This includes hazard identification, risk estimation, risk evaluation, risk control, and evaluation of residual risk acceptability. FDA-Plus: Risk management must be integrated with design controls; risk analysis outputs must feed design inputs, and risk control measures must be verified and validated.
Why this clause exists
The single most consequential structural change in the QMSR is the elevation of risk management from a clause within design validation — where Part 820.30(g) treated risk analysis as something you did at the end of design — to a lifecycle discipline grounded in ISO 14971:2019 and woven through every major quality system process. The underlying regulatory rationale is grounded in decades of post-market evidence: devices recalled for safety failures frequently show risk management records that were correct at design transfer but were never updated when post-market complaints, design changes, and software anomalies accumulated that changed the risk profile. The QMSR's incorporation of ISO 14971 is a paradigm shift: a standalone FMEA without the surrounding framework of a Risk Management Plan defining acceptability criteria, a Risk Management Report evaluating overall residual risk, and a post-market feedback loop to update the risk file is no longer sufficient. Risk management is not a design-phase activity; it is a continuous organizational obligation that connects design controls, CAPA, complaint handling, supplier management, and management review into a coherent lifecycle safety discipline. FDA inspectors approaching a QMSR inspection now use the Risk Management File as the primary navigation tool — any process gap they find in any QMS subsystem is evaluated against whether the risk management process should have caught and mitigated it.
What changed
§820.30(g) — Part 820 (legacy)
"Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF."
§7.1 — ISO 13485:2016 (current)
"The organization shall plan and develop the processes needed for product realization. Planning of product realization shall be consistent with the requirements of the other processes of the quality management system. The organization shall document one or more processes for risk management in product realization. Records of risk management activities shall be maintained (see 4.2.5). In planning product realization, the organization shall determine the following, as appropriate: a) quality objectives and requirements for the product; b) the need to establish processes and documents (see 4.2.4) and to provide resources specific to the product, including infrastructure and work environment; c) required verification, validation, monitoring, measurement, inspection and test, handling, storage, distribution and traceability activities specific to the product together with the criteria for product acceptance; d) records needed to provide evidence that the realization processes and resulting product meet requirements (see 4.2.5). The output of this planning shall be documented in a form suitable for the organization's method of operations. NOTE Further information can be found in ISO 14971."
Δ Risk management is elevated from an optional add-on within design validation to a mandatory documented process spanning the entire product realization lifecycle.
Common gaps (what we see in audits)
- No Risk Management Plan — The organization performs risk analysis (typically an FMEA) but does not have a product-specific Risk Management Plan per ISO 14971 section 4.4. Without a plan, there are no defined risk acceptability criteria, no assigned responsibilities, no defined scope, and no method for evaluating overall residual risk. The FMEA exists in isolation without the framework that gives it meaning.
- Risk Analysis Limited to Design Phase Only — Risk analysis was performed during product design and development but is not maintained through production, post-market surveillance, and device retirement. The risk file has not been updated since initial product launch, despite field complaints, design changes, and new regulatory information becoming available.
- No Risk Management Report — The organization has an FMEA but no Risk Management Report per ISO 14971 sections 7-9. There is no documented evaluation of overall residual risk, no formal risk management review confirming all planned activities were completed, and no overall benefit-risk conclusion for the device.
- Risk Acceptability Criteria Not Defined — The FMEA contains risk priority numbers (RPNs) or risk ratings but there are no defined, pre-established criteria for what constitutes acceptable vs. unacceptable risk. Acceptability decisions are made ad hoc based on engineering judgment without reference to a risk acceptance matrix approved before the analysis began.
- Risk Control Hierarchy Not Applied — Risk controls are identified but not evaluated using the ISO 14971 priority hierarchy (inherent safety by design > protective measures > information for safety). Labeling and warnings are used as primary risk controls without documenting why design changes or protective measures are not feasible.