Home › IEC 62304 Consultants

IEC 62304 Consultants for Medical Device and SaMD Software

IEC 62304 consultants at I3CGLOBAL help medical device manufacturers and SaMD developers navigate the complexities of IEC 62304 standard compliance across all three software safety classes — Class A, Class B, and Class C.

Our consultants work directly with your software development team and process owners to explain each clause of IEC 62304:2006+AMD1:2015, interpret Certification Body (CB) and Notified Body (NB) expectations, and build a compliant software lifecycle from development planning through release and post-market maintenance. We support clients worldwide, mainly in the USA, UK and India.

Request IEC 62304 Proposal Talk to an IEC 62304 Consultant

The basics

What Do IEC 62304 Consultants Do?

IEC 62304 consultants help medical device and SaMD teams build a software lifecycle that meets the standard. They classify the software, assess gaps, provide procedures, guide risk management and review the evidence for audits and submissions. Your developers remain responsible for the technical work.

Whether you are preparing for an FDA 510(k) submission, EU MDR CE marking, or IVDR technical documentation, our team of consultants bridges the gap between your software engineering team and regulatory requirements by providing ready-to-use procedure templates, SOP drafts, risk management guidance aligned with ISO 14971, and hands-on review of every deliverable from your end.

We do not just hand over documents; we sit with your process owners, walk them through all 16 IEC 62304 procedures, and ensure they understand what auditors and reviewers expect to see. Our engagement model clearly defines what I3CGLOBAL delivers as your IEC 62304 compliance consultant and what your software developers own as the technical execution team, so there are no gaps, no overlaps, and no surprises during a CB or NB audit.

Prefer to listen? This audio overview runs for about 6 minutes.

Roles

Key Roles of IEC 62304 Consultants

IEC 62304 consultants work best when roles are clear from the start. Five practices keep consultants and developers aligned: clear communication, a shared understanding of goals, defined responsibilities, regular meetings and documentation review. Together, they help your team keep the knowledge after the engagement ends.

IEC 62304 consultants collaboration with software developers — Five pillars of effective collaboration.

Our services

What Does IEC 62304 Consulting Include?

Medical device software compliance consulting connects your software engineering work with regulatory expectations. The scope of our IEC 62304 implementation services depends on your software safety class, current development process and target market. Your software team remains responsible for the technical work, while our consultants guide the process and review the evidence.

IEC 62304 gap assessment

We compare your current software lifecycle with the IEC 62304 clauses that apply to your safety class, then give you a clear list of gaps to close.

Software safety classification

We help you document the reasoning for Class A, B or C, based on the harm that could result from a software failure.

Procedures and templates

We provide ready-to-use procedure templates and SOP drafts for development, maintenance, configuration management and problem resolution.

Risk management guidance

We support a software risk process aligned with ISO 14971, including hazardous situations, risk controls and verification of those controls.

Deliverable review

We review plans, requirements, architecture, test records and release documents for completeness and regulatory fit.

Process owner training

We walk process owners through all 16 procedures, so they can explain their work during an audit or review.

SOUP and third-party software

We advise on identifying SOUP items, specifying their requirements and documenting why they are acceptable for use.

Audit and submission readiness

We help prepare your documentation for Certification Body and Notified Body audits and for FDA 510(k), EU MDR or IVDR reviews.

Post-market maintenance

We help you set up maintenance, feedback, change analysis and problem resolution processes for released software.

Safety classes

IEC 62304 Software Classification

Software failures in medical devices can have direct consequences for patients. A miscalculated dose, a missed alarm, an incorrect reading. This is addressed in IEC 62304, which requires manufacturers to classify their software based on what could realistically go wrong. The greater the potential danger, the more stringent the development and testing standards.

This risk-based approach means that a basic administrative interface on a device is held to a different standard than the algorithm managing drug distribution.

Knowing your software’s class is the starting point for everything that follows: your development lifecycle, testing requirements and regulatory submission.

