Software teams building SaMD tend to think of ISO 14971 as the hardware team's problem. Risk management files, FMEA tables, severity scores: 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 has to 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. A Bluetooth timeout that fails silently in a specific environment, affecting a patient who is 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 US and most international markets. It applies to every device, whether hardware, software, or both. FDA's more recent software guidance accepts a declaration of conformance to IEC 62304 as an acceptable way to describe your software lifecycle 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 FDA's 2023 premarket cybersecurity guidance. These do not 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 are not 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 are 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 may never trace back to its source.
Usability failure modes (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 has to account for that. A screen too small to read in bright conditions, a workflow that moves faster than an impaired user can follow: these 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 their software bill of materials, your cybersecurity submission is already in trouble. Cloud service providers fall here too: 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 one 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 has to address both paths, even though they're scored differently: severity and probability on the safety side, CVSS exploitability and impact on the cybersecurity side. The hazard is the same. The routes to it are different, and your documents need to reflect that linkage.
Traceability is the core of ISO 14971 for SaMD
The most important output of software risk management under ISO 14971 is traceability. 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 at the time you make them. Three years later, when 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 reach the same conclusion you did about your product's safety, independently, using only what you've documented.
Risk management runs throughout the software development lifecycle
A common failure pattern for SaMD teams: finishing development, then doing risk management retrospectively. You can recover from that position if the work is done rigorously, but ISO 14971 is intended to run throughout the software development lifecycle, not in a sprint at the end.
For software that updates, this matters more. Each release is a change that could introduce new risks or affect existing controls. Predetermined change control plans (PCCPs) let you define in advance the boundaries of changes that stay within your safety case without requiring a new submission. But PCCPs have to be grounded in your existing risk analysis. You need to know what changes your current safety case covers and which ones breach it.
Post-market vigilance for software includes monitoring complaint data, field reports, and vulnerability disclosures for your components. A known vulnerability in a library you're using is not theoretical risk; it's an open item that needs to be assessed against your risk file and acted on. The same discipline that applies to hardware post-market applies to software, though software moves faster.
What FDA inspectors look for in software risk management
Software risk management comes up in inspections. If you use software in your development environment, in manufacturing, or as your device, expect questions. Inspectors will want to know what software you're using, whether it's being maintained, whether you've identified its vulnerabilities, whether you're patching it, and whether you've applied least-privilege access controls.
Software of unknown provenance, referred to in FDA guidance as SOUP, gets particular attention, though the term gets used loosely. Well-documented open-source software with a clear maintainership structure is not SOUP. Community-built components where you can't identify who's responsible when something breaks are a different matter. The FDA concern is about whether you understand what you're building with and whether you've assessed the risks it introduces.
For AI and machine learning components, FDA expects you to describe what your algorithm is doing. A black box answer is not acceptable. If you've published peer-reviewed work on the algorithm, share it with reviewers. Demonstrate that you understand the model's behavior, its boundaries, and its failure modes in clinical contexts.
Keeping software risk documentation current as your product evolves
Software risk management that holds up over time depends on how your quality system is structured, not just how carefully you did the initial analysis. When the team that made your original architecture decisions turns over, the rationale needs to already be in writing, captured at decision time rather than reconstructed at release time. Software releases require a risk analysis update before shipping. A disclosed vulnerability needs to be assessed and the response tracked in your quality system.
Running compliance separate from development is where SaMD teams feel the cost most clearly. If risk items, design outputs, verification results, and change history live in separate spreadsheets and document repositories, keeping them synchronized as the product evolves is a manual tax on every release cycle. That manual work is time your engineers spend on documentation instead of development, and it's time your QA team spends chasing context instead of doing quality work.
An eQMS built to connect those elements in a single structure, one where traceability is maintained as you build rather than reconstructed after the fact, removes that friction. The traceability that FDA expects to see during a 510(k) review is the same traceability you need to run your own change control process. Ultralight is designed to keep that chain intact across releases, so SaMD teams aren't choosing between moving fast and staying compliant.
For a deeper look at how software risk management connects to the full documentation picture for SaMD teams, the IEC 62304 and the software DHF post covers the design history file structure and traceability in detail. For the cybersecurity side, medical device cybersecurity covers where the two parallel risk processes intersect and what FDA's current expectations look like.
Keep reading
If you are building out your SaMD risk management process, these related guides go deeper on the specific components:
- IEC 62304 and the software DHF: design controls that don't slow engineers down
- Medical device cybersecurity: FDA requirements, threat modeling, and parallel risk processes
- SaMD quality ops: why Jira and GitHub belong inside your QMS
- ISO 14971 medical device risk management: what to know
- Design history file (DHF), device master record (DMR), and device history record (DHR)
- What auditors actually look for in software documentation
BONUS RESOURCE: 3-in-1 SaMD Gap Assessment Tool
