IEC 62304 + ISO 14971: A Combined Software Lifecycle Risk Strategy

IEC 62304 (medical device software lifecycle) and ISO 14971 (medical device risk management) are usually run as two separate processes by two separate teams in medical-device companies. The compliance result passes audit. The artefacts they produce overlap by maybe 60%, often disagree on details, and require ongoing reconciliation work that no one budgets for. The teams that integrate the two processes into one operational lifecycle ship faster and with stronger evidence.

This piece is the integration pattern we use with medical-device software teams pursuing FDA, MDR, or IVDR clearance. It is opinionated about which artefacts should converge into single sources of truth and which should remain distinct.

Why the standards are usually separated

The historical separation makes some sense. ISO 14971 is a risk management standard applicable to all medical devices, written for organisations that may have minimal software content. IEC 62304 is a software lifecycle standard applicable specifically to medical software, written by people deeply familiar with software engineering practice. They have different vocabularies, different audit checkpoints, and different roles required to operate them.

In a typical medical-device company, this manifests as:

• A risk management file owned by the regulatory or quality team, updated at major milestones.
• A software development process owned by engineering, with its own documents (SDP, SRS, SDD, test plans, test reports).
• A handoff between the two at design transfer, where engineering produces software hazards that the risk team incorporates into the risk file.

The handoff is where the integration breaks down. Software hazards identified by engineering arrive at the risk team in a different vocabulary, different format, and often missing the harm-mapping that 14971 requires. The risk team rewrites them. The rewrites are no longer traceable to the engineering artefacts they came from. The reconciliation work between the two registers begins.

The integration pattern

A combined IEC 62304 + ISO 14971 lifecycle treats the software hazard analysis (62304 §7) and the risk analysis (14971 §5) as a single activity producing one register, with both standards' required attributes captured in one row.

A typical row in this combined register has:

• Hazard description (14971 vocabulary)
• Sequence of events leading to harm (14971 §5.5)
• Harm and severity (14971 §5.6)
• Probability of occurrence of harm (14971 §5.7)
• Software cause (62304 §7.2): which software item or interaction is the cause
• Software safety classification of the implicated software item (62304 §4.3): A, B, or C
• Risk control measure (14971 §6 and 62304 §7.4)
• Residual risk and acceptability decision (14971 §7)
• Verification evidence (test case ID, requirement ID, design element ID)

The standards do not require this exact structure, but they require all of these attributes. Maintaining them as one register rather than as cross-referenced separate registers is what saves the reconciliation work.

The software safety classification merits specific attention. IEC 62304 classifies each software item as A (no possible injury or damage to health), B (non-serious injury possible), or C (death or serious injury possible). The classification drives the rigor of the lifecycle activities required for that item: more documentation, more verification, more change control for higher classes. The classification depends on the hazards the item participates in producing, which is exactly what the 14971 analysis identifies. Doing the classifications separately produces inconsistency; doing them together produces traceable evidence.

What this changes in the lifecycle

Three lifecycle activities change shape under the integrated pattern:

Software requirements analysis (62304 §5.2). Requirements must trace to risk control measures from the integrated register. A requirement of the form "the system shall display a warning if heart rate exceeds X" must trace to the hazard, the harm, the severity, and the rationale for choosing this control. Requirements that do not trace to the register either need a non-safety justification or do not belong.

Software architectural design (62304 §5.3). The architecture must reflect the safety classifications. Items classified as C cannot be casually replaced by class A items at the boundary; segregation of items by classification (62304 §5.3.5) is a structural property the architecture must support. The risk register's classifications drive architecture decisions, not just documentation.

Verification and validation activities. Test cases trace to requirements, requirements trace to risk controls, risk controls trace to hazards. The verification evidence is the proof that the controls are working, which is what 14971 §6 requires and what 62304 §5.7 requires through different language. One test produces evidence for both standards.

This traceability is not novel; both standards expect it. The integration is in producing it through one process rather than reconciling it after the fact.

What stays separate

The integration is not total. A few elements stay properly separate.

The risk management plan (14971 §4.4) and the software development plan (62304 §5.1.1). These are governing documents at different scopes; they should not be merged. The risk management plan covers the entire device; the SDP covers the software development activities. They cross-reference each other but remain distinct.

The post-market surveillance plan and the software maintenance plan. Post-market activities for the device as a whole include clinical surveillance, complaint handling, and broader market signals. Software maintenance includes change requests, defect handling, and version-control activities. They share inputs but operate at different cadences.

The risk-benefit analysis. This is a 14971 activity at the device level that integrates considerations beyond software. It receives input from the software risk register but produces a higher-level conclusion that does not flow back into engineering artefacts.

The discipline is in keeping the integration where it pays (hazard analysis, traceability, classification) and the separation where it would distort either standard's intended use (governance plans, post-market activities, risk-benefit).

Where AI complicates the picture

For SaMD with AI components, the integrated lifecycle picks up the AI-specific risk dimensions covered in the EU AI Act piece: bias, distribution shift, automation bias, performance degradation. These extend the 14971 hazard categories. The 62304 software safety classification interacts with the AI components specifically — an AI inference component contributing to a class C decision is itself class C, with the corresponding lifecycle rigor.

The integration we describe accommodates these extensions cleanly because the register structure already captures hazard-cause-control-evidence relationships. AI-specific entries fit into existing rows; the 14971 vocabulary expands to include the AI-relevant harm categories.

Where this connects to our practice

Pelican Tech's MedTech practice builds the integrated 62304 + 14971 lifecycle as a delivered programme, with the combined risk register, traceability matrix, and lifecycle artefacts produced through one process. We work with our QMS team when the underlying ISO 13485 quality system needs to align with the integrated lifecycle, and with our regulatory affairs team when the resulting evidence has to be assembled into 510(k) or MDR submissions.

If your team is currently maintaining separate 62304 and 14971 processes and the reconciliation work has become a bottleneck, that is the conversation to have with us before the next major release.