Risk management for Software as a Medical Device under MDR follows EN ISO 14971:2019+A11:2021 as the governing process, but the hazards live in places that hardware risk management was never designed to find. Algorithms can be wrong. Training data can drift. State can desynchronise between user, server and persistence layer. Concurrent requests can produce race conditions that bench testing never exercises. Under MDR Annex VIII Rule 11, the software safety classification driven by EN 62304:2006+A1:2015 determines the lifecycle rigour, but the risk process has to identify software-specific hazards first. The integration point is the risk file: EN ISO 14971 supplies the framework and the file itself, EN 62304 supplies the software safety class that drives the process rigour, and the two together satisfy the general safety and performance requirements in MDR Annex I Sections 14 and 17 for software.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • MDR Annex I Section 17.1 requires software devices to be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management, including information security, verification and validation.
  • MDR Annex VIII Rule 11 classifies software intended to provide information used to take decisions for diagnostic or therapeutic purposes based on its potential harm profile, with most non-trivial SaMD landing at Class IIa or above.
  • EN ISO 14971:2019+A11:2021 is the governing risk management process for SaMD. EN 62304:2006+A1:2015 supplies the software safety classification (Class A, B, C) that drives lifecycle rigour.
  • Software hazards include algorithmic failures, training data bias and drift, state desynchronisation, concurrency and race conditions, resource exhaustion, and third-party component vulnerabilities. Hardware-centric hazard lists miss most of these.
  • The software safety class is derived from the possible harm that a software failure could contribute to, assuming external risk controls fail. It is not a free choice.
  • Risk management for SaMD is continuous. Updates, retraining, configuration changes and SOUP library updates all trigger risk file review.
  • MDCG 2019-11 Rev.1 operationalises Rule 11 classification. It does not replace the risk management process.

Why this matters

Felix has watched more than one startup submit a risk file for a software device that reads as if the device were a hardware product with a few software checkboxes added. Electrical hazards. Mechanical hazards. A thin software section at the back with three entries about "wrong output". The notified body review surfaces the gap in minutes, because the software hazards that actually matter live in places the hardware-shaped risk process cannot see.

MDR does not let a SaMD manufacturer hide behind a hardware-flavoured risk file. Annex I Section 17 applies specifically to devices that incorporate electronic programmable systems and to software that is itself a device. It requires the software to be developed and manufactured in accordance with the state of the art taking into account the principles of development lifecycle, risk management, including information security, verification and validation. The three things the sentence names, lifecycle, risk management, and verification and validation, are the ones EN 62304:2006+A1:2015 and EN ISO 14971:2019+A11:2021 together operationalise.

Tibor frames it plainly in audits. Risk management is the framework. EN ISO 14971 runs the process and owns the risk file. EN 62304 sits inside that framework and determines how much lifecycle rigour the software development has to have, based on the software safety classification. The two standards are not alternatives. A SaMD file that cites only one of them is incomplete.

What MDR actually says

Annex I Section 17.1 of Regulation (EU) 2017/745 requires that devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance.

Section 17.2 requires that for devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development lifecycle, risk management, including information security, verification and validation. Section 17.4 adds that manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

Annex VIII Rule 11 classifies software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes. Under Rule 11, such software is classified as Class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person's state of health, in which case it is in Class III, or a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as Class IIb. Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb. All other software is classified as Class I.

Rule 11 classification is not the same thing as software safety classification under EN 62304:2006+A1:2015. The standard classifies software components as Class A, B, or C based on the possible effects to the patient, operator, or other people resulting from a hazard to which the software system can contribute. Class A is where no injury or damage to health is possible. Class B is where non-serious injury is possible. Class C is where death or serious injury is possible. The software safety class is derived by assuming that external risk control measures outside the software system fail. It drives the lifecycle activities and documentation required by EN 62304.

MDCG 2019-11 Rev.1, originally issued in October 2019 and updated in June 2025, provides the authoritative interpretation of Rule 11 and the relationship between software qualification, classification, and the development lifecycle. It sits alongside the standards, not in place of them.

