IEC 62304

This topic is part of the SG Systems Global medical device software lifecycle, quality management & regulatory compliance glossary.

Updated December 2025 • Medical Device QMS, QMSR, ISO 14971 Risk Management, Verification & Validation (V&V), Computer System Validation (CSV), GAMP 5, 21 CFR Part 11, Annex 11, Change Control, Data Integrity, Audit Trail (GxP), V5 QMS, V5 Connect API

IEC 62304 is the global “you need a real software lifecycle” standard for medical device software. It defines what you must do (and prove you did) to develop and maintain software safely: planning, requirements, architecture, implementation, verification, maintenance, risk management, configuration management, and problem resolution. It does not tell you to use Waterfall, Agile, V-Model, or any specific toolchain. It tells you the minimum lifecycle evidence a competent manufacturer should be able to produce when software can influence patient safety.

Put bluntly: if your software process is “we ship when it feels ready” and your documentation is “whatever is in Jira,” IEC 62304 is the standard that turns that chaos into an auditable, risk-based system. And it matters because regulators don’t judge your intent; they judge your evidence.

“IEC 62304 doesn’t make your software safe by itself. It makes it impossible to pretend you did the work when you didn’t.”

1) What IEC 62304 Actually Is

IEC 62304 is an international standard that defines life cycle requirements for medical device software—both software that is the device (standalone software) and software that is embedded or integral to a device. It establishes a common framework of processes, activities, and tasks for the development and maintenance of that software.

It is widely used because it aligns with how regulators think: software introduces systematic risk, and systematic risk demands a systematic lifecycle. When inspectors and reviewers ask “How do you know this change didn’t break a safety function?” IEC 62304 is one of the most accepted ways to answer with structured evidence rather than opinions.

Conceptually, IEC 62304 sits at the intersection of:

• Engineering discipline (requirements, architecture, verification),
• Quality management (document control, training, audits, supplier control), and
• Risk management (hazards, hazardous situations, risk controls, residual risk).

If you treat it as “a software SOP,” you will miss the point. It is a lifecycle framework that must be integrated into the QMS—especially change control, CAPA, and postmarket feedback loops.

2) What IEC 62304 Is Not (Common Misreads That Hurt Companies)

IEC 62304 has sharp boundaries. Misunderstanding them is a reliable way to fail audits or ship risky software.

• It does not prescribe a lifecycle model. You can use Agile, V-Model, staged gating, or hybrid approaches. The standard cares that required tasks happen and evidence exists—not the branding of your methodology.
• It does not define overall medical device validation and final release. You still need system-level validation, regulatory release controls, and overall QMS controls. IEC 62304 is necessary—but not sufficient—when software is part of a regulated product.
• It is not a cybersecurity standard. It does not replace secure development practices, threat modeling, vulnerability management, or security testing. Cybersecurity must be folded into risk management and lifecycle controls, not bolted on as a separate “security project.”
• It is not a documentation template. It doesn’t require “a 200-page document.” It requires documentation evidence. That evidence can live in modern tools—if you structure it, control it, and can retrieve it under audit without heroics.

In short: IEC 62304 isn’t about producing a pretty binder. It’s about being able to demonstrate disciplined control of software risk across the product lifecycle.

3) The Only Mental Model That Works: Risk-Based Evidence, End-to-End Traceability

Successful IEC 62304 programs share one trait: they build a single traceable story. Not five disconnected stories in five tools.

That story usually looks like:

• Why the software exists (intended use, system needs, user needs),
• What it must do (software requirements with acceptance criteria),
• How it is designed (architecture and interfaces that control risk),
• What you built (versioned code and build outputs),
• How you proved it (verification evidence scaled to A/B/C class),
• What you released (baselines, release records, known issues), and
• How you control change (impact analysis, regression, CAPA, field feedback).

If any link in that chain is missing, the organization ends up doing “regulatory archaeology” every time a customer complaint or audit happens. That is the expensive way to learn IEC 62304.

4) Software Safety Classification (A, B, C) — The Decision That Sets Your Workload

IEC 62304 requires you to classify software into one of three safety classes—A, B, or C—based on the potential harm that could result if the software fails. This classification is foundational because it determines the degree of rigor expected across development and verification.

• Class A: No injury or damage to health is possible from software failure.
• Class B: Non-serious injury is possible from software failure.
• Class C: Death or serious injury is possible from software failure.

Two hard truths about classification:

• Under-classifying is a recurring audit failure. Teams talk themselves into Class A because “the clinician would notice.” Inspectors will ask: “Where is that risk control defined, verified, and shown effective?” If you can’t prove the containment, you don’t get to assume it.
• Class drives verification depth, not just paperwork. For Class B/C software, you should expect more explicit architectural risk controls, tighter traceability, stronger unit/integration testing discipline, and more robust regression expectations.

