How are IEC 62304 and ISO 14971 related?
IEC 62304 §4.2 · §4.3 · §5.1.1 · §5.2 · §7.1 · ISO 14971:2019
The short answer
ISO 14971 is the risk management standard; IEC 62304 is the software lifecycle standard. They are tightly integrated — IEC 62304 explicitly references ISO 14971 and requires risk management activities at multiple lifecycle stages. Software safety classification (IEC 62304 §4.3) is determined by applying ISO 14971 risk management. The two standards cannot be applied independently for medical device software.
Integration points
| Stage | IEC 62304 activity | ISO 14971 connection |
|---|---|---|
| Safety classification | §4.3 — assign software safety class | Class determined by residual risk severity after ISO 14971 risk controls are applied |
| Development planning | §5.1.1 — SDP includes risk management activities | Risk management plan must be coordinated with software development plan |
| Requirements | §5.2 — software requirements include safety requirements | Risk controls identified in ISO 14971 risk management become software requirements |
| Verification | §5.7 — verify software items and system | Verification tests for risk control requirements close the risk management loop |
| Post-market maintenance | §7.1 — feedback loop for software maintenance | Post-market data (incidents, complaints) must update the ISO 14971 risk management file |
Practical workflow
- Hazard analysis (ISO 14971): Identify hazards and hazardous situations — which of these involve software failure modes?
- Risk estimation and evaluation (ISO 14971): Assess severity and probability; determine which risks require risk controls
- Define risk controls (ISO 14971): Some controls will be implemented in software (safe state detection, alarms, dose limits); these become software requirements
- Software requirements (IEC 62304 §5.2): Risk controls implemented in software become explicit SRS requirements with references to the risk management file
- Trace requirements through IEC 62304 lifecycle: Risk control requirements traced from SRS through architecture, units, and verification tests
- Verification closes the risk management loop (ISO 14971 §10.4): Test evidence that the risk control was implemented and works is the closing evidence for the risk management file
- Post-market feedback (IEC 62304 §7.1 + ISO 14971 §10): Post-market data feeds back into risk management, which may trigger software changes
IEC 62304 sections that explicitly reference ISO 14971
- §4.2: Risk management activities must be coordinated with software lifecycle activities throughout the product lifecycle
- §4.3: Software safety classification must be based on the possible effects of a software failure on the patient, using ISO 14971 risk management process
- §5.1.1 (e): The Software Development Plan shall include the risk management activities to be performed
- §5.2.2: Software requirements shall include safety requirements derived from risk management
- §7.1: Software maintenance shall include a feedback mechanism for post-market safety information to update the risk management process
Frequently asked questions
Should there be one risk management file for the whole device including software?
Yes. ISO 14971 applies to the whole device system. There should be one integrated risk management file that covers hardware and software risks. Software-specific hazards are part of the same file — not a separate "software risk file." The risk management file must be maintained as a living document throughout the product lifecycle.
Who owns risk management — regulatory affairs or engineering?
Risk management is a cross-functional responsibility. In practice, a regulatory affairs or quality engineer often facilitates the process and maintains the risk management file, but software engineers must contribute to hazard analysis for software failure modes, and clinical/product experts must contribute to severity estimation. Siloed risk management without engineering input is a common audit finding.
How do I trace risk controls to software tests?
Each risk control implemented in software should have a unique risk control ID in the risk management file. That risk control ID should appear in the SRS requirement derived from it. The traceability matrix should link the SRS requirement to the test case(s) that verify it. This creates a complete audit trail: hazard → risk control → software requirement → verification test.