Medical device software compliance is exponentially more complex than hardware compliance because software development intersects three major regulatory standards simultaneously: IEC 62304 (software lifecycle), ISO 14971 (risk management), and ISO 13485 (quality management). Each standard addresses different aspects of software development, yet they are deeply interconnected. A software development activity that satisfies IEC 62304 requirements may still fail to address ISO 14971 risk controls or ISO 13485 quality evidence. Misunderstanding how these standards work together is a common cause of software compliance failures and delayed regulatory submissions.

Why Medical Device Software Compliance Is More Complex Than You Think

Software permeates modern medical devices. Devices that were historically hardware-only now include embedded microcontrollers, firmware, and software algorithms. Standalone software applications classified as Software as a Medical Device (SaMD) are growing rapidly. Regulators recognize that software defects can harm patients just as readily as hardware flaws, yet software is intangible and requires different validation approaches than physical components. Traditional hardware engineering relies on physical testing and inspection. Software validation requires traceability, code review, testing across multiple configurations, regression analysis, and rigorous documentation of the software development process.

The complexity multiplies when one considers that software exists in different contexts. A device may include firmware (compiled code running on hardware), software libraries (third-party code integrated into the product), legacy software (inherited from prior generations), and artificial intelligence (trained models whose behavior may not be fully deterministic). Each context creates different compliance obligations. The FDA, EMA, Health Canada, and other regulators have issued guidance documents addressing specific software categories, but a single device often spans multiple categories, requiring integration of overlapping compliance frameworks.

IEC 62304: The Software Lifecycle Standard

IEC 62304 defines the software development lifecycle (SDLC) processes required for medical device software. The standard is process-centric, not prescriptive. It does not mandate specific programming languages, development tools, or methodologies (Waterfall, Agile, DevOps). Instead, it requires that organizations define and follow a documented software development process, record evidence that the process was followed, and maintain traceability from requirements through code to testing.

Software Safety Classification: Classes A, B, and C

IEC 62304 classifies software into three safety levels based on the severity of harm that could occur if the software fails. Class A software cannot injure anyone if it fails (e.g., display software for non-critical status information). Class B software could cause reversible injury (e.g., infusion pump controls that over-deliver medication but within a range that does not cause permanent harm). Class C software could cause death or permanent injury if it fails (e.g., cardiac pacemaker timing, ventilator controls, insulin delivery). The software safety class determines the stringency of development, testing, and documentation requirements. Class A requires minimal rigor. Class C requires maximum rigor, including formal methods, design reviews, and comprehensive testing.

Software Development Process Requirements by Class

Class A software requires basic documentation: software requirements, design description, source code, and unit testing. No formal design review, integration testing, or system testing is mandated, though these are best practices. Class B software requires more rigorous documentation and process discipline. Software requirements must be formally reviewed and traced to design. Code must be reviewed by personnel other than the original developer. Integration testing and system testing are required. Design changes and defect reports must be documented and tracked.

Class C software demands the most stringent controls. Software requirements must undergo formal review with traceability to design inputs. Design and code reviews must be documented and critical findings resolved. All integration and system testing must be planned in advance, executed, and comprehensively documented. Test coverage must be comprehensive and appropriate to the safety class, with specific targets defined and justified in the software development plan (IEC 62304 does not mandate a specific percentage, though industry practice for Class C software commonly targets high structural code coverage). Defect tracking and closure is mandatory. Software version control, configuration management, and change control are essential. Many organizations performing Class C development now use automated testing, continuous integration, and DevOps practices, provided that the automated processes are validated and documented as part of the SDLC.

Software Maintenance, Problem Resolution, and Configuration Management

IEC 62304 emphasizes that software development does not end at market release. The standard requires that organizations maintain the ability to support the software throughout its lifetime: responding to customer reports of defects, investigating whether defects are genuine software problems or user errors, prioritizing fixes based on patient safety impact, developing and testing patches, and documenting all problem resolution activities. Configuration management must track all versions of software released to customers and must enable rapid identification of which versions contain particular defects or fixes.

ISO 14971 and Software Risk Management

ISO 14971 requires that organizations identify hazards associated with the device, estimate the risk of each hazard, implement controls to reduce risk, verify that controls are effective, and monitor residual risk throughout the product lifecycle. Software contributes to device risk in multiple ways: software defects can trigger incorrect device behavior, software can amplify or attenuate human errors in use, and software configuration errors can render safety controls ineffective.

Identifying Software-Related Hazards

Risk identification for software includes fault tree analysis, failure mode and effects analysis (FMEA), and hazard analysis. Teams ask: what could go wrong in the software? What conditions could cause the software to produce incorrect output? What would happen if the software did not execute a critical function? Could the software execute an unintended function? Risk identification must consider not just the intended use case, but also foreseeable misuse and edge cases (e.g., what if the device loses power mid-operation? What if the wireless connection drops? What if the user enters invalid data?).

Risk Controls Implemented Through Software

Once hazards are identified, the device design includes controls to prevent or mitigate hazards. Many controls are implemented in software: input validation to reject invalid parameters, watchdog timers to detect processor hangs, checksums to verify data integrity, authentication to prevent unauthorized access, and alarm logic to alert users to abnormal conditions. Each software-based risk control must be designed, coded, tested, and verified. The V&V plan must include specific test cases that verify each risk control works as intended.