IEC 62304 standard establishes a cohesive framework for designing and testing software for medical devices through defined processes, activities, and tasks, ensuring safe usage in patients. The standard categorizes software into three safety classes according to the risk to the patient from a possible software failure

Class A

No injury or damage to health is possible

Class B

Non-serious injury is possible

Class C

Death or serious injury is possible

How does the safety class affect your work?

The class decides how many clauses apply. Class A has the smallest set of activities, while Class C adds requirements such as detailed design and additional unit verification. The statement of work on this page shows which class each procedure applies to.

Classification should be recorded and reviewed as your software changes. A new function, a change in intended use or new risk information can change the class, so it should be linked to your risk management file.

Clauses

What Do Clauses 5 to 9 of IEC 62304 Require?

Clauses 5 to 9 of IEC 62304 set the process requirements for medical device software. All five clauses apply to every safety class, but the number of activities inside each clause grows from Class A to Class C: Class A skips architectural and detailed design (5.3, 5.4), integration testing (5.6) and most unit verification (5.5.2 to 5.5.5), and applies only 7.4.1 in the risk management clause.

IEC 62304 software lifecycle requirements

Clause	Description	Applies to
Clause 5	Software development and planning process including requirements analysis, design, testing, and release processes.	A, B, C (5.3, 5.4 and 5.6 only B and C)
Clause 6	Software maintenance plan, including the implementation of a maintenance plan and issue analysis procedures.	A, B, C (6.2.3 only B and C)
Clause 7	Software risk management and identification of hazardous situations, risk control, verification, and risk management procedures following the ISO 14971 standard.	A, B, C (Class A: 7.4.1 only)
Clause 8	Software configuration management including change control and configuration status tracking.	A, B, C
Clause 9	Software problem resolution investigating and reporting on problems, change control processes, trend analysis, and resolution testing and verification.	A, B, C

Regulators

How Does IEC 62304 Relate to FDA, EU MDR and IVDR?

IEC 62304 is a software lifecycle standard, not a law. Regulators expect a controlled development process, and many manufacturers use this standard to show one. The way you use it should match your market and submission.

Market	Role of IEC 62304	What to prepare
United States	FDA recognized consensus standard. Use is generally voluntary	Declaration or evidence supporting your software documentation for the 510(k)
European Union (MDR)	Supports Annex I Section 17.2 on software life cycle, risk management, verification and validation	Lifecycle records in the technical documentation
European Union (IVDR)	Supports Annex I Section 16.2 on software for in vitro diagnostic devices	Lifecycle records in the technical documentation

The FDA encourages the use of recognized consensus standards to show compliance. IEC 62304 is recognized by the FDA for this purpose. Employing 62304 can facilitate the 510(k) submission process as it offers a comprehensive framework for software development, risk management, and documentation. FDA lists Edition 1.1, the consolidated version of the 2006 edition and Amendment 1:2015, under recognition number 13-79.

For US submissions, also review the FDA guidance on content of premarket submissions for device software functions. For wider support, see our software device 510(k) and software CE marking pages.

IEC 62304 safety classes are separate from the EU MDR device class. The MDR class (I, IIa, IIb or III) for software comes from Annex VIII Rule 11 and decides the conformity assessment route; software whose output can lead to death or irreversible harm is Class III. Both classifications are recorded in the technical documentation.

IEC 62304 Edition 2 is still a draft. As of November 2026 the IEC working group was preparing a second committee draft (CD2), with publication forecast for 2028. The title changes to “Health software – software life cycle processes”, and security risk management and usability engineering are added as explicit requirements. IEC 62304:2006 with Amendment 1:2015 (Edition 1.1) remains the version to apply and the version recognised by the FDA.

Benefits

Why Follow IEC 62304 If No Certificate Exists?

There is no IEC 62304 certificate. Conformity is shown through the life cycle records themselves, which is why the standard matters to reviewers in three specific ways.

No certificate, but an expected framework

