Risk Management in Design Control

rmforge.io | Part 4 of a 5-Part Series on Design Controls

Integrating ISO 14971 from Design Input through Design Transfer.

Risk management is not a parallel activity. It is embedded in design controls. Yet teams routinely treat the risk management file as a standalone deliverable, drafted late, disconnected from Design Inputs and Design Outputs, and reviewed in isolation from Design Verification and Design Validation (DV&V). The consequence: risk controls that exist on paper but are not traceable to design requirements, not verified, and not validated. Reviewers and Auditors find these gaps immediately and it is a readily apparent problem in a submission.

ISO 14971:2019 defines a systematic process for identifying hazards, estimating and evaluating risks, controlling those risks, and monitoring effectiveness. When executed correctly, risk management feeds directly into Design Inputs as risk control measures, is documented through Design Outputs, and is confirmed through DV&V. This article addresses how to integrate that process so the risk management file and the Design History File (DHF) or Technical Documentation tell one coherent story.

Regulations and Standards at a Glance

• 21 CFR 820.10(c) (QMSR, 2026): requires Class II, Class III, and specified Class I manufacturers to comply with ISO 13485:2016 Clause 7.3. The current U.S. federal design control requirement.
• ISO 13485:2016 Section 7.1: planning of product realization shall include risk management activities.
• ISO 13485:2016 Section 7.3.3: design and development inputs shall include applicable outputs of risk management.
• ISO 13485:2016 Section 7.3.4: outputs shall be in a form suitable for verification against inputs.
• ISO 13485:2016 Sections 7.3.6 and 7.3.7: verification confirms outputs meet inputs (including risk control requirements); validation confirms the product conforms to defined user needs and intended uses.
• ISO 14971:2019: risk analysis, risk evaluation, risk control, evaluation of overall residual risk, production and post-production activities.
• ISO/TR 24971:2020: guidance on the application of ISO 14971.
• EU MDR 2017/745 Annex I: General Safety and Performance Requirements (GSPRs) mandate risk management integrated throughout design and manufacture.

Mapping the Risk Process to Design Controls

ISO 14971:2019 defines five sequential activities within the risk management process. Each maps directly to one or more design control phases under ISO 13485:2016 Clause 7.3.

Risk Control Measures: From Options Through Verification

This is the integration point most teams either miss or implement poorly. ISO 14971:2019 Clause 7 defines risk control as a multi-step process, not a single action.

Risk Control Measure Options (Clause 7.1)

When a risk requires control, the team analyzes risk control measure options in this priority order:

• Design (Inherent Safety by Design): eliminate the hazard or reduce risk through design changes (optimize strut geometry, select biocompatible alloy, eliminate sharp edges). Highest-priority control.
• Protective Measures: in the device itself or the manufacturing process (guards, alarms, coatings, validated sterilization). Applied when inherent safety by design alone is insufficient.
• Information for Safety: labeling, Instructions for Use (IFU), training, warnings. Lowest tier. Shall not be the sole control for high-severity hazards.

Risk Control Measures as Design Inputs

Each selected risk control measure, regardless of tier, must be documented as a Design Input: either a Product Requirement (quantitative) or a User Need and Intended Use (qualitative). Per ISO 13485:2016 Section 7.3.3, design and development inputs shall include applicable outputs of risk management. The risk control does not live only in the risk management file. It must exist in the design control system with a unique identifier so it can be traced, verified, and validated.

Each risk control Design Input shall reference back to the originating Hazard ID in the risk analysis, and each Hazard ID shall reference forward to the Design Input(s) implementing its control. This bidirectional traceability is required by ISO 14971:2019 Clause 7.1 and Clause 4.5, and supported by ISO 13485:2016 Section 7.3.3.

Risk Control Implementation (Design Outputs)

The Design Output documents implement the risk control requirement. A dimensional specification on a drawing implements a geometry change. A sterilization process instruction implements a validated Sterility Assurance Level (SAL). An IFU implements an information for safety control. Per ISO 13485:2016 Section 7.3.4, Design Outputs must be in a form suitable for verification against Design Inputs, including those originating from risk control measures.

Risk Control Verification

ISO 14971:2019 Clause 7.2 requires verification of implementation of each risk control measure. This connects directly to DV&V under ISO 13485:2016 Sections 7.3.6 and 7.3.7:

• Design Verification (Section 7.3.6): confirms the Design Output meets the risk control requirement. Example: durability testing confirms fatigue life meets the Product Requirement.
• Design Validation (Section 7.3.7): confirms the risk control satisfies its intended use context. Example: simulated use in a tortuous anatomy model confirms the catheter resists kinking.
• Inspection: in some cases, verification is accomplished through in-process or final inspections documented in the Lot History Record (LHR). Example: dimensional inspection confirms a critical tolerance implementing a design-based risk control.

