Last month we wrote about Clause 6 — the maintenance process that turns every post-clearance commit into a regulated event. One of the five failure patterns we flagged was maintenance branches that drift: a hotfix ships, "we'll merge it back next sprint" goes in the ticket, and next sprint doesn't happen.

That failure pattern isn't a Clause 6 problem. It's a Clause 8 problem wearing a Clause 6 costume.

Clause 8 is the software configuration management process — the rules that govern what your codebase actually is at any given moment, and how you can prove it. It's the least discussed clause in IEC 62304, mostly because it sounds like a version-control best-practices post that happens to have a regulatory citation attached. That undersells it. Clause 8 is the reason an auditor can ask "what code was running in the field on March 3rd" and get an answer instead of a shrug.

Here's the practitioner's read on Clause 8 — what it actually asks for, and the patterns that keep it from becoming fiction six months after go-live.

What Clause 8 actually requires

Clause 8 has two sub-processes. Two, not three — it's a shorter clause than 5 or 6, which is part of why teams underinvest in it. Short doesn't mean light.

8.1 — Configuration identification. Every item that makes up your software system gets uniquely identified and versioned: source code, third-party components, build scripts, test artifacts, documentation, the works. Not "we can find it in Git if we look." Identified — meaning there's a documented, unambiguous way to say "this is version X of this item, and here's how it relates to the release it shipped in."

8.2 — Change control. Every change to a configuration item goes through a controlled process before it's incorporated: proposed, evaluated, approved, implemented, verified, and recorded. This is the sub-clause that turns "I merged a fix" into "I merged an authorized, traceable fix that someone can reconstruct the reasoning for."

That's the whole clause. Two sub-processes, both simple to state, both surprisingly easy to satisfy on paper and fail in practice — because the failure mode isn't ignorance of the requirement. It's a codebase that grew faster than the configuration management process did.

Where teams get stuck

Five patterns show up repeatedly once a team is a year or two past their first clearance:

1. The hotfix branch that never came home. This is the Clause 6 failure pattern from last month, traced back to its root: a branch gets created outside the normal change-control path because it's urgent, ships once, and nobody owns getting it back into main. Six months later there are three of them. Configuration identification is supposed to tell you what's running where. If the branches don't reconcile, it can't.

2. "Latest" as a version identifier. Third-party dependencies pinned to a moving tag, containers built from a rolling base image, a library that auto-updates in CI. Convenient until an auditor asks which exact version of a component was in the build that shipped to a specific customer, and the honest answer is "whatever `latest` resolved to that day."

3. Change control that only covers your own code. Teams build rigorous PR review and approval for first-party changes, then treat a dependency bump or a base-image update as routine maintenance that doesn't need the same evaluation. A version bump is a change like any other. If it isn't evaluated, it isn't controlled — it's just deployed.

4. Configuration items that exist informally. Build scripts, environment configs, infrastructure-as-code, test data sets — items that clearly affect what the software does but never got formally identified as configuration items in the first place. You can't control the change history of something you never agreed to track.

5. No single source of truth for "what shipped where." Release notes in one place, deployment logs in another, the actual git tag somewhere else, and no artifact that ties them together. Reconstructing a release six months after the fact becomes an investigation instead of a lookup.

Five patterns that work

These are the habits that keep Clause 8 boring — which, for a compliance process, is the goal:

  • Treat every dependency the way you treat your own code. Pin exact versions, not tags. Evaluate a version bump with the same rigor as a first-party PR: what changed, why, what it affects, who approved it. "It's just a dependency update" is the sentence that precedes most Clause 8 findings.
  • Give configuration items a real, written list. Source code, build tooling, third-party components, test artifacts, environment configuration — decide explicitly what counts as a configuration item and write it down in the configuration management plan. If it's not on the list, someone will eventually assume it doesn't need control, and they'll be technically correct.
  • Make branch lifecycle part of change control, not a Git convention. A hotfix branch gets created with an expected merge-back date attached to the same change-control record that authorized the fix. If the branch outlives that date, that's a tracked exception, not a surprise discovered during an audit prep scramble.
  • Automate configuration status accounting — don't reconstruct it by hand. Your CI/CD pipeline already knows what commit, what dependency versions, and what test results produced a given build. Capture that automatically at build time instead of assembling it retroactively when someone asks.
  • Review change control records as part of your release checklist, not after. Before a release goes out, confirm every configuration item that changed has an approved, recorded change behind it. This is a five-minute check when it's built into the release process. It's a multi-day forensic exercise when it's done after the fact.

What this looks like in production

The teams that get Clause 8 right don't think of it as a documentation exercise layered on top of engineering work. They think of it as a property of the pipeline: the build system that produces the release also produces the configuration record, automatically, as a side effect of building it correctly. Nobody has to remember to do configuration management, because it's not a separate step — it's baked into how a build happens at all.

The teams that struggle usually have good engineering practices and a configuration management plan that describes a process the engineering practices quietly stopped following a year ago. The plan says every dependency is pinned and every branch has an owner. The repo says otherwise. Nobody updated the plan, and nobody enforced it against the repo, so the gap grew until an audit found it.

Clause 6 is the process that responds when something needs to change. Clause 8 is what makes sure you can trust what you're changing from. Get the second one wrong, and the first one is operating on a codebase nobody can actually describe.

If you're heading into an audit, or just haven't looked hard at your configuration management plan since the day you wrote it: the branches that never merged back are usually the fastest way to find out where the gap is.

Building or medical device software? Aside from software development, Hattrick also advises medtech companies to design FDA-compliant software processes. Get in touch at [email protected].