IEC 62304 Consulting Support
IEC 62304 lifecycle implementation, software documentation and verification & validation for Software as a Medical Device across FDA, EU MDR, CDSCO and 50+ markets.
IEC 62304 Software Lifecycle Implementation for SaMD
IEC 62304 is the international standard that defines the software lifecycle processes for medical device software, including Software as a Medical Device (SaMD). It requires a documented development plan, requirements, architecture, verification, risk management, configuration management, problem resolution and maintenance, scaled to the software’s safety class (A, B or C). The FDA recognises IEC 62304 as a consensus standard, EU MDR notified bodies treat it as the state of the art, and CDSCO expects it for software devices in India.
Most SaMD submissions that get deficiency letters are not rejected for the algorithm. They are rejected because the software lifecycle evidence is missing, inconsistent or reconstructed after the fact. NexorTest builds IEC 62304 into your engineering workflow from sprint one, so the Design History File and technical documentation come out of the work your team already does.
| IEC 62304 clause | Process | What we implement and document |
|---|---|---|
| Clause 4 | General requirements | QMS link to ISO 13485, ISO 14971 risk process, software safety classification rationale, legacy software assessment (4.4) |
| 5.1 | Software development planning | Software Development Plan (SDP) covering lifecycle model, deliverables, traceability, tools, standards, and SOUP management |
| 5.2 | Software requirements analysis | Software Requirements Specification (SRS) with functional, performance, security, usability and risk-control requirements |
| 5.3 – 5.4 | Architectural & detailed design | Software architecture, segregation for risk control, SOUP identification, detailed unit design for Class C |
| 5.5 – 5.7 | Unit, integration & system testing | Unit verification criteria, integration test plan, system test protocols and reports, regression strategy |
| 5.8 | Software release | Release checklist, known residual anomalies evaluation, version archive, reproducible build records |
| Clause 6 | Software maintenance | Maintenance plan, change impact analysis, post-market feedback loop, PCCP alignment for AI/ML updates |
| Clause 7 | Software risk management | Software hazard analysis, contributing causes, risk controls traced to requirements and tests (ISO 14971, IEC/TR 80002-1) |
| Clause 8 | Configuration management | Configuration items, branching and baseline strategy, SOUP and dependency version control, SBOM |
| Clause 9 | Problem resolution | Problem report workflow, trend analysis, link to software CAPA and vigilance |
Compliance basis: IEC 62304:2006 + Amendment 1:2015 (EN 62304:2006/A1:2015), the edition currently recognised by FDA and assessed by EU notified bodies.
IEC 62304 Software Safety Classification: Class A, B and C
IEC 62304 assigns each software system a safety class based on the worst harm a software failure could contribute to: Class A means no injury is possible, Class B means non-serious injury is possible, and Class C means death or serious injury is possible. Software failure is assumed to happen (100% probability), so only risk controls outside the software can lower the class. The higher the class, the more documentation and testing the standard requires.
| Deliverable / activity | Class A | Class B | Class C |
|---|---|---|---|
| Software development plan | ✓ | ✓ | ✓ |
| Software requirements specification | ✓ | ✓ | ✓ |
| Software architecture | Not required | ✓ | ✓ |
| Detailed design of each software unit | Not required | Not required | ✓ |
| Unit verification (with acceptance criteria) | Not required | ✓ | ✓ + additional criteria |
| Integration testing | Not required | ✓ | ✓ |
| Software system testing | ✓ | ✓ | ✓ |
| Software risk management (Clause 7) | Partial | ✓ | ✓ |
| SOUP requirements & known anomaly evaluation | Not required | ✓ | ✓ |
| Release, maintenance, configuration & problem resolution | ✓ | ✓ | ✓ |
Simplified summary. Exact sub-clause applicability is defined in IEC 62304:2006+A1:2015. Most diagnostic, triage and AI/ML SaMD lands in Class B or C.
SaMD Verification and Validation (V&V) Studies
Verification proves the software was built right: each requirement is implemented and tested at unit, integration and system level. Validation proves the right software was built: the finished SaMD meets user needs and its intended use in the real clinical environment, through usability, analytical and clinical performance studies. Regulators expect both, linked by a traceability matrix from user needs to requirements, risks and test results.
Software verification testing
- Software V&V plan and test strategy
- Unit test criteria and code review records
- Integration and system test protocols and reports
- SOUP and third-party library verification
- Automated regression suites for CI/CD pipelines
- Unresolved anomaly list with risk justification
Design and clinical validation
- Usability engineering and summative validation (IEC 62366-1)
- Health software product validation (IEC 82304-1)
- Analytical validation: sensitivity, specificity, AUC, reproducibility
- Clinical performance and clinical evaluation support
- Standalone and reader studies for AI/ML imaging
Cybersecurity and non-functional testing
- Penetration testing and vulnerability scanning (IEC 81001-5-1)
- SBOM and SOUP vulnerability monitoring
- Performance, load and interoperability testing
- Platform and OS compatibility for mobile and cloud SaMD
- Test evidence formatted for FDA and notified body review
Traceability that survives an audit
Every requirement, risk control and test is linked in one traceability matrix: user need → system requirement → software requirement → architecture item → risk control → verification test → validation result. Reviewers can follow any line in both directions, and every change triggers an impact analysis rather than a re-write of the file.
AI/ML model validation
For machine learning SaMD we document training, tuning and test dataset separation, reference standard definition, subgroup and bias analysis, multi-site performance, and the verification protocol your PCCP will use for future model updates.
IEC 62304 Documentation for FDA, EU MDR and CDSCO Submissions
One IEC 62304 documentation set can support FDA, EU MDR and CDSCO submissions. The FDA’s Content of Premarket Submissions for Device Software Functions guidance (2023) asks for Basic or Enhanced documentation depending on risk. EU MDR Annex I §17.2 requires software to follow a state-of-the-art lifecycle with risk management, information security, verification and validation. CDSCO requires the same evidence in the device master file.
| Document | FDA Basic | FDA Enhanced | EU MDR technical documentation | CDSCO (India) |
|---|---|---|---|---|
| Documentation level evaluation / software description | ✓ | ✓ | ✓ | ✓ |
| Risk management file (ISO 14971) | ✓ | ✓ | ✓ | ✓ |
| Software requirements specification | ✓ | ✓ | ✓ | ✓ |
| System and software architecture diagram | ✓ | ✓ | ✓ | ✓ |
| Software design specification | Not required | ✓ | ✓ | ✓ |
| Lifecycle evidence (IEC 62304 declaration or plans) | Declaration of conformity or summary | Plus configuration & maintenance plans | ✓ | ✓ |
| Software testing (V&V) | System test summary + traceability | Plus unit & integration test evidence | ✓ | ✓ |
| Version history and unresolved anomalies | ✓ | ✓ | ✓ | ✓ |
| Cybersecurity documentation and SBOM | ✓ | ✓ | ✓ | ✓ |
Also applies to UKCA (MHRA), TGA, Health Canada, SFDA and other IMDRF-aligned regulators. Cybersecurity content for FDA follows section 524B of the FD&C Act for cyber devices.
Our IEC 62304 Implementation Process
Whether you are a start-up writing your first line of code or a scale-up with a product already in the market, we take you from where you are to a submission-ready software file.
IEC 62304 gap assessment
We review your code repository, tools, tickets and existing documents against every applicable IEC 62304 clause and the FDA software guidance, and give you a prioritised remediation plan.
Safety classification and development plan
We determine the software safety class with a documented rationale, define software items, and write the Software Development Plan, SOUP list and configuration management plan.
Agile-compatible lifecycle set-up
We map IEC 62304 activities onto your sprints in Jira, Azure DevOps, GitHub or GitLab (following AAMI TIR45), so requirements, risks and tests are traced automatically instead of in spreadsheets.
Design documentation and software risk management
We produce the SRS, architecture, detailed design (Class C) and software hazard analysis, with every risk control linked to a requirement and a test.
Verification and validation execution
We write the V&V protocols, execute or witness testing, run usability and cybersecurity testing through our labs, and compile test reports and the traceability matrix.
Submission, release and maintenance
We compile the FDA eSTAR software section, EU MDR technical documentation and CDSCO dossier, then keep the file current through releases, patches and AI/ML model updates.
IEC 62304 Edition 2: What Is Changing for SaMD?
IEC 62304 Edition 2 is being developed to replace the 2006 standard and its 2015 amendment. Drafts replace the three safety classes (A, B, C) with two process rigor levels, extend the scope to all health software, and add explicit expectations for AI/ML and cybersecurity. Publication has been delayed several times. Until it is published and recognised by FDA and the EU, IEC 62304:2006+A1:2015 remains the version your submissions are assessed against.
- Process rigor levels: Classes A/B/C replaced by process rigor levels; today's Class B software is expected to need the higher rigor level
- Broader scope: Scope broadened from medical device software to health software
- Security and AI/ML: Stronger links to cybersecurity (IEC 81001-5-1) and AI/ML development practices
How we prepare you
We build your lifecycle to the current edition, with the extra rigor that Edition 2 drafts point towards, so moving to the new edition does not mean rewriting your Design History File. Regulators are expected to allow a transition period after publication.
IEC 62304 FAQ
Is IEC 62304 mandatory for Software as a Medical Device?
IEC 62304 is not written into law, but in practice it is required. The FDA recognises it as a consensus standard and expects lifecycle evidence in every software submission. EU MDR Annex I §17.2 requires state-of-the-art software lifecycle processes, which notified bodies assess against EN 62304. CDSCO, MHRA, TGA and Health Canada expect the same. Not following IEC 62304 means proving an equivalent process, which is harder and slower.
What documents does IEC 62304 require?
Depending on the safety class: a software development plan, software requirements specification, software architecture, detailed design (Class C), unit, integration and system test records, software risk management file, SOUP list, configuration management records, problem reports, release records and a maintenance plan. All of them must be traceable to each other.
How do you determine the IEC 62304 software safety class?
Assume the software fails, then identify the worst harm that failure could contribute to after risk controls external to the software. No injury possible is Class A, non-serious injury is Class B, and serious injury or death is Class C. The rationale must be documented in the risk management file.
What is the difference between verification and validation for SaMD?
Verification confirms the software meets its specified requirements (unit, integration and system testing). Validation confirms the finished SaMD meets user needs and its intended use, through usability testing, analytical validation and clinical performance evaluation. Both are required for FDA clearance and CE marking.
What is SOUP in IEC 62304?
SOUP (Software of Unknown Provenance) is third-party or open-source software not developed under IEC 62304, such as operating systems, libraries and frameworks. You must list each SOUP item with its version, define its functional and performance requirements, specify the hardware and software it needs, and evaluate its published anomalies for risk.
What is the difference between IEC 62304 and IEC 82304-1?
IEC 62304 covers the software development lifecycle. IEC 82304-1 covers the whole standalone health software product: product requirements, product validation, accompanying documents and post-market activities. Standalone SaMD usually needs both, with IEC 82304-1 referencing IEC 62304 for the development process.
Can you get certified to IEC 62304?
IEC 62304 is not a management-system standard like ISO 13485, so there is no mandatory IEC 62304 certificate. Conformity is shown in your FDA submission or EU technical documentation and checked during audits. Some test bodies offer voluntary IEC 62304 assessments, which NexorTest can prepare you for.
Does IEC 62304 apply to AI/ML medical software?
Yes. AI/ML SaMD follows IEC 62304 for the software around the model, while the model itself needs additional evidence: dataset management, training and test separation, bias analysis and performance validation. For FDA, algorithm changes after clearance are managed through a Predetermined Change Control Plan (PCCP).
Ready to Get a Free IEC 62304 Gap Assessment?
Our specialists review your code repository, tools, tickets and existing documents against every applicable IEC 62304 clause and the FDA software guidance, then give you a prioritised remediation plan for FDA, EU MDR and CDSCO submissions.