← Learning Center

ISO 14971

ISO 14971: The Global Standard for Risk Management in Medical Device Development

ISO 14971 represents the international standard for applying risk management principles throughout the lifecycle of medical devices. For DevSecOps leaders, security directors, and development teams working in regulated industries, understanding ISO 14971 becomes critical when building software-driven medical devices or maintaining secure development pipelines for healthcare technology products. This standard provides a systematic framework for identifying, evaluating, controlling, and monitoring risks associated with medical devices—a discipline that shares remarkable parallels with modern software supply chain security practices and DevSecOps methodologies used across highly regulated environments.

What is ISO 14971? Definition and Core Principles

ISO 14971 is defined as the international standard that outlines requirements for establishing risk management processes for medical devices throughout their entire lifecycle. Originally published in 2000 and subsequently revised, this standard establishes a comprehensive framework that medical device manufacturers must follow to systematically address risks that could affect patients, operators, or other individuals.

The standard applies to all stages of a medical device's existence—from initial conception and design through production, distribution, installation, and eventual decommissioning. For software development teams in the medical device sector, ISO 14971 provides the foundation for integrating security and safety considerations directly into the SDLC (Software Development Lifecycle).

Risk management under ISO 14971 operates on several foundational principles:

  • Continuous process: Risk management isn't a one-time activity but an ongoing process that extends throughout the product lifecycle
  • Systematic approach: The standard requires documented, structured methodologies rather than ad-hoc risk assessment
  • Residual risk evaluation: After implementing risk controls, organizations must evaluate and document remaining risks
  • Risk-benefit analysis: The standard recognizes that some residual risks may be acceptable when weighed against medical benefits
  • Production and post-production monitoring: Risk management extends beyond initial release to include real-world monitoring and feedback

For development teams accustomed to DevSecOps practices, the principles embedded in ISO 14971 mirror concepts like continuous security monitoring, shift-left testing, and vulnerability management throughout the software supply chain. The standard essentially mandates what security-forward organizations already practice: integrating risk assessment into every phase of development rather than treating it as a final checkpoint.

Explanation of ISO 14971 Risk Management Process

The ISO 14971 framework establishes a structured risk management process consisting of several interconnected phases. Understanding these phases helps DevSecOps teams translate regulatory requirements into practical implementation within their development workflows.

Risk Analysis Phase

Risk analysis under ISO 14971 begins with identifying intended use and reasonably foreseeable misuse of the medical device. This phase requires development teams to document the device's characteristics, identify known and foreseeable hazards, and estimate the risks associated with each hazard.

For software-intensive medical devices, this analysis must account for cybersecurity threats, software failures, integration risks with other systems, and human factors that could lead to dangerous situations. The parallels to threat modeling in DevSecOps are striking—both disciplines require teams to systematically identify what could go wrong before it happens.

The risk analysis phase involves:

  • Hazard identification across all device lifecycle stages
  • Estimation of risks for each identified hazardous situation
  • Documentation of intended use, user profiles, and use environments
  • Consideration of both normal and fault conditions
  • Analysis of sequences of events that could result in hazardous situations

Risk Evaluation and Acceptability

After analyzing risks, ISO 14971 requires organizations to evaluate whether identified risks are acceptable according to predefined criteria. This step forces teams to establish clear risk acceptance thresholds before beginning development—a practice that prevents subjective decision-making later in the process.

Risk evaluation criteria typically consider:

  • Severity of potential harm
  • Probability of occurrence
  • Regulatory requirements and industry standards
  • State of the art in risk reduction technology
  • Stakeholder concerns and expectations

Development teams must document these criteria and apply them consistently across all identified risks. For organizations building medical device software, this means establishing clear security baselines and vulnerability severity classifications that align with patient safety considerations.

Risk Control Implementation

When risks exceed acceptable levels, ISO 14971 mandates implementation of risk control measures following a specific hierarchy. This hierarchy prioritizes inherent safety by design, followed by protective measures in the device itself, and finally information for safety such as warnings and training.

The risk control hierarchy directly translates to software development practices:

  • Inherent safety by design: Architectural decisions that eliminate vulnerabilities, secure coding practices, input validation, and secure defaults
  • Protective measures: Authentication systems, encryption, access controls, monitoring systems, and automated security testing
  • Information for safety: User documentation, security advisories, training materials, and incident response procedures

