What Is IEC 62304? A Practical Guide to the Medical Device Software Lifecycle Standard

IEC 62304 is the international standard governing the lifecycle of software embedded in medical devices and standalone medical device software. Published jointly by IEC and ISO, its full title is Medical device software — Software life cycle processes. It defines what you must do—plan, develop, maintain, and risk-manage software—and at what level of rigor, depending on how dangerous a software failure could be for a patient.

If your organization is developing software that is part of a medical device subject to FDA clearance, CE marking under MDR 2017/745, or equivalent regulatory approval in other jurisdictions, IEC 62304 is effectively mandatory. The FDA recognizes it as a consensus standard. Notified bodies across the EU expect conformance. Auditors use it as the checklist.

This guide explains what the standard actually requires, where teams struggle, and what requirements tooling needs to provide in order to make compliance operationally sustainable—not just achievable on paper for an audit.

The Core Concept: Software Safety Classes

IEC 62304 organizes everything around a single foundational question: what is the worst credible harm if this software fails, and can that harm be prevented by independent means outside the software itself?

The answer determines the software’s safety class, and the safety class drives nearly all downstream lifecycle obligations.

Class A — No injury or damage to health is possible. A failure of this software unit cannot contribute to patient harm, either directly or by causing another part of the system to behave dangerously. Example: a configuration screen that only affects display preferences unconnected to any clinical function.

Class B — Injury is possible but not serious. A software failure could cause harm, but that harm is not life-threatening and is not permanently debilitating. Example: a dosing calculation aid with independent clinical cross-checks that would catch an error before it reaches a patient.

Class C — Death or serious injury is possible. A software failure could directly cause or contribute to life-threatening harm, and no independent safeguard external to the software prevents that outcome. Example: closed-loop insulin delivery, radiation therapy dose delivery, ventilator control logic.

These classes are assigned at the software item level—the units, components, and subsystems that make up the overall system—not just once at the product level. A Class C device can contain Class A and Class B software items. The classification must be documented with rationale, and it directly affects:

  • Whether you need detailed software requirements (required for B and C)
  • Whether you need documented software architecture (required for B and C)
  • The granularity of unit testing and integration testing required
  • What change management documentation is mandatory
  • What you must verify before release

Class A has the lightest burden. Class C has the full burden. There is no shortcut that lets you argue a Class C item down to Class B without changing the actual system design—specifically, by adding an independent hardware or software safeguard that can catch and handle the failure.

Lifecycle Requirements: What the Standard Actually Mandates

IEC 62304 is a process standard, not a technical standard. It does not prescribe algorithms, architectures, or languages. It prescribes a lifecycle—a sequence of processes that must be planned, executed, and documented.

Software Development Planning

Before development begins, you must produce a software development plan. This plan must describe:

  • The lifecycle model you are using (agile, iterative, waterfall—all are permitted)
  • The standards, methods, and tools you will use
  • The activities and tasks to be performed
  • The deliverables and their relationship to the overall development process

The plan is a living document. It must be updated when circumstances change. Auditors will ask for it and will check whether your actual practice matches what the plan describes.

Software Requirements

For Class B and C software items, you must document software requirements that are:

  • Derived from system requirements (the upstream source)
  • Complete enough to be the basis for design and verification
  • Inclusive of all safety-related requirements identified through risk analysis

The standard is explicit that risk control measures implemented in software must appear as software requirements. If your risk management process (typically governed by ISO 14971) identifies a software-based safeguard, that safeguard must be traceable to a specific software requirement. This is where requirements management and risk management converge—and where siloed tooling creates serious compliance gaps.

Software Architecture and Detailed Design

Class B and C software items require documented architecture showing how software items are decomposed and how they interact. The architecture must identify which items are safety-related. Class C adds the requirement that the architecture segregates software items by safety class, so that lower-class items cannot compromise higher-class items.

Unit Implementation and Verification

Each software unit must be implemented and verified. Verification at the unit level means demonstrating that the unit meets its detailed design and, by implication, the requirements it implements. For Class C, the standard requires specific testing strategies: boundary testing, equivalence partitioning, and structural coverage requirements. For Class B, the rigor is somewhat lighter but still requires documented verification.

Integration and System Testing

Software units must be integrated in a planned order, with integration testing at each step. System testing verifies that the complete software meets its software requirements. Both must be documented with test cases, test procedures, and test results that are traceable to the requirements they verify.

Maintenance and Change Management

IEC 62304 does not stop at release. Section 6 governs software maintenance, and it requires that every change—bug fix, enhancement, configuration update—goes through a documented process that includes:

  • Problem analysis and classification
  • Change request evaluation
  • Impact analysis (what else could this change affect?)
  • Verification that the change was implemented correctly
  • Regression analysis

This is where many organizations struggle. The discipline applied during initial development degrades over time unless the tooling actively enforces the process. Change impact analysis is only meaningful if your traceability links are current, correct, and complete.

Traceability: The Structural Backbone of IEC 62304 Compliance

Traceability in IEC 62304 is not optional documentation. It is the mechanism by which regulators verify that your software actually does what you said it would do, that you tested what you said you would test, and that you managed changes safely.

