This is exactly what IEC 62304 provides — a globally recognised software lifecycle framework referenced by EU MDR Annex I, the MHRA, and the FDA’s new QMSR. If your device contains software, IEC 62304 is not a “nice-to-have”; it’s the backbone of compliance.
And the stakes are rising. According to MedTech Europe’s 2024 industry review, over 65% of new Class IIb and Class III medical devices now contain embedded software, making IEC 62304 essential for almost every new market application.
Failing to meet these lifecycle requirements is one of the most common causes of Notified Body delays and regulator pushback.
Need help aligning your software with IEC 62304? Talk to Patient Guard’s software compliance team today. Get in touch.
What Is IEC 62304 and Why It Matters
IEC 62304 is an international standard defining the complete software lifecycle for medical devices — including Software as a Medical Device (SaMD) and embedded firmware.
It covers:
- Development
- Design
- Risk management
- Verification and validation
- Release
- Maintenance
- Problem resolution
- Ongoing lifecycle control
In short, it tells you how medical device software must be built, documented, and maintained to demonstrate safety.
It is referenced explicitly by:
- EU MDR Annex I (GSPR 17)
- UK MDR (MHRA SaMD requirements)
- FDA QMSR (enforceable Feb 2026), where IEC 62304 is a recognised consensus standard
Software Safety Classes
IEC 62304 defines three classes based on risk:
- Class A – No possibility of injury
- Class B – Non-serious injury possible
- Class C – Death or serious injury possible
The safety class determines the level of documentation, testing, and rigour required.
The IEC 62304 Software Lifecycle – Step by Step
IEC 62304 defines a structured lifecycle that aligns closely with ISO 13485 design controls. Here’s how each phase works.
1. Software Development Planning
This phase sets the foundation for the entire software lifecycle.
Your Software Development Plan (SDP) must include:
- Development methodology
- Software safety classification
- Configuration management
- Problem resolution
- Maintenance planning
- Integration with design and development (ISO 13485)
- Definition of lifecycle deliverables
- Traceability approach
Auditors expect the SDP to be device-specific and actively maintained — not a generic template.
2. Requirements Analysis & Specification
You must define:
- System requirements that the software supports
- Detailed software requirements with unique identifiers
- Risk controls derived from ISO 14971
- Traceability linking requirements → design → tests
Weak or ambiguous requirements are one of the top Notified Body findings for SaMD.
3. Architecture & Design
Your software architecture must:
- Define modules
- Identify safety-related components
- Document data flows
- Separate Class C modules from lower-risk components
- Show how the design supports risk control
- Include interface specifications
This is essential for demonstrating safe behaviour even in fault conditions.
4. Implementation & Unit Verification
IEC 62304 expects objective evidence that:
- Coding standards are followed
- Safety-critical modules meet higher verification levels
- Static analysis and peer review are performed
- Unit tests verify each module’s intended behaviour
For Class C software, the expectations are similar to those for safety-critical aerospace systems, i.e. thorough and traceable.
5. Integration & System Testing
This phase verifies that the full software system works as intended.
Testing must be:
- Planned
- Traceable
- Repeatable
- Based on acceptance criteria
- Linked to risk controls
- Documented with objective evidence
For SaMD, this can include simulated environments, clinical datasets, or real-world test scenarios.
6. Release & Maintenance
Regulators expect ongoing control, including:
- Versioning and release notes
- Cybersecurity considerations
- Field performance monitoring
- Post-market updates
- Controlled maintenance processes
SOUP (Software of Unknown Provenance) must also be validated, documented, and monitored, this being a significant area of Notified Body scrutiny.
Risk Management in IEC 62304
IEC 62304 is tightly interwoven with ISO 14971 — every software requirement, design element, and test must link back to risk controls.
Examples:
- Hazard → software requirement
- Software fault → test case
- Risk control → design element
- Post-market hazard → updated requirements
Class B and Class C software require deeper risk analyses, including:
- Fault-tree analysis
- Software failure modes
- Cybersecurity threats
- Data-handling risks
- Algorithmic decision risks
Documentation & Deliverables Required by IEC 62304
A compliant IEC 62304 file typically contains:
- Software Development Plan (SDP)
- Software Requirements Specification (SRS)
- Software Architecture & Design Documentation
- Verification & Validation (V&V) Evidence
- Software Risk Management File
- Problem Resolution Procedure
- Maintenance Plan
- SOUP Assessment & Monitoring Evidence
- Traceability Matrix
Statistic:
Industry analysis shows that a medium-complexity medical software project generates 150–300 pages of IEC 62304 documentation — before SOUP and advanced V&V are added.
Related post: Software as a Medical Device
How to Implement IEC 62304 in Your Organisation
Here’s a pragmatic implementation strategy, ideal for start-ups and SMEs.
Align IEC 62304 With Your QMS
You must integrate IEC 62304 with:
- ISO 13485 (design controls, risk, CAPA)
- ISO 14971 (risk management)
- IEC 82304 (health software)
- IEC 60601-1 (safety of active devices)
A siloed software lifecycle will fail an audit every time.
Use a Phase-Gate Model
Map 62304 phases to your product development cycle:
- Concept → Feasibility → Development → Verification → Validation → Launch → Post-market
This helps teams stay aligned and gives auditors a clear evidence flow.
Cross-Functional Training
Developers often don’t speak “regulatory”, and regulators don’t speak “developer”.
A good training plan ensures everyone understands:
- Safety classes (A/B/C)
- Documentation requirements
- Traceability
- Testing evidence
- Risk-linked design
Automate Traceability
Recommended tools include:
- Jira
- Azure DevOps
- Polarion
- Greenlight Guru
- Helix ALM
Automation reduces manual errors and creates clear, audit-ready evidence.
Common IEC 62304 Pitfalls (and How to Avoid Them)
These are the issues most commonly reported by Notified Bodies and MHRA assessors:
1. Treating software documentation like hardware documentation
Software needs higher traceability and objective evidence.
2. Missing Problem Resolution Procedure
IEC 62304 requires a defined method for defect logging, triage, and closure.
3. No linkage between ISO 14971 and V&V
If a risk exists, there must be a requirement. If a requirement exists, there must be a test.
4. SOUP not assessed properly
SOUP must be risk-evaluated, verified, and continuously monitored.
IEC 62304 and Regulatory Compliance (UK, EU, US)
IEC 62304 is accepted by:
Region | Regulator | Acceptance |
UK | MHRA | Required for SaMD and embedded software under UKCA |
EU | Notified Bodies (MDR/IVDR) | Required evidence under Annex I GSPR 17 |
USA | FDA (QMSR 2026) | Recognised consensus standard |
Speak to us about UKCA Marking for Software Devices
Case Study – Applying IEC 62304 in Practice
Scenario:
A Class IIa diagnostic mobile app deployed for real-time interpretation of sensor data.
Challenges:
- Fragmented documentation
- Unclear safety classification
- No SOUP assessment
- Weak traceability
Patient Guard intervention:
- Created a full Software Development Plan
- Risk-based classification (Class B)
- Implemented requirement → test traceability
- Validated third-party software components
- Prepared a Notified Body-ready software file
Outcome:
- Defect rate reduced 40%
- NB review accelerated
- Successful UKCA submission
Conclusion
IEC 62304 is the core framework for developing safe, validated, and compliant medical device software. Whether you’re building a Class A utility or a Class C diagnostic engine, regulators expect a fully traceable, lifecycle-driven approach aligned with IEC 62304, ISO 14971, and ISO 13485.
A strong software lifecycle doesn’t just support compliance — it improves product quality, reduces defects, and accelerates approvals. Contact Patient Guard for a complete software lifecycle compliance assessment — from IEC 62304 gap analysis to full documentation support.
Frequently Asked Questions
Any medical device containing software — including SaMD — must demonstrate compliance.
Class A: no harm possible
Class B: non-serious harm possible
Class C: serious harm or death possible
SDP, SRS, architecture, V&V reports, risk file, SOUP assessment, maintenance plan, and more.
ISO 14971 = risk management
ISO 13485 = design control
IEC 62304 = software lifecycle
All three must integrate.
Yes – in UK, EU, and US regulatory systems.
Yes, including documentation, lifecycle implementation, and NB audit preparation.
Patient Guards Recent Posts
CE Marking vs UKCA: 2026 Guide for Manufacturers
Post-Brexit, many medical device manufacturers are still navigating the split between CE marking and the UKCA mark — and the rules keep evolving. As the MHRA advances its “future regime” for medical devices, regulatory teams face the ongoing challenge of complying with both EU MDR obligations and the UK’s own UK MDR 2002 (as amended) framework.
ISO 10993-1:2025 – What’s New in Biological Evaluation
The newly revised ISO 10993-1:2025 has quietly done something big: it’s turned biological evaluation from a “tick-the-box biocompatibility test list” into a fully integrated risk narrative that regulators now expect to hold together scientifically, from chemistry through to clinical data.
EUDAMED Mandatory from May 2026: What You Need to Know
After years of “coming soon”, the EU has finally put a fixed date on reality: the first EUDAMED mandatory modules must be used from 28 May 2026.