After implementing risk controls, organizations must verify their effectiveness and ensure they don't introduce new risks. This verification process resembles security testing and validation in DevSecOps pipelines, where teams must confirm that security controls work as intended without breaking functionality.

Residual Risk Assessment

ISO 14971 explicitly acknowledges that not all risks can be eliminated. After implementing controls, teams must evaluate residual risks—those that remain even after mitigation efforts. The standard requires documenting these residual risks and determining whether they're acceptable given the medical benefits of the device.

For software development teams, residual risk management means accepting that perfect security doesn't exist. Known vulnerabilities with low exploitability, theoretical attack vectors with negligible real-world risk, or risks mitigated through operational controls all represent residual risks that must be documented and monitored.

Risk Management Review

Before releasing a medical device, ISO 14971 requires a comprehensive review of the entire risk management process. This review ensures that all identified risks have been addressed, risk management activities are complete, and the overall residual risk is acceptable.

This final review gate mirrors the security review checkpoints in mature DevSecOps processes, where security teams assess whether a release meets established security criteria before production deployment.

How to Implement ISO 14971 in Software Development Lifecycles

Translating ISO 14971 requirements into practical software development workflows requires integrating risk management activities throughout the SDLC. For DevSecOps teams, this integration builds upon existing security practices while adding the rigor and documentation that medical device regulations demand.

Establishing the Risk Management Framework

Implementation begins with establishing organizational policies, procedures, and responsibilities for risk management. Development teams need documented processes that define how risk management activities integrate with sprint planning, code reviews, testing cycles, and release processes.

The framework should specify:

  • Risk management roles and responsibilities within development teams
  • Risk acceptability criteria and decision-making authority
  • Tools and methodologies for risk analysis and tracking
  • Integration points between risk management and existing SDLC processes
  • Documentation requirements and templates
  • Review and approval workflows

Integrating Risk Management with Agile Development

Many medical device software teams use agile methodologies, which can seem at odds with ISO 14971's documentation-heavy approach. However, the standard's emphasis on continuous risk management actually aligns well with iterative development when implemented thoughtfully.

Practical integration strategies include:

  • Conducting risk analysis sessions during sprint planning to identify risks associated with new features
  • Including risk assessment in definition of done criteria for user stories
  • Maintaining living risk management documents that evolve with the product
  • Automating risk tracking through integration with project management tools
  • Performing incremental risk reviews at the end of each sprint or release cycle

The key is building risk management into the rhythm of development rather than treating it as a separate compliance activity that happens outside the normal workflow.

Leveraging DevSecOps Tools for ISO 14971 Compliance

Modern DevSecOps tooling provides significant advantages for organizations implementing ISO 14971. Static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), and container security scanning tools automate much of the hazard identification work required by the standard.

Organizations can map security tool outputs directly to ISO 14971 requirements:

  • SAST tools identify coding vulnerabilities that could lead to hazardous situations
  • SCA tools detect supply chain risks from open source dependencies
  • DAST tools validate that implemented security controls function correctly
  • Container scanning identifies risks in deployment environments
  • Penetration testing simulates real-world attack scenarios to validate risk controls

For teams looking to strengthen their software supply chain security while meeting medical device regulatory requirements, platforms like Kusari provide comprehensive visibility into supply chain risks and help automate the evidence collection needed for ISO 14971 documentation.

Documentation and Traceability Requirements

ISO 14971 mandates extensive documentation throughout the risk management process. For development teams, this means establishing traceability between risk management activities and all other development artifacts—requirements, design decisions, code changes, test results, and deployment records.

Effective documentation strategies include:

  • Using requirements management tools that link risks to specific requirements and design elements
  • Maintaining risk traceability matrices that connect hazards to controls and verification activities
  • Leveraging version control commit messages to reference risk control implementations
  • Automating evidence collection from CI/CD pipelines to demonstrate risk control effectiveness
  • Creating dashboards that provide real-time visibility into risk management status

The documentation burden shouldn't slow development to a crawl. Teams that integrate documentation generation into their automated pipelines can meet regulatory requirements without sacrificing development velocity.

ISO 14971 and Software Supply Chain Security

Modern medical devices increasingly rely on complex software supply chains that include open source components, third-party libraries, cloud services, and containerized deployments. ISO 14971's risk management framework extends to these supply chain elements, creating natural alignment with software supply chain security practices.