Practical rule: classification should be decided using your ISO 14971 risk management logic, documented, reviewed, and treated as a controlled decision. It is not a casual engineering opinion.

5) The Five Process Groups — What IEC 62304 Forces You to Operate

IEC 62304 is easiest to understand as five connected process groups:

• Software development: planning → requirements → architecture → detailed design → implementation → verification → release.
• Software maintenance: maintenance planning, change evaluation, implementation, verification, and release of updates.
• Risk management: identify hazards, define and implement risk controls, verify controls, track residual risk and risk acceptability.
• Configuration management: versioning, baselines, build control, change control linkage, release configuration identity.
• Problem resolution: handling anomalies, defects, complaints, investigations, corrective actions, and learning loops.

The key is that these are not “departments.” They are lifecycle capabilities. Small companies must still execute them; they just execute them with smaller teams and tighter tooling.

When IEC 62304 goes wrong, it is usually because an organization only implements the development process and treats everything else as “operations.” Regulators will not accept that split. Maintenance, configuration, and problem resolution are part of product safety.

6) Development Planning — The Plan is the Contract With Your Future Self

IEC 62304 expects a software development plan that defines how you will execute lifecycle activities. This plan is not “nice-to-have”; it is what auditors use to judge whether you did what you said you would do.

A defensible plan typically defines:

• Lifecycle model and iteration strategy (Agile, staged, hybrid).
• Roles and responsibilities, including independent review where appropriate.
• Deliverables and records (what evidence will exist, where it lives).
• Tooling and tool validation expectations (especially if tools impact quality records).
• Interfaces with QMS processes: document control, training, supplier controls, and change control.
• Safety classification rationale and how class affects verification strategy.

Planning also forces a decision many teams avoid: what is the unit of release? Is it a compiled firmware image? A container tag? A mobile app build number? A cloud deployment snapshot? If you cannot uniquely identify what you released, you cannot reliably investigate what happened in the field.

7) Requirements — Where Most IEC 62304 Failures Start

IEC 62304 expects disciplined requirements work: clear software requirements, traceability, and verification against those requirements. This is where organizations most often cut corners, then pay for it later.

Practical expectations for software requirements under an IEC 62304 program:

• Each requirement is testable. If it cannot be verified, it is not a requirement—it’s a wish.
• Acceptance criteria exist. “Fast” becomes “<200 ms under defined load.” “Secure” becomes “enforced access control rules, logged events, and verification evidence.”
• System-to-software traceability exists. Software requirements should trace back to system needs and user needs (often captured in a URS or equivalent product definition).
• Risk controls are reflected. If risk management demands an alarm, lockout, or data integrity control, it must be a requirement with verification evidence.

Requirements discipline is not “bureaucracy.” It is the only scalable way to run regression testing, impact analysis, and postmarket investigation. Without good requirements, every change becomes a guessing game.

8) Architecture & Design — Risk Controls Live Here, Not in a PDF

Architecture is where IEC 62304 becomes real engineering rather than process theatre. For Class B/C software especially, architecture is how you prevent hazards from turning into harm.

Strong medical device software architecture tends to include:

• Clear decomposition: software system → software items → software units, with defined responsibilities.
• Controlled interfaces: documented inputs/outputs, constraints, error handling, and data validation rules.
• Containment of safety functions: safety-related features are isolated, monitored, and fail safe where possible.
• Defensive design: plausibility checks, sanity limits, watchdogs, safe defaults, and robust logging.
• Traceability to requirements and risk controls: architecture is not a diagram for marketing; it must map to safety and performance intent.

Design also needs to acknowledge real-world constraints: concurrency, timing, network loss, partial sensor failure, corrupted data, operator misuse, and the inevitable “unexpected input.” Many severe software incidents are not exotic bugs—they are missing design defenses.

9) Implementation & Verification — “We Tested It” Is Not Evidence

IEC 62304 requires verification activities appropriate to your software’s safety class. The standard does not force a particular test framework, but it does force a testable chain of evidence.

A practical verification stack often includes:

• Code-level controls: coding standards, peer reviews, and static analysis where appropriate.
• Unit verification: tests or analyses proving each software unit behaves as intended.
• Integration testing: tests proving that interfaces between units behave correctly, including error paths.
• System testing: tests proving the full software system meets software requirements under expected and stress conditions.
• Risk control verification: explicit tests proving safety controls work (alarms, interlocks, safe states, data integrity checks).

Verification is tightly linked to V&V. Verification answers “Did we build it right?” Validation answers “Did we build the right thing?” IEC 62304 focuses heavily on verification, but you cannot ignore validation just because software is the main component.

Also: traceability is not optional. For regulated software, you need to be able to show which tests verify which requirements, and which requirements implement which risk controls. That linkage is what makes regression testing rational rather than random.

10) Risk Management Integration — IEC 62304 and ISO 14971 Are Joined at the Hip

IEC 62304 assumes you are running risk management consistent with ISO 14971. In practice, this means software work must be connected to:

• Hazards and hazardous situations where software contributes (directly or indirectly).
• Risk control measures implemented in software, hardware, labeling, or workflow.
• Verification of risk controls—not just implementation.
• Residual risk evaluation and benefit-risk logic where applicable.

What auditors look for is the loop: risk analysis identifies a control → requirement captures it → design implements it → tests verify it → change control preserves it. Break that loop anywhere and you end up with “risk management as a document,” not a system.

Risk management also doesn’t stop at release. Field issues, complaints, cybersecurity findings, and trend signals should feed back into risk files and potentially CAPA. Software teams that treat postmarket as “support’s problem” eventually meet regulators who disagree.

11) SOUP (Third-Party Software) — The Biggest Source of “Unknown Risk”

Modern medical device software is built on layers of third-party components: operating systems, databases, open-source libraries, cloud services, drivers, and SDKs. IEC 62304 recognizes this reality through the concept commonly called SOUP (software of unknown provenance).

The compliance problem is simple: if you did not develop a component under your controlled lifecycle, you must still manage the risk it introduces. That typically requires:

• Selection criteria: why this component is acceptable (functionality, support, maturity, known issues).
• Known anomaly review: what is already known to be broken and whether it matters for your intended use.
• Security and patch strategy: how vulnerabilities and updates are evaluated and controlled.
• Integration verification: proof that the component works safely in your environment, not just in its vendor demo.
• Configuration identity: exact version(s) used, including transitive dependencies.

In audits, SOUP failures show up as “we use open source” with no bill of materials, no vulnerability handling, and no evidence of evaluation. That is not defensible anymore—especially for networked devices and cloud-connected products.

12) Configuration Management & Change Control — The Spine of IEC 62304

Configuration management is what keeps software lifecycle evidence from collapsing into a mess of mismatched versions. IEC 62304 expects you to control and identify:

• Code and configuration (version control, branching strategy, access control).
• Build outputs (how binaries are generated, reproducibility, build environment control).
• Baselines (what set of artifacts define a release candidate and a released version).
• Change records linked to requirements, tests, and risk evaluation.

This is where change control intersects engineering reality. A controlled change should include:

• Problem statement (or feature intent) and scope.
• Impact analysis (requirements impacted, tests impacted, risk impacted).
• Verification plan (what must be re-tested and why).
• Approval and release criteria.
• Updated traceability (requirements ↔ tests ↔ release baseline).

If your organization can’t reliably answer “Which customers are running the build that contains this bug?” you don’t have configuration management—you have hope.

13) Maintenance & Problem Resolution — Post-Release is Still Regulated Work

IEC 62304 explicitly treats maintenance and problem resolution as lifecycle processes. That matters because software doesn’t “ship and stop.” It evolves: bug fixes, performance improvements, OS updates, dependency updates, security patches, and labeling changes.

In a compliant system, maintenance includes:

• Maintenance planning: how updates are evaluated, tested, released, and documented.
• Problem intake: from support tickets, service reports, complaints, and postmarket surveillance signals.
• Investigation and root cause: including whether the issue is a safety concern, a usability concern, or a performance defect.
• Correction + verification: fix is implemented under change control with appropriate regression.
• Field communication decisions: release notes, customer notices, and escalation where required.

Two traps companies fall into:

• “Hotfix culture”—shipping patches outside controlled processes because “customers need it now.” That is how you create untraceable safety risk.
• “Support silo”—bugs are handled as service issues, never linked to risk management or CAPA. Regulators treat that as a broken feedback loop.

14) Agile & DevOps Under IEC 62304 — Allowed, But You Must Prove Control

Agile and DevOps are compatible with IEC 62304, but only if you translate speed into controlled evidence rather than uncontrolled output. The standard doesn’t care that you do sprints; it cares that required lifecycle tasks are completed and captured.

Practical ways to run Agile without collapsing compliance:

• Define “done” with compliance in it: requirement updated, tests written/executed, traceability established, risk impact checked.
• Use tickets as controlled records: but only if they are governed—role-based access, audit trails, approvals where needed, and retention.
• Automate evidence capture: CI test results, static analysis reports, build provenance, and release artifact identity.
• Gate releases, not commits: you can iterate internally fast, but product release must meet defined release criteria and approvals.

Continuous delivery creates a specific compliance question: what counts as a “release” for regulated software? If you deploy multiple times per day, you must still be able to identify what changed, which requirements and risks were impacted, and what verification supports it. Many teams can do this technically. The ones that fail are the ones that never formalize release identity and decision-making.

15) Audit Readiness — What Inspectors and Notified Bodies Actually Probe

Audits rarely fail on “not having IEC 62304.” They fail on gaps in the lifecycle story. Common findings include:

• Safety class is asserted but not justified (or contradicts risk analysis).
• Traceability is incomplete (requirements not linked to tests, risk controls not linked to verification).
• Configuration management is weak (no baselines, unclear build identity, poor access control).
• SOUP is unmanaged (no inventory, no evaluation, no patch/vulnerability strategy).
• Testing evidence is not reviewable (screenshots, missing logs, no objective pass/fail criteria).
• Change control doesn’t drive regression (impact analysis is superficial or missing).
• Problem resolution is not connected to CAPA, risk, or postmarket obligations.

Best practice is to maintain an “audit bundle” for each released version that can be produced quickly:

• Release configuration identity (what exactly shipped).
• Requirements baseline and traceability report.
• Risk file linkage (software-related hazards and controls).
• Verification summary with objective evidence (unit/integration/system as applicable).
• Open issues and rationale (what is known and why it is acceptable).

If generating this bundle takes weeks of scrambling, your process is not under control.

16) What IEC 62304 Means for V5

IEC 62304 compliance is ultimately a data integrity and traceability challenge disguised as a software engineering challenge. The easiest way to fail is to spread lifecycle evidence across disconnected tools with weak governance.

On the V5 platform, IEC 62304 becomes more manageable because you can connect software lifecycle records to QMS controls with audit-ready traceability:

• V5 QMS:
  • Controls document lifecycles for plans, specifications, protocols, reports, and release records under governed document control.
  • Runs change control workflows that force impact assessment, approvals, and linkage to tests and risk updates.
  • Supports CAPA and deviation logic for software issues that have quality or safety impact.
  • Enforces audit trails and e-sign expectations aligned with 21 CFR Part 11 and data integrity expectations.
• V5 Connect API:
  • Integrates modern engineering tools (issue tracking, requirements tools, CI results) into a controlled QMS record chain.
  • Reduces “copy-paste compliance” by linking objective evidence (build IDs, test runs, approvals) to quality records.
• Lifecycle visibility:
  • Links field issues and complaints into problem resolution and CAPA, closing the IEC 62304 maintenance loop.
  • Creates a durable evidence trail that survives team turnover, vendor changes, and scaling.

Net effect: IEC 62304 stops being an annual panic before audits and becomes a continuous, controlled lifecycle—exactly what regulators expect when software can influence safety.

FAQ

Q1. Is IEC 62304 mandatory?
Not as a universal law, but in practice it is one of the most widely accepted ways to demonstrate a controlled medical device software lifecycle. Many regulators and reviewers expect equivalent lifecycle evidence even if you don’t explicitly claim IEC 62304.

Q2. Can we be compliant with Agile?
Yes—if you still perform the required lifecycle tasks and produce auditable evidence. Agile is compatible; undisciplined Agile is not.

Q3. Does IEC 62304 replace ISO 14971?
No. IEC 62304 expects risk management consistent with ISO 14971. The standards complement each other: ISO 14971 frames risk, IEC 62304 operationalizes software lifecycle controls that manage that risk.

Q4. What is the fastest way to get into trouble with IEC 62304?
Under-classifying software safety, skipping traceability, and shipping “hotfixes” outside change control. Those three mistakes create safety risk and destroy audit credibility.

Q5. What evidence do auditors usually want first?
Safety classification rationale, traceability from requirements to tests, controlled configuration/release identity, and proof that changes and field issues flow through controlled maintenance and problem resolution processes.

Related Reading
• Software & Validation: Computer System Validation (CSV) | GAMP 5 | 21 CFR Part 11 | Annex 11
• Risk & Quality: ISO 14971 Risk Management | CAPA | Quality Management System (QMS) | QMSR
• Design Controls & Evidence: Design History File (DHF) | Device Master Record (DMR) | Verification & Validation (V&V) | Change Control
• Data Governance: Data Integrity | Audit Trail (GxP) | Document Control System
• Postmarket Loop: Postmarket Surveillance | Customer Complaint Handling