IEC 62304 sets requirements for the software life cycle but has no certification scheme. Notified Bodies and the FDA instead expect to see the planning, requirements, verification, release and maintenance records that the standard defines, matched to your safety class.

Showing compliance

Conformity is demonstrated by a declaration in the technical documentation or 510(k) and by records that trace each applicable clause to a plan, an activity and a result. Gaps are most often found in traceability and in unit and integration verification evidence.

Evidence for stakeholders

The same records give customers, auditors and regulators an auditable history of how the software was built and maintained, including SOUP justification and problem resolution, which supports market access and post-market change control.

IEC 62304 consultants such as I3CGLOBAL help developers prepare, implement and keep these procedures under review, so the evidence stays complete as the software changes.

Statement of work

Who Does What: Consultant vs Software Developer

This table shows the responsibility split across the 16 procedures in I3CGLOBAL’s IEC 62304 implementation framework (the standard’s Clauses 5 to 9 broken into working procedures), so your team knows what I3CGLOBAL delivers and what your developers own.

IEC 62304 – Statement of Work

IEC 62304:2006+AMD1:2015 — Statement of Work

All 16 procedures · Responsibility split: I3CGLOBAL (Consultant) vs. Software Developer

I3CGLOBAL

Developer

Shared

ⓘ

Common I3CGLOBAL responsibility across all 16 procedures Interact with process owners to explain applicable IEC 62304 clauses, interpret CB / NB (Certification Body / Notified Body) requirements, and ensure the team understands what each clause demands in the context of their software safety class and regulatory submission (FDA 510k / EU MDR / IVDR).

