IEC 62304 Clause 5: Software Development in Practice

Clause 6 of IEC 62304 is where most teams get hurt. We covered that last month — the maintenance traps, the frozen risk files, the patch backlogs that become audit findings.

But Clause 6 problems are almost always Clause 5 problems in disguise.

Clause 5 is the software development lifecycle — the eight sub-processes that govern everything from initial planning to release. If you run Clause 5 well, Clause 6 is manageable. If you cut corners in Clause 5, you spend the back half of your product’s life in remediation.

Here’s the practitioner’s read on Clause 5: what each sub-process actually requires, where teams consistently go wrong, and the patterns that hold up when an auditor starts asking questions.

What Clause 5 actually requires

Clause 5 has eight sub-processes. They’re sequential in structure but overlapping in practice, and all of them produce artifacts that end up in your FDA submission.

5.1 — Software development planning

Before development starts, you commit in writing to how it will run. Your Software Development Plan defines the lifecycle model, identifies software items and their safety classes, specifies deliverables and who owns them, and describes how the process connects to risk management and configuration management. This is the document that governs everything else. Auditors read it first, then check whether what follows actually matches it.

5.2 — Software requirements analysis

Requirements get documented before code gets written. Each requirement carries a unique identifier, is testable, and traces upward to system requirements and downward to design and test. This is not a description of the software you built. It’s the specification the software was built against. That distinction matters enormously when an FDA reviewer asks how you verified the device does what it claims.

5.3 — Software architectural design

You identify the software items that compose the system, assign a safety class to each, define the interfaces between them, and document the architectural rationale — particularly for decisions that affect safety or risk. This is where the compliance dividend from modular design pays off. Teams that built a monolith have to assign Class C treatment to everything. Teams that isolated safety-critical components get to apply proportionate rigor.

5.4 — Software detailed design

For each software item — or at least each Class B and C item — you document the detailed design with enough specificity that someone could implement and verify it without inventing requirements along the way. Interfaces, data flows, error handling, state transitions. The standard doesn’t mandate a format. It mandates the content.

5.5 — Software unit implementation and verification

Code gets written. Units get tested. The verification evidence gets captured. For Class C software items, this means unit tests with pass/fail records, coverage appropriate to the safety class, and traceability from each test back to the requirement it exercises. The tests themselves are not enough. The evidence that they ran and passed is what FDA sees.

5.6 — Software integration and integration testing

Software items get assembled and tested together. Integration test protocols are written before testing runs. Anomalies — any unexpected behavior — get documented and resolved. The integration test report becomes part of the submission package. Teams that run integration testing informally, without protocols, produce results that can’t be referenced in a submission without explanation.

5.7 — Software system testing

The complete software system gets tested against the Software Requirements Specification. System test protocols are pre-approved. Every test has a pass/fail criterion. Anomalies are recorded, evaluated, and closed — or formally accepted with rationale if residual. The system test report is one of the most-reviewed documents in a 510(k) submission.

5.8 — Software release

Before release, you confirm that release criteria are met, document known anomalies and their risk-evaluated status, establish a configuration baseline, and create a release record. The release record is the final artifact that closes the Clause 5 lifecycle. Teams that skip it — or create it retroactively — have a gap that’s hard to explain.

Clause 5 doesn’t just require that you run a process. It requires that you can prove you ran it.

Where teams get stuck

After supporting medtech software teams through development and FDA submission, the same failure patterns appear:

1. The SDP that describes intent, not reality

The Software Development Plan is written at the start of a project when everything is still theoretical. Six months later, the team has adapted — different lifecycle phases, different deliverable owners, sprint rhythm that doesn’t match the plan. Nobody updated the SDP. Now the plan says one thing and the actual artifacts say another. Auditors reconcile these. The gaps become findings.

2. Requirements written after the fact

Development runs ahead of documentation. Features get built, then someone writes the requirements to match what was built. The SRS describes the software, not the specification it was developed against. The traceability chain looks intact on paper, but any reviewer who pulls on a thread finds that requirements and design decisions are not actually in the right order. This is one of the most common — and most detectable — problems in submissions.