Clause 7.3 also requires residual risk evaluation after each risk control measure is verified. If the residual risk introduced by the control itself creates a new hazard, that hazard must be added to the risk analysis, and the cycle continues.

Forward and Backward Traceability

Bidirectional traceability between the risk management file and the design control system is not optional. It is required by ISO 14971:2019 Clause 4.5 and Clause 7.1, ISO 13485:2016 Sections 7.3.3, 7.3.6, 7.3.7, and 7.3.10, and 21 CFR 820.10(c). Assume the frame of reference is the Hazard Analysis:

• Forward Reference (Risk to Design): each Hazard ID (e.g., HZ0001) in the risk analysis references the Design Input ID(s) implementing its risk control. The risk analysis includes a column for Design Input Reference.
• Backward Reference (Design to Risk): each Design Input originating from a risk control references back to the Hazard ID. The Design Input and Design Output Matrix (Part 5) includes a column for Risk Reference.

Best practice: use a consistent convention. One approach is to reference the Design Inputs in the RCM Requirements Column(e.g., PR-001) and include the originating Hazard ID in the Design Input and Design Output Matrix as a Risk Analysis Linking Column (e.g., HZ-001 for Hazard Analysis, DF-001 for design FMEA).

The Risk Management File

ISO 14971:2019 Clause 4.5 requires a risk management file. This is not a single document. It is a collection of records that provides traceability through the entire risk management process. At minimum:

• Risk Management Plan: scope, responsibilities, risk acceptability criteria, verification activities, production and post-production information collection
• Risk Analysis: hazard identification, foreseeable sequence of events, hazardous situation identification, risk estimation (severity and probability), and harm
• Risk Evaluation: determination of acceptability against pre-defined criteria
• Risk Control Records: option analysis, requirements (Design Inputs), implementation (Design Outputs), verification (DV&V or Inspection), residual risk evaluation per measure
• Evaluation of Overall Residual Risk: all risk controls in aggregate
• Risk Management Report: the documentation output from the Risk Management Review Meeting

The Risk Management Report is the formal record of a cross-functional Risk Management Review that evaluates the completeness and adequacy of the risk management process before any phase completion ideally, but minimally before Design Transfer (Section 7.3.8). This meeting aligns with the Design Review requirements of ISO 13485:2016 Section 7.3.5.

Best practice: cross-reference the risk management file to the DHF. The Risk Management Report should reference specific Design Input identifiers, Design Output documents, and DV&V protocol and report numbers. A reviewer should be able to trace from any hazard to its risk control, into the design, and through to objective evidence of effectiveness, without switching between disconnected systems.

Risk-Benefit Analysis and Residual Risk

ISO 14971:2019 Clause 7.4 addresses the situation where residual risk remains after all practicable risk control measures have been implemented. When residual risk exceeds acceptability criteria, a risk-benefit analysis is required. If the medical benefit outweighs the residual risk, the risk may be deemed acceptable. This analysis must be documented and justified, not assumed.

Clause 8 requires evaluation of overall residual risk after all individual risk controls are in place. This is distinct from evaluating individual residual risks. The team must consider whether the cumulative effect of all residual risks remains acceptable. This evaluation is documented in the Risk Management Report and typically occurs at or near Design Transfer (Section 7.3.8).

Common Pitfalls

1. Risk Management Treated as a Standalone Activity

Problem: the risk management file is drafted by a single engineer late in development with no linkage to Design Inputs, Outputs, or DV&V. Risk controls are documented in the FMEA but never become Product Requirements.

Solution: initiate risk management at project start per ISO 13485:2016 Section 7.1. Assign risk control measures as Design Inputs with unique identifiers per Section 7.3.3. Verify and validate them through DV&V protocols per Sections 7.3.6 and 7.3.7. Maintain bidirectional traceability between Hazard IDs and Design Input IDs.

2. Incomplete Hazard Identification

Problem: the team identifies only obvious hazards and misses hazards related to foreseeable misuse, use error, manufacturing variability, transport and storage, or end-of-life disposal.

Solution: use structured hazard identification and failure mode techniques: Hazard Analysis (HA) or Failure Mode and Effects Analysis (FMEA). ISO/TR 24971:2020 and IEC 60812:2018 provides guidance. Include cross-functional input: clinical, engineering, manufacturing, quality, and regulatory.

3. Risk Controls Not Verified

Problem: risk control measures are listed in the FMEA but there is no verification that they were implemented and effective. ISO 14971:2019 Clause 7.2 requires verification of implementation for each risk control measure.

