Yes, ISO 14971:2019 applies to medical device software and requires a documented risk management system. Software teams must deliver a risk management plan, a risk management file with a device hazard analysis, documented risk controls, and a residual-risk justification. Getting there also means referencing complementary standards and FDA guidances when you prepare premarket documentation, because reviewers expect the two to line up.
TL;DR:
- Software risk management should include a hazard analysis table linking hazards to causes, severity, controls, and verification evidence for clear traceability.
- The risk analysis must focus on detecting foreseeable failure sequences and justify acceptability based on severity, not probability, especially for high-risk devices like infusion pumps.
- Maintaining a living risk management file with continuous post-market data integration is crucial to avoid outdated hazard analyses, especially beyond launch.
- Using linked risk objects and automated reviews improves accuracy, but tools must export traceability in reviewer-expected formats to prevent credibility issues.
- Early clinical input, via fractional Chief Medical Officers, reduces rework by grounding severity assumptions in real clinical context and clarifying acceptability criteria.
Table of Contents
- What ISO 14971 requires for software
- Regulatory expectations and related standards for software
- Risk management lifecycle and required artifacts
- How to estimate and evaluate risk for software
- Modern approaches and tools for software risk management
- Where early-stage teams actually lose time
- Balancing delivery speed with regulatory assurance
- Where fractional clinical leadership fits in
- FAQ
- Sources
What ISO 14971 requires for software
ISO 14971:2019 does not carve out software as a special case. The standard's scope covers "medical devices," and software that meets the medical device definition, including software as a medical device (SaMD), falls squarely inside it. That means a standalone diagnostic algorithm or a clinical decision support tool carries the same risk management obligation as an infusion pump.
The practical challenge is translating the standard's device-centric language into something a software team can act on. A few definitions do most of the work:
- Hazard: a potential source of harm, which in software often traces back to a wrong calculation, a missed alert, or a data integrity failure.
- Hazardous situation: the circumstance where a patient, user, or property is exposed to a hazard, such as a clinician acting on a corrupted result.
- Harm: the physical injury or damage to health that results, or the downstream clinical consequence.
- Cause: for software, this is usually a failure mode such as a logic error, a race condition, an unhandled exception, or a misconfigured interface.
Four clauses matter most for software teams. Risk analysis asks you to identify foreseeable sequences of events, not just obvious bugs. Risk evaluation asks you to judge whether an identified risk is acceptable against criteria you set in advance, not after the fact. Risk control asks you to implement and verify measures that reduce risk, which for software usually means input validation, alarms, access controls, or design simplification rather than hardware guards. Production and post-production monitoring asks you to keep watching after release, which matters enormously for software because a patch or a third-party library update can introduce new hazards that didn't exist at launch.
Regulatory expectations and related standards for software
ISO 14971 rarely stands alone in a submission. IEC 62304, the software life cycle standard, makes a normative reference to ISO 14971, which means a reviewer checking your software development file will expect to see your risk management activities cross-referenced, not duplicated in a separate silo. IEC/TR 80002-1 exists specifically to bridge the gap, offering guidance on applying ISO 14971's general risk process to the specifics of medical device software.
On the FDA side, the guidance for premarket submissions for software contained in medical devices recommends harmonizing your terminology with consensus standards and lists the risk management content reviewers expect to see as part of the submission package. The agency also recommends presenting your device hazard analysis in tabular form, with one line item per identified hazard, rather than as narrative prose.
A few documents come up in nearly every review cycle:
- A risk management plan that states your methods, criteria, and team roles before analysis begins.
- A device hazard analysis table mapping hazards to causes, hazardous situations, severity, and controls.
- A traceability matrix linking software requirements to hazards, to risk controls, to verification evidence.
- A summary of residual risk with your rationale for acceptability.
Traceability is where most submissions lose credibility. If a reviewer can't follow a single hazard from its identification through to a verified control and a documented residual risk decision, the quality system looks disorganized even when the underlying work was sound. Our design controls guidance for SaMD walks through how to keep that chain intact between IEC 62304 activities and your risk management file.
Risk management lifecycle and required artifacts
A compliant risk management file is built from a specific sequence of artifacts, each feeding the next.
- Risk management plan: defines scope, roles, methods, and the acceptability criteria you'll use before any analysis starts, and states how risk activities interface with verification and validation and with design controls.
- Device hazard analysis: a table with one row per hazard, capturing the hazard itself, its cause, the hazardous situation, foreseeable harm, severity, and the control applied. Software-specific hazards commonly include incorrect dosage calculations, failure to display a critical alert, unauthorized access to patient data, and race conditions between concurrent processes; understanding these risks is crucial in how medical device networking works.
- Risk controls and verification: each control gets implemented, then verified with objective evidence, a test result, a code review record, or a formal analysis, that the control actually works as intended.
- Residual risk evaluation: after controls are applied, you document what risk remains and justify why it's acceptable given the clinical context and intended use.
- Risk management report: a summary tying the whole file together, typically produced before release and updated at major milestones.
- Post-production monitoring: complaint data, field reports, and update logs feed back into the risk management file, and a corrective action should trace back to the original hazard analysis row it affects.
Pro Tip: Build your traceability matrix as a living spreadsheet or platform record from day one, not as a retrospective document you assemble before an audit.
The weak link in most startup risk files is step six. Teams build a solid hazard analysis before launch, then let it go stale the moment the product ships. Our post-market surveillance guidance covers how to route field data back into the same risk file so it stays current rather than becoming a one-time exercise.
How to estimate and evaluate risk for software
Traditional risk estimation leans on failure rate data, mean time between failures, component reliability statistics. Software rarely offers any of that in a usable form, because a software defect doesn't degrade gradually the way a mechanical part does. It either triggers or it doesn't, and historical failure rates for a given code path are usually meaningless once the code changes.
The FDA's response is to recommend a severity-first approach: assume the software will fail, then estimate risk based on the severity of harm that failure would cause, rather than trying to assign it a probability. This is a meaningfully different posture from hardware risk analysis, and it changes how you prioritize mitigation.
- Severity-based estimation: assume failure happens, then ask how bad the resulting harm would be, not how often it might occur.
- Objective acceptability criteria: set thresholds in advance, grounded in intended use, clinical context, and comparable marketed devices, since the standard requires criteria but doesn't hand you universal numbers.
- Level of concern matters: a clinical decision support tool that surfaces a recommendation a clinician can override carries a different risk profile than software that directly controls therapy delivery.
A clinical decision support tool flagging an abnormal lab value and a closed-loop insulin dosing algorithm sit at opposite ends of the same framework. Both require a hazard analysis under ISO 14971:2019, but the acceptability bar for the dosing algorithm sits far higher because a software failure there bypasses clinical judgment entirely.
Modern approaches and tools for software risk management
Spreadsheets handle a hazard analysis fine on the day you build it. They fall apart the moment your product enters continuous delivery, because every sprint that touches a risk-controlled feature should trigger a re-check of the linked hazards, and nobody remembers to open the spreadsheet for that.
What works better for active development is treating each hazard as a persistent object rather than a static row. A few capabilities separate a workable platform approach from a documentation liability:
- Linked risk objects: each hazard stays connected to its controls, its verification tests, and the requirements that implement it, so a change to one surfaces everywhere it matters.
- Change-triggered review: a modified requirement or failed test automatically flags the hazards it touches instead of relying on someone to remember the connection.
- Auto-generated documentation: the risk management file and hazard analysis table get produced from the linked data rather than assembled by hand before every audit.
Pro Tip: Before adopting any risk management tool, confirm it can export a traceability matrix in the exact row structure your reviewers expect, hazard, cause, severity, control, verification, not just a generic risk register.
For higher-complexity software, particularly anything approaching autonomous decision-making, a structured safety or assurance case adds a layer the hazard table alone doesn't provide: an explicit argument connecting your evidence to the claim that the device is acceptably safe, which gives reviewers a narrative to follow rather than just a table to parse.
Where early-stage teams actually lose time
The teams that move fastest through review treat risk management as infrastructure, not paperwork. A short list covers the immediate priorities: write the risk management plan before analysis starts, not after; run a structured hazard identification workshop with clinical and engineering voices in the room together; build the traceability matrix early; write the verification plan alongside the controls, not weeks later; and wire post-market feedback into the same file from day one.
The recurring mistake is conflating device risk with process risk. ISO 14971 is about patient safety risk from the device itself, not about whether your software testing process is itself reliable, a distinction that trips up teams who think a solid QMS substitutes for a hazard analysis. The other common gap is acceptability criteria written so loosely they justify almost anything, which collapses the first time a reviewer asks for the rationale. We typically see the fastest return on fractional clinical and regulatory advisory right at that acceptability-criteria stage, where a clinician's read on intended use context prevents months of rework later.
Balancing delivery speed with regulatory assurance
Documentation burden and evidence sufficiency pull against each other, and most early-stage teams resolve that tension by under-investing until a reviewer forces the issue. A better path phases in rigor deliberately: a straightforward hazard table for a low-concern feature, a fuller assurance case once the product touches therapy decisions or scales toward a funding round that invites more scrutiny. Acceptability criteria deserve a named clinical or regulatory sign-off, not a committee vote, because someone has to own the judgment when a reviewer asks why a given residual risk was deemed acceptable.
— Paul Bergeron MD, MBA
Where fractional clinical leadership fits in
We work with healthcare SaaS teams at exactly this stage, where the risk management file needs a clinician's judgment on acceptability criteria and intended use. As a fractional Chief Medical Officer, our role often includes sitting in the hazard analysis workshop itself, grounding severity assumptions in real clinical context rather than a generic risk matrix pulled from another company's template. That's the gap a fractional Chief Medical Officer is built to close for teams that have strong engineering discipline but no clinician in the room when acceptability decisions get made. If your risk management file needs that kind of clinical sign-off before your next submission or funding round, our advisory and fractional CMO services are built for exactly that engagement.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
FAQ
Does ISO 14971 apply to standalone software (SaMD)?
Yes, ISO 14971:2019 explicitly covers medical devices, and software that meets the medical device definition, including standalone SaMD, falls within its scope. The same risk management plan, hazard analysis, and residual risk documentation apply regardless of whether the software runs on dedicated hardware.
What's the difference between ISO 14971 and IEC 62304?
ISO 14971 governs patient safety risk management across the whole device, while IEC 62304 governs the software development life cycle process and makes a normative reference back to ISO 14971. In practice, your software development file and risk management file need to cross-reference each other rather than duplicate content.
How do you estimate risk for software without failure rate data?
The FDA recommends a severity-first approach for software: assume the failure occurs, then estimate risk based on the severity of resulting harm rather than its probability. This avoids relying on failure statistics that software rarely provides in a reliable form.
What format should a device hazard analysis take?
FDA guidance recommends a tabular format with one line item per identified hazard, listing the cause, hazardous situation, severity, and applied control in each row. This structure makes traceability to verification evidence and residual risk decisions far easier for reviewers to follow than narrative prose.
When does a team need a safety or assurance case instead of just a hazard table?
A structured assurance case adds value once software complexity or autonomy increases, particularly for devices approaching therapy control rather than decision support. It organizes evidence into an explicit argument for safety, which helps reviewers evaluate complex systems that a flat hazard table can't fully represent.
Sources
- Accessdata
- ISO 14971:2019 - Medical devices — Application of risk management to medical devices
- Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices - Guidance for Industry and FDA Staff