EN ISO 14971:2019+A11:2021 supplies the overarching risk management process that captures software hazards and feeds them into the risk file. EN 62304:2006+A1:2015 defines the lifecycle activities including software requirements, architecture, unit implementation, integration and system testing, release, and post-release problem resolution. The amendment A1:2015 added explicit requirements for SOUP (software of unknown provenance) identification, evaluation, and monitoring, which is a direct risk management concern.

A worked example

Consider a Class IIa SaMD that processes ECG waveforms and flags arrhythmias for clinician review. Under Rule 11, it is software providing information used to take decisions with diagnostic purposes, non-life-threatening arrhythmia workflow, Class IIa. Under EN 62304:2006+A1:2015, the software safety classification is Class B because a missed arrhythmia flag could contribute to non-serious injury, even though external risk controls, including clinician oversight, exist.

A hardware-shaped hazard list might include power loss, display failure, and data transmission failure. A SaMD-aware list adds the hazards that actually drive incidents: algorithmic false negatives on waveform patterns underrepresented in training data, false positives causing alarm fatigue, state desynchronisation where the client shows yesterday's result because a cache never invalidated, race conditions on concurrent uploads, silent request drops under peak load, a SOUP library CVE enabling remote code execution, and model performance drift as population characteristics shift.

Each of those hazards is entered into the risk file under EN ISO 14971:2019+A11:2021 with its hazardous situation, foreseeable sequence of events, potential harm, initial probability, and initial severity. Risk controls are applied. Inherent safety by design ranks first: for the algorithm, this means training on representative data, validating performance against the state of the art, and locking the model version in production. Protective measures follow: alarm fatigue mitigations, rate limits, explicit human confirmation for high-consequence flags. Information for safety is the last resort.

EN 62304:2006+A1:2015 then drives the lifecycle rigour. Because the software is Class B, the standard requires software requirements, software architecture, unit verification, integration testing, and system testing with documented activity. It also requires SOUP identification and evaluation, which maps directly to the SBOM discussion and the library vulnerability hazard in the risk file. Problem resolution and software maintenance are lifecycle activities that also feed the risk file when findings change the risk estimate.

Tibor's repeated audit observation: the gap between a hardware-shaped SaMD risk file and a software-aware one is typically thirty to eighty entries the hardware-shaped process never had a way to find. The benefit-risk determination derived from the thin file is not defensible.

The Subtract to Ship playbook

Felix's playbook for SaMD risk management is to treat it as a software discipline first, with EN ISO 14971:2019+A11:2021 as the file format and EN 62304:2006+A1:2015 as the lifecycle driver, rather than as a regulatory document produced at the end.

Step one is to run hazard identification with the engineers who actually built the software. Risk management sessions that include only regulatory affairs and clinical specialists miss algorithmic, state, and concurrency hazards because nobody in the room has the mental model that reaches them. A credible session has developers, a regulatory lead, a clinical specialist, and a risk engineer in the same room.

Step two is to use a software-specific hazard prompt list covering algorithmic failures (false positive, false negative, bias, drift), data pipeline failures, state failures (cache incoherence, stale data, concurrency conflicts), concurrency failures (race conditions, deadlocks), resource failures, security failures (injection, auth bypass, SOUP CVE), interoperability failures, update failures, and observability failures. A prompt list prevents the most common blind spots.

Step three is to derive the EN 62304 software safety classification honestly. The classification is based on the possible harm that a software failure could contribute to, assuming external risk controls outside the software fail. Choosing a lower class because "the clinician will always catch it" is the most common non-conformity Tibor sees at software audits. The standard does not allow that assumption.