ISO 13485: Quality Management for Software Development

ISO 13485 is the quality management standard for medical devices. While not software-specific, ISO 13485 applies to all aspects of medical device development, manufacturing, and support—including software. Key ISO 13485 requirements relevant to software include design controls (documented design input, output, review, verification), change control, document management, configuration management, traceability, and training. Software teams must participate in the company's quality management system: changes to software must follow the same change control procedure as hardware changes, software documentation must be controlled the same way as hardware drawings, and software developers must receive training on quality system procedures.

ISO 13485 also requires management responsibility for quality. This means that software development cannot be siloed. Quality objectives must be defined, management review must occur, and the organization must commit resources to quality initiatives. Many medical device companies struggle to integrate software development into an ISO 13485 quality system because software development culture and hardware manufacturing culture differ significantly. Applying ISO 13485 rigorously to software development requires that organizations invest in software quality infrastructure: requirements management tools, automated testing frameworks, code version control, and formal review processes.

How IEC 62304, ISO 14971, and ISO 13485 Interconnect

The three standards overlap and reinforce each other. IEC 62304 requires software requirements documentation. ISO 14971 requires that risk analysis identify software hazards and that software be designed to implement risk controls. Those risk controls must appear as requirements in the software requirements specification (linking 62304 and 14971). ISO 13485 requires that design inputs and outputs be reviewed and approved, which includes software design inputs and outputs.

A practical example illustrates the interconnection. Suppose risk analysis (ISO 14971) identifies the hazard: "Software could fail to detect and alert to critically high glucose levels in a diabetes management app." A risk control is designed: "Software shall perform glucose measurement validation and trigger an audible and visual alarm if glucose exceeds 400 mg/dL within 30 seconds of measurement." This risk control becomes a design input. The design input drives software requirements (IEC 62304): "Software shall accept glucose values from the glucose meter, validate that values are within the biologically plausible range of 20–600 mg/dL, and trigger an alarm for values exceeding 400 mg/dL." Those requirements are designed, coded, and tested. The test protocol includes verification that the alarm triggers correctly (demonstrating the risk control is effective and satisfying both ISO 14971 and IEC 62304). The entire design, code, test, and risk control documentation is managed under ISO 13485 configuration control and is part of the DHF.

SaMD vs. Embedded Software: Does the Compliance Approach Differ?

Software as a Medical Device (SaMD) is software that functions as a medical device independent of any hardware. Examples include diagnostic software, clinical decision support, patient monitoring apps, and image analysis algorithms. Embedded software is compiled code that runs on a processor inside a hardware device (e.g., firmware in a ventilator, infusion pump, or monitor).

The regulatory classification and review pathway may differ between SaMD and embedded software. In the United States, the FDA classifies SaMD and embedded software separately and may apply different guidance. However, the core compliance requirements remain the same: both must follow IEC 62304 (or equivalent), both must address ISO 14971 risk controls, both must be part of the ISO 13485 quality system, and both must be thoroughly verified and validated. The V&V approach may differ—SaMD may require less hardware integration testing but more focus on clinical validation—but the principle of rigorous, documented verification applies to both.

Common Compliance Mistakes for Medical Device Software Teams

• Treating software as an afterthought: Hardware design is completed first, then software is hastily written to interface with hardware. This leads to software that cannot meet requirements or implement risk controls properly. Software must be considered during initial design planning and risk analysis.

• Insufficient software requirements specification: Requirements are vague, incomplete, or missing acceptance criteria. Developers interpret ambiguous requirements differently, leading to inconsistent implementations and failed verification tests. Requirements must be precise and testable.

• Missing test coverage for risk controls: Tests focus on happy-path use cases (normal operation) but fail to test edge cases or failure modes that could trigger hazards. Risk control testing must be comprehensive and traceable back to ISO 14971 hazard analysis.

• No traceability between requirements, design, code, and tests: It is unclear which code implements which requirements, which tests verify which requirements, and which risk controls are verified. Traceability must be explicit and auditable.

• Inadequate configuration management: Multiple versions of software exist, but there is no clear record of what code was released to customers, what changes were made between versions, or how to reproduce a previous version. This creates support nightmares and regulatory compliance gaps.

• Insufficient software maintenance planning: At product release, the organization assumes software development is complete and reallocates developers to new projects. When customer issues arise, there is no documented process for investigating, fixing, and releasing patches. Software maintenance must be planned and resourced.

• Ignoring cybersecurity: Software connecting to networks or receiving data from external sources is vulnerable to cyberattacks. IEC 62304 does not explicitly address cybersecurity, but FDA and EMA guidance emphasizes that medical device software must be designed and tested to resist malicious input and unauthorized access.

• Mixing legacy and new code without validation: Existing software from prior product generations is reused without re-validating that it still meets current requirements and risk controls. Legacy code must be assessed for compliance under current standards.

💡 Matrix Req integrates IEC 62304 software requirements with ISO 14971 risk controls and ISO 13485 design controls in a unified platform. Software requirements are traced to risk controls, ensuring no hazard is left unaddressed. Risk controls are traced to verification test cases, confirming that each control is validated. Built-in compliance checking flags incomplete requirements, missing risk control links, and verification gaps. When software requirements change, the system shows impact on risk controls, test plans, and downstream documentation, preventing the fragmentation and disconnection that leads to compliance failures.