Under EN 62304, code review is a legitimate software unit verification activity. Clause 5.5 requires you to verify that each unit meets its detailed design and its acceptance criteria — and peer review of source code is an acceptable method, provided the review is planned, has criteria, and leaves a record. The standard does not mandate pull requests or any specific tool; it mandates evidence.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN 62304:2006+A1:2015 clause 5.5 allows code review as a software unit verification method, alongside testing and static analysis.
  • The standard does not require a specific tool, workflow, or reviewer count — it requires planned criteria, executed review, and retained records.
  • For Class B and Class C software, unit verification and its records are explicit requirements; for Class A, the scope is smaller but the QMS under EN ISO 13485:2016+A11:2021 still applies.
  • A modern Git pull-request workflow can satisfy clause 5.5 if the checklist, approvals, and merge history are retained and traceable to the software unit.
  • The startup failure mode is not "no code review." It is "code reviews happened but we cannot prove it" — which, under audit, is the same thing.

Why this matters for small software teams

Every software startup reviews code. What very few of them do is treat the review as a regulated verification activity with an audit trail.

The cost of getting this wrong is not theoretical. At a notified body audit for a Class IIa SaMD, the auditor will pick a release, pick a software unit, pick a change, and ask: "Show me the verification evidence for this unit." If you can show unit tests, you have covered part of clause 5.5. If you can also show a recorded peer review against written acceptance criteria, you have covered the rest. If your only answer is "we always review, it's in the culture," the finding writes itself.

EN 62304 does not punish pragmatism. It punishes undocumented pragmatism. The distinction matters because the same engineering practice — two developers reviewing a change before it merges — can be either audit-ready evidence or audit-invisible effort. The difference is whether the review was planned, had criteria, and left a record that ties back to a specific software unit.

What EN 62304 clause 5.5 actually requires (and what it does not)

EN 62304:2006+A1:2015 clause 5.5 covers software unit implementation and verification. The relevant obligations for code review are:

Clause 5.5.1 — Implement each software unit. The manufacturer shall implement each software unit.

Clause 5.5.2 — Establish software unit verification process. The manufacturer shall establish strategies, methods and procedures for verifying the software units. Where verification is done by testing, the test procedures shall be evaluated for correctness.

Clause 5.5.3 — Software unit acceptance criteria. Before integration, the manufacturer shall establish acceptance criteria for software units prior to integration into larger software items, and ensure that software units meet acceptance criteria. The standard lists possible criteria including: does the software code implement requirements including risk control measures; does the software code conform to its design; is the software code free from contradiction with the interfaces; does the software code conform to programming procedures or coding standards.

Clause 5.5.4 — Additional software unit acceptance criteria. For Class B and Class C software, the manufacturer shall include additional acceptance criteria as appropriate such as proper event sequence, data and control flow, planned resource allocation, fault handling, initialisation of variables, self-diagnostics, memory management and memory overflows, and boundary conditions.

Clause 5.5.5 — Software unit verification. The manufacturer shall perform the software unit verification and document the results. This is the clause that code review directly serves.

What the standard does not say: - It does not require pull requests. - It does not require two reviewers, or a senior reviewer, or any specific reviewer count. - It does not require a specific code review tool. - It does not prohibit the author from being involved in the review record. - It does not mandate inline comments or any particular review artefact format.

What the standard does require, when read together with EN ISO 13485:2016+A11:2021: - A planned method for verification (clause 5.5.2). - Written acceptance criteria (clauses 5.5.3 and 5.5.4). - Executed verification with results (clause 5.5.5). - Records that are retained, controlled, and traceable (ISO 13485 clauses 4.2.4 and 4.2.5). - Sufficient scope for the software safety class (clause 4.3 of EN 62304).

Code review is one way to satisfy the method requirement. It can coexist with testing and static analysis — in fact, for well-designed verification plans, it usually does.

Code review as verification vs code review as hygiene

Most software teams already do code review as engineering hygiene: catching bugs, sharing knowledge, enforcing style. That is valuable. It is not, by itself, EN 62304 verification.

The gap is small but meaningful. Hygiene review asks: "Is this code good?" Verification review asks: "Does this code meet its specified requirements, its detailed design, and the acceptance criteria set out under clause 5.5.3 / 5.5.4?"

To turn hygiene into verification, three things need to be true:

  1. The criteria exist in writing before the review. If the reviewer is inventing criteria as they read, it is not verification.
  2. The review records which criteria were checked and the outcome. "LGTM" does not record what was checked.
  3. The review is traceable to the software unit it verified. If you cannot link the review record to a specific unit and a specific version of that unit, the evidence is weak.

Done correctly, a single code review can cover multiple clause 5.5.3 and 5.5.4 criteria at once — and for the criteria that genuinely cannot be checked by reading code (resource allocation under load, memory behaviour under stress), you combine review with testing or static analysis.

A worked example: the PR workflow that passed an audit

A four-person startup building Class B SaMD uses GitHub pull requests. They want their normal PR workflow to serve as clause 5.5 evidence. Here is what they did — and what their notified body accepted.

Step 1. They wrote a short "Software Unit Verification Procedure" under their QMS. One page. It listed the clause 5.5.3 criteria plus the applicable clause 5.5.4 criteria (they are Class B) and said explicitly that code review is one of three verification methods, alongside unit testing and static analysis.

