What is IEC 62304?

IEC 62304:2006, amended in 2015 and currently under the IEC 62304:2006+AMD1:2015 designation, establishes lifecycle requirements for software that is part of a medical device or that is itself a medical device (Software as a Medical Device, or SaMD). The standard was developed jointly by ISO and IEC and is recognized by FDA, the EU MDR framework, and most other major regulatory jurisdictions.

The standard does not tell developers how to write software. It specifies what processes, activities, and documentation must exist throughout the software lifecycle: from planning and requirements through architecture, detailed design, implementation, testing, maintenance, and problem resolution. The depth of these processes scales with the software’s safety classification.

Software safety classification: the foundation of IEC 62304

IEC 62304 divides medical device software into three safety classes based on the severity of harm that could result from software failure.

Class A: Software whose failure cannot contribute to a hazardous situation, or whose failure can contribute only to a hazardous situation that results in no injury or only negligible injury. Class A software has the lightest documentation requirements under the standard.

Class B: Software whose failure can contribute to a hazardous situation resulting in non-serious injury. Class B requires most of the standard’s process activities but does not require the detailed unit-level testing that Class C demands.

Class C: Software whose failure can contribute to a hazardous situation resulting in serious injury or death. Class C carries the full weight of the standard’s requirements, including unit-level software testing, detailed software architecture documentation, and comprehensive traceability from requirements through testing.

Classification is determined through the risk management process conducted under ISO 14971. Software that controls drug delivery, performs diagnostic calculations that directly drive treatment decisions, or operates implantable devices typically falls into Class C. Administrative software, data archiving tools, and non-decision-support displays often qualify for Class A or B. Misclassification is one of the most common IEC 62304 compliance problems FDA encounters during device inspections.

Core lifecycle processes required by IEC 62304

Software development planning (clause 5.1)

Before development begins, a software development plan must define the lifecycle model to be used, the methods and tools for each activity, the standards to be applied, the approach to integration and testing, the configuration management approach, and the problem resolution process. For Class C software, the plan must also address the approach to software architecture and detailed design. The plan is a living document that must reflect the actual development approach, not a generic template filled in after the fact.

Software requirements analysis (clause 5.2)

All software requirements must be documented. This includes functional requirements, performance requirements, interface requirements, and requirements derived from the risk management process. Requirements must be traceable: every risk control measure that depends on software must appear as a software requirement, and that requirement must be traceable through design, implementation, and verification testing.

A common gap here is that requirements documents describe what the software shall do but omit the performance parameters and failure mode behaviors that determine whether the software meets its safety obligations. FDA reviewers specifically look for requirements that cover how the software behaves under abnormal conditions.

Software architectural design (clause 5.3)

The software architecture must identify all software items (the modular components that make up the system) and their interfaces, and must identify which software items implement security and safety-critical functions. For Class C software, the architecture must be documented in detail sufficient for subsequent detailed design. Architecture documentation must be reviewed and its ability to meet requirements verified before detailed design proceeds.

Software detailed design (clause 5.4)

Required for Class C software (and recommended for Class B), detailed design specifies the internal logic of software units to the level where implementation can proceed without ambiguity. This is the level at which code-to-design traceability is established.

Software unit implementation and verification (clause 5.5)

Each software unit must be implemented according to its detailed design and verified to confirm the implementation is correct. For Class C, unit testing is specifically required. Unit test procedures and results must be documented. For Class B, the verification approach at unit level is more flexible but must still be documented.

Software integration and integration testing (clause 5.6)

Software units are integrated into software items, and software items are integrated into the complete system. Integration testing verifies the interfaces between integrated components work as specified. Test procedures, expected results, and actual results must all be documented. Anomalies discovered during integration testing must enter the problem resolution process.

Software system testing (clause 5.7)

System-level testing verifies that the complete software system meets its requirements under all specified conditions, including boundary conditions and failure modes defined in the risk management process. Test procedures, expected results, and actual results must be documented. For Class C software, regression testing must be performed when the software is modified.

Software release (clause 5.8)

