IEC 62304: what it actually requires of your software

Standard · Medical Device Software

IEC 62304:2006+AMD1:2015 sets 5 clauses of life-cycle process (development, maintenance, risk management, configuration management, and problem resolution), and each software item's Safety Class (A, B, or C) decides how much of each clause your requirements traceability matrix and verification records must evidence.

Jump to the Class C documentation checklist ↓

The five processes, and where teams actually lose evidence

Every software item gets a Safety Classification — A, B, or C — based on the harm it could contribute to if it failed, and that classification sets how much process rigor each clause actually demands.

The standard is organized as five process groups. Clause 5 (Software Development) is the one most teams think of first — planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing (§5.5–§5.6), system testing, and release. Clauses 6–9 are the ones that get skipped under deadline pressure and then discovered missing during an audit: Clause 6 Software Maintenance, Clause 7 Software Risk Management (which interfaces directly with ISO 14971's risk-analysis process), Clause 8 Software Configuration Management, and Clause 9 Software Problem Resolution.

Safety classification determines rigor, not the other way around

Per Clause 4.3, classification is driven by the severity of harm the software could contribute to if it failed, established through the ISO 14971 risk-analysis process — not by how complex the code is:

  • 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.

Under IEC 62304, a Class C classification makes 2 clauses non-negotiable, §5.5 unit verification and §5.6 integration testing, each with its own test evidence log, and is where most of the documentation-completeness gap actually lives.

Where traceability breaks in practice

The single most common IEC 62304 audit finding in MedTech software is not a missing document — it's a broken link in the requirements traceability matrix between a requirement, the architectural element that implements it, the unit-level test that verifies it, and the risk control it satisfies. When that chain is kept by hand in a spreadsheet, it drifts the moment a requirement changes and nobody updates the matrix. An automated, source-control-derived traceability matrix (requirement → design element → test → risk control, regenerated on every commit) is the practical fix — not a heavier document template.

Artifact: Class C documentation-completeness checklist

A worked checklist for the documentation set a Class C software item needs before it can honestly be called "IEC 62304-ready." Generated client-side; no server round-trip, no account required. 

# IEC 62304 Class C Documentation-Completeness Checklist (v1.0.0)

Engineering reference checklist only. Not formal regulatory counsel, not an FDA
or notified-body submission. Verify against your own quality system.

## Clause 5 — Software Development
- [ ] 5.1 Software development plan exists and names the safety class
- [ ] 5.2 Software requirements are individually identified and traceable
- [ ] 5.3 Software architecture documents item-to-unit decomposition
- [ ] 5.4 Detailed design exists for each Class C software unit
- [ ] 5.5 Unit implementation and verification records exist per unit
- [ ] 5.6 Integration testing records trace to architecture interfaces
- [ ] 5.7 System testing records trace to software requirements
- [ ] 5.8 Release record confirms all required verification is complete

## Clause 6 — Software Maintenance
- [ ] 6.1 Maintenance plan exists and is distinct from the development plan
- [ ] 6.2 Problem and modification analysis references the risk management file

## Clause 7 — Software Risk Management
- [ ] 7.1 Software items contributing to hazardous situations are identified
- [ ] 7.2 Risk control measures implemented in software are traceable to ISO 14971 records
- [ ] 7.3 Verification of risk control measures is documented

## Clause 8 — Software Configuration Management
- [ ] 8.1 Configuration items are uniquely identified (including third-party/SOUP)
- [ ] 8.2 Change control records exist for every configuration item change
- [ ] 8.3 A build is reproducible from the identified configuration items

## Clause 9 — Software Problem Resolution
- [ ] 9.1 Problem reports are logged with a unique identifier
- [ ] 9.2 Each problem report's evaluation for safety impact is documented
- [ ] 9.3 Problem resolution is traceable to a verified change

Download the checklist (Markdown)

Engineering reference checklist only. Not formal regulatory counsel, not an FDA or notified-body submission, not a substitute for your own quality system's document-control process. Version: 1.0.0.

Does IEC 62304 apply to your system?

This guide's Class C checklist is directly relevant if:

  • Your software is itself a medical device, or is embedded in one.
  • Your software is an accessory to a medical device and can affect its safe use.
  • A hazard analysis under ISO 14971 has not yet assigned your software a safety class.
  • Your requirements-to-test traceability currently lives in a spreadsheet maintained by hand.

This is a static applicability check, not a scored assessment — it states conditions, not a computed result. Run the interactive, scored version below (Pattern P1 per specs/constitution/plg.md), or open it as its own page at /tools/iec-62304-gap-assessment.

Engineering self-assessment diagnostic only. Not formal regulatory counsel, not an FDA or notified-body submission, not a 510(k)/PMA clearance guarantee, not a legal opinion. Results depend entirely on the accuracy of self-reported inputs.

Runs entirely in your browser. Nothing you enter here — your answers or your evidence notes — is sent to any server. Only anonymous, derived counts (which family, how many items) are recorded as first-party telemetry.

Safety classification

Every software item has a documented Safety Classification (A, B, or C) derived from an ISO 14971 risk analysis — not asserted informally. IEC 62304 §4.3

Software development (Clause 5)

A software development plan exists and names the safety class. §5.1

Software requirements are individually identified and traceable to design elements. §5.2

Software architecture documents the item-to-unit decomposition. §5.3

Unit implementation and verification records exist for every Class B/C unit. §5.5

Integration and system testing records trace back to requirements and architecture interfaces. §5.6–§5.7

Software maintenance (Clause 6)

A software maintenance plan exists, distinct from the development plan. §6.1

Software risk management (Clause 7)

Risk control measures implemented in software are traceable to ISO 14971 records. §7.2

Software configuration management (Clause 8)

Configuration items — including third-party and SOUP components — are uniquely identified with enforced change control. §8.1–§8.2

Software problem resolution (Clause 9)

Problem reports are logged, evaluated for safety impact, and traced to a verified resolution. §9.1–§9.3

Try with AI (Claude, ChatGPT, Gemini)

Before you finalize a Class A or B classification, use this prompt with Claude, ChatGPT, or Gemini to pressure-test it the way an auditor would — before an auditor does.

Challenge Your Medical Device Software Safety Classification

Prompt type
CHALLENGE
Version
v1.0 · PROMPT-62304-CHALLENGE-v1
Who this is for
Regulatory affairs and quality engineering leads assigning or reviewing an IEC 62304 §4.3 software safety classification.
What you'll need
Your device's intended use, its role in the clinical workflow, and your team's current Class A/B rationale (the ISO 14971 risk-analysis summary it rests on).
You are acting as a skeptical FDA or Notified Body auditor reviewing a medical device software safety classification under IEC 62304:2006+AMD1:2015 Clause 4.3.

I will describe my device's intended use, its role in the clinical workflow, and the safety classification (Class A or Class B) my team has assigned to a specific software item.

Your job is NOT to confirm our classification. Aggressively look for every reason a regulator could argue it should be escalated to Class C (death or serious injury possible):

1. Identify every clinical pathway — direct or indirect — through which a malfunction, wrong output, or delayed output of this software item could contribute to death or serious injury, including a clinician relying on the output without independently verifying it.
2. Challenge every assumption in our stated intended use that reduces apparent risk ("for reference only," "a clinician always reviews the result," "used only in a monitored setting"). State whether each assumption is enforced by the software itself or only by procedure/labeling — a risk analysis is not supposed to credit a purely procedural mitigation at face value.
3. Identify any foreseeable misuse or off-label use pathway our hazard analysis might have missed.
4. Point out where our Class A/B rationale relies on a downstream hardware or human safeguard that is not itself verified to Class C rigor. If that safeguard fails, does the software's own contribution to harm reappear?
5. For each escalation argument, rate it Weak / Moderate / Strong, and state exactly what evidence (hazard analysis record, clinical evaluation, post-market data) would be needed to rebut it.

My device's intended use: {describe the device, clinical setting, intended user, and the specific software function being classified}
My team's current classification and stated rationale: {state Class A or B and why}

Finish with: (a) the single strongest escalation argument, and (b) the specific evidence gap that would most likely cause an auditor to push back on this classification.

What to verify before trusting this:

  • Cross-check every escalation argument against your actual ISO 14971 risk analysis file — this prompt cannot see it.
  • Treat an AI-surfaced escalation argument as a hypothesis to investigate, not a classification decision; IEC 62304 classification must still be formally documented and approved under your quality system.
  • Do not paste real patient data, incident reports, or confidential clinical evaluation text into a public AI tool — describe the device and rationale in general terms only.

If classification remains borderline, have Netspective perform a formal software safety architecture review.

Have Netspective perform a formal software safety architecture review

Useful next step

Download the Class C documentation checklist

Run it against your current software file before your next design review.

Provenance & review state

Review state
draft — published as a working implementation proof; formal Two-Key sign-off (CONTENT-ENGINEERING.md §5.1) has not yet occurred.
Last reviewed
Sources
  • IEC 62304:2006+AMD1:2015, Medical device software — Software life cycle processes — International Electrotechnical Commission (IEC)
  • ISO 14971:2019, Medical devices — Application of risk management to medical devices — International Organization for Standardization (ISO)

Continue with an engineer

A scoped review of your requirements-to-test evidence chain, not a sales call.

Review your Class C traceability checklist with a Verification Engineer

Sign in or sign up

Enter your work email to receive a temporary sign-in link.

By continuing, you agree to our Terms of Service and Privacy Policy.