Step 2. They added a PR template. The template had a checklist with the actual clause 5.5 criteria, phrased as questions the reviewer could answer with a tick: "Does the code implement the stated requirement and linked risk controls? Does the code conform to the detailed design? Does the code conform to the coding standard? Is fault handling present where required? Are boundary conditions handled? Is memory management and variable initialisation correct?"

Step 3. They required the PR description to link the requirement ID(s) and the risk control ID(s) covered by the change. This created the traceability from the review record to the software unit's specification.

Step 4. They required at least one reviewer other than the author to complete the checklist before merge. Branch protection enforced this. The review conversation — including any issues raised and resolved — became the record.

Step 5. They enabled GitHub's "squash and merge" with preserved PR history, and added a monthly export job that archived closed PRs to their controlled document storage, linked to the release they were part of.

Step 6. For clause 5.5.4 criteria that cannot be verified by reading code alone — memory overflows, resource allocation under load — they required the PR template to reference the corresponding unit test or static analysis result.

At audit, the notified body picked a release, picked a software unit, and asked for verification evidence. The team showed the PR template, the completed checklist, the linked requirements, the linked unit tests, the static analysis report, and the archived PR export. The auditor closed the line item.

Total process overhead above "normal" engineering: the one-page procedure, the PR template, the archive job, and the discipline to actually fill in the checklist.

The Subtract to Ship playbook for code review

Smaller teams should aim for the minimum process that produces audit-ready evidence and no more.

1. Write a one-page software unit verification procedure. Name your verification methods (review, testing, static analysis). State your clause 5.5.3 criteria. For Class B or C, state the applicable clause 5.5.4 criteria. Reference EN 62304:2006+A1:2015 clause 5.5 by name.

2. Turn the criteria into a PR checklist. Not a standalone document — the template of every PR. If the reviewer has to open another tab, the checklist will drift out of use within a month.

3. Require traceability in every PR description. Requirement IDs, risk control IDs, and the software unit(s) touched. This is also required by clause 5.1.1 and by MDR Annex II traceability expectations.

4. Enforce peer review via branch protection. At least one reviewer other than the author. For software safety Class C, consider stricter rules — senior reviewer involvement, or second-pair reviews for critical modules. The standard does not require this but your risk analysis might.

5. Archive the review record. PR exports, merge history, review comments. Retained under ISO 13485 clauses 4.2.4 and 4.2.5 for the required period. The archive is what an auditor will ask for, not the live Git history.

6. Integrate, do not duplicate. Code review does not replace unit testing or static analysis — it complements them. For each clause 5.5.3 / 5.5.4 criterion, decide which method covers it. Write that mapping down once. Reuse it.

7. Scale review depth to safety class. Class A software has lighter unit verification obligations under clause 5.5; Class B adds 5.5.4; Class C adds the full set plus stricter scrutiny. Do not apply Class C rigour to Class A code and call it efficient.

Reality Check

  1. Does your QMS have a written software unit verification procedure that names code review as a method and references EN 62304 clause 5.5?
  2. Can you show, for a randomly selected merged change from last month, the code review record and the criteria that were checked?
  3. Does every PR description link the requirements and risk controls the change implements or affects?
  4. For Class B or C software, are the clause 5.5.4 additional criteria — fault handling, boundary conditions, memory management, initialisation — actually on your review checklist?
  5. If GitHub (or your Git host) disappeared tomorrow, could you still produce the review history for the last two releases from your controlled archive?
  6. Do reviewers know what they are verifying against, or are they inventing criteria as they read?
  7. Have you mapped which clause 5.5 criteria are covered by review, which by unit testing, and which by static analysis — and is that mapping written down?

Frequently Asked Questions

Does EN 62304 require two reviewers per pull request? No. EN 62304 clause 5.5 does not specify a reviewer count. It specifies that verification is planned, executed, and recorded. Your own risk-based decision, documented in the verification procedure, determines reviewer count.

Can the author of the code be involved in the review record? The author implementing the code and a separate person verifying it is standard good practice and what most notified bodies expect. The standard does not forbid the author from participating in the review conversation, but the verification decision should be made by someone other than the author.

Is "LGTM" enough as a review record? No. A bare approval does not document which acceptance criteria were checked. The review record must allow an auditor to see what was verified against what.

Do we need a separate code review tool, or is GitHub / GitLab enough? A Git hosting platform with pull requests, checklists, required reviewers, and exportable history is enough, provided the archive is controlled under your QMS document and record control procedures.

How does this relate to static code analysis? Static analysis is a separate verification method under clause 5.5. It covers things humans read poorly — uninitialised variables, null dereferences, simple boundary errors. Code review covers things tools read poorly — intent, design conformance, risk control correctness. A mature verification plan uses both.

What about AI-assisted code review? AI suggestions can supplement human review, but they do not replace the planned, human-accountable verification record required by clause 5.5. An AI reviewer is not a signing authority under your QMS.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2; Annex II.
  2. EN 62304:2006+A1:2015 — Medical device software — Software lifecycle processes. Clauses 4.3, 5.1.1, 5.5.1–5.5.5.
  3. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems. Clauses 4.2.4, 4.2.5, 7.3.4.