Step four is to map every software-specific hazard to the EN 62304 lifecycle activities that control it. Architectural design addresses state and concurrency hazards by explicit design decisions. Unit and integration testing address algorithmic edge cases. System testing addresses load and resource hazards. SOUP evaluation addresses library vulnerabilities. Post-release problem resolution addresses drift and CVEs that emerge after release. Each risk control in the file has a lifecycle activity it corresponds to, and each lifecycle activity has the risks it verifies.

Step five is to tie the SaMD risk file to the PMS plan with the same integration approach described for any MDR risk file. Software signals, including usage telemetry, error logs, model performance metrics, SOUP CVE monitoring, and user feedback, feed the PMS plan, which feeds the risk file, which drives the benefit-risk determination. The loop runs continuously because software changes continuously.

Step six is to plan for change control. Every SaMD release is a potential change to the risk profile. A lightweight risk file review as part of the release process catches new hazards at the moment they are introduced, not months later during the annual review.

Reality Check

  • Does the SaMD hazard list include algorithmic, data, state, concurrency, resource, security, and drift hazards, or does it read like a hardware list with software labels?
  • Was the EN 62304:2006+A1:2015 software safety classification derived without assuming that external risk controls work, as the standard requires?
  • Are the engineers who built the software present in hazard identification sessions, or is risk management an outside function writing about code it has not read?
  • Is SOUP identification and monitoring linked to specific risk file entries, or is the SBOM a standalone document?
  • Does every software release trigger a risk file review, or is the file reviewed only annually?
  • Can the PMS plan detect drift in model performance, state inconsistency, or silent degradation, or does it only detect user complaints?
  • Does the benefit-risk determination reference the SaMD-specific risk profile, or does it read as if the device were passive hardware?

Frequently Asked Questions

Does EN 62304:2006+A1:2015 replace EN ISO 14971:2019+A11:2021 for software devices? No. The two standards operate at different levels. EN ISO 14971:2019+A11:2021 is the risk management process and owns the risk file. EN 62304:2006+A1:2015 is the software development lifecycle standard and determines the rigour of lifecycle activities based on the software safety classification. A compliant SaMD file uses both, with clear cross-references.

Is the Rule 11 classification the same as the EN 62304 software safety class? No. Rule 11 under MDR Annex VIII gives the device class (I, IIa, IIb, III) based on the potential harm of software-driven decisions or monitoring. EN 62304:2006+A1:2015 software safety class (A, B, C) is derived from the harm a software failure could contribute to assuming external controls fail. A Class IIa SaMD can contain Class B or Class C software components under EN 62304.

Can training data hazards be excluded from the risk file if the model is locked? No. A locked model can still have training data bias that manifests differently in the deployed population. EN ISO 14971:2019+A11:2021 expects these hazards to be identified, evaluated, and controlled, and the state of the art in AI-enabled SaMD increasingly expects explicit documentation of data representativeness and performance by subgroup.

What about SOUP and open-source libraries? EN 62304:2006+A1:2015 amendment A1:2015 explicitly added SOUP requirements. Each SOUP item is identified, evaluated, and monitored for safety-relevant information. A SOUP vulnerability published after release is a risk management input, not a separate cybersecurity problem. The risk file and the SBOM should reference each other.

How does continuous deployment fit with EN ISO 14971 and EN 62304? It fits if change control, risk file review, verification, and validation run on the release cadence the team actually uses. The standards do not require a specific release frequency. They require documented lifecycle activities. A continuous deployment pipeline that automates those activities is compliant. A pipeline that skips them is not.

Does MDCG 2019-11 Rev.1 change how the risk file is written? MDCG 2019-11 Rev.1 is the authoritative interpretation of software qualification and Rule 11 classification. It informs the classification decision and the scope of the regulated software, which in turn determines what the risk file has to cover. It does not replace EN ISO 14971:2019+A11:2021 or EN 62304:2006+A1:2015.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Section 17, Annex VIII Rule 11.
  2. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices.
  3. EN 62304:2006+A1:2015, Medical device software – Software life cycle processes.
  4. MDCG 2019-11 Rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR. October 2019, Rev.1 June 2025.