The standard requires bidirectional traceability across multiple artifact types:

  • System requirements → Software requirements: Every software requirement must trace to the system-level need that justified it. Every system requirement must be addressed by at least one software requirement.
  • Software requirements → Software architecture: Requirements must trace to the architectural elements that implement them.
  • Software requirements → Software tests: Every software requirement must be verified by at least one test. Every test must trace to the requirement it verifies.
  • Risk controls → Software requirements: Risk control measures implemented in software must trace to specific requirements.
  • Software changes → Impact analysis → Affected requirements and tests: When a change occurs, you must be able to identify every affected requirement and every test that must be re-executed.

This is a graph, not a list. The relationships run in multiple directions. They span multiple document types. They must remain consistent as the product evolves over years and multiple releases.

The fundamental problem with spreadsheets and Word-based requirements documents is that they model this graph as disconnected tables. Maintaining consistency manually is an exercise in sustained human vigilance—which is reliable during initial development, unreliable over time, and nearly impossible to audit confidently. Gaps compound silently until an auditor or a post-market adverse event surfaces them.

What Modern Tooling Needs to Provide

IEC 62304 does not mandate specific tools. It mandates outcomes: maintained traceability, documented rationale, controlled changes, and auditable records. Your tools either make those outcomes easier or harder to achieve.

Requirements tooling built for IEC 62304 workflows needs to support:

Native bidirectional traceability. Not links added as text fields in a spreadsheet, but first-class relationships between requirements, tests, architecture elements, and risk controls that the tool maintains, validates, and surfaces when something breaks.

Coverage analysis. The ability to ask, at any point: what requirements have no downstream test? What system requirements have no derived software requirements? What risk controls have no implementing requirement? These are compliance gaps, and you want the tool to find them, not the auditor.

Change impact propagation. When a requirement changes, the tool should surface every downstream artifact that may be affected—tests, design elements, risk assessments—so your team can make deliberate decisions about what needs to be reviewed or updated.

Audit-ready traceability reports. Regulatory submissions require traceability matrices. The tool should generate them from live data, not from a manual export process that is already out of date the moment the export runs.

Support for risk integration. Software requirements derived from ISO 14971 risk analysis need to be linkable to the risk items that generated them. Tools that treat requirements and risk as separate concerns with no structural connection create a compliance liability.

Lifecycle and configuration management. Requirements at different versions, baselines at different release points, change history with rationale—all must be maintained and retrievable.

How Modern Tools Implement IEC 62304 Workflows

Legacy requirements management platforms like IBM DOORS and Polarion were designed in an era when document-based traceability was the norm. They can be configured to support IEC 62304 workflows, and many organizations use them successfully for exactly that purpose. The tradeoff is configuration complexity: getting these tools to enforce the right structure requires significant upfront engineering and ongoing administration.

Newer entrants have built traceability as a first-class structural property rather than an add-on. Flow Engineering (flowengineering.com) is built around a graph-based model in which requirements, tests, architecture elements, and risk controls are nodes with typed, bidirectional relationships between them. This structural approach maps directly onto what IEC 62304 requires: a maintained web of relationships across artifact types that can be queried for coverage, audited for completeness, and navigated during impact analysis.

Flow Engineering’s AI-assisted capabilities are relevant to IEC 62304 work specifically because requirements derivation and gap identification—the tasks of asking “have I captured every software requirement this system requirement implies?” and “which requirements have no verification?”—are exactly the kind of coverage analysis that AI assistance can accelerate without replacing engineering judgment. The tool does not automate compliance decisions; it makes the information available to make those decisions quickly and confidently.

For teams doing iterative or agile development under IEC 62304, the ability to maintain live traceability rather than periodic snapshot exports is operationally significant. The standard permits iterative development; it requires that your process artifacts remain consistent regardless of how many iterations you have run.

Practical Starting Points

If you are beginning IEC 62304 compliance work—or auditing an existing program against the standard—here is where to focus first:

1. Classify your software items. Do not classify the product once and stop. Decompose to the item level, assign classes with documented rationale, and confirm that your architecture segregates Class C items appropriately.

2. Map your traceability gaps. Build a complete picture of what currently traces to what. Identify every broken or missing link. Prioritize gaps that affect safety-related requirements and risk controls first.

3. Align your risk management with your requirements. Pull ISO 14971 risk controls into your requirements process so that each software-implemented risk control becomes a traceable software requirement with a corresponding verification test.

4. Establish your change control baseline. Document your change control process, including impact analysis procedures. If your current process cannot answer “what tests must be re-run if this requirement changes,” fix that before the next release.

5. Evaluate your tooling against the coverage requirements. Your tool should be able to generate a requirements traceability matrix on demand from live data. If it cannot, that is a structural risk to your compliance program, not just an inconvenience.

IEC 62304 is not a compliance checkbox. It is an engineering discipline for building software that does not harm patients. The organizations that treat it as the former spend enormous energy on documentation for audits. The organizations that treat it as the latter build better software and find compliance less burdensome—because the discipline is built into their process rather than bolted on afterward.