Risk Management
Risk Management Plan
Establish systematic risk management framework defining acceptance criteria responsibilities and lifecycle processes.
Summary
The Risk Management Plan establishes your systematic approach to identifying, analyzing, controlling, and monitoring risks throughout your medical device lifecycle, defining risk acceptance criteria, responsibilities, and processes that ensure compliance with ISO 14971 and regulatory requirements.Why is a Risk Management Plan Important?
A comprehensive Risk Management Plan provides the regulatory framework for systematic risk management throughout your device development and lifecycle. Without a structured plan, risk management becomes reactive and inconsistent, leading to missed hazards, inadequate controls, and regulatory compliance failures that can prevent market approval and compromise patient safety. This plan transforms abstract risk management requirements into concrete processes and criteria that guide your team through critical activities like hazard identification, risk assessment, and control implementation. It establishes clear risk acceptance criteria that enable consistent decision-making about what risks are acceptable and what require additional controls. For medical device development, the plan serves as your risk management roadmap by defining how you’ll systematically address safety throughout the device lifecycle. It demonstrates to regulatory authorities that your organization has established appropriate processes for managing risks and ensures that risk management activities are integrated with design controls and quality management systems.Regulatory Context
Under 21 CFR Part 820.30 (Design Controls), the FDA requires:
- Documented risk management processes as part of design controls
- Risk analysis during design and development activities
- Risk control measures implemented through design requirements
- Risk management file maintained throughout device lifecycle
- Design review of risk management activities and outcomes
- Risk management plan defining scope, responsibilities, and criteria
- Systematic risk analysis and evaluation processes
- Risk control implementation and verification
- Post-market risk monitoring and review
- Benefit-risk analysis for overall residual risk evaluation
Special attention required for:
- Software risk management per IEC 62304 must be integrated with overall device risk management
- Cybersecurity risks require ongoing assessment and control per FDA cybersecurity guidance
- Combination devices need coordinated risk management across hardware and software components
- Post-market surveillance must feed back into risk management file updates
Guide
Your Risk Management Plan must establish a comprehensive framework that defines how your organization will systematically manage risks throughout the medical device lifecycle.Scope and Objectives Definition
Begin by clearly defining the scope of your risk management activities. Identify which device components, software modules, and lifecycle phases are covered by the plan. Document the intended use, user population, and use environment that will influence risk identification and assessment. Establish risk management objectives that align with your organization’s safety goals and regulatory requirements. Define how risk management will integrate with design controls, quality management, and post-market surveillance activities. Ensure objectives address both individual risk acceptability and overall residual risk evaluation.Risk Policy and Acceptance Criteria
Develop your organizational risk policy that establishes the framework for risk acceptability decisions. Define the principles that will guide risk management activities, including commitment to reducing risks as far as possible (AFAP) and prioritizing risk control measures appropriately. Create risk acceptance criteria using a structured risk matrix that combines probability and severity assessments. Define severity categories from negligible to catastrophic based on potential harm to users and patients. Establish probability categories that reflect realistic occurrence rates for your device type and use environment.Risk Assessment Methodology
Define your risk analysis process following ISO 14971 requirements. Establish methods for hazard identification including preliminary hazard analysis, failure mode analysis, and use-related risk analysis. Document how you’ll link hazards to hazardous situations and potential harms. Specify risk evaluation procedures that use your risk acceptance matrix to determine if risks are acceptable, require reduction as far as possible, or are unacceptable. Define how you’ll handle situations where probability cannot be estimated and establish criteria for benefit-risk analysis when residual risks remain unacceptable.Risk Control Strategy
Establish risk control priorities following the ISO 14971 hierarchy: inherent safety by design, protective measures, and information for safety. Define how risk controls will be implemented as design requirements, protective features, or user information and training. Document verification requirements for risk control measures including testing methods, acceptance criteria, and documentation standards. Establish procedures for assessing whether risk controls introduce new risks and how those will be evaluated and controlled.Responsibilities and Authorities
Define team roles and responsibilities for risk management activities. Assign responsibility for risk management plan development, risk assessment conduct, risk control implementation, and risk management file maintenance. Establish review and approval authorities for risk management decisions. Document competency requirements for personnel involved in risk management activities. Define training needs and establish procedures for ensuring team members have appropriate knowledge of risk management principles, device technology, and regulatory requirements.Risk Management File Structure
Establish documentation requirements for your risk management file including required documents, version control procedures, and traceability requirements. Define how risk management records will be organized and maintained throughout the device lifecycle. Specify review and update procedures for risk management documentation including triggers for updates, review frequencies, and approval processes. Establish procedures for incorporating post-market information into risk management file updates.Integration with Development Processes
Define how risk management integrates with design controls including when risk assessments will be conducted, how risk controls become design requirements, and how verification activities will confirm risk control effectiveness. Establish change control procedures that ensure design changes are evaluated for risk impact and that risk management documentation is updated appropriately. Define how risk management will inform design review decisions and release criteria.Post-Market Risk Management
Document post-market surveillance integration including how complaint data, adverse event reports, and clinical feedback will be evaluated for risk management implications. Establish procedures for updating risk assessments based on real-world experience. Define production and post-production information collection and evaluation procedures. Establish criteria for determining when post-market information requires risk management file updates or additional risk control measures.Example
Scenario: You’re developing a wearable stress monitoring device that collects physiological data and provides stress management recommendations. The device includes hardware sensors, firmware, mobile app software, and cloud services. Risk management must address both technical failures and clinical use risks.Risk Management Plan
ID: RMP-StressWear-2024-001 1. Scope and Objectives This Risk Management Plan applies to the StressWear Stress Monitoring System including:- Wearable hardware device with physiological sensors
- Device firmware and embedded software
- Mobile application (iOS/Android)
- Cloud-based data processing and storage services
- User interface and recommendation algorithms
- Systematically identify and control all foreseeable risks throughout device lifecycle
- Ensure compliance with ISO 14971:2019, FDA design controls, and EU MDR requirements
- Integrate risk management with design controls and quality management processes
- Establish clear criteria for risk acceptability and benefit-risk evaluation
- Maintain comprehensive risk management file with appropriate traceability
- Inherent safety by design - Eliminate hazards through design choices
- Protective measures - Implement safeguards in device or processes
- Information for safety - Provide warnings, training, and user guidance
- S1 (Negligible): Inconvenience or temporary discomfort
- S2 (Minor): Temporary injury not requiring medical intervention
- S3 (Serious): Injury requiring medical or surgical intervention
- S4 (Critical): Permanent impairment or irreversible injury
- S5 (Catastrophic): Death
- P1 (Improbable): 1 in 1,000,000 uses
- P2 (Remote): 1 in 100,000 uses
- P3 (Occasional): 1 in 10,000 uses
- P4 (Probable): 1 in 1,000 uses
- P5 (Frequent): 1 in 100 uses
| Probability | S1 | S2 | S3 | S4 | S5 |
|---|---|---|---|---|---|
| P1 | Acceptable | Acceptable | Acceptable | Reduce AFAP | Unacceptable |
| P2 | Acceptable | Acceptable | Reduce AFAP | Reduce AFAP | Unacceptable |
| P3 | Acceptable | Reduce AFAP | Reduce AFAP | Unacceptable | Unacceptable |
| P4 | Reduce AFAP | Reduce AFAP | Unacceptable | Unacceptable | Unacceptable |
| P5 | Reduce AFAP | Unacceptable | Unacceptable | Unacceptable | Unacceptable |
- Preliminary Hazard Analysis (PHA) for system-level hazards
- Failure Mode and Effects Analysis (FMEA) for component failures
- Use-related risk analysis per IEC 62366-1
- Software hazard analysis per IEC 62304
- Cybersecurity risk assessment per FDA guidance
- Identify hazards associated with device components and use
- Link hazards to hazardous situations and potential harms
- Estimate probability of hazardous situation occurrence (P1)
- Estimate probability of harm given hazardous situation (P2)
- Calculate overall probability (P1 × P2) and assign probability category
- Estimate severity of potential harm and assign severity category
- Determine risk acceptability using risk acceptance matrix
- Risk controls implemented as design requirements in Software Requirements List
- Hardware risk controls specified in Hardware Design Requirements
- User interface risk controls addressed in Usability Engineering activities
- Information for safety included in Instructions for Use and user training
- Risk control effectiveness verified through appropriate testing methods
- Verification results documented in verification and validation reports
- New risks from risk controls evaluated and controlled appropriately
| Role | Responsibilities |
|---|---|
| Quality Manager | Risk management plan approval, process oversight, regulatory compliance |
| Product Manager | Risk assessment participation, user needs input, clinical context |
| Software Lead | Software risk analysis, IEC 62304 compliance, cybersecurity risks |
| Hardware Lead | Hardware risk analysis, component failure modes, environmental risks |
| Clinical Advisor | Clinical risk evaluation, benefit-risk analysis, use-related risks |
- Risk Management Plan (this document)
- Risk Assessment with risk analysis tables
- Risk Management Report summarizing activities and conclusions
- Risk control verification records
- Post-market risk evaluation records
- Design changes affecting safety
- New hazards identified during development or post-market
- Risk control effectiveness issues
- Regulatory guidance updates
- Annual management review
- Customer complaints and feedback
- Technical support incident reports
- Clinical data from real-world use
- Cybersecurity threat intelligence
- Regulatory adverse event databases
- Monthly review of post-market information for risk implications
- Quarterly risk management file updates as needed
- Annual comprehensive risk management review
- Immediate evaluation for serious safety issues
Q&A
How do I determine appropriate risk acceptance criteria for my device?
How do I determine appropriate risk acceptance criteria for my device?
Risk acceptance criteria should reflect your device’s intended use, user population, and clinical context. Consider the baseline risks your users face from their medical condition and alternative treatments. For monitoring devices, temporary discomfort may be acceptable while serious injury is not. For therapeutic devices, higher risks may be acceptable if benefits are significant. Review similar devices, clinical literature, and regulatory guidance to establish appropriate severity and probability thresholds. When in doubt, choose more conservative criteria that can be refined based on clinical evidence.
What level of detail should I include in risk management responsibilities?
What level of detail should I include in risk management responsibilities?
Define specific roles and decision-making authorities rather than generic responsibilities. Identify who conducts risk assessments, who approves risk acceptance decisions, and who has authority to implement risk controls. Include competency requirements and training needs for each role. For small teams, individuals may have multiple roles, but ensure clear accountability for each risk management activity. Document backup responsibilities and escalation procedures for risk management decisions that exceed normal authority levels.
How do I integrate risk management with agile development processes?
How do I integrate risk management with agile development processes?
Adapt risk management activities to agile sprint cycles while maintaining ISO 14971 compliance. Conduct initial risk assessment during sprint planning and update risks during sprint reviews. Use risk-based criteria for sprint prioritization and feature acceptance. Maintain living risk documentation that evolves with each sprint rather than waiting for formal milestones. Ensure risk controls are implemented as user stories or acceptance criteria. Conduct risk reviews during retrospectives to identify process improvements.
When should I update my risk management plan during development?
When should I update my risk management plan during development?
Update the risk management plan when fundamental assumptions change about your device, users, or regulatory requirements. Common triggers include scope changes, new regulatory guidance, significant design changes, or post-market information that affects risk assessment approaches. Minor updates to risk acceptance criteria or responsibilities may not require full plan revision. Document all changes with rationale and ensure team training on updated procedures. Maintain version control and traceability for all plan changes.
How do I handle risks that cannot be quantified with probability estimates?
How do I handle risks that cannot be quantified with probability estimates?
Use qualitative risk assessment methods when quantitative data is unavailable. Establish qualitative probability categories (very low, low, medium, high, very high) with clear definitions based on available evidence. Consider worst-case scenarios and use expert judgment from clinical advisors. Document assumptions and uncertainty in risk estimates. Plan for additional data collection through clinical evaluation or post-market surveillance to refine risk estimates over time. Focus on implementing robust risk controls regardless of probability uncertainty.
What's the relationship between risk management and clinical evaluation?
What's the relationship between risk management and clinical evaluation?
Risk management informs clinical evaluation by identifying risks that require clinical evidence to demonstrate acceptability. Clinical evaluation provides evidence for benefit-risk analysis when residual risks remain unacceptable after control measures. Clinical data can refine risk probability estimates and validate risk control effectiveness. Post-market clinical follow-up should monitor risks identified in risk management. Ensure coordination between risk management and clinical evaluation teams to maintain consistency in risk-benefit conclusions.