No	Cl#	Procedure	I3CGLOBAL (Consultant)	Software Developer	Lead
Clause 5 — Software Lifecycle (Development)
1	5.1	Software Development Planning Class A+B+C	Provide SDP template and guidance Define documentation structure per safety class Review and approve the final SDP Advise on Class C-specific clauses (5.1.4–5.1.11)	Author the Software Development Plan Define lifecycle model and project milestones Identify tools, languages, and SOUP dependencies Maintain and update SDP throughout the project	Shared
2	5.2	Software Requirements Analysis Class A+B+C	Provide SRS template aligned with IEC 62304 Facilitate requirements traceability matrix setup Review SRS for regulatory completeness	Elicit and document software system requirements Map system-level to software requirements Maintain requirements traceability	Shared
3	5.3	Software Architectural Design Class B+C	Provide architectural design document template Review architecture for IEC 62304 compliance Advise on SOUP identification and interface spec	Design and document software architecture Define software item interfaces and SOUP items Identify risk controls within architecture Verify architecture against requirements	Developer
4	5.4	Software Detailed Design Class B+C	Provide detailed design document template Review detailed design documentation	Refine architecture into unit-level design Define unit interfaces and algorithms Produce class/data flow diagrams (Class C: 5.4.2–5.4.4)	Developer
5	5.5	Verification of Software Unit Class A+B+C	Define unit verification strategy Review unit test reports for completeness	Develop and execute unit test cases Define unit verification and acceptance criteria Perform code reviews and static analysis Document and maintain unit test records Apply coverage criteria for Class B/C (5.5.2–5.5.5)	Developer
6	5.6	Verification & Testing of Integrated Software Class B+C	Provide integration test plan template Review integration test results	Define and execute integration test plan Verify software item interfaces and data flows Document integration test results and anomalies	Developer
7	5.7.1	Software System Testing Class A+B+C	Define system test strategy and traceability to requirements Review system test protocol and final report	Develop and execute system test cases covering all requirements Document test results and open defects	Shared
8	5.7.3	Retest After Changes Class A+B+C	Advise on regression test scope and impact assessment criteria Review retest results and approve closure	Retest software system whenever changes occur during testing Document retest scope, results, and pass/fail evidence Update traceability matrix to reflect retested requirements	Developer
9	5.8	Software Release Class A+B+C	Define release checklist and record template Verify all lifecycle activities are complete pre-release	Compile release documentation and known anomaly list Confirm all test evidence is captured Issue release authorization Tag and archive the release build in configuration management	Shared
Clause 6 — Software Maintenance
10	6.1	Establishing Software Maintenance Plan Class A+B+C	Provide maintenance plan template Review maintenance plan for regulatory alignment	Establish and document the software maintenance plan Define change evaluation and implementation process	Shared
11	6.2.1	Feedback Class A+B+C	Define feedback monitoring SOP and escalation criteria Review feedback log and advise on regulatory significance	Monitor and record feedback from users and internal sources on released software Categorise and log feedback for analysis and follow-up	Shared
12	6.2.3 / 6.2.4 / 6.2.5	Analysis, Approval & Communication of Changes Class A+B+C	Define change analysis and approval procedure Advise on regulatory reporting obligations for changes Review change impact assessments	Analyse and document change requests and impact Obtain approvals per defined change control process Communicate approved changes to users and regulators	Shared
13	6.5	Implementation of Approved Modifications Class A+B+C	Ensure modifications follow the defined development process Review updated documentation post-modification	Implement approved modifications using development or maintenance lifecycle processes Update all affected documentation and test records	Developer
Clause 7 — Risk Management
14	7	Risk Management Process Class A+B+C	Lead risk management process per ISO 14971 Provide risk analysis, evaluation, and control SOP templates Review risk file for completeness and regulatory adequacy Advise on software-specific hazardous situations	Identify software failure modes and hazardous situations Implement risk control measures in software design Verify effectiveness of risk controls through testing Maintain and update the risk management file	Shared
Clause 8 — Configuration Management
15	8	Configuration Management Class A+B+C	Define configuration management procedure and document templates Verify configuration Item List and the corresponding records Audit configuration records for compliance	Implement version control for all software items and documents Establish version control naming conventions and baselines Maintain configuration status accounting records Control changes through the defined change control process	Shared
Clause 9 — Problem Resolution
16	9	Software Problem Resolution Class A+B+C	Provide guidance on applicable regulatory reporting and vigilance requirements. Review problem reports and trend analysis outputs Advise on reportable problem thresholds	Record, investigate, and analyse all software problems Implement and verify problem fixes Track trends and escalate recurring issues Identifying reportable problem thresholds by evaluating software-related complaints, incidents, malfunctions, and safety concerns against agreed escalation criteria	Shared

Step by step

How Does an IEC 62304 Consulting Engagement Work?

A typical engagement moves from understanding your software to preparing evidence for an audit or submission. The order can change depending on how far your development has progressed.

Define scopeConfirm the software, intended use, target markets and existing quality system.
Classify the softwareDocument the safety class and the reasoning behind it.
Assess the gapsCompare current processes and records with the applicable clauses.
Agree responsibilitiesUse the statement of work to confirm what consultants and developers own.
Implement the proceduresIntroduce templates and procedures, then guide process owners through them.
Review the evidenceReview lifecycle records, test results, risk files and release documents.
Prepare for reviewCheck readiness for the audit or submission, and close any open items.

Why it matters: early involvement is usually faster and less costly than finding deficiencies during an MDR, IVDR or FDA 510(k) document review.

Work with I3CGLOBAL

Request an IEC 62304 Gap Assessment

Our IEC 62304 consultants work with your software team to build a compliant lifecycle from development planning through release and maintenance.

Gap analysis and process implementation
Procedure templates and SOP drafts
ISO 14971 aligned risk guidance
Review of every deliverable

Request your proposal

Tell us your software class and target market. You can also review our IEC 62304 implementation fee.

Request IEC 62304 Proposal Contact Us

FAQs

IEC 62304 Consulting: Frequently Asked Questions

What is medical device software?

Medical device software is software developed for use as a medical device or as part of one. This includes software as a medical device (SaMD), software in a medical device (SiMD), firmware and embedded software.

