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