Teams building software as a medical device (SaMD) tend to think of ISO 14971 as the hardware team’s problem. Risk management files, FMEA tables, severity scores: all quality and regulatory territory, while the engineers close Jira tickets. That split is where things go wrong.

ISO 14971 applies to your entire device. If your device contains software, or is software, risk management must account for what happens when the code behaves unexpectedly, gets misused, loses connectivity, or interacts with components you don’t fully control. A hardware fault that stops a pump is obvious. But a Bluetooth timeout that fails silently in a specific environment, affecting a patient who’s already cognitively impaired? That’s a software risk, and it’s just as real.

The question is how SaMD teams find it, document it, and trace it back to their design before it surfaces in a submission review or an inspection.

How ISO 14971 applies to software-enabled medical devices

ISO 14971 is the recognized method for safety risk management for medical devices in the U.S. and most international markets. It applies to every device, whether hardware, software, or both. The U.S. Food and Drug Administration’s more recent software guidance accepts a declaration of conformance to IEC 62304 as an acceptable way to describe software life cycle processes, which means the two standards overlap in practical application for SaMD teams.

IEC 62304 governs how you build and document software. ISO 14971 governs how you identify and control risks. Both feed into your design history file, and both are evaluated during a premarket submission and during inspections.

If your device is connected or internet-enabled, cybersecurity standards enter the picture, too: AAMI TIR57, AAMI SW96, and the FDA’s 2023 premarket cybersecurity guidance. These don’t replace your ISO 14971 risk management. They run alongside it as a parallel process, governed by different people, scored by different rubrics, producing different documents. Where a cybersecurity threat leads to a patient safety hazard, the two processes link. Any hazardous situation that originates from a cybersecurity vulnerability must appear in your ISO 14971 risk analysis. But the processes aren’t the same, and treating them as one is a common mistake that both FDA and European notified bodies have flagged in recent deficiency letters.

Where software-related risk actually comes from

Hardware risk analysis is relatively intuitive. You can point to a component, model its failure modes, estimate probability. Software failure is harder to scope because a clean “this part broke” event is rarely how software fails.

Several categories of software-related risk deserve explicit treatment in your risk analysis.

Software failure modes and effects (SWFMEA)

SWFMEA covers the foundational failures: logic errors, bugs, timing anomalies, race conditions, and supply chain considerations in your software components. If you’re using open-source libraries or third-party components, you’re responsible for understanding what’s in them. An open-source library that carries unpatched vulnerabilities is a risk you own—one that gets maliciously manipulated is a patient safety risk you might never trace back to its source.

Usability failure modes and effects analysis (UFMEA)

UFMEA covers what happens when real users interact with the software in ways you didn’t anticipate. If your intended users include older patients, or people who may be cognitively impaired at the point of use (a hypoglycemic patient operating an insulin pump, for example), the interface must account for that. A screen too small to read in bright conditions, or a workflow that moves faster than an impaired user can follow, are foreseeable harms that belong in your risk analysis.

Availability and connectivity failures

Availability and connectivity failures matter wherever your device provides continuous therapy or depends on real-time data. A closed-loop insulin pump that loses its continuous glucose monitoring connection needs a defined fallback mode: Alert the user, drop to a basal rate, don’t continue dosing blindly.

What if connectivity fails in an environment with heavy radio frequency interference (a home near a microwave, or a summer camp with 30 teenagers and their Bluetooth devices in a small room)? These scenarios are predictable, and predictable scenarios are risk management problems.

Third-party dependencies

Third-party dependencies introduce a category of risk that’s easy to underestimate. If you’re relying on third-party hardware that generates outputs your software interprets, and that vendor won’t share its software bill of materials, your cybersecurity submission is already in trouble. Cloud service providers fall here, too: The FDA has pursued companies that didn’t adequately describe the risks associated with their cloud environments, including what happens when the provider makes infrastructure changes without your knowledge.

Software risk assessment: Top down and bottom up

Risk assessment for SaMD doesn’t work with a single direction of analysis. A top-down approach starts from intended use and known hazardous situations, then traces down to identify which software conditions could trigger them. A bottom-up approach starts from potential software errors and asks what harm they could lead to at the system level. Running both lets you find the gaps that either direction alone would miss.

The intersection of software risk and cybersecurity risk makes this concrete. A race condition that occurs once in 10,000 executions is a software failure mode. An attacker who can deliberately trigger that race condition turns it into a cybersecurity threat that leads to the same hazardous situation. Your ISO 14971 risk analysis must address both paths, even though they’re scored differently: severity and probability on the safety side; common vulnerability scoring system (CVSS) exploitability and its effect on the cybersecurity side. The hazard is the same. The routes to it are different, and your documents should reflect that link.

Traceability is the core of ISO 14971 for SaMD

The most important output of software risk management under ISO 14971 is traceability. It’s not the table itself, but what the table proves: that you understand your design, identified the risks it creates, implemented controls, and tested that those controls work.

Traceability connects requirements to implementation, risk analysis to verification activities, and architecture decisions to the rationale behind them. That last piece is where many SaMD teams fall short. Choosing Rust over C for memory safety is a risk control decision. Choosing minimum hardware requirements that leave headroom for future changes is a design decision with real risk implications. Write those decisions down. Three years later, when the FDA asks why you made a particular architectural choice, and three key engineers have since left the company, your documentation is the only answer you have.

Architecture decisions belong in your design history file and your software architecture documentation. They don’t need to be elaborate: “We chose X over Y because Y carries these specific disadvantages” is sufficient. The goal is to show a reviewer that you thought it through, and the thinking is captured. That chain of evidence, from hazard identification through control implementation through verification, is what a submission reviewer or inspector follows. They need to independently reach the same conclusion you did about your product’s safety, using only what you’ve documented.

Published June 9, 2026, by Greenlight Guru.