What is IEC 62304?

IEC 62304 is an international standard that defines lifecycle requirements for medical device software. It covers development, maintenance, risk management, configuration management and problem resolution.

What Types of Software are Included?

IEC 62304 applies to medical device software: software that is itself a medical device, and software that is part of a medical device, including firmware and embedded software. Tools used in design, production or quality control are generally not in its scope. They are normally validated under your quality system, for example ISO 13485.

What is the timeline for IEC 62304 implementation?

Most projects take 3 to 4 months from gap assessment to audit-ready records. The range assumes a Class B product, an existing ISO 13485 quality system and a development team that turns deliverables around within two weeks. Class C software with no prior QMS takes longer; Class A with mature processes is often faster.

How much does IEC 62304 consultancy cost?

Cost varies based on the safety class of your software and the complexity of your development processes. The documentation requirements for Class A software are less complex and less expensive. Class C projects require full traceability, architectural evaluations and extensive verification, and take much more time. Engaging consultants early is usually faster and less costly than finding deficiencies during MDR, IVDR or FDA 510(k) document review.

Is IEC 62304 mandatory for an FDA 510(k) submission?

No. IEC 62304 is a recognized consensus standard, and using it is generally voluntary. It can support your software documentation for a 510(k) submission, but you must still meet applicable FDA requirements for your device software.

I am a software developer. Why does IEC 62304 apply to me?

If your software is an app that functions as a medical device, or runs on or controls one, regulators treat it as part of that device. Your development process must be controlled and documented, and manufacturers commonly use IEC 62304 to show this.

Does IEC 62304 apply to off-the-shelf software in my product?

Yes, in part. Even if you use third-party or open-source components, you still need to determine whether they meet the requirements or document why they are acceptable as they are. You cannot assume that a library is covered.

Can I use Agile or iterative development with IEC 62304?

Yes. A waterfall model is not required. Requirements, architecture, testing and change control must still happen, but they can take place inside sprints. Make sure your documentation keeps pace with your development.

What happens if my software has a bug after the device is on the market?

That triggers your problem resolution process under IEC 62304 Clause 9. Log it, evaluate whether it is a safety issue, fix and verify it and, depending on severity, potentially report it to the regulatory authority. A well-maintained issue log makes this significantly easier.

What does SaMD IEC 62304 consulting cover?

SaMD IEC 62304 consulting applies the standard to software that is itself the medical device. It covers safety classification, development and maintenance procedures, SOUP, ISO 14971 risk management, and the lifecycle records needed for your audit or submission.

What is an IEC 62304 gap assessment?

An IEC 62304 gap assessment compares your current software lifecycle and records with the clauses that apply to your safety class. You receive a clear list of gaps to close before an audit or submission.

What is SOUP?

SOUP stands for “software of unknown provenance”. It means existing software, such as a third-party or open-source library, that was not developed under a process you can fully document. You must identify it, specify its requirements and manage its risks.

How do I determine my software safety class?

Assess the harm that could result if the software fails. Class A means no injury or damage to health is possible, Class B means non-serious injury is possible, and Class C means death or serious injury is possible. Record your reasoning and link it to your risk management file.

Is there an IEC 62304 certificate?

The standard itself does not require a certificate. You show compliance through your documented processes and records, which can be reviewed during audits and regulatory submissions.

Is IEC 62304 Edition 2 published?

No. As of November 2026 Edition 2 is a committee draft and the IEC forecasts publication in 2028. Continue to apply IEC 62304:2006 with Amendment 1:2015, which is the edition recognised by the FDA and used for MDR and IVDR technical documentation.

Does IEC 62304 decide my MDR classification?

No. IEC 62304 safety classes A, B and C describe the software’s own risk and decide which life cycle activities apply. The MDR class (I, IIa, IIb or III) comes from Annex VIII Rule 11 and decides the conformity assessment route. The two classifications are recorded separately and both go in the technical documentation.