Supply Chain Risk Identification

Under ISO 14971, medical device manufacturers must identify hazards related to software components from external sources. This includes risks from vulnerabilities in open source dependencies, compromised development tools, malicious packages, and insecure deployment configurations.

Supply chain risk identification for medical devices involves:

  • Maintaining a complete software bill of materials (SBOM) that inventories all software components
  • Continuously monitoring for disclosed vulnerabilities in identified components
  • Assessing the security posture of third-party software suppliers
  • Evaluating risks associated with development tools and build environments
  • Analyzing container images and base layers for known vulnerabilities

Organizations that implement comprehensive software supply chain security practices gain a significant advantage in meeting ISO 14971 requirements, as these practices generate the evidence and traceability needed for regulatory compliance.

Managing Open Source Risk Under ISO 14971

Open source software presents particular challenges under ISO 14971 because manufacturers must manage risks associated with components they didn't develop. The standard requires organizations to treat third-party software as a potential source of hazards and implement appropriate controls.

Effective open source risk management includes:

  • Establishing approved component lists based on security assessment and license compatibility
  • Implementing automated scanning for newly disclosed vulnerabilities
  • Creating processes for rapid patching when critical vulnerabilities are discovered
  • Maintaining fallback plans when components become unsupported or abandoned
  • Documenting the rationale for accepting residual risks in dependencies

The risk-based approach of ISO 14971 allows teams to make pragmatic decisions about open source usage. Not every disclosed vulnerability requires immediate action—teams must assess actual risk based on how their device uses the component, whether vulnerable code paths are reachable, and what other controls are in place.

Build and Deployment Pipeline Security

ISO 14971 risk management must extend to the tools and processes used to build, test, and deploy medical device software. Compromised build environments or insecure deployment pipelines represent potential sources of hazards that could affect patient safety.

Pipeline security controls that support ISO 14971 compliance include:

  • Cryptographic signing of build artifacts to ensure integrity
  • Access controls limiting who can modify pipeline configurations
  • Audit logging of all pipeline activities for traceability
  • Isolated build environments to prevent cross-contamination
  • Automated security gates that prevent deployment of components with unacceptable risks

Modern DevSecOps platforms provide these controls as standard features, making it easier for medical device teams to demonstrate compliance while maintaining rapid development cycles.

Risk Monitoring and Post-Production Surveillance

ISO 14971 doesn't end when a device ships. The standard requires ongoing monitoring during production and post-production phases to gather information that might indicate previously unknown hazards or show that estimated risks were incorrect.

Production Monitoring Requirements

During production, organizations must monitor for deviations in manufacturing processes, component quality issues, and any information suggesting risks were underestimated. For software products, production monitoring focuses on build reproducibility, component updates, and supply chain changes.

Production monitoring activities include:

  • Tracking changes in third-party component versions and security status
  • Monitoring build environments for unauthorized modifications
  • Validating that deployed software matches approved release artifacts
  • Scanning production deployments for configuration drift

Post-Production Surveillance and Feedback

After devices reach customers, ISO 14971 requires systems for collecting and reviewing information that could indicate new hazards or inadequate risk controls. This post-market surveillance creates a feedback loop that informs future risk management activities.

Post-production surveillance for software-based medical devices encompasses:

  • Monitoring security advisories and vulnerability databases for new threats
  • Analyzing device logs and telemetry for anomalous behavior
  • Reviewing customer complaints and incident reports
  • Tracking cybersecurity incidents and attempted attacks
  • Evaluating effectiveness of deployed risk controls through real-world data

When post-production information reveals new hazards or shows that risk estimates were incorrect, ISO 14971 requires updating the risk management file and potentially implementing additional controls. This might trigger software updates, security patches, or changes to user instructions.

Incident Response and Risk Management Updates

Cybersecurity incidents affecting medical devices must be handled within the ISO 14971 framework. When an incident occurs, teams must assess whether it represents a previously unidentified hazard, whether existing risk controls failed, or whether risk estimates need revision.

The incident response process should:

  • Document the incident details and patient safety impact
  • Evaluate whether risk management documentation needs updating
  • Assess whether additional risk controls are needed
  • Determine if regulatory reporting obligations are triggered
  • Implement corrective and preventive actions
  • Update risk management training based on lessons learned

