Risk management is a core part of developing Software as a Medical Device (SaMD). When software informs a clinical decision, detects a condition, monitors a patient, delivers a digital intervention, or supports treatment, failures can affect patient safety, clinical workflow, regulatory readiness, and market access.
ISO 14971 provides a structured framework for identifying hazards, estimating and evaluating risks, implementing and verifying risk controls, assessing residual risk, and using production and post-production information to keep the risk-management process up to date throughout the device lifecycle.
For SaMD teams, this is not a quality-system exercise to complete at the end of development. It is a practical operating model that should shape intended use, requirements, architecture, cybersecurity, verification and validation, release decisions, and postmarket updates from the start.
Important: This guide provides general educational information, not legal or regulatory advice. Regulatory requirements, market authorization pathways, and appropriate risk controls depend on the device’s intended use, functionality, risk profile, target markets, and applicable laws. The legal manufacturer remains responsible for the product’s risk-management process, quality system, evidence, submission, and postmarket obligations.
What Is ISO 14971 Risk Management?
ISO 14971:2019 is the internationally recognized standard for applying risk management to medical devices. It describes a lifecycle process for identifying hazards associated with a medical device, estimating and evaluating associated risks, controlling those risks, monitoring whether controls remain effective, and reviewing production and post-production information.
The standard applies broadly to medical devices, including Software as a Medical Device (SaMD), software in a medical device, connected devices, in vitro diagnostic devices, and traditional hardware devices. It is not a project management, financial risk, or general enterprise risk standard. Its focus is on risks associated with the safety and performance of the medical device.
For teams placing devices on the EU market, note that the European version of the standard includes Annex Z tables that map its content to the relevant EU regulatory requirements. The technical requirements of the standard itself are not changed by these annexes, but the mapping matters when demonstrating conformity in the EU. Confirm the current harmonization and amendment status for your target market, as this can change.
What Does “Risk” Mean in ISO 14971?
In ISO 14971 terminology, risk is the combination of:
Risk=Probability of occurrence of harm × Severity of that harm
The equation is a useful simplification, but risk management is not just a numerical calculation. Teams must identify reasonably foreseeable sequences of events, determine how a device could contribute to hazardous situations, establish objective risk-acceptability criteria, implement appropriate controls, and evaluate whether the remaining risk is acceptable in the context of the device’s benefits.
Key Terms SaMD Teams Should Distinguish
Term | Practical meaning |
Hazard | A potential source of harm, such as electrical energy, incorrect clinical information, loss of data integrity, or unauthorized access |
Sequence of events | A chain of foreseeable events that can lead from a hazard or device failure to a hazardous situation |
Hazardous situation | A circumstance in which people, property, or the environment are exposed to one or more hazards |
Harm | Physical injury, damage to health, or damage to property or the environment |
Risk analysis | Identifying hazards and estimating risk for hazardous situations |
Risk evaluation | Comparing estimated risk against predefined risk-acceptability criteria |
Risk control | Measures implemented to reduce risk |
Residual risk | Risk remaining after risk controls have been implemented and verified |
Risk-management file | The set of records and references generated through the risk-management process |
Why ISO 14971 Matters for SaMD Development
Risk management is especially important for medical software because it can influence diagnosis, triage, monitoring, treatment, clinical decisions, or patient behavior without any visible hardware failure. A fault can result from software logic, data quality, interfaces, cloud infrastructure, user interaction, cybersecurity events, third-party components, model behavior, or a change introduced after launch.
For example, a cloud-based SaMD platform may analyze patient-recorded ECG data and flag recordings that may require clinician review. A potentially harmful outcome could result from a false-negative output, missing or corrupted data, an unsupported mobile device configuration, a cloud service outage, an unclear user interface, a vulnerability affecting data integrity, or a model update that reduces performance for a relevant patient subgroup.
A risk-management process helps teams translate those concerns into controlled requirements, architecture decisions, verification activities, validation evidence, release criteria, and postmarket monitoring.
SaMD Risk Sources to Consider
A software risk analysis should consider more than code defects. Depending on the device, relevant risk sources may include:
- Incorrect, incomplete, late, duplicated, corrupted, or unavailable input data
- False positives, false negatives, incorrect classifications, inaccurate measurements, or inappropriate recommendations
- Software logic failures, calculation errors, race conditions, and failure to handle exceptions
- Interoperability failures involving EHRs, wearables, imaging systems, APIs, medical devices, or third-party data feeds
- Unsupported operating systems, browsers, mobile devices, device configurations, or network conditions
- Cloud availability, latency, backup, recovery, synchronization, and deployment failures
- User-interface design that leads to misunderstanding, alert fatigue, automation bias, or use outside the intended workflow
- Cybersecurity vulnerabilities that affect confidentiality, integrity, availability, authentication, authorization, or auditability
- Third-party, open-source, and software-of-unknown-provenance components
- Data drift, model drift, bias, or degraded performance in AI/ML-enabled SaMD
- Incomplete labeling, unclear limitations, inadequate training, or inadequate information for safety
ISO 14971 Risk Management Process for SaMD
ISO 14971 risk management is a continuous lifecycle process. The following sequence gives SaMD teams a practical implementation model.
1. Establish Risk-Management Policy and Responsibilities
Senior management should establish the organization’s risk-management policy and define responsibilities, authority, review expectations, and criteria for risk acceptability. The policy should be consistent with the organization’s quality system, product portfolio, clinical context, target markets, and applicable regulatory obligations.
For SaMD, responsibilities usually span product management, clinical expertise, software engineering, quality assurance, regulatory affairs, cybersecurity, usability/human factors, data science (where applicable), and postmarket functions. The legal manufacturer remains accountable for the process, even when external engineering, testing, cloud, or regulatory partners contribute records or expertise.
2. Create a Risk-Management Plan
The risk-management plan explains how the organization will apply risk management to a specific device or device family. It should be established early enough to influence intended use, user needs, design inputs, architecture, evidence planning, and supplier decisions.
A practical risk-management plan for SaMD should define:
- The device description, intended use, intended users, patient population, use environment, and lifecycle scope
- The roles, responsibilities, competence requirements, and approval authorities for risk activities
- The methods for hazard identification, risk estimation, risk evaluation, and risk-control selection
- Objective criteria for risk acceptability, including criteria for individual and overall residual risk
- The interfaces between risk management, software development, cybersecurity, usability engineering, clinical evaluation, and postmarket surveillance
- Required risk-management records and the systems used to control them
- Verification of risk-control implementation and effectiveness
- Review milestones, escalation conditions, and the risk-management report or review process
- Production and postproduction data sources, feedback channels, and triggers for updating the file
3. Establish and Maintain the Risk-Management File
The risk-management file is the organized set of records and references produced during risk management. It does not need to be one static document. In a modern electronic quality system, it may be a controlled index that links risk analyses, requirements, design records, test results, cybersecurity records, clinical evidence, change assessments, complaints, CAPAs, and postmarket information.
For software, the risk-management file should support bidirectional traceability. A reviewer should be able to start with a hazard and identify the associated risk controls, requirements, implementation records, verification evidence, released versions, and postmarket monitoring activities. The same reviewer should also be able to start with a change or failed test and determine which risks and controls are affected.
4. Identify Hazards and Foreseeable Sequences of Events
Hazard identification should be systematic and multidisciplinary. It should consider normal use, reasonably foreseeable misuse, fault conditions, interface failures, cybersecurity events, maintenance, updates, deployment conditions, and production/postproduction information.
For SaMD, do not stop at “the algorithm may be wrong.” Consider how an error could arise and how it could reach a user or patient. A sequence may include poor source data quality, a software defect, a failed data transfer, a misleading user interface, delayed alert delivery, user misunderstanding, a workflow failure, or a failure to act on an output.
Useful risk-analysis methods can include preliminary hazard analysis, fault-tree analysis, failure modes and effects analysis (FMEA), use-related risk analysis, cybersecurity threat modeling, software architecture review, interface hazard analysis, and review of complaints or field data. No single method is automatically sufficient for every device.
5. Estimate Risk
For each hazardous situation, estimate the risk using the criteria and methods defined in the plan. The analysis should consider the severity of potential harm and the probability of its occurrence, including the likelihood that a sequence of events will lead to harm.
The level of certainty available may vary. In early development, teams may use clinical expertise, scientific literature, known failure modes, usability research, analogous products, engineering analysis, and preliminary testing. As evidence develops, risk estimates should be revisited using stronger product-specific information.
6. Evaluate Risk Against Acceptability Criteria
Risk evaluation compares estimated risk with the manufacturer’s predefined risk-acceptability criteria. The criteria should be established before risk evaluation and applied consistently.
A risk that is not acceptable requires risk control. A risk considered acceptable at one stage may need reassessment when intended use changes, a new patient population is added, new postmarket information emerges, a software update is released, or evidence changes the understanding of likelihood or severity.
7. Implement Risk Controls
ISO 14971 uses a hierarchy for selecting risk-control options. Teams should consider:
- Inherent safety by design.
- Protective measures in the device or manufacturing process.
- Safety information, such as warnings, limitations, instructions, training, and labeling.
For SaMD, inherent safety by design may include input-quality checks, safe defaults, software constraints, robust exception handling, required confirmation steps, validated thresholds, fail-safe behavior, access controls, data-integrity protections, architecture that isolates critical functions, and controls that prevent use in unsupported conditions.
Protective measures may include automated checks, alarms, user-interface safeguards, monitoring, redundancy, authentication, audit logs, encryption, backup/recovery processes, and controls for secure deployment.
Safety information can be important, but it should not be the first or only answer when a more effective design or protective control is reasonably available. Warnings alone rarely eliminate a significant software risk.
8. Verify Risk-Control Implementation and Effectiveness
A risk control is not complete because it appears in a risk table. Teams must confirm that it was implemented and that it performs as intended.
For example, if a risk control requires the software to reject ECG recordings below a defined signal-quality threshold, evidence may include a software requirement, an algorithm/design specification, an implementation record, a test protocol, test results covering boundary conditions, regression evidence, and release approval.
Risk controls should be traceable to verification activities and results. Where controls relate to user behavior, clinical workflow, or intended use, appropriate validation or usability evidence may also be necessary.
9. Evaluate Residual Risk and Benefit-Risk Where Needed
Residual risk is the risk remaining after controls have been implemented and verified. Individual residual risks should be evaluated against the criteria established in the risk-management plan.
When residual risk is unacceptable, the manufacturer may need to implement additional controls, reconsider the intended use, modify the design, collect further evidence, or, where appropriate, conduct a benefit-risk analysis. A benefit-risk conclusion should be evidence-based and documented; it should not be used as a shortcut for avoiding feasible risk controls.
10. Review Overall Residual Risk and Issue the Risk-Management Report
Before commercial release or another defined lifecycle milestone, the manufacturer should review whether the overall residual risk is acceptable when considering the device’s intended use, available evidence, implemented controls, and relevant benefits.
The review should confirm that the risk-management plan was followed, risk controls were implemented and verified, residual risks were evaluated, appropriate production and postproduction processes are in place, and unresolved issues are understood and controlled. Document the conclusion in the risk-management report or other controlled review record defined by the quality system.
11. Collect Production and Postproduction Information
Risk management continues after release. Teams should collect and review relevant production and post-production information to identify new hazards, changes in risk estimates, control failures, emerging cybersecurity threats, use-related issues, performance concerns, and opportunities for corrective action.
For SaMD, relevant information can include complaints, support tickets, adverse event reports, software defects, uptime and reliability signals, security vulnerability reports, penetration test findings, application telemetry (where appropriate), real-world performance monitoring, model drift signals, customer feedback, and regulatory or standards updates.
When new information changes the risk picture, the risk-management file, affected requirements, tests, labeling, clinical evidence, and regulatory assessment should be updated through controlled change processes.
Risk Analysis Example: ECG-Triage SaMD
Consider a cloud-based SaMD that analyzes patient-recorded ECG data and flags recordings that may require clinician review. The following is a simplified illustration, not a complete risk analysis or a substitute for product-specific risk-management work.
Element | Illustrative example |
Intended use context | The software analyzes uploaded ECG recordings and provides a prioritized output for clinician review |
Hazard | Incorrect clinical information or failure to identify a clinically important pattern |
Sequence of events | Poor signal quality, mislabeled data, algorithm limitation, unsupported device configuration, data-transfer failure, or software defect causes an abnormal recording not to be flagged |
Hazardous situation | A clinician does not receive or recognize the output that would prompt timely review |
Potential harm | Delayed clinical assessment or treatment, potentially contributing to patient injury depending on the clinical condition |
Design-input examples | The software must apply defined data-quality checks, meet approved performance requirements, identify unsupported configurations, and present limitations clearly |
Potential risk controls | Input-quality validation, performance thresholds, supported-device controls, data-integrity checks, user-interface safeguards, audit logs, alert-delivery monitoring, clear labeling, and clinician workflow training where appropriate |
Verification evidence | Requirements-based testing, boundary-condition testing, interoperability testing, security testing, regression testing, and documented results |
Validation evidence | Usability or simulated-workflow evidence that intended users can interpret and act on the output appropriately |
Postmarket monitoring | Complaints, missed-alert investigations, performance monitoring, configuration trends, vulnerability reports, and change-impact assessments |
The essential principle is traceability. Each risk control should link to a design requirement, a design output, a verification method, a test result, a released version, and a relevant postmarket feedback source.
ISO 14971 for SaMD Cybersecurity Risk Management
Cybersecurity is not separate from medical-device risk management when a security weakness can affect device safety or performance. Unauthorized access, modification of clinical data, denial of service, compromised updates, loss of data integrity, or unavailable functionality can all contribute to hazardous situations.
A SaMD risk-management process should interface with secure-development and cybersecurity activities, including:
- Security requirements and security architecture
- Threat modeling and attack-surface analysis
- Authentication, authorization, least-privilege access, encryption, logging, and auditability
- Third-party, open-source, and software-of-unknown-provenance component inventory
- SBOM practices where appropriate
- Vulnerability assessment, remediation, verification, and communication processes
- Secure build, release, deployment, and rollback controls
- Security monitoring and incident-response procedures
- Change-impact assessments when infrastructure, dependencies, or interfaces change
A vulnerability does not automatically equal patient harm. The risk analysis should show the plausible path from the vulnerability or security event to a hazardous situation and potential harm, then identify appropriate controls and evidence.
AI/ML Risk Management for Medical Software
AI/ML-enabled SaMD introduces additional risk-management considerations because performance can depend on dataset characteristics, ground truth, model design, clinical workflow, intended population, and how users interpret or act on model output.
In addition to standard software risks, consider:
- Dataset provenance, permissions, quality, representativeness, and labeling methods
- Ground-truth definitions and reference standards
- Performance across clinically relevant patient subgroups and use environments
- False-positive, false-negative, calibration, robustness, and uncertainty risks
- Bias, distribution shift, and performance degradation
- Automation bias, user overreliance, and misunderstanding of model limitations
- Data-pipeline failures, preprocessing changes, and interface changes
- Model, data, code, and evaluation-protocol versioning
- Monitoring for model drift, data drift, and real-world performance changes
- Controlled assessment of model updates, including changes covered by any applicable planned-modification approach
A locked model still requires controlled releases and postmarket monitoring. An adaptive model adds complexity because changes to model behavior must be governed, evaluated, documented, and assessed against applicable regulatory expectations.
Linking ISO 14971 to IEC 62304, ISO 13485, and the DHF
ISO 14971 does not operate alone. For SaMD, risk management should be integrated with the software lifecycle, quality management system, usability engineering, cybersecurity, clinical evidence, and design-and-development documentation.
Framework or record | Relationship to ISO 14971 risk management |
ISO 13485 quality management system | Provides the organizational quality-system context for controlled processes, records, responsibilities, suppliers, CAPA, and management review |
IEC 62304 software lifecycle | Helps organize software development, maintenance, configuration management, problem resolution, and risk-informed software activities |
Usability engineering | Helps identify and address use-related hazards, foreseeable misuse, user-interface risks, and validation needs |
Cybersecurity engineering | Identifies and mitigates security threats that can affect device safety, performance, confidentiality, integrity, or availability |
Design History File (DHF) | Organizes or references design-and-development evidence, including risk records, requirements, design outputs, V&V records, releases, and changes |
Traceability matrix | Connects hazards and risk controls to requirements, design outputs, tests, results, defects, changes, and released versions |
A practical evidence chain looks like this:
HazardHazardous situationRisk controlDesign inputSoftware requirementDesign outputVerification evidenceRelease record
This relationship is important because a risk file alone cannot demonstrate that the risk control was implemented, tested, and released. Similarly, a test result alone cannot demonstrate why the test matters unless it connects to a requirement or risk control.
Common ISO 14971 Implementation Mistakes
Starting Risk Management Too Late
If intended use, user needs, architecture, and development decisions are made before risk management begins, teams may need to redesign features, repeat tests, revise claims, or recreate documentation. Begin early and update continuously.
Treating Risk Management as a One-Time Submission Task
Risk management continues through development, release, maintenance, cybersecurity response, and postmarket surveillance. A static risk file quickly becomes unreliable when a software product changes.
Using FMEA as the Entire Risk-Management Process
FMEA can be useful, but it may not identify every hazard, use-related issue, cybersecurity threat, or multi-step failure sequence. Use methods appropriate to the device and supplement them with other analyses when needed.
Confusing Risk Analysis With Risk Evaluation
Risk analysis identifies hazards and estimates risk. Risk evaluation compares that estimate with predefined acceptability criteria. Both steps should be visible in the records.
Relying Only on Warnings or Training
Safety information has a role, but it may be less effective than designing out a risk or adding a protective measure. Evaluate the risk-control hierarchy before relying on labeling or training alone.
Failing to Verify Risk Controls
A risk-control statement is not evidence. Each control should link to implementation records and objective verification results. User-dependent controls may need usability or validation evidence.
Weak Traceability Between Risk, Requirements, and Testing
Risk controls should flow into requirements, design outputs, test cases, results, releases, and changes. Missing links make it difficult to show that a safety concern was addressed in the released product.
Ignoring Cybersecurity, Cloud, and Third-Party Components
Software risk management should include data integrity, availability, interfaces, dependencies, cloud infrastructure, open-source components, cybersecurity vulnerabilities, and secure update processes, where applicable.
Forgetting Postmarket Feedback and Change Control
Complaints, support tickets, defects, performance trends, vulnerability reports, and AI/ML monitoring can reveal new hazards or change risk estimates. Establish clear triggers for risk-file review and controlled updates.
ISO 14971 Risk Management Checklist for SaMD Teams
Use this checklist as a planning and readiness review. The appropriate depth and evidence depend on the specific device, intended use, risk profile, and markets.
# | Checklist item | What supporting evidence typically looks like |
1 | Risk-management policy, roles, and responsibilities documented | Policy document, defined authorities, competence requirements |
2 | Device-specific risk-management plan established early | Approved plan covering scope, methods, criteria, and review milestones |
3 | Intended use, users, patient population, and use environment defined | Intended-use statement consistent with requirements and labeling |
4 | Objective risk-acceptability criteria set before evaluation | Criteria for individual and overall residual risk, defined in the plan or procedure |
5 | Controlled risk-management file or index maintained | File or index with version control and traceable references to records |
6 | Systematic hazard identification performed | Hazard analysis covering normal use, foreseeable misuse, faults, interfaces, and cybersecurity |
7 | Software-specific risk sources considered | Analysis addressing data quality, algorithm behavior, interoperability, cloud, UI, and AI/ML where applicable |
8 | Risk estimation and risk evaluation documented | Severity and probability rationale, compared against acceptability criteria |
9 | Risk controls selected using the ISO 14971 hierarchy | Evidence that inherent safety by design was considered before protective measures and information for safety |
10 | Risk controls implemented in requirements and design outputs | Requirements, architecture, and design records implementing each control |
11 | Risk-control implementation and effectiveness verified | Verification protocols, test results, and validation or usability evidence where relevant |
12 | Traceability maintained from hazard to control to requirement to test to release | Bidirectional traceability across the risk file, requirements, tests, and released versions |
13 | Cybersecurity activities interfaced with risk management | Threat modeling, component inventory, vulnerability handling, and secure-release records |
14 | Residual risk and overall residual risk evaluated | Residual-risk evaluation, benefit-risk rationale where applicable, and the risk-management report |
15 | Postmarket inputs feed back into the risk file | Complaint, defect, vulnerability, and performance-monitoring channels with defined update triggers |
Frequently Asked Questions
What is ISO 14971 risk management?
ISO 14971 risk management is a lifecycle process for identifying medical-device hazards, estimating and evaluating risks, implementing and verifying risk controls, evaluating residual risk, and reviewing production and post-production information. It supports risk management for medical devices, including SaMD.
Is ISO 14971 mandatory for SaMD?
The specific legal status of ISO 14971 depends on the target market, the device, the applicable regulations, and how a manufacturer demonstrates conformity. ISO 14971 is widely recognized and commonly used to support medical device risk management expectations. Manufacturers should determine applicable requirements with qualified regulatory guidance.
What is the difference between risk analysis and risk evaluation in ISO 14971?
Risk analysis identifies hazards, foreseeable sequences of events, hazardous situations, and associated risk estimates. Risk evaluation compares the estimated risk with the manufacturer’s predefined risk-acceptability criteria.
What is a risk-management plan?
A risk-management plan defines how risk management will be performed for a specific device. It typically describes the device scope, responsibilities, methods, acceptability criteria, required records, review milestones, interfaces with development and postmarket processes, and verification of risk controls.
What belongs in a risk-management file?
A risk-management file contains or references the records generated through risk management. These may include the plan, hazard analyses, risk estimates, evaluations, risk controls, verification evidence, residual-risk assessments, review conclusions, postmarket information, and links to affected requirements, tests, changes, and releases.
Is FMEA enough for ISO 14971?
FMEA can be a useful risk-analysis method, but it is not sufficient on its own. The appropriate methods depend on the device and should address hazards, use-related risks, software and interface failures, cybersecurity threats, postmarket information, and, where applicable, foreseeable sequences of events.
What is residual risk in ISO 14971?
Residual risk is the risk that remains after risk-control measures have been implemented and verified. Manufacturers should evaluate individual residual risks and the overall residual risk against established criteria and the device’s benefits.
How does ISO 14971 apply to AI/ML medical software?
AI/ML-enabled SaMD requires standard risk-management activities, along with attention to data quality, representativeness, bias, subgroup performance, model performance, human interaction, drift, model updates, versioning, and postmarket monitoring.
How do ISO 14971 and IEC 62304 work together?
ISO 14971 provides the risk-management framework. IEC 62304 organizes medical-device software lifecycle activities. Together, they help teams translate risk controls into software requirements, design, verification, configuration management, maintenance, and evidence for problem resolution.
When should a SaMD risk-management file be updated?
Update it when new information could affect risk, including changes to intended use, requirements, architecture, algorithms, data sources, interfaces, cybersecurity posture, cloud infrastructure, components, labeling, clinical evidence, complaints, vulnerabilities, performance trends, or released software versions.
Who is responsible for overall residual-risk acceptability?
The legal manufacturer is responsible for the product’s risk management process and overall residual risk decision-making within its quality system. Cross-functional experts and external partners may contribute evidence and analysis, but responsibility should be defined and retained by the manufacturer.
How Sequenex Supports Risk-Informed SaMD Development
Risk management is strongest when it is integrated into engineering rather than reconstructed during submission preparation. Requirements, architecture, risk controls, test evidence, cybersecurity documentation, traceability, release records, and change assessments should be created as the product is built.
Sequenex supports medical device software teams with risk-informed SaMD engineering, including system and software requirements, architecture, connected-device and cloud integrations, traceability, verification and validation support, cybersecurity engineering, and controlled technical documentation.
For teams that need to strengthen their documentation and traceability, Sequenex can help structure engineering deliverables, including risk artifacts, V&V records, cybersecurity evidence, and traceability matrices, to integrate with the manufacturer’s quality system and Design History File (DHF). The legal manufacturer remains responsible for regulatory strategy, product evidence, submissions, and postmarket obligations.
Explore Sequenex’s SaMD development services to learn how regulated engineering practices can support your product roadmap, risk-management process, and submission readiness.