Before release, the manufacturer must ensure that all required activities have been completed and documented, that all known anomalies have been evaluated and either resolved or formally accepted, that the software version is identified in the software configuration record, and that the risk register reflects the final software risk evaluation. A software release record documenting all of this is required.

Software maintenance and problem resolution

IEC 62304 clause 6 covers software maintenance: changes to released software must go through a controlled process that re-evaluates safety classification, conducts impact analysis, and ensures all affected requirements, design elements, and tests are updated and re-verified. This is where organizations with weak change control processes accumulate significant compliance debt: software changes applied outside the formal lifecycle process create documentation gaps that are difficult to reconstruct under regulatory scrutiny.

Clause 9 covers the problem resolution process: a structured feedback loop that captures field problems, software anomalies, and defects, evaluates their safety significance, initiates corrective action where required, and closes the loop with verification that the problem is resolved. This process must be active throughout the product’s market life, not just during development.

Relationship to FDA guidance and QMSR

FDA recognizes IEC 62304 as a consensus standard under the 510(k) and PMA submission process. A declaration of conformance to IEC 62304 in a submission provides reviewers with confidence that the software development lifecycle meets recognized standards without requiring submission of all lifecycle documentation. Submission of the Software Description, Software Level of Concern, and supporting documentation follows FDA’s guidance documents on software in medical devices.

Under the Quality Management System Regulation (QMSR), which took effect in February 2026 and aligns 21 CFR Part 820 with ISO 13485:2016, design and development requirements for software are evaluated under the design controls provisions. IEC 62304 activities map directly to the design planning, design input, design output, design verification, design validation, and design transfer requirements in QMSR and ISO 13485 Section 7.3.

FDA’s 2023 guidance on cybersecurity in medical devices also intersects with IEC 62304: security requirements for software must be captured in the requirements phase, security testing must occur during verification and validation, and the software bill of materials (SBOM) required under the Consolidated Appropriations Act of 2023 depends on the configuration management practices IEC 62304 requires.

Common IEC 62304 deficiencies in FDA inspections

Incorrect safety classification. Manufacturers classify software as Class A or B when the failure mode analysis supports Class C. FDA inspectors are trained to evaluate this, and misclassification found during inspection is a major finding.

Missing traceability. Requirements not traced to test cases. Test cases not traced to requirements. Risk control measures implemented in software but not appearing in the requirements document. Traceability matrices that exist on paper but were not maintained as the software evolved.

Incomplete anomaly management. Known defects in released software that were not formally evaluated for safety significance. A defect log managed informally in a bug tracker that was never reviewed for its relationship to the risk management process.

Inadequate problem resolution process. Post-market complaints and field problems that entered customer service processes but never reached the software problem resolution process for safety evaluation.

How a QMS supports IEC 62304 compliance

IEC 62304 generates a significant volume of controlled documentation: software development plans, requirements specifications, architecture documents, test protocols, test reports, anomaly records, change requests, and release records. Managing this volume in a paper-based or disconnected electronic system creates the traceability gaps that generate FDA findings.

An electronic QMS with design controls, document management, CAPA, and change control modules provides the structured environment these records need. When an anomaly enters the problem resolution process, it links to the relevant software requirement and test record. When a software change is made, the change control workflow ensures that impact analysis, requirement updates, and regression testing are all completed and documented before the change is released.

Cloudtheapp’s platform supports medical device software quality programs with design controls, document control, risk management, CAPA, and change management applications that can be configured to the IEC 62304 lifecycle structure. The 60+ applications available in the Cloudtheapp store give medical device software teams a complete quality infrastructure without building custom systems for each process. To see how Cloudtheapp supports medical device software quality programs, request a demo.

Conclusion

IEC 62304 compliance is not optional for manufacturers of software-embedded or software-as-a-medical-device products. It is the established standard by which regulators evaluate whether a medical device software development program produces reliable, safe output. The companies that execute it well treat it as an engineering discipline rather than a documentation burden: they classify software correctly, maintain traceability throughout the lifecycle, and run a problem resolution process that connects field experience back to the development record. Done with this mindset, IEC 62304 compliance produces better software, fewer recalls, and more predictable regulatory submissions.

This post created by and appeared first on Cloudtheapp