skill_id: REG-ISO14971 version: 1.0.0 last_updated: 2026-01-04 applies_to: [Class A, Class B, Class C] jurisdiction: [FDA, EU MDR, Canada, UK] prerequisites: []

ISO 14971 Risk Management for Software

Purpose

Integrate ISO 14971:2019 risk management into software development: hazard identification, risk evaluation, control implementation in code, verification of effectiveness, and documentation of residual risk.

When to Apply

• Any change affecting hazards, controls, or mitigations.
• New features, interfaces, or protocols.
• Safety classification updates or architecture changes.
• Cybersecurity-relevant changes (maps into threat modeling skill if used).

Requirements (testable)

1. Hazard Identification: Maintain a software hazard list with causes, sequences, and harms per ISO 14971:2019 5–6. Rationale: foundation for controls.
2. Risk Evaluation: Use defined criteria for severity/probability; classify risks and document rationale. Rationale: consistent decisions.
3. Risk Control Implementation: For each unacceptable risk, implement controls in design/code with explicit link to RISK-CTRL-### per 7. Rationale: traceable controls.
4. Verification of Controls: Each control has verification evidence (test, analysis, inspection) showing risk reduction per 8. Rationale: effectiveness.
5. Residual Risk: Record residual risk acceptability and justification; escalate if aggregate risk changes per 8. Rationale: decision visibility.
6. Safe State Definition: Define and implement safe states for hazardous conditions; test transitions. Rationale: bounded failure behavior.
7. Fault Handling: Link fault handlers to hazards/controls and verify logging/annunciation where applicable. Rationale: detect/respond to faults.
8. Documentation: Maintain risk management file artifacts updated with changes (hazards, controls, verification, residuals). Rationale: auditability.
9. Commit Traceability: Commits modifying controls or hazards must include IDs (RISK-###, RISK-CTRL-###, REQ-###). Rationale: change traceability.

Recommended Practices

• Keep a single source of truth: risk-register.yaml with hazards, controls, verification.
• Use templated commit messages: RISK: RISK-12 mitigated via RISK-CTRL-7; TEST-305 added.
• Align safe-state logic with architecture segregation (see safety-classification skill).
• Pair risk controls with monitoring/diagnostics to detect degradation.

Patterns

Risk control with traceability and safe state:

// HZ-07: Over-infusion; RISK-CTRL-19: clamp and alarm within 100 ms
// REQ-221, TEST-410 covers timing
bool enforce_over_infusion_limit(float rate_ml_per_hr) {
    if (rate_ml_per_hr > MAX_RATE_ML_PER_HR) {
        clamp_line();            // physical mitigation
        alarm_over_rate();       // user mitigation
        enter_safe_state();      // safe state: pump stopped, alarm latched
        return false;
    }
    return true;
}

Residual risk documentation (YAML):

hazard: HZ-07
control: RISK-CTRL-19
verification:
  - TEST-410: timing <100 ms pass
  - TEST-411: alarm annunciation pass
residual_risk: acceptable_per_policy_RP-02
justification: Meets severity/probability target after control per table RM-1

Commit message format:

feat: enforce over-infusion limit

RISK: HZ-07 mitigated by RISK-CTRL-19
REQ: REQ-221 updated
TEST: TEST-410 added, TEST-411 updated

Anti-Patterns (risks)

• Generic “improved safety” commits without IDs -> risk: lost traceability.
• Controls implemented without verification -> risk: unproven effectiveness.
• Safe state undefined or unreachable -> risk: uncontrolled hazardous behavior.
• Fault handlers that log only -> risk: no actual mitigation.
• Residual risk not reassessed after change -> risk: aggregate risk drift.

Verification Checklist

• Hazards updated for new/changed functionality; causes and harms documented.
• Risk evaluation uses defined criteria; severity/probability recorded.
• Controls mapped to hazards with IDs (RISK-CTRL-###) and implemented.
• Verification evidence exists and passes for each control.
• Safe states defined, reachable, and tested for hazardous conditions.
• Fault handling paths tied to hazards; logging/annunciation verified.
• Residual risk acceptability documented; escalation performed if needed.
• Commits touching hazards/controls include IDs in message.
• Risk management file artifacts regenerated/baselined after change.

Traceability

• Use stable IDs: hazards (HZ-###), controls (RISK-CTRL-###), requirements (REQ-###), tests (TEST-###).
• Embed IDs in code comments, test names, and commit messages.
• Maintain risk-register.yaml or equivalent; generate hazard->control->verification views.

References

• ISO 14971:2019, clauses 4–10 (risk management process).
• IEC TR 80002-1:2019 (guidance on applying ISO 14971 to software; second edition).
• FDA Guidance: "Content of Premarket Submissions for Device Software Functions" (2023) for submission expectations.
• FDA Guidance: "Cybersecurity in Medical Devices" (2023) for security risk management alignment.
• MDCG 2019-16 (guidance on cybersecurity for medical devices; EU MDR context).

Changelog

• 1.0.1 (2026-01-04): Audit corrections - updated IEC TR 80002-1 to 2019 edition, clarified FDA guidance references.
• 1.0.0 (2026-01-04): Initial skill with hazard/control patterns, safe state guidance, commit traceability, and verification checklist.

Audit History

• 2026-01-04: Regulatory audit performed. Corrections applied:
  • IEC TR 80002-1:2009 updated to 2019 edition (second edition)
  • Generic "FDA premarket software guidance" replaced with specific 2023 guidance titles