Software, Cybersecurity and AI
IEC 62304: Medical Device Software Lifecycle Processes
IEC 62304 defines the lifecycle processes for developing and maintaining medical device software, both software embedded in a device and software that is itself a medical device. It doesn't prescribe a methodology such as agile or waterfall. It sets out the activities and records required, and scales how much is required by the software's safety classification.
At a Glance
- Standard
- IEC 62304
- Subject
- Medical Device Software Lifecycle Processes
- Group
- Software, Cybersecurity and AI
- Industries
- 5 industry guides reference it
A plain-language summary of scope, not the standard itself. Buy the current edition from the publisher and check which edition your auditor or market expects.
What It Covers
Software is classified A, B or C according to the severity of harm that could result if the software contributes to a hazardous situation, taking into account risk controls outside the software. The class drives the rigor: Class C software calls for more detailed design and unit-level verification than Class A. The classification rationale is one of the first things a reviewer reads, because an understated class undermines everything downstream.
The development process runs from planning and software requirements through architecture, detailed design, unit implementation and verification, integration and system testing, to release. Alongside it the standard requires software risk management tied to ISO 14971, configuration management and a problem resolution process. Software of unknown provenance (SOUP), such as third-party libraries and operating systems, has to be identified, with its requirements stated and its known anomalies evaluated.
Maintenance is a process in its own right, and it's where many firms are weakest. After release, feedback, bug reports and changes to SOUP have to be evaluated, and modifications go back through the relevant development activities. IEC 62304 doesn't cover validation of the finished device; that stays with design controls in the QMS.
Who It Applies To
- Manufacturers of devices with embedded software or firmware
- Software as a Medical Device and AI-enabled software functions
- Firms maintaining legacy software built before they adopted a formal lifecycle
- Contract software developers working under a device maker's quality system
What Auditors Check
Safety Classification Rationale
A documented class for the software system, and for software items where they're segregated, with reasoning tied to the hazard analysis.
Software Development Plan
A plan that matches how the team actually works, including tools, reviews and how agile practices map to the required activities.
Requirements to Test Traceability
Traceability from software requirements and risk controls through design to verification, with any gaps explained.
SOUP List
An inventory of third-party software with versions, the requirements placed on it, and evaluation of its published anomalies.
Known Anomalies at Release
A list of unresolved anomalies at release, with an evaluation showing none contributes to unacceptable risk.
Problem Reports and Change Records
Problem reports investigated and linked to changes, and changes verified with regression testing proportionate to their impact.
Configuration Management
Identified configuration items and the ability to reproduce any released version of the software.
Related Services
Software Validation and Device Software (CSV, IEC 62304)
Validate software used in production and the QMS, and build device software on an IEC 62304 lifecycle.
AI-Assisted QMS Gap Assessment
An AI-assisted first pass over the QMS documents you already have, with every result reviewed by an advisor.
Submission Readiness (510(k), De Novo, PMA, Pre-Sub, 513(g))
The design, risk and V&V evidence behind a 510(k), De Novo or PMA, organized and gap-checked.
CAPA System Remediation
Fixing a CAPA system auditors keep citing: the procedure, the records, root cause, effectiveness and backlog.
Questions
Does IEC 62304 require waterfall development?
No. The standard defines activities and outputs, not a sequence or methodology. Agile teams can conform as long as their plan maps sprints, reviews and definitions of done to the required activities and the records exist. Auditors look for that mapping in the software development plan.
How should we handle open-source libraries?
Treat them as SOUP. Identify each one and its version, state the requirements your software relies on, and evaluate its published bug or anomaly lists for anything that could contribute to a hazardous situation. Keep that evaluation current as versions change.
Can hardware risk controls lower our software safety class?
Risk controls outside the software can be taken into account when classifying, but they need to be real, verified and documented in the risk management file. A class lowered on the strength of an assumed control is something reviewers challenge.
We have legacy software with no IEC 62304 records. Where do we start?
Start with a gap assessment of the current software and its history. Typical steps include documenting the existing architecture, reconstructing requirements and risk analysis, reviewing field experience, and applying the full process to every future change. The right path depends on your device, its class and your markets.
IEC 62304
Check Your Quality System Against IEC 62304
An AI-assisted first pass maps your existing documents against the requirements in scope, and an advisor reviews every result. Please don't send confidential documents yet: secure upload is set up after onboarding.