Connecting ISO 14971 to Security Frameworks and Standards

ISO 14971 doesn't exist in isolation. Medical device software teams must often comply with multiple overlapping standards and frameworks, including IEC 62304 for medical device software lifecycle processes, ISO 13485 for quality management systems, and various cybersecurity standards.

Integration with IEC 62304

IEC 62304 provides specific requirements for software lifecycle processes in medical devices. ISO 14971 and IEC 62304 work together—the former focuses on risk management principles while the latter specifies how to implement those principles within software development activities.

The standards integrate through:

  • IEC 62304 software safety classification driving ISO 14971 risk control rigor
  • Risk management activities feeding into IEC 62304 software requirements
  • Software verification and validation activities providing evidence of risk control effectiveness
  • Software change management processes triggering risk management updates

Alignment with Cybersecurity Standards

Medical device cybersecurity has become a major regulatory focus, with standards like IEC 81001-5-1 and guidance documents from FDA and other regulatory bodies. ISO 14971 provides the overarching risk management framework within which cybersecurity risks are addressed.

Organizations building secure medical device software benefit from aligning ISO 14971 risk management with cybersecurity frameworks like NIST Cybersecurity Framework or CIS Controls. This alignment helps teams demonstrate that cybersecurity risks receive the same systematic treatment as other safety hazards.

Leveraging Existing DevSecOps Maturity

Teams with mature DevSecOps practices already have many building blocks needed for ISO 14971 compliance. Security practices like threat modeling, vulnerability management, secure coding standards, and automated security testing directly support risk management requirements.

The transition from general DevSecOps to ISO 14971-compliant development primarily involves:

  • Adding the documentation and traceability that regulations require
  • Implementing formal review and approval gates at defined points
  • Establishing clear risk acceptability criteria
  • Creating processes for post-production surveillance and updates
  • Building competency in regulatory language and expectations

Organizations don't need to abandon their existing development culture to meet ISO 14971 requirements. The standard's principles align naturally with security-first development approaches.

Securing Medical Device Development Pipelines

Meeting ISO 14971 requirements while maintaining development velocity requires secure, automated pipelines that integrate risk management activities into daily workflows. Modern DevSecOps platforms enable this integration by providing visibility, automation, and traceability across the software supply chain.

Organizations developing medical device software face unique challenges around supply chain security, regulatory compliance, and risk management documentation. Purpose-built solutions help teams navigate these challenges without sacrificing the speed and innovation that modern development practices enable.

If your organization develops medical device software or operates in other highly regulated industries where software supply chain security and regulatory compliance intersect, schedule a demo with Kusari to explore how comprehensive supply chain security platforms can streamline ISO 14971 compliance while strengthening your overall security posture. The platform provides automated SBOM generation, continuous vulnerability monitoring, policy enforcement, and the traceability needed to demonstrate regulatory compliance without manual overhead.

What are the main requirements of ISO 14971 for medical device manufacturers?

The main requirements of ISO 14971 establish a comprehensive framework that medical device manufacturers must follow throughout the product lifecycle. ISO 14971 requires organizations to establish, document, and maintain a systematic risk management process that identifies hazards, estimates and evaluates risks, controls risks through a defined hierarchy of measures, and monitors the effectiveness of those controls.

Key requirements include establishing a risk management plan at the beginning of each project that defines the scope, responsibilities, risk acceptability criteria, and verification activities. Organizations must conduct thorough risk analysis that identifies intended use, reasonably foreseeable misuse, known and foreseeable hazards, and hazardous situations that could result from device use.

ISO 14971 mandates that organizations implement risk controls following a specific hierarchy: inherent safety by design takes priority, followed by protective measures in the device itself, and finally information for safety such as warnings and training. After implementing controls, manufacturers must verify their effectiveness and evaluate residual risks to determine if they're acceptable.

The standard requires maintaining a risk management file that contains all documentation related to risk management activities, including hazard identification records, risk analysis results, risk control implementation evidence, and verification records. This file must be reviewed before release to ensure risk management is complete and the overall residual risk is acceptable.

Post-production requirements under ISO 14971 obligate manufacturers to establish processes for gathering and reviewing information from production and post-production phases that might indicate new hazards or show that risks were underestimated. When such information emerges, organizations must update risk management documentation and implement additional controls if necessary.

