IEC 62304 compliance and requirements for device software that survives regulatory review.

What it is

What is IEC 62304 and what is it used for?

IEC 62304 is the international standard for the life cycle of medical device software. It covers the development and the maintenance of software that is a medical device in its own right or that runs inside one, and it gives manufacturers, reviewers and regulators a shared framework for how that software should be engineered. It deliberately stops short of validating and releasing the finished device, which stays with the manufacturer's design controls.

In practice the standard answers a reviewer's first question about any device software: how do you know it does what you claim, and how do you keep it that way after every change? It asks for a planned process, risk-based rigour through safety classes, traceable requirements and tests, controlled configurations and a disciplined way of handling problems found in the field.

Current edition. IEC 62304:2006 with Amendment 1:2015, published by IEC as the consolidated edition 1.1 in June 2015. ISO's systematic review confirmed the standard in August 2023. IEC's medical software maintenance team is drafting a second edition; no publication date has been set on IEC's own site, so edition 1.1 is the one to build to today, and we track the draft for our clients.

Who it is for

Who needs IEC 62304 compliance?

Any organisation whose software contributes to a medical device's intended use needs a life cycle that stands up to review, whether it writes firmware for an infusion pump, a mobile app that interprets patient data or an algorithm sold as a stand-alone product. Organisations come to Sterling for IEC 62304 from four directions:

• A regulator or notified body has asked for the software file. A technical documentation review or a premarket submission has exposed gaps in requirements, architecture, verification or traceability, and the questions need answers backed by records.
• A device customer requires it of its software supplier. Manufacturers flow the life cycle down to contract developers, and a supplier without a defined process loses the tender or the renewal.
• You are launching software as a medical device. A digital health start-up moving from wellness features to a diagnostic or therapeutic claim needs a process built before the first regulated release, not reconstructed afterwards.
• A group company or acquirer wants one way of working. Several product teams follow different practices, and the parent needs a common process that its ISO 13485 system and its auditors can rely on.

Requirements

What are the main IEC 62304 requirements?

IEC 62304 is organised as a set of processes, each with activities and tasks whose depth depends on the software's safety class, A, B or C. The higher the class, the more design detail and verification the standard expects. The list below maps the processes in plain language; your software is checked against the edition itself during the engagement.

• Clause 4 General requirements: work within a quality management system, apply risk management to the software and assign a safety class that sets the rigour of everything that follows.
• Clause 5 Software development process: plan the work, then analyse requirements, design the architecture and the detail, implement and verify units, integrate and test, test the software system and release it under control.
• Clause 6 Software maintenance process: plan how released software is changed, analyse each problem and modification request, and implement changes with the same discipline as new development.
• Clause 7 Software risk management process: identify how software could contribute to hazardous situations, define and verify risk control measures, and reassess risk whenever the software changes.
• Clause 8 Software configuration management process: identify every configuration item, including third-party components, control changes and keep a record of what went into each release.
• Clause 9 Software problem resolution process: record, investigate and resolve problems, check for trends and confirm that each fix works without creating new issues.

Compliance route

How do you demonstrate IEC 62304 compliance?

There is no audit that ends in an IEC 62304 certificate. You establish the process, apply it to each product and show the result in the device's technical documentation. The notified body or regulator reviewing the device then judges whether the evidence supports conformity.

1. 01
   Define the products, teams and markets in scope.Confirm which software items are regulated, who develops them, which suppliers contribute code and which regulators will review the device.
2. 02
   Gap analysis: compare current practice with the standard.Plans, requirements, architecture, tests, configuration control and problem handling are reviewed against each process for the relevant safety class; what works is kept, and actions, owners and dates are agreed.
3. 03
   Set up the software process and classify the software.Procedures and templates fitted to your development method and tools, the safety classification documented, and the links to design controls and risk management made explicit.
4. 04
   Apply it to the product and audit the result.The current release is brought into line, traceability is completed, and an internal audit tests the software file and the process before any reviewer sees them.
5. 05
   Submit, answer questions and keep the file current.The software documentation goes into the technical file or submission, reviewer questions are answered with records, and maintenance and problem resolution keep it true after each release.

Check the route before you sign. IEC 62304 conformity is judged by notified bodies and regulators within device conformity assessment, and your ISO 13485 certification body will look at the software processes as part of your quality system. Confirm a notified body's designation for your device type in the official EU database, and treat any offer of a quick "IEC 62304 certificate" as something no reviewer asked for. How to choose a credible IEC 62304 provider · The certification buyer's checklist

Cost

How much does IEC 62304 compliance cost?

The effort depends far more on the software than on the size of the company. A small team with one class A app and good habits needs a different scope from a manufacturer with class C firmware, legacy code and several suppliers. We price the work after the gap analysis scope is clear, and nothing is added later.

Timeline

How long does IEC 62304 compliance take?

As an estimate, most teams need four to nine months to set up the process and bring one product's software file into line. A new product built to the process from its first sprint moves fastest; released class C software with thin records takes longest, because verification and traceability have to be reconstructed from real work.

Share your submission date at the start and we will say what is achievable and which decisions are needed early.

Your engagement

What your IEC 62304 engagement includes

Every engagement runs on Sterling OS™. You choose the level of support: with Design™ we guide your team while your developers write and apply the process; with Drive™ Sterling carries the work and your team reviews and approves. After submission, Sustain™ keeps the software file current through each release, and Automate™ is Effivity, which runs the process day to day. Sterling does not certify; the notified body or regulator assesses the device and its documentation.

• Scope, gap analysis and plan

  Products, safety classes, gaps and actions agreed with owners and dates before work starts.

• Software process and templates

  Development, maintenance, configuration and problem resolution procedures fitted to your method and tools.

• Effivity ISO & GRC software

  The software file, risks, changes and problems in one workspace, included with the engagement at no additional cost.

• Training for developers and testers

  Internal auditor training, as applicable to your standard, and preferential Sterling Academy access, including complimentary awareness training for your people as part of the engagement.

• Internal audit of the software file

  An independent look at the process and the records, with findings closed before submission.

• Submission and review support

  Help assembling the software documentation and answering reviewer questions with evidence.

Conformity assessment decisions remain with the notified body or regulator.

Often combined with

Standards organisations pair with IEC 62304

• 21 CFR Part 11 / EU Annex 1121 CFR Part 11 and Annex 11 compliance for GxP systems: requirements, validation, audit trails and e-signatures, with evidence ready for FDA and EU inspectors.
• ADHICS (Abu Dhabi)ADHICS compliance consulting for DoH-regulated healthcare entities in Abu Dhabi: patient information, systems and devices protected, with audit-ready evidence.
• CAP accreditationCAP accreditation readiness for laboratories: checklist gap analysis, method records, self-inspection and peer inspection support.
• EU IVDR 2017/746EU IVDR compliance consulting for IVD manufacturers: performance evidence, QMS, traceability and post-market follow-up prepared for your notified body.
• EU MDR 2017/745EU MDR compliance consulting for CE marking: QMS, technical documentation, traceability and post-market surveillance prepared for your notified body.
• FDA QMSR (21 CFR 820)FDA QMSR compliance consulting for device makers selling in the US: a quality management system ready for FDA inspection, wherever you manufacture.