Solution: map each risk control to a DV&V protocol or inspection record. Document verification results in the risk management file with cross-references to DV&V reports or LHR inspection records.

4. Confusing Severity with Risk

Problem: teams assign high risk to every hazard with high severity, regardless of probability. Everything becomes "high risk" and risk controls lose prioritization value.

Solution: risk is the combination of severity of harm and probability of occurrence of that harm (ISO 14971:2019 Section 3.18). Estimate each independently. Use the risk acceptability matrix defined in the risk management plan. Severity does not change with risk control; probability does.

5. No Post-Production Feedback Loop

Problem: the risk management file is closed at Design Transfer and never updated. Post-market complaints and adverse events are handled through Corrective and Preventive Action (CAPA) but never fed back into the risk management file.

Solution: ISO 14971:2019 Clause 10 requires production and post-production information collection and review. Establish a documented process to review complaints, field data, and literature against the risk management file and update when new hazards or changed risk estimates are identified. Feed changes back through ISO 13485:2016 Section 7.3.9 (Design Changes).

6. Missing Bidirectional Traceability

Problem: the risk analysis references "design inputs” or “design controls" generically but does not cite specific Design Input IDs. The Design Input list does not reference back to specific Hazard IDs. Auditors cannot trace from hazard to requirement to evidence without manual reconstruction.

Solution: implement forward references (Hazard ID to Design Input ID) in the risk analysis and backward references (Design Input ID to Hazard ID) in the design input documentation. Build it into your templates from day one.

Why It Matters

Clarity. Integrated risk management gives the team a clear, prioritized view of what the device must do to be safe. Risk controls that flow into Design Inputs as requirements create unambiguous design targets with traceable risk justifications.

Alignment. A risk management process linked to design controls, with bidirectional traceability between Hazard IDs and Design Inputs, gets engineering, quality, regulatory, and clinical teams working from the same requirements.

Documentation and Traceability. Auditors and regulatory reviewers expect to trace from hazard to harm to risk control option to Design Input to Design Output to DV&V evidence. A disconnected risk file creates the gaps that trigger 483 observations, non-conformances, and submission deficiencies.

Regulatory Compliance. Under the QMSR, 21 CFR 820.10(c) requires compliance with ISO 13485:2016 Clause 7.3. That standard requires risk management outputs as design inputs (Section 7.3.3), verification (Section 7.3.6), validation (Section 7.3.7), and change control (Section 7.3.9). EU MDR Annex I mandates risk management throughout design and manufacture.

Final Thought

Risk management is essentially part of design control directly through Risk Control Measures. When executed as an integrated system, with risk control measures documented as requirements, implemented as outputs, and verified through testing or a QMS-released inspection, it protects patients and property, reduces development cycle time, and produces a regulatory submission that tells one traceable story from hazard to evidence.

The Risk Management File (RMF) and the Design History File (DHF) should be companion records, cross-referenced at every level from hazard identification through DV&V evidence, with forward and backward references between Risk IDs and Design Inputs. The regulatory reviewer should never have to reconstruct the linkage between a hazard and the design control evidence that addresses it. Make it explicit.

Done poorly, risk management becomes a paper exercise that adds cost, creates audit findings, and provides no actual safety benefit to the patient.

The 5-Part Series

• Part 1: Design Inputs
• Part 2: Design Outputs
• Part 3: Design Verification and Design Validation
• Part 4: Risk Management in Design Control (this article)
• Part 5: Design Input and Design Output Matrix

References

Quality Management System Regulation (QMSR), 21 CFR Part 820, Feb. 2, 2026.

ISO 13485:2016. Medical Devices, Quality Management Systems, Requirements for Regulatory Purposes. ISO, 2016.

ISO 14971:2019. Medical Devices, Application of Risk Management to Medical Devices. ISO, 2019.

ISO/TR 24971:2020. Medical Devices, Guidance on the Application of ISO 14971. ISO, 2020.

Design Control Guidance for Medical Device Manufacturers. FDA, 1997. (Interpretive reference; regulatory citations reference legacy 820.30, now [Reserved].)

Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices. Official Journal of the European Union, 2017.

IEC 62366-1:2015+A1:2020. Medical Devices, Part 1: Application of Usability Engineering to Medical Devices.

IEC 60812:2018. Failure Modes and Effects Analysis (FMEA and FMECA).

IEC 60601-1:2005+A1:2012+A2:2020. Medical Electrical Equipment, General Requirements for Basic Safety and Essential Performance.

FDA Guidance. Factors to Consider Regarding Benefit-Risk in Medical Device Product Availability, Compliance, and Enforcement Decisions. FDA, December 27, 2016.

Questions or feedback: mike@rmforge.io

Try the platform: rmforge.io