3. Safety class applied to the system, not the items

A team correctly identifies that their device contains Class C software. But instead of decomposing the system into items and classifying each, they apply Class C treatment to everything. This is technically defensible but practically expensive — and it usually means the team hasn’t done the architectural work to isolate components. The missed opportunity is proportionality: Class C rigor where it’s warranted, Class A speed everywhere else.

4. Test evidence that exists somewhere but isn’t organized

Teams run unit tests. CI pipelines generate results. Integration tests happen in a staging environment. System tests get run by a QA team. All of this produces evidence — but none of it is organized against the requirements it’s supposed to verify. When submission time arrives, the evidence exists but can’t be presented coherently. The traceability matrix is built backward from the test runs, not forward from the requirements.

5. Integration test protocols that don’t exist before testing starts

FDA expects protocols to be written, reviewed, and approved before testing runs — not created to document testing that already happened. Teams that run integration testing informally, without pre-approved protocols, can’t reference the results in a submission without a qualification. Writing protocols after the fact is re-testing on paper. It’s detectable, and it erodes confidence in the submission.

Five patterns that work

1. Keep the SDP alive

Designate an owner for the SDP and treat it like any other regulated document — versioned, updated when the process changes, approved at each revision. The SDP is not a project artifact you file and forget. It’s the governing document for everything Clause 5 produces. A living SDP that accurately reflects how the team worked is a strong audit signal. A stale one is a liability.

2. Write requirements before sprints, not after

This is the hardest discipline to establish in an Agile team and the most valuable one. Requirements don’t need to be waterfall-style documents — they can live in your ticket system. But they need to exist, carry unique IDs, and be approved before the sprint that implements them. The traceability chain runs forward from requirements. If requirements are written after implementation, that chain doesn’t exist — it’s simulated.

3. Decompose software items and classify each one

Do the architectural work to separate safety-critical from non-critical components before development starts. Define the interfaces. Assign safety classes at the item level. This creates the proportionality that makes Clause 5 tractable — and makes Clause 6 maintenance significantly cheaper. A well-decomposed architecture generates the Clause 5.3 artifact naturally. A monolith requires a retrofit.

4. Build verification evidence collection into your CI pipeline

Unit test results, coverage reports, static analysis output — configure your pipeline to capture and archive these automatically, tagged to the requirement IDs they cover. The goal is not just to run tests. It’s to generate evidence that can be referenced in a submission without manual reconstruction. Teams that build this in from the start have their 5.5 package ready when they need it. Teams that don’t spend weeks organizing output from dozens of CI runs.

5. Write integration test protocols before the integration test sprint

Schedule a protocol-writing phase before integration testing starts. Protocols don’t have to be long — but they need to specify what’s being tested, how, and what constitutes pass/fail. Approved before execution. Results recorded against the protocol. Anomalies documented. This is the difference between integration test evidence that holds up in a submission and test output that has to be re-characterized.

What this looks like in practice

The teams that move fastest through FDA review have one thing in common: they generated Clause 5 evidence as a natural byproduct of how they worked, not as a submission-preparation exercise.

Their CI pipeline produced archived test evidence. Their ticket system carried requirement IDs. Their sprint retrospectives caught SDP drift before it accumulated. Their release records existed because someone put them on the sprint checklist.

The teams that struggle treated Clause 5 as a documentation checklist to be completed before submission. By the time they started checking boxes, the development was done and the evidence was missing.

Clause 5 is not a documentation exercise. It’s a development discipline. The documentation is the residue.

The submission you file is a retrospective account of how the software was built. If the process was right, the documentation is easy. If the process wasn’t right, no amount of documentation can fix it retroactively — it can only obscure it, and not for long.

If you’re in pre-development: the time to design for Clause 5 is now, before sprint 1.

If you’re mid-development: run a gap assessment against each sub-process. Find out what’s missing while you can still generate it organically.

If you’re pre-submission: you need an honest inventory of what exists and what was reconstructed. Reviewers can tell the difference.