Risk Management Specialist
ISO 14971:2019 risk management implementation throughout the medical device lifecycle.
Table of Contents
Risk Management Planning Workflow
Establish risk management process per ISO 14971.
Workflow: Create Risk Management Plan
- Define scope of risk management activities:
- Medical device identification
- Lifecycle stages covered
- Applicable standards and regulations
- Establish risk acceptability criteria:
- Define probability categories (P1-P5)
- Define severity categories (S1-S5)
- Create risk matrix with acceptance thresholds
- Assign responsibilities:
- Risk management lead
- Subject matter experts
- Approval authorities
- Define verification activities:
- Methods for control verification
- Acceptance criteria
- Plan production and post-production activities:
- Information sources
- Review triggers
- Update procedures
- Obtain plan approval
- Establish risk management file
- Validation: Plan approved; acceptability criteria defined; responsibilities assigned; file established
Risk Management Plan Content
| Section |
Content |
Evidence |
| Scope |
Device and lifecycle coverage |
Scope statement |
| Criteria |
Risk acceptability matrix |
Risk matrix document |
| Responsibilities |
Roles and authorities |
RACI chart |
| Verification |
Methods and acceptance |
Verification plan |
| Production/Post-Production |
Monitoring activities |
Surveillance plan |
Risk Acceptability Matrix (5x5)
| Probability \ Severity |
Negligible |
Minor |
Serious |
Critical |
Catastrophic |
| Frequent (P5) |
Medium |
High |
High |
Unacceptable |
Unacceptable |
| Probable (P4) |
Medium |
Medium |
High |
High |
Unacceptable |
| Occasional (P3) |
Low |
Medium |
Medium |
High |
High |
| Remote (P2) |
Low |
Low |
Medium |
Medium |
High |
| Improbable (P1) |
Low |
Low |
Low |
Medium |
Medium |
Risk Level Actions
| Level |
Acceptable |
Action Required |
| Low |
Yes |
Document and accept |
| Medium |
ALARP |
Reduce if practicable; document rationale |
| High |
ALARP |
Reduction required; demonstrate ALARP |
| Unacceptable |
No |
Design change mandatory |
Risk Analysis Workflow
Identify hazards and estimate risks systematically.
Workflow: Conduct Risk Analysis
- Define intended use and reasonably foreseeable misuse:
- Medical indication
- Patient population
- User population
- Use environment
- Select analysis method(s):
- FMEA for component/function analysis
- FTA for system-level analysis
- HAZOP for process deviations
- Use Error Analysis for user interaction
- Identify hazards by category:
- Energy hazards (electrical, mechanical, thermal)
- Biological hazards (bioburden, biocompatibility)
- Chemical hazards (residues, leachables)
- Operational hazards (software, use errors)
- Determine hazardous situations:
- Sequence of events
- Foreseeable misuse scenarios
- Single fault conditions
- Estimate probability of harm (P1-P5)
- Estimate severity of harm (S1-S5)
- Document in hazard analysis worksheet
- Validation: All hazard categories addressed; all hazards documented; probability and severity assigned
Hazard Categories Checklist
| Category |
Examples |
Analyzed |
| Electrical |
Shock, burns, interference |
☐ |
| Mechanical |
Crushing, cutting, entrapment |
☐ |
| Thermal |
Burns, tissue damage |
☐ |
| Radiation |
Ionizing, non-ionizing |
☐ |
| Biological |
Infection, biocompatibility |
☐ |
| Chemical |
Toxicity, irritation |
☐ |
| Software |
Incorrect output, timing |
☐ |
| Use Error |
Misuse, perception, cognition |
☐ |
| Environment |
EMC, mechanical stress |
☐ |
Analysis Method Selection
| Situation |
Recommended Method |
| Component failures |
FMEA |
| System-level failure |
FTA |
| Process deviations |
HAZOP |
| User interaction |
Use Error Analysis |
| Software behavior |
Software FMEA |
| Early design phase |
PHA |
Probability Criteria
| Level |
Name |
Description |
Frequency |
| P5 |
Frequent |
Expected to occur |
>10⁻³ |
| P4 |
Probable |
Likely to occur |
10⁻³ to 10⁻⁴ |
| P3 |
Occasional |
May occur |
10⁻⁴ to 10⁻⁵ |
| P2 |
Remote |
Unlikely |
10⁻⁵ to 10⁻⁶ |
| P1 |
Improbable |
Very unlikely |
<10⁻⁶ |
Severity Criteria
| Level |
Name |
Description |
Harm |
| S5 |
Catastrophic |
Death |
Death |
| S4 |
Critical |
Permanent impairment |
Irreversible injury |
| S3 |
Serious |
Injury requiring intervention |
Reversible injury |
| S2 |
Minor |
Temporary discomfort |
No treatment needed |
| S1 |
Negligible |
Inconvenience |
No injury |
See: references/risk-analysis-methods.md
Risk Evaluation Workflow
Evaluate risks against acceptability criteria.
Workflow: Evaluate Identified Risks
- Calculate initial risk level from probability × severity
- Compare to risk acceptability criteria
- For each risk, determine:
- Acceptable: Document and accept
- ALARP: Proceed to risk control
- Unacceptable: Mandatory risk control
- Document evaluation rationale
- Identify risks requiring benefit-risk analysis
- Complete benefit-risk analysis if applicable
- Compile risk evaluation summary
- Validation: All risks evaluated; acceptability determined; rationale documented
Risk Evaluation Decision Tree
Risk Estimated
│
▼
Apply Acceptability Criteria
│
├── Low Risk ──────────► Accept and document
│
├── Medium Risk ───────► Consider risk reduction
│ │ Document ALARP if not reduced
│ ▼
│ Practicable to reduce?
│ │
│ Yes──► Implement control
│ No───► Document ALARP rationale
│
├── High Risk ─────────► Risk reduction required
│ │ Must demonstrate ALARP
│ ▼
│ Implement control
│ Verify residual risk
│
└── Unacceptable ──────► Design change mandatory
Cannot proceed without control
ALARP Demonstration Requirements
| Criterion |
Evidence Required |
| Technical feasibility |
Analysis of alternative controls |
| Proportionality |
Cost-benefit of further reduction |
| State of the art |
Comparison to similar devices |
| Stakeholder input |
Clinical/user perspectives |
Benefit-Risk Analysis Triggers
| Situation |
Benefit-Risk Required |
| Residual risk remains high |
Yes |
| No feasible risk reduction |
Yes |
| Novel device |
Yes |
| Unacceptable risk with clinical benefit |
Yes |
| All risks low |
No |
Risk Control Workflow
Implement and verify risk control measures.
Workflow: Implement Risk Controls
- Identify risk control options:
- Inherent safety by design (Priority 1)
- Protective measures in device (Priority 2)
- Information for safety (Priority 3)
- Select optimal control following hierarchy
- Analyze control for new hazards introduced
- Document control in design requirements
- Implement control in design
- Develop verification protocol
- Execute verification and document results
- Evaluate residual risk with control in place
- Validation: Control implemented; verification passed; residual risk acceptable; no unaddressed new hazards
Risk Control Hierarchy
| Priority |
Control Type |
Examples |
Effectiveness |
| 1 |
Inherent Safety |
Eliminate hazard, fail-safe design |
Highest |
| 2 |
Protective Measures |
Guards, alarms, automatic shutdown |
High |
| 3 |
Information |
Warnings, training, IFU |
Lower |
Risk Control Option Analysis Template
RISK CONTROL OPTION ANALYSIS
Hazard ID: H-[XXX]
Hazard: [Description]
Initial Risk: P[X] × S[X] = [Level]
OPTIONS CONSIDERED:
| Option | Control Type | New Hazards | Feasibility | Selected |
|--------|--------------|-------------|-------------|----------|
| 1 | [Type] | [Yes/No] | [H/M/L] | [Yes/No] |
| 2 | [Type] | [Yes/No] | [H/M/L] | [Yes/No] |
SELECTED CONTROL: Option [X]
Rationale: [Justification for selection]
IMPLEMENTATION:
- Requirement: [REQ-XXX]
- Design Document: [Reference]
VERIFICATION:
- Method: [Test/Analysis/Review]
- Protocol: [Reference]
- Acceptance Criteria: [Criteria]
Risk Control Verification Methods
| Method |
When to Use |
Evidence |
| Test |
Quantifiable performance |
Test report |
| Inspection |
Physical presence |
Inspection record |
| Analysis |
Design calculation |
Analysis report |
| Review |
Documentation check |
Review record |
Residual Risk Evaluation
| After Control |
Action |
| Acceptable |
Document, proceed |
| ALARP achieved |
Document rationale, proceed |
| Still unacceptable |
Additional control or design change |
| New hazard introduced |
Analyze and control new hazard |
Post-Production Risk Management
Monitor and update risk management throughout product lifecycle.
Workflow: Post-Production Risk Monitoring
- Identify information sources:
- Customer complaints
- Service reports
- Vigilance/adverse events
- Literature monitoring
- Clinical studies
- Establish collection procedures
- Define review triggers:
- New hazard identified
- Increased frequency of known hazard
- Serious incident
- Regulatory feedback
- Analyze incoming information for risk relevance
- Update risk management file as needed
- Communicate significant findings
- Conduct periodic risk management review
- Validation: Information sources monitored; file current; reviews completed per schedule
Information Sources
| Source |
Information Type |
Review Frequency |
| Complaints |
Use issues, failures |
Continuous |
| Service |
Field failures, repairs |
Monthly |
| Vigilance |
Serious incidents |
Immediate |
| Literature |
Similar device issues |
Quarterly |
| Regulatory |
Authority feedback |
As received |
| Clinical |
PMCF data |
Per plan |
Risk Management File Update Triggers
| Trigger |
Response Time |
Action |
| Serious incident |
Immediate |
Full risk review |
| New hazard identified |
30 days |
Risk analysis update |
| Trend increase |
60 days |
Trend analysis |
| Design change |
Before implementation |
Impact assessment |
| Standards update |
Per transition period |
Gap analysis |
Periodic Review Requirements
| Review Element |
Frequency |
| Risk management file completeness |
Annual |
| Risk control effectiveness |
Annual |
| Post-market information analysis |
Quarterly |
| Risk-benefit conclusions |
Annual or on new data |
Risk Assessment Templates
Hazard Analysis Worksheet
HAZARD ANALYSIS WORKSHEET
Product: [Device Name]
Document: HA-[Product]-[Rev]
Analyst: [Name]
Date: [Date]
| ID | Hazard | Hazardous Situation | Harm | P | S | Initial Risk | Control | Residual P | Residual S | Final Risk |
|----|--------|---------------------|------|---|---|--------------|---------|------------|------------|------------|
| H-001 | [Hazard] | [Situation] | [Harm] | [1-5] | [1-5] | [Level] | [Control ref] | [1-5] | [1-5] | [Level] |
FMEA Worksheet
FMEA WORKSHEET
Product: [Device Name]
Subsystem: [Subsystem]
Analyst: [Name]
Date: [Date]
| ID | Item | Function | Failure Mode | Effect | S | Cause | O | Control | D | RPN | Action |
|----|------|----------|--------------|--------|---|-------|---|---------|---|-----|--------|
| FM-001 | [Item] | [Function] | [Mode] | [Effect] | [1-10] | [Cause] | [1-10] | [Detection] | [1-10] | [S×O×D] | [Action] |
RPN Action Thresholds:
>200: Critical - Immediate action
100-200: High - Action plan required
50-100: Medium - Consider action
<50: Low - Monitor
Risk Management Report Summary
RISK MANAGEMENT REPORT
Product: [Device Name]
Date: [Date]
Revision: [X.X]
SUMMARY:
- Total hazards identified: [N]
- Risk controls implemented: [N]
- Residual risks: [N] Low, [N] Medium, [N] High
- Overall conclusion: [Acceptable / Not Acceptable]
RISK DISTRIBUTION:
| Risk Level | Before Control | After Control |
|------------|----------------|---------------|
| Unacceptable | [N] | 0 |
| High | [N] | [N] |
| Medium | [N] | [N] |
| Low | [N] | [N] |
CONTROLS IMPLEMENTED:
- Inherent safety: [N]
- Protective measures: [N]
- Information for safety: [N]
OVERALL RESIDUAL RISK: [Acceptable / ALARP Demonstrated]
BENEFIT-RISK CONCLUSION: [If applicable]
APPROVAL:
Risk Management Lead: _____________ Date: _______
Quality Assurance: _____________ Date: _______
Decision Frameworks
Risk Control Selection
What is the risk level?
│
├── Unacceptable ──► Can hazard be eliminated?
│ │
│ Yes─┴─No
│ │ │
│ ▼ ▼
│ Eliminate Can protective
│ hazard measure reduce?
│ │
│ Yes─┴─No
│ │ │
│ ▼ ▼
│ Add Add warning
│ protection + training
│
└── High/Medium ──► Apply hierarchy
starting at Level 1
New Hazard Analysis
| Question |
If Yes |
If No |
| Does control introduce new hazard? |
Analyze new hazard |
Proceed |
| Is new risk higher than original? |
Reject control option |
Acceptable trade-off |
| Can new hazard be controlled? |
Add control |
Reject control option |
Risk Acceptability Decision
| Condition |
Decision |
| All risks Low |
Acceptable |
| Medium risks with ALARP |
Acceptable |
| High risks with ALARP documented |
Acceptable if benefits outweigh |
| Any Unacceptable residual |
Not acceptable - redesign |
Tools and References
Scripts
Risk Matrix Calculator Features:
- ISO 14971 5x5 risk matrix calculation
- FMEA RPN (Risk Priority Number) calculation
- Interactive mode for guided assessment
- Display risk criteria definitions
- JSON output for integration
References
Quick Reference: ISO 14971 Process
| Stage |
Key Activities |
Output |
| Planning |
Define scope, criteria, responsibilities |
Risk Management Plan |
| Analysis |
Identify hazards, estimate risk |
Hazard Analysis |
| Evaluation |
Compare to criteria, ALARP assessment |
Risk Evaluation |
| Control |
Implement hierarchy, verify |
Risk Control Records |
| Residual |
Overall assessment, benefit-risk |
Risk Management Report |
| Production |
Monitor, review, update |
Updated RM File |
Related Skills
AI-Specific Risk Management (ISO 14971 + AI Risk Considerations)
AI/ML Medical Device Risk Categories
Traditional ISO 14971 hazard categories must be extended for AI/ML-based devices:
| AI-Specific Hazard |
Description |
Severity Potential |
Detection Difficulty |
| Model bias |
Discriminatory outputs across patient subgroups |
S3-S5 (misdiagnosis) |
High — requires subgroup analysis |
| Data drift |
Input data distribution shifts from training data |
S2-S4 (degraded performance) |
Medium — requires monitoring |
| Concept drift |
Clinical ground truth changes over time |
S3-S5 (outdated predictions) |
High — requires clinical validation |
| Adversarial inputs |
Intentionally crafted inputs to deceive model |
S2-S5 (incorrect output) |
High — requires adversarial testing |
| Hallucination/confabulation |
Plausible but incorrect outputs |
S3-S5 (false diagnosis) |
Medium — requires output validation |
| Training data poisoning |
Corrupted training data leads to systematic errors |
S3-S5 |
Very High — requires data provenance |
| Automation complacency |
Users over-trust AI outputs |
S3-S5 (missed clinical findings) |
Medium — requires human factors study |
AI Risk Analysis Methodology
Step 1: AI System Characterization
→ Define intended use, user population, clinical context
→ Classify: locked algorithm vs. adaptive vs. continuously learning
→ Map to SaMD risk framework (IMDRF)
Step 2: AI-Specific Hazard Identification
→ Apply standard ISO 14971 hazard categories
→ ADD: data quality hazards, algorithmic hazards, integration hazards
→ Consider: training data representativeness, edge cases, failure modes
Step 3: AI Failure Mode Analysis
→ Extend FMEA with AI-specific failure modes:
- False positive/negative beyond acceptable rates
- Performance degradation over time
- Out-of-distribution input handling
- Feature importance shift
→ For each failure mode: determine harm pathway to patient
Step 4: AI-Specific Risk Controls
→ Confidence thresholds (reject uncertain predictions)
→ Human-in-the-loop for high-risk decisions
→ Input validation and out-of-distribution detection
→ Continuous performance monitoring with drift detection
→ Automated model retraining safeguards
→ Fail-safe modes when AI system is unavailable
Step 5: AI Risk Monitoring Plan
→ Define performance metrics and acceptable thresholds
→ Establish monitoring frequency (real-time, daily, weekly)
→ Define retraining triggers and validation requirements
→ Plan for model versioning and rollback procedures
AI Risk Acceptability Considerations
| Risk Factor |
Additional Consideration for AI |
| Probability |
Include statistical confidence intervals for model performance |
| Severity |
Consider both direct harm and harm from delayed correct treatment |
| Detectability |
Factor in opacity of AI decision-making (explainability) |
| Benefit |
Quantify clinical benefit vs. non-AI alternative |
| ALARP |
State-of-the-art includes current AI best practices (GMLP) |
Cybersecurity Risk Integration (IEC 81001-5-1)
Health Software Cybersecurity Risk Management
IEC 81001-5-1:2021 establishes cybersecurity lifecycle requirements for health software. Integrate with ISO 14971:
| ISO 14971 Stage |
IEC 81001-5-1 Integration |
Combined Output |
| Risk Management Plan |
Include cybersecurity scope, threat modeling methodology |
Combined RM + cybersecurity plan |
| Hazard identification |
Add cybersecurity threat identification (STRIDE, attack trees) |
Extended hazard analysis with cyber threats |
| Risk estimation |
Estimate probability based on threat landscape and exploitability |
Risk register with cyber-specific likelihood factors |
| Risk control |
Implement security controls as risk mitigations |
Controls traceable to both safety and security risks |
| Residual risk |
Evaluate residual cybersecurity risk |
Combined residual risk assessment |
| Post-production |
Monitor threat landscape, CVE databases, incident reports |
Integrated PMS + security monitoring |
Cybersecurity Threat Categories for Medical Devices
| Threat Category |
Examples |
ISO 14971 Harm Pathway |
| Unauthorized access |
Credential theft, privilege escalation |
Modification of device settings → patient harm |
| Data breach |
PHI exfiltration, ransomware |
Loss of data availability → delayed treatment |
| Denial of service |
Network flooding, resource exhaustion |
Device unavailable → delayed diagnosis/treatment |
| Malware |
Ransomware, trojans, supply chain compromise |
Device malfunction → incorrect output |
| Data integrity |
Man-in-the-middle, data manipulation |
Corrupted clinical data → incorrect treatment |
| Supply chain |
Compromised dependencies, malicious updates |
Backdoor access → any harm pathway |
Cybersecurity FMEA Extension
Add these columns to standard FMEA for cybersecurity failure modes:
CYBERSECURITY FMEA EXTENSION
| ID | Component | Security Function | Threat | Attack Vector | Exploitability | Impact | S | O | D | RPN | Security Control |
|----|-----------|-------------------|--------|---------------|---------------|--------|---|---|---|-----|-----------------|
| CS-001 | Auth module | User authentication | Credential theft | Phishing | High (8) | Full access | 8 | 6 | 4 | 192 | MFA + session management |
| CS-002 | Data store | Data confidentiality | SQL injection | Network input | Medium (5) | Data breach | 9 | 4 | 3 | 108 | Parameterized queries + WAF |
| CS-003 | Update mechanism | Integrity | Supply chain | Compromised update | Low (3) | Malware install | 10 | 2 | 7 | 140 | Code signing + integrity verification |
Supply Chain Risk Management
Medical Device Supply Chain Risks
| Risk Category |
Description |
Probability |
Impact |
Control Strategy |
| Single-source component |
Critical component from sole supplier |
Medium |
Critical |
Dual-source qualification, safety stock |
| Counterfeit components |
Fraudulent parts entering supply chain |
Low-Medium |
Catastrophic |
Supplier audits, incoming inspection, chain of custody |
| Supplier quality failure |
Supplier QMS breakdown |
Medium |
High |
Supplier qualification, periodic audits, quality agreements |
| Software dependency |
Vulnerable or unsupported open-source library |
High |
Medium-High |
SBOM management, vulnerability scanning, update policy |
| Geopolitical disruption |
Sanctions, trade restrictions, supply interruption |
Low-Medium |
High |
Geographic diversification, buffer inventory |
| Raw material shortage |
Rare earth, specialty materials unavailability |
Low |
High |
Alternative material qualification, forward contracts |
Supply Chain Risk Assessment Workflow
Step 1: Supply Chain Mapping
→ Identify all direct suppliers (Tier 1)
→ Map critical Tier 2 and Tier 3 suppliers
→ Document component criticality (safety-critical, quality-critical, standard)
Step 2: Supplier Risk Scoring
→ Quality risk: past performance, certification status, audit results
→ Financial risk: stability, dependency on your business
→ Geographic risk: natural disaster, political stability
→ Cyber risk: supplier's information security posture
→ Concentration risk: single-source, regional concentration
Step 3: Risk Treatment
→ Critical suppliers: quality agreements, annual audits, dual-sourcing
→ High-risk suppliers: enhanced monitoring, contingency plans
→ Medium-risk suppliers: periodic review, performance metrics
→ Low-risk suppliers: standard purchasing controls
Step 4: Ongoing Monitoring
→ Supplier scorecard tracking (quality, delivery, responsiveness)
→ Annual supplier risk reassessment
→ Trigger-based reassessment (quality event, financial change, M&A)
Post-Market Risk Monitoring Automation
Automated Signal Detection
| Data Source |
Automation Approach |
Alert Threshold |
| Complaint database |
Statistical process control (SPC) charts on complaint rates |
>2 sigma deviation from baseline |
| Adverse event reports |
NLP-based classification + trend analysis |
Any serious event; trend >3x baseline |
| Literature monitoring |
Automated PubMed/regulatory database searches |
New publication on similar device adverse events |
| Field service data |
Automated failure rate tracking |
Failure rate exceeds design MTBF by >20% |
| Social media/forums |
Keyword monitoring for device-related complaints |
Cluster of similar complaints in 30-day window |
| Regulatory databases |
MAUDE, EUDAMED vigilance module, BfArM monitoring |
New recall or safety communication for similar device |
Risk Management File Update Automation
Automated Trigger → Risk Review Decision Tree
New complaint received
→ Classify by hazard category (auto or manual)
→ Check: Known hazard?
YES → Update frequency data → Recalculate risk level
→ Risk level changed? → Flag for risk management review
NO → New hazard identified → Initiate risk analysis
→ Estimate initial risk → Determine controls needed
→ Update risk management file
Trend threshold exceeded
→ Generate trend report with statistical analysis
→ Convene risk management review within 30 days
→ Update risk management file with new probability estimates
→ Evaluate if additional risk controls needed
→ If safety issue: initiate FSCA/field action assessment
Cross-Reference: NIST Cybersecurity Framework Risk Assessment
Map ISO 14971 risk management to NIST CSF 2.0 for comprehensive risk coverage:
| ISO 14971 Process |
NIST CSF 2.0 Function |
Integration Point |
| Hazard identification |
Identify (ID.RA) |
Combine clinical and cyber threat identification |
| Risk estimation |
Identify (ID.RA-03, ID.RA-04) |
Unified likelihood and impact scales |
| Risk evaluation |
Identify (ID.RA-05, ID.RA-06) |
Single risk register with combined acceptance criteria |
| Risk control |
Protect (PR), Detect (DE) |
Security controls as risk mitigations |
| Residual risk evaluation |
Govern (GV.RM) |
Combined residual risk statement |
| Post-production monitoring |
Detect (DE.CM, DE.AE) |
Unified monitoring for safety and security events |
See also: ../information-security-manager-iso27001/SKILL.md for ISO 27001 security controls that serve as risk mitigations.
Cross-Reference: DORA ICT Risk Management
For medical device companies operating as or supplying to financial entities in the EU, the Digital Operational Resilience Act (DORA, Regulation 2022/2554) adds ICT risk requirements:
| DORA Requirement |
ISO 14971 Integration |
Action |
| ICT risk management framework (Art. 6) |
Extend risk management plan to include ICT risks |
Add ICT-specific risk categories to hazard analysis |
| ICT incident management (Art. 17) |
Align with post-production monitoring |
Unified incident classification and response |
| Digital operational resilience testing (Art. 24-27) |
Complement risk control verification |
Include penetration testing in verification activities |
| Third-party ICT risk (Art. 28-30) |
Extend supply chain risk management |
Assess ICT service providers per DORA requirements |
| Information sharing (Art. 45) |
Enhance post-market information sources |
Participate in threat intelligence sharing arrangements |
Enhanced FMEA with Cybersecurity Failure Modes
Combined Safety-Security FMEA Template
COMBINED SAFETY-SECURITY FMEA
Product: [Device Name]
Subsystem: [Subsystem]
Date: [Date]
TRADITIONAL SAFETY FAILURE MODES:
| ID | Item | Function | Failure Mode | Effect | S | Cause | O | Detection | D | RPN | Control |
|----|------|----------|--------------|--------|---|-------|---|-----------|---|-----|---------|
| FM-001 | Sensor | Measure vital sign | Incorrect reading | Wrong diagnosis | 8 | Calibration drift | 4 | Self-test | 3 | 96 | Auto-calibration |
CYBERSECURITY FAILURE MODES:
| ID | Asset | Security Objective | Threat | Attack Vector | Exploitability (O) | Impact (S) | Detection (D) | RPN | Security Control |
|----|-------|-------------------|--------|---------------|-------------------|-----------|---------------|-----|-----------------|
| CS-001 | Sensor data | Integrity | Data manipulation | MITM attack | 3 | 8 | 5 | 120 | TLS + data signing |
| CS-002 | Firmware | Integrity | Malicious update | Supply chain | 2 | 10 | 6 | 120 | Secure boot + code signing |
| CS-003 | User interface | Availability | DoS attack | Network flooding | 5 | 6 | 4 | 120 | Rate limiting + redundancy |
AI/ML FAILURE MODES (if applicable):
| ID | Component | ML Function | Failure Mode | Clinical Effect | S | Cause | O | Detection | D | RPN | ML Control |
|----|-----------|-------------|--------------|----------------|---|-------|---|-----------|---|-----|-----------|
| AI-001 | Classifier | Diagnose condition | False negative | Missed diagnosis | 9 | Distribution shift | 4 | Performance monitoring | 5 | 180 | Drift detection + human review |
| AI-002 | Classifier | Diagnose condition | Biased output | Health disparity | 8 | Unrepresentative training data | 3 | Subgroup analysis | 6 | 144 | Fairness constraints + diverse data |
COMBINED RPN THRESHOLDS:
>200: Critical — Immediate action required (all categories)
100-200: High — Action plan within 30 days
50-100: Medium — Monitor and consider action
<50: Low — Accept and monitor
Cybersecurity-Safety Interaction Analysis
| Safety Control |
Cybersecurity Impact |
Mitigation |
| Alarm system |
Alarm suppression via unauthorized access |
Access control + alarm integrity monitoring |
| Fail-safe mode |
Denial of service forcing perpetual safe mode |
Rate limiting + redundant communication |
| Software update |
Malicious update compromising safety function |
Code signing + dual authorization + rollback capability |
| Data logging |
Log tampering concealing safety events |
Append-only logs + cryptographic integrity |
| User authentication |
Lockout preventing emergency use |
Break-glass procedures + local override |
Enhanced Risk Management — AI, Cybersecurity & Cross-Framework Integration
AI-Specific Risk Management
When managing risk for AI/ML medical devices, extend ISO 14971 with:
- AI Model Risk: Training data bias, model drift, adversarial attacks, explainability gaps
- Performance Degradation: Monitor for distribution shift, concept drift, and data quality issues
- Algorithmic Bias: Demographic parity, equalized odds, calibration across subgroups
- Human-AI Interaction Risks: Over-reliance, automation bias, alert fatigue, trust calibration
- Cross-reference: See
eu-ai-act-specialist for EU AI Act risk classification
Cybersecurity Risk Integration (IEC 81001-5-1)
- Health Software Cybersecurity: IEC 81001-5-1 extends ISO 14971 for cybersecurity
- Threat Modeling: STRIDE methodology applied to medical device architecture
- Cybersecurity FMEA: Failure modes include unauthorized access, data breach, ransomware, supply chain attack
- Vulnerability Management: CVSS scoring integrated with ISO 14971 severity/probability matrix
- Cross-reference: See
infrastructure-compliance-auditor for technical security checks
Supply Chain Risk Management
- Component Risk: Third-party software vulnerabilities (SBOM-based assessment)
- Supplier Risk: Single-source dependencies, geopolitical risks, quality history
- Cloud Risk: Data residency, service availability, vendor lock-in
- Cross-reference: See
nis2-directive-specialist for NIS2 supply chain requirements
Cross-Framework Risk Mapping
| Risk Area |
ISO 14971 |
NIST CSF 2.0 |
DORA |
NIS2 |
| Risk Assessment |
Clause 4 |
ID.RA |
Art. 6 |
Art. 21.1 |
| Risk Treatment |
Clause 7 |
PR (all) |
Art. 9 |
Art. 21.2 |
| Monitoring |
Clause 9 |
DE.CM |
Art. 10 |
Art. 21.2.f |
| Incident Response |
Clause 9 |
RS.MA |
Art. 17 |
Art. 23 |
| Continuous Improvement |
Clause 10 |
ID.IM |
Art. 13 |
Art. 21.2.f |
Troubleshooting
| Problem |
Likely Cause |
Resolution |
| Risk matrix calculator returns "Invalid probability" |
Probability value outside 1-5 range |
Use integers 1-5 for probability (--probability) and 1-5 for severity (--severity). Run --list-criteria to display the full scale definitions. |
| FMEA RPN calculation produces unexpected results |
Severity, occurrence, or detection values outside 1-10 range |
FMEA mode (--fmea) requires --severity, --occurrence, and --detection values each in the 1-10 range. Values outside this range produce unreliable RPNs. |
| Risk level shows "Medium" but stakeholders expect "High" |
Risk acceptability criteria differ from the tool's default 5x5 matrix |
The default matrix follows common ISO 14971 practice. If your organization uses a custom risk matrix, adjust the risk acceptability criteria in your Risk Management Plan and document deviations. |
| Post-production risk data not triggering file updates |
Review triggers not defined or too narrow |
Define explicit triggers: any serious incident (immediate), new hazard identification (30 days), trend increase (60 days), design change (before implementation), and standards update (per transition period). |
| AI-specific hazards not captured in FMEA |
Standard FMEA template lacks AI failure modes |
Extend the FMEA with AI-specific failure modes: model bias, data drift, concept drift, adversarial inputs, automation complacency. Use the AI Risk Analysis Methodology section as a guide. |
| Cybersecurity threats not integrated into risk assessment |
Threat modeling methodology not aligned to ISO 14971 |
Use STRIDE methodology for threat identification, then map each threat to an ISO 14971 harm pathway. Reference IEC 81001-5-1 for health software cybersecurity integration. |
| Benefit-risk analysis requested but no template available |
The tool calculates risk levels but does not generate benefit-risk documents |
The benefit-risk analysis is a narrative document per ISO 14971 Clause 8. Use the risk matrix outputs as quantitative inputs, then document clinical benefits vs. residual risks in the Risk Management Report. |
Success Criteria
- Risk Management Plan approved with defined scope, risk acceptability matrix, RACI chart, and post-production monitoring plan before design input phase
- 100% of ISO 14971 hazard categories analyzed (electrical, mechanical, thermal, radiation, biological, chemical, software, use error, environmental) with documented rationale for each
- All identified risks evaluated against the 5x5 acceptability matrix with no uncontrolled "Unacceptable" residual risks remaining
- Risk controls implemented following the priority hierarchy (inherent safety first, then protective measures, then information for safety) with verification records for every control
- Overall residual risk evaluated as acceptable or ALARP demonstrated, with benefit-risk analysis completed for any residual risks remaining in High territory
- Post-production risk monitoring operational with defined information sources, review triggers, and a documented process for updating the Risk Management File
- For AI/ML devices: AI-specific risk categories (bias, drift, adversarial inputs) assessed per BS/AAMI 34971:2023 or equivalent, with continuous performance monitoring thresholds defined
Scope & Limitations
In Scope:
- ISO 14971:2019 risk management process implementation (planning, analysis, evaluation, control, residual risk, production/post-production)
- 5x5 risk matrix calculation and FMEA RPN scoring
- Hazard analysis methodology guidance (FMEA, FTA, HAZOP, Use Error Analysis, PHA)
- Risk control hierarchy application and verification planning
- Benefit-risk analysis framework
- Post-production risk monitoring and risk file update triggers
- AI/ML-specific risk management extensions (model bias, drift, adversarial inputs)
- Cybersecurity risk integration per IEC 81001-5-1
- Supply chain risk assessment methodology
- Cross-framework risk mapping (ISO 14971, NIST CSF, DORA, NIS2)
Out of Scope:
- Clinical investigation design or execution (risk management informs clinical strategy but does not execute studies)
- Software hazard analysis per IEC 62304 (the skill references software risk but detailed software lifecycle management requires IEC 62304 expertise)
- Biocompatibility testing or ISO 10993 evaluation (the skill identifies biological hazards but does not execute biocompatibility testing)
- Cybersecurity penetration testing or vulnerability scanning (use infrastructure-compliance-auditor for technical security testing)
- CAPA root cause analysis execution (use capa-officer for 5-Why, Fishbone, FTA, FMEA-based root cause investigation)
- Regulatory submission of risk management files (use regulatory-affairs-head for submission strategy and packaging)
Integration Points
| Skill |
Integration |
| quality-manager-qms-iso13485 |
Risk management (Clause 7.1) integrates with QMS product realization planning; risk file is part of the Design History File |
| capa-officer |
Post-market risk signals may trigger CAPA; CAPA root cause analysis methods (FMEA, FTA) overlap with risk analysis techniques |
| regulatory-affairs-head |
Risk management file is required for FDA submissions and EU MDR Technical Documentation; benefit-risk analysis supports clinical evaluation |
| quality-documentation-manager |
Risk management file and records must be controlled per document control procedures (Clause 4.2) |
| fda-consultant-specialist |
FDA cybersecurity guidance (2025 update) requires integration of security risks into ISO 14971 processes for premarket submissions |
| infrastructure-compliance-auditor |
Technical security controls validated by the infrastructure auditor serve as risk mitigations for cybersecurity threats in the risk assessment |
| nist-csf-specialist |
NIST CSF risk assessment (ID.RA) maps to ISO 14971 hazard identification and risk estimation; unified risk register possible |
Tool Reference
risk_matrix_calculator.py
Calculates ISO 14971 risk levels and FMEA Risk Priority Numbers.
| Flag |
Required |
Description |
--probability |
Yes (for ISO 14971 mode) |
Probability level (1-5): 1=Improbable, 2=Remote, 3=Occasional, 4=Probable, 5=Frequent |
--severity |
Yes (for both modes) |
Severity level: 1-5 for ISO 14971 mode, 1-10 for FMEA mode |
--fmea |
No |
Switch to FMEA RPN calculation mode (requires --severity, --occurrence, --detection) |
--occurrence |
Yes (for FMEA mode) |
Occurrence rating (1-10) for FMEA RPN calculation |
--detection |
Yes (for FMEA mode) |
Detection rating (1-10) for FMEA RPN calculation |
--interactive |
No |
Launch interactive mode for guided risk assessment |
--list-criteria |
No |
Display probability, severity, and risk level criteria definitions |