What is IEC 62304?
IEC 62304 was published by the International Electrotechnical Commission in 2006 and amended in 2015 (the consolidated edition IEC 62304:2006+AMD1:2015 is current). The standard does not prescribe a particular development model — you can work agile or waterfall — but it requires that defined processes, activities and tasks be planned, performed and documented.
The standard covers five main processes: software development (clause 5 — from planning through requirements, architecture, implementation, integration and system testing to release), maintenance (clause 6), software risk management (clause 7, tied to ISO 14971), configuration management (clause 8) and problem resolution (clause 9). It presupposes that the organisation operates within a quality management system (usually ISO 13485).
A key concept is SOUP (Software of Unknown Provenance) — off-the-shelf software not developed under IEC 62304: libraries, frameworks, operating systems, open source components. The standard requires specifying requirements for every SOUP component, tracking its version in configuration management, evaluating the known anomalies published by its supplier, and analysing the safety consequences of its failure.
Safety classes A, B and C
The heart of the standard is safety classification, which determines the scope of required activities and documentation. A class is assigned to every software system — and, after decomposition, to its software items — based on the possible consequences of failure, taking into account risk control measures external to the software.
Since Amd 1:2015 the classification also considers the probability that a hazardous situation leads to harm. A higher class means more obligations: class C requires, among other things, a detailed design of every unit and a justified architectural segregation of critical items; class B the full path of requirements, architecture and testing; and class A the shortest path with planning, requirements, release, configuration management and problem resolution. The amendment also introduced a path for legacy software (clause 4.4), allowing conformity of existing software to be demonstrated without recreating full development documentation.
- Class A — a software failure cannot cause injury or damage to health.
- Class B — a failure could contribute to non-serious injury.
- Class C — a failure could contribute to death or serious injury.
Who is it for?
The standard applies to anyone developing software that is a medical device or part of one: manufacturers of devices with embedded software (for example infusion pumps, ventilators, imaging diagnostics), companies building standalone medical software (SaMD — diagnostic apps, decision support algorithms, therapy planning software), and manufacturers of in vitro diagnostic software.
In practice, IEC 62304 conformity is expected by authorities and assessment bodies worldwide: in the European Union the standard is the recognised state of the art for demonstrating software compliance with MDR and IVDR requirements (its European version EN 62304 was harmonised under the earlier medical device directives), and the US FDA lists it as a recognized consensus standard and accepts a declaration of conformity to it in premarket submissions. The standard works alongside ISO 13485 (QMS), ISO 14971 (risk management), IEC 62366-1 (usability engineering) and IEC 82304-1 (health software products).
How is conformity demonstrated?
IEC 62304 is not a management system standard like ISO 27001 — there is no separate accredited “IEC 62304 certificate” analogous to management system certification. Conformity is demonstrated through software life cycle documentation that becomes part of the device’s technical documentation: a notified body assesses it during MDR/IVDR conformity assessment (or the regulator of another market), and ISO 13485 auditors verify that the software processes operate within the quality system. Independent labs and bodies (for example TÜV) offer voluntary assessments and conformity reports against the standard, which ease discussions with the notified body.
A typical evidence package includes: the software development plan, the safety classification with rationale, the requirements specification, architecture documentation, verification and test plans and reports, the SOUP list with versions and anomaly evaluation, configuration management and release records, the problem report register, and a traceability matrix linking requirements, risks and tests. Reviewers usually start with classification and traceability — that is where it shows fastest whether the process is real.
How long does it take and what does it cost?
The effort depends primarily on the safety class and the maturity of existing engineering practices. A team already working with version control, code reviews, continuous integration and automated tests has most of the mechanics in place — what remains is formalising them: the development plan, classification, traceability, the SOUP list and verification records. Setting up the processes for a new project typically takes 2 to 6 months; back-filling documentation for an existing product (or the legacy path) can take longer.
The main costs are the engineering and quality team’s time and — for devices assessed by a notified body — the technical documentation review within conformity assessment. Good practice is to wire the standard’s requirements into everyday tooling (the ticketing system, CI/CD, SBOM generation) so evidence is produced automatically as you work rather than reconstructed before an audit — this is where automation pays off most.
How does Guardiso help?
Guardiso turns the IEC 62304 requirements into a step-by-step programme — from safety classification to evidence generated by the team’s daily work.
- All 53 requirements of the standard (clauses 4-9) seeded automatically when you enable it — with implementation statuses and assigned owners.
- A requirement structure mirroring the standard’s processes: development, maintenance, risk management, configuration management and problem resolution.
- A risk register supporting the traceability chain: hazardous situation → risk control → requirement → verification.
- Evidence collected in one place — plans, test reports, release records and SOUP lists — ready for the technical documentation review.
- Recurring tasks that guard maintenance duties: SOUP anomaly reviews, vulnerability monitoring, problem register reviews.
- Policies and procedures (development plan, change control procedure, problem resolution procedure) generated from templates, with versioning and approval.
- Cross-mapping to ISO 13485, ISO 27001 and related frameworks — quality and security processes are done once, in one system.