For software development teams, these requirements translate to integrating risk management checkpoints throughout the SDLC, maintaining traceability between risks and requirements/design/code, automating evidence collection through DevSecOps tooling, and establishing continuous monitoring of deployed software for security vulnerabilities and operational issues.

How does ISO 14971 apply to software as a medical device?

ISO 14971 applies to software as a medical device (SaMD) by requiring the same systematic risk management approach used for hardware medical devices, adapted to address software-specific hazards and risks. Software as a medical device faces unique risks related to coding errors, cybersecurity vulnerabilities, integration with other systems, software updates, and the supply chain of third-party components.

When applying ISO 14971 to software medical devices, organizations must identify hazards that stem from software failures, incorrect calculations, user interface design issues, data corruption, unauthorized access, and integration problems with other systems or devices. The risk analysis must consider both the software itself and the environment in which it operates, including operating systems, browsers, network connectivity, and connected devices.

Risk control implementation for SaMD typically emphasizes inherent safety by design through architectural decisions, secure coding practices, input validation, error handling, and defensive programming techniques. Protective measures include authentication systems, encryption, access controls, audit logging, and automated monitoring for anomalous behavior. Information for safety includes user documentation, training materials, system requirements specifications, and security advisories.

Software updates present unique challenges under ISO 14971 because each update potentially introduces new risks while addressing others. Organizations must conduct risk assessment for each software change, considering not just the modified code but also regression risks, deployment risks, and the possibility that updates might fail or be applied incorrectly.

Cybersecurity risks receive particular attention when applying ISO 14971 to SaMD. Manufacturers must identify potential cyber threats, assess their likelihood and potential impact on patient safety, implement security controls following established frameworks, and maintain vigilance through continuous monitoring and vulnerability management.

The software supply chain adds another layer of complexity to ISO 14971 compliance for SaMD. Organizations must manage risks associated with open source components, third-party libraries, development tools, cloud services, and container base images. This requires maintaining comprehensive software bills of materials, continuously monitoring for vulnerabilities, and having processes for rapid patching when critical issues are discovered.

Post-production surveillance for SaMD includes monitoring for newly discovered software vulnerabilities, analyzing logs and telemetry for signs of cyber attacks or system misuse, reviewing user feedback for unreported issues, and tracking the effectiveness of deployed security controls through real-world data.

What is the difference between ISO 14971 and ISO 13485?

The difference between ISO 14971 and ISO 13485 centers on their distinct purposes and scopes within medical device development and manufacturing. ISO 14971 specifically addresses risk management processes for medical devices, while ISO 13485 establishes requirements for a comprehensive quality management system for medical device organizations.

ISO 14971 focuses exclusively on identifying, evaluating, controlling, and monitoring risks throughout a medical device's lifecycle. The standard provides detailed requirements for how organizations should conduct risk analysis, implement risk controls, evaluate residual risks, and maintain risk management documentation. It's a process standard that specifies what activities must happen and in what sequence, but doesn't address broader organizational quality management.

ISO 13485 takes a wider view, establishing requirements for an organization's entire quality management system including management responsibility, resource management, product realization, and measurement/analysis/improvement processes. Quality management systems under ISO 13485 encompass design controls, document management, supplier management, production controls, and corrective/preventive actions across all organizational functions.

The relationship between ISO 14971 and ISO 13485 is complementary rather than competing. ISO 13485 requires organizations to have documented processes for risk management, and ISO 14971 provides the specific framework for meeting that requirement. Organizations typically implement ISO 14971 as part of their broader ISO 13485 quality management system.

From a documentation perspective, ISO 14971 requires maintaining a risk management file for each device that contains all risk management documentation. ISO 13485 requires a much broader set of documentation covering all aspects of the quality management system, including quality manual, procedures, work instructions, and records across all functional areas.

For software development teams, ISO 14971 directly impacts how they conduct threat modeling, security testing, and vulnerability management, providing specific requirements for these activities. ISO 13485 affects software teams more broadly, requiring documented software development processes, design controls, configuration management, and verification/validation activities that extend beyond just risk management.

Certification also differs between the two standards. Organizations can become certified to ISO 13485 through third-party audits that verify their quality management system meets standard requirements. ISO 14971 isn't typically a certification standard—instead, regulatory auditors and notified bodies review ISO 14971 compliance as part of evaluating whether a specific medical device meets regulatory requirements.

Both standards require organizations to establish processes before beginning work rather than retrofitting compliance after development. However, ISO 14971's risk management activities are more directly embedded in the product development workflow, while ISO 13485 requirements span organizational operations beyond individual product development projects.

How do I document compliance with ISO 14971 requirements?

Documenting compliance with ISO 14971 requirements involves creating and maintaining a comprehensive risk management file that demonstrates systematic application of risk management principles throughout the device lifecycle. The risk management file must contain evidence that all required activities were performed, documented according to established procedures, reviewed by appropriate personnel, and resulted in acceptable risk levels.

The foundation of ISO 14971 documentation is the risk management plan, which should be created at the project's beginning and describe the scope of risk management activities, assign responsibilities, define risk acceptability criteria, specify verification activities, and outline the approach to production and post-production information gathering. This plan establishes the framework against which compliance will be assessed.

Risk analysis documentation must demonstrate that hazards were systematically identified across all device lifecycle phases, hazardous situations were analyzed, and risks were estimated using defined methodologies. For software medical devices, this includes documenting threat models, security risk assessments, failure mode analyses, and integration risk evaluations. Traceability matrices connecting hazards to their sources help demonstrate completeness.

Risk evaluation documentation should show that each identified risk was compared against predefined acceptability criteria and that decisions about risk acceptability were made by authorized personnel. When risks exceed acceptable levels, documentation must show what controls were selected and why, following the risk control hierarchy mandated by ISO 14971.

Risk control implementation documentation provides evidence that selected controls were actually implemented as intended. For software teams, this might include references to design documents, code commits, security test results, penetration testing reports, and configuration records. Automated evidence collection from CI/CD pipelines can streamline this documentation significantly.

Verification records demonstrate that implemented risk controls work as intended and don't introduce new hazards. Testing documentation, validation reports, security assessment results, and review meeting minutes all serve as verification evidence. Traceability from risks to controls to verification activities helps auditors understand the complete story.

Residual risk documentation must show that remaining risks after control implementation were evaluated and found acceptable, or that risk-benefit analysis supports accepting higher residual risks. The overall residual risk must be evaluated and documented before device release.

Production and post-production information documentation demonstrates ongoing monitoring activities, how information is collected and reviewed, what actions were taken in response to new information, and how the risk management file was updated based on real-world experience. For software products, vulnerability monitoring logs, security incident reports, and update deployment records provide this evidence.

Organizations should leverage existing development artifacts rather than creating parallel documentation purely for compliance. Requirements specifications, design documents, code repositories, test results, deployment records, and monitoring dashboards can all serve as ISO 14971 evidence when properly organized and maintained with traceability to risk management activities.

Bringing Risk Management and DevSecOps Together

Medical device software development sits at the intersection of regulatory compliance, patient safety, and modern development practices. Successfully navigating this space requires teams that understand both the rigorous risk management principles embodied in ISO 14971 and the automation, velocity, and security focus of mature DevSecOps organizations.

Organizations that view ISO 14971 as merely a compliance checkbox miss opportunities to leverage its framework for building genuinely safer, more secure products. The standard's systematic approach to identifying hazards, implementing controls, and monitoring effectiveness mirrors best practices in application security and DevSecOps. Teams that embrace this alignment can meet regulatory requirements while maintaining development velocity and engineering culture.

The software supply chain represents both a significant risk area under ISO 14971 and an opportunity for competitive advantage. Organizations that implement comprehensive supply chain security practices—maintaining SBOMs, continuously monitoring for vulnerabilities, securing build pipelines, and automating compliance evidence collection—position themselves to move faster than competitors still managing these concerns manually.

As medical devices become increasingly software-defined and connected, the convergence of regulatory compliance and cybersecurity intensifies. Standards like ISO 14971 will continue evolving to address emerging threats, creating ongoing challenges for development teams. Organizations that build strong foundations now, integrating risk management into their development DNA rather than treating it as an external obligation, will adapt more successfully as requirements evolve.

For DevSecOps leaders, security directors, and development teams working in regulated industries, understanding ISO 14971 provides valuable perspective even beyond medical devices. The standard's principles apply broadly to any situation where software failures could have serious consequences—financial systems, industrial controls, automotive systems, and other safety-critical applications all benefit from systematic risk management approaches similar to those required by ISO 14971.