IEC 62304 software lifecycle essentials

In plain language

IEC 62304 is about making software work visible, planned, tested, released, and maintained in a controlled way. For founders, the main takeaway is that regulated software is not just code. It is code plus requirements, architecture, tests, release records, problem resolution, maintenance, and evidence that connects those pieces.

What this page helps you decide

This page helps learners understand regulated software as a controlled lifecycle. The product is not only code; it is requirements, architecture, implementation, verification, anomaly tracking, release records, maintenance, and evidence that connects those pieces.

Use it when software affects safety, claims, clinical workflow, device behavior, or any regulated product function.

Lifecycle expectations

IEC 62304 expects clear planning, requirements, architecture, implementation, verification, release, and maintenance activities with evidence at each stage.

Founder focus points

• Define software safety classification assumptions with QA/RA.
• Budget for documentation and evidence generation, not just coding.
• Treat maintenance and updates as planned lifecycle work.

Minimum software file contents

Early teams do not need heavyweight ceremony, but they do need enough structure that another qualified person can understand what was built and why. A credible software file usually points to requirements, architecture, risk controls, verification evidence, known anomalies, release notes, dependency records, and maintenance decisions.

Software safety class (implications)

Higher classes demand more rigorous planning, independence of verification, and maintenance discipline. Mis-classifying to “save time” creates audit and submission risk. Revisit classification when intended use, hardware interfaces, or algorithms change.

SOUP (software of unknown pedigree)

Third-party libraries, operating systems, and cloud SDKs are SOUP. You must record versions, monitor anomalies, and verify your product still meets requirements when SOUP updates. SBOM practice (see SBOM template) supports this.

Anomalies and problem resolution

Track defects from report to fix, impact analysis, verification, and release. Serious anomalies may trigger vigilance reporting—connect the IT ticket to the quality record, not only a chat thread.

Change control and AI / PCCP

Model retraining that stays inside an authorized PCCP still needs software change records, regression tests, and risk review. Changes outside the PCCP may require a licence amendment or new submission. Align your model change policy with IEC 62304 maintenance activities.

Minimum records for audits

Expect auditors to trace from requirement to test to release artifact. If you cannot produce versioned documents quickly, assume the QMS is not yet credible—regardless of how polished the UI looks.