← All articles

Nick ·

SaMD Risk Management: Where Software Teams Go Wrong

SaMD risk management explained: how software changes ISO 14971, what a notified body finds missing, and what good looks like in practice.

Reviewed by Nick Radoux. Sources checked 1 October 2026.

SaMD risk management is the work of finding how software could contribute to patient harm, controlling those risks and keeping the evidence current for as long as the product is in use. The standard method is ISO 14971, but software makes it harder: failures are systematic rather than random, a security flaw can become a safety hazard, and a release, a dependency update or a retrained model can change the risk picture.

Key takeaways

  • Software risk management applies ISO 14971 to software. IEC 62304 expects a risk management process that complies with it.
  • Define harms clinically, not as software faults. A wrong output often leads to a wrong clinical decision.
  • Security and safety risk assessments must inform each other.
  • AI/ML models and third-party components need change control and monitoring in the risk file.
  • Trace every risk control to a requirement and a verification result, and feed post-market data back into the file.

Quotations come from FutureReady MedTech webinar recordings hosted by Nick Radoux of Codon Partners with IndieMedTech, edited only to remove filler words and transcription errors. Speakers' views are their own.

Contents

What is SaMD risk management?

It is the application of a risk management process to software that is a medical device in its own right, and to the software inside other devices.

Software as a medical device (SaMD) is, in the IMDRF definition, software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. Software in a medical device (SiMD) is software that is part of a hardware device, such as firmware or an embedded application.

Risk management , under ISO 14971, is a process to identify the hazards associated with a medical device, estimate and evaluate the risks, control them and monitor whether the controls work. ISO 14971:2019 defines a hazard as a potential source of harm, a hazardous situation as a circumstance in which people, property or the environment are exposed to one or more hazards, and risk as the combination of the probability of occurrence of harm and the severity of that harm.

Kim Trautman, who told the QMSR episode's audience about 24 years at the FDA and writing the quality system regulation there in the late 1990s, put the importance bluntly:

"The foundation of risk management is so underrated. This is where actually so much remediation still needs to happen in the industry with mature big companies just as much."

— Kim Trautman, FutureReady MedTech QMSR episode

Which standards and regulations govern SaMD risk management?

No single document does. Status on 1 October 2026:

This article is educational, not regulatory advice.

How is SaMD risk management different for software?

Why is probability of software failure treated differently?

A bug is not a wear-out event, so failure rates rarely exist. FDA staff said in a CDRH webinar on its software guidance (July 2023) that probability is difficult to assess for software, and that for cybersecurity they focus on exploitability and impact. IEC 62304 asks teams, when deciding the software safety class, to assume a software failure occurs and to look at the severity of the possible harm after risk controls outside the software, as the Johner Institute explains. That is a classification rule, not a prediction that every hazard will occur.

How does security risk feed safety risk?

MDCG 2019-16 says that when a security risk or control measure could affect safety and effectiveness, it should be included in the safety risk assessment, and that safety controls which might affect security should be included in the security risk analysis. Christopher Gates, introduced as founder and CEO of ARS Med Security, made a related point in a FutureReady MedTech Off Air conversation, arguing that a device with low safety risk still needs security:

"Can it be used as a pivot point into the rest of the hospital?"

— Christopher Gates, founder and CEO of ARS Med Security

For cyber devices, the FDA's section 524B requires sponsors to submit a plan to monitor, identify and address postmarket vulnerabilities, to maintain processes that give reasonable assurance of cybersecurity, and to provide a software bill of materials.

What changes after release?

Software keeps changing, and AI models get retrained. Jay Vaishnav, director of regulatory at Canon Medical Informatics, who works on AI-enabled SaMD, described the FDA's response for AI:

"The FDA took a big, big step forward by introducing this thing called the predetermined change control plan, where you could tell FDA, 'I'm going to expand my training data set, and here's how I'm going to validate the device.'"

— Jay Vaishnav, director of regulatory at Canon Medical Informatics

She cautioned that it is limited: not every change is covered. The FDA's final PCCP guidance for AI-enabled device software functions was issued in December 2024; its broader draft guidance on AI-enabled device software lifecycle management was still a draft on the FDA's AI page as of 22 September 2026. ISO 14971 also requires post-production activities, so field data should feed back into the risk file.

What do notified bodies and regulators find wrong?

Sandy Wright, head of devices at Scarlet, a notified body specialising in software and AI medical devices, shared themes from an AI-assisted look at his organisation's assessments. They are informal observations, not published statistics. On risk management he listed:

"Risk management deficiencies. An incorrect definition of harms, poor risk control verification, and, in relation to software and AI, incomplete hazard identification, not really considering those AI and ML specific risks, those cybersecurity related hazards as well."

— Sandy Wright, head of devices at Scarlet

His other themes included a poorly developed argument for the software safety classification and inadequate management of software of unknown provenance (SOUP), including third-party large language models.

Amie Smirthwaite, founder of Salve Medical, a regulatory consultancy, traced many problems to timing. Regulatory thinking, she said, should start at design, because "it shapes all the testing that you do", and it starts with intended purpose:

"What's this thing supposed to do? Who's it supposed to do it for? What are the risks of doing that, etc."

— Amie Smirthwaite, founder of Salve Medical

The failure patterns, then:

  • Harms defined as software faults rather than clinical consequences.
  • Risk controls that are not verified or traced.
  • Hazard lists that stop at the code.
  • A vague intended purpose.
  • A risk file that stops at release.

Kim Trautman described what an integrated risk file looks like, when warning that risk management would shock some pharma-oriented combination-product makers:

"an integrated hazard analysis, design risk assessment, use risk assessment, process risk assessment, all traceable, all being used in pre-market and post-market throughout the organization"

— Kim Trautman, FutureReady MedTech QMSR episode

Does AI break cybersecurity risk management?

One practitioner argues that it does, and the argument is worth understanding, though it is not regulatory fact. Gates said conventional security risk management scores each vulnerability with a rubric such as CVSS and decides what to fix and when, and that this was based largely on how a human being would attack a device. If an AI attacker can try every known weakness, he argued:

"There's no more cybersecurity risk management when suddenly all of them is on the menu."

— Christopher Gates, founder and CEO of ARS Med Security

Gates himself acknowledged that regulatory processes are slow to change. Current guidance still expects the work: MDCG 2019-16 sets out security risk management, and FDA staff said in 2023 that sponsors of cyber devices are expected to do both a cybersecurity risk assessment and a safety risk assessment. Read his view as a prompt to test your assumptions about attacker speed and patch timelines, and not as a reason to skip the process.

What does good look like in practice?

Use this as a discussion framework, not a procedure. In a hypothetical decision-support app, the hazardous situation is a clinician acting on an out-of-date result; the cause a caching defect; the control a freshness check; the verification a test that proves it; the post-market link complaint monitoring.

  1. Start from intended use. Write down who uses the software, for what, and where.
  2. Define harms clinically, then work back to software causes.
  3. Trace each control to a requirement, a verification result and, where relevant, labelling. The FDA says it evaluates traceability partly through the risk assessment in the risk management file, as its webinar explained.
  4. Assess security and safety together.
  5. Treat third-party and AI components as hazard sources, including SOUP, models and their data.
  6. Plan for change. Check risk impact on every release; for ML, read ISO/TS 24971-2 and consider whether a PCCP applies.
  7. Close the loop. Review complaints, vulnerabilities and performance data against the risk file on a defined schedule.

For QMS context, see QMS software or specialist support.

Why do teams bring in specialist help?

Because the gaps above are rarely about missing templates. They are about judgement, capacity and skill. A tool can store the risk file; it cannot tell you whether the file is right.

IMSQ, the Institute of MedTech Software Quality, is a platform for medtech software teams. Teams work with industry experts through usable training, expert support and expert delivery. Its specialist support list includes ISO 14971, IEC 62304, IEC 81001-5-1, requirements and traceability, verification and validation, SOUP qualification, threat modelling and AI/ML change control.

  • A team that needs to learn can use usable training, designed by IMSQ's board of industry experts and tailored to the company.
  • A team stuck on one decision, such as a harm definition, can work through the reasoning with an expert.
  • A team without the time can agree a scope and have an expert complete the work, with an explanation of the decisions behind it. The deliverable stays with your team.
  • A team unsure where to begin can take the free fit check, about two minutes with no login, or the SaMD / SiMD Readiness Diagnostic, which screens for likely readiness gaps. Neither is a regulatory opinion.

Frequently asked questions

Does ISO 14971 apply to software?

Yes. The scope of ISO 14971:2019 includes software as a medical device. IEC 62304 expects a risk management process complying with ISO 14971 for medical device software, and ISO/TR 24971 gives guidance on applying it.

What is the difference between SaMD and SiMD?

SaMD performs a medical purpose without being part of a hardware medical device. SiMD is software that is part of a hardware device. The process is the same, but SiMD can contribute to physical hazards through hardware, while SaMD risk is often informational or indirect.

Is IEC 62304 enough on its own?

No. IEC 62304 covers software life cycle processes and safety classification, and relies on ISO 14971 for risk management. Security activities sit in IEC 81001-5-1, and regulators set their own requirements.

How does cybersecurity fit into risk management?

According to MDCG 2019-16, security risks that could affect safety or effectiveness belong in the safety risk assessment, and safety controls that might affect security belong in the security risk analysis. In the US, section 524B adds requirements for cyber devices.

How should AI and machine learning changes be managed?

Plan the change first. ISO/TS 24971-2:2026 gives guidance for ML-enabled devices, though not for devices using large language models or generative AI. In the US, a predetermined change control plan can pre-agree specific modifications and how they will be validated.

Bring one software risk problem to an IMSQ program review

If your team has a hazard analysis you are unsure about, a risk control you cannot trace, or a change you cannot assess, book a free 30-minute IMSQ program review. No commitment.

Sources checked on 1 October 2026 against FDA, IEC, European Commission and other publishers' material. This article is educational and is not regulatory advice.