EN 62304:2006+A1:2015 clause 8 defines software configuration management as three linked activities: configuration identification, change control, and configuration status accounting. Every software item, document, and third-party component carries a unique identifier and a version; every change to a controlled item follows a documented change-control process; and the current state of every configuration item is traceable at any point in the lifecycle. The goal is narrow and concrete — any released version of the software must be reproducible from the configuration record, and any field report must be attributable to a specific known version. MDR Annex I Section 17 makes the lifecycle discipline a legal obligation; EN 62304:2006+A1:2015 clause 8 is the harmonised tool that operationalises it.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN 62304:2006+A1:2015 clause 8 requires software configuration management with three sub-processes: configuration item identification, change control, and configuration status accounting.
  • A configuration item is anything whose version matters to the released product — source code, build scripts, design documents, test artefacts, third-party libraries, and the toolchain used to build the release.
  • Every controlled item carries a unique identifier and a version; every change to a controlled item runs through a documented change-control process that links the change to the reason, the reviewer, and the verification.
  • Configuration status accounting means that at any moment the manufacturer can answer three questions: what is the current state of any configuration item, what was the state at a previous release, and what changed between the two.
  • The release record is reproducible from the configuration management system. Given a version number, the manufacturer can reconstruct the exact source, dependencies, and build environment used.
  • Git solves configuration identification and change control for source code out of the box, but git alone is not a complete SCM system under EN 62304:2006+A1:2015 — documents, third-party components, build tools, and release decisions have to be covered too.
  • MDR Annex I Section 17 requires software to be developed under a lifecycle that reflects the state of the art; EN 62304:2006+A1:2015 is the harmonised standard that provides presumption of conformity, and clause 8 is the configuration management clause.
  • Startups pass audits on this clause by documenting the SCM approach the engineering team already runs, not by buying a second tool stack.

Why this matters for your startup

The configuration management question at an audit is almost always the same. A Notified Body auditor points at a version number in the release record and asks, "Show me the source code, the dependencies, and the build environment for this version. Show me what changed between this version and the previous one. Show me who approved the change." A team that has run clause 8 discipline from day one opens three browser tabs and produces the answers in two minutes. A team that has not has a hard week ahead.

This is one of the few clauses of EN 62304:2006+A1:2015 where modern engineering practice and the standard already agree. Git, semantic versioning, pull requests, release tags, dependency lockfiles, reproducible builds — the tooling exists and the discipline is familiar. The regulatory work is to document that discipline as the configuration management approach, extend it to documents and third-party components, and ensure that a released version is reproducible from the record years after the release went out. A startup that gets this right spends very little additional effort on the clause; a startup that ignores it until the audit spends weeks reconstructing history that should have been captured automatically.

The cost of getting SCM wrong is paid twice. First at the audit, when the manufacturer cannot reproduce a released version or cannot explain a change, and the Notified Body writes a finding. Second in the field, when a problem report comes in and the manufacturer cannot tell which versions are affected, which means the corrective action has to be broader and more expensive than it would have been with a clean configuration record. Both failures trace to the same missing discipline.

What clause 8 of EN 62304:2006+A1:2015 actually covers

EN 62304:2006+A1:2015 is organised into eight main clauses. Clause 5 covers the software development process, clause 6 covers maintenance, clause 7 covers software risk management, clause 8 covers software configuration management, and clause 9 covers software problem resolution. The clauses are linked — configuration management under clause 8 is the process that makes maintenance under clause 6, risk management under clause 7, and problem resolution under clause 9 possible, because each of those processes depends on knowing exactly what version of the software is under discussion.

Clause 8 has three sub-processes. The first is configuration identification: every configuration item has a unique identifier and a version, and the set of items that make up a release is documented. The second is change control: changes to a configuration item follow a documented process that includes the reason for the change, the authorisation, the verification, and the traceability to requirements and risk. The third is configuration status accounting: the current and historical state of every configuration item is retrievable, and the information is sufficient to reproduce past releases and to answer audit and field-report questions.

The clause applies to all software safety classes — A, B, and C — under EN 62304:2006+A1:2015. Class C software runs the full set of activities; Class B runs a reduced set; Class A still runs configuration identification and basic change control, because without those the lifecycle has nothing to anchor on. Clause 8 is one of the clauses where the minimum for Class A is still meaningful.

MDR Annex I Section 17 is the legal hook. Section 17.2 requires software to be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management including information security, verification, and validation. Configuration management is one of the principles of the development life cycle, and EN 62304:2006+A1:2015 clause 8 is the harmonised interpretation of what that principle means in practice. Compliance with clause 8 provides presumption of conformity with the configuration management aspects of MDR Annex I Section 17. Post 376 walks through the full Annex I Section 17 mapping.

Configuration items — what has to be under control

A configuration item is anything whose version affects the released product. The test is concrete: if the version of this item changes, does the released product potentially change? If yes, it is a configuration item. If no, it is not.

For most medical device software, the list of configuration items breaks down into five groups. Source code is the first and the most obvious — every file in the repository that becomes part of the released binary or the deployed service. Build scripts and build configuration are the second — the files that define how the source becomes the release. Documentation is the third — requirements specifications, architecture and design documents, test plans, risk-management outputs, the software development plan itself. Third-party components are the fourth — libraries, frameworks, runtime dependencies, and any code the team did not write but ships with the product. The toolchain is the fifth — compilers, interpreters, linkers, and the version of the build environment that produced the release.

The fifth group is the one startups miss most often. A release that compiled cleanly against one compiler version may not compile the same way against a different compiler version a year later, and the binary may not be byte-identical. For software that needs to be reproducible — and regulated software does — the toolchain version is part of the configuration. The modern answer is containerised builds with a pinned base image, and the image digest becomes a configuration item.

Third-party components need their own attention because MDR Annex I Section 17 and the cybersecurity expectations around it require the manufacturer to know what they ship. A software bill of materials (SBOM) is the artefact that captures this, and the SBOM for a release is itself a configuration item. When a vulnerability is disclosed in a library version, the manufacturer who can query the SBOMs for all released versions can answer the question "which versions are affected" in minutes. The manufacturer who cannot has to re-examine every release manually.

The identification scheme

Configuration identification is the naming and versioning convention that makes every item addressable. The scheme needs three properties: every controlled item has a unique identifier, the identifier is stable over time, and the version is monotonic so older and newer versions can be distinguished unambiguously.

For source code, the modern default is that the repository path is the identifier and the git commit hash is the canonical version, with semantic version tags applied to releases. Semantic versioning — MAJOR.MINOR.PATCH with documented increment rules — is the release-level version that matches what the standard expects. The commit hash is the implementation-level pointer that makes the release exactly reproducible.

For documents, the identifier is the document title plus a stable document number, and the version is an explicit version string maintained in the document header and the repository. Documents live in the same repository as the code where possible, so they share the git versioning and the release tagging. Documents that live outside the repository — spreadsheets, diagrams, binary formats — still carry a document number and version, and the current version is referenced from the main documentation index in the repository.

For third-party components, the identifier is the package name plus the registry or source, and the version is the exact version pinned in the dependency lockfile. The lockfile — package-lock.json, poetry.lock, Cargo.lock, go.sum, or the equivalent — is a configuration item and is committed with the source.

For the toolchain, the identifier is the container image name or the documented tool version, and the version is the image digest or an explicit version string. The build process pulls from the pinned version and fails if it cannot.

The scheme is documented in one place — the configuration management plan or the equivalent section of the software development plan — and the engineering team follows it. The scheme does not have to be elaborate. It has to be consistent and it has to be actually used.

Change control — the process that gates every change

Change control under clause 8 is the documented process by which changes to configuration items are authorised, implemented, verified, and recorded. The process does not need to be heavy. It needs to cover six things for every change: the reason for the change, the items affected, the authorisation, the implementation, the verification, and the traceability to requirements and risk.

For most modern teams running a pull-request workflow, the six elements map onto practices the team already runs. The reason for the change is the pull request description, linked to the ticket or issue that triggered it. The items affected are the changed files in the pull request. The authorisation is the code review approval and, for changes that affect regulated behaviour, an explicit review by the designated reviewer named in the development plan. The implementation is the merged commit. The verification is the CI run — unit tests, integration tests, static analysis — attached to the pull request. The traceability is the link from the ticket to the requirement and the risk-management entry.

What turns a pull-request workflow into a clause 8 change control process is the documentation that these six elements are the change control process, and the discipline that every change to a controlled item goes through it. No emergency commits to main. No unreviewed changes to release branches. No undocumented edits to design documents. The process is the same for a one-line fix and a major refactor; the depth of review scales with the change, the process does not.

Change control also covers changes that are not code. A change to a requirement document, a design document, or a test plan follows the same process — reason, authorisation, implementation, verification, traceability. Treating documents as code and running them through the same change control pipeline is the move that saves startups the most time on this clause.

Configuration status accounting

Configuration status accounting is the reporting layer on top of identification and change control. At any moment, the manufacturer can answer three questions with recorded evidence: what is the current version of every configuration item, what was the set of versions at a specific past release, and what changed between two releases.

The current-state query is answered by the repository as it stands. The past-release query is answered by the release tags and the release record — given a release version, the tag points at the exact commit, the commit references the dependency lockfile, the lockfile references the third-party versions, and the toolchain pin references the build environment. The change-between-releases query is answered by the git diff between the two tags plus the corresponding ticket and review history.

The artefact that ties this together is the release record — a small document or database entry created for each release that captures the version number, the commit hash, the SBOM, the build environment reference, the list of changes since the previous release, the verification evidence summary, and the release authorisation. The release record is itself a configuration item. At audit, the release record is the single document the Notified Body asks for first, and it has to be complete for every release that has shipped to users.

Git solves a large portion of clause 8 for source code out of the box. It provides configuration identification through commit hashes and tags. It provides change control through the branching model, pull requests, and review workflows. It provides status accounting through the log, the diff, and the tag history. A team running git with a disciplined pull-request workflow is already doing most of what clause 8 requires for source code.

What git alone does not do is cover everything else. Documents that live outside the repository need to be brought inside it or referenced from it. Third-party dependencies need explicit lockfiles and SBOM generation. The toolchain needs to be pinned and reproducible. Release decisions need an explicit record that links the git tag to the regulatory authorisation. Change-control documentation — the plan that says "this is how we do change control, and every change goes through it" — has to exist.

The practical move is to layer the regulatory discipline on top of the existing git workflow, not to replace the workflow with a second tool. Dependency lockfiles and SBOMs come out of the build process. Documents move into the repository. A release script generates the release record from the git history, the lockfile, and the CI run. The engineering team runs the same workflow they were running before; the regulatory file collects the evidence from that workflow.

Common mistakes startups make

  • Treating git commits as sufficient on their own. Git covers source code well. It does not cover documents that live in a shared drive, dependencies that float to the latest version, build environments that drift with the developer's laptop, or release authorisations that happen in chat without a record. Clause 8 requires all of these under control.

  • Letting dependencies float. Running npm install or pip install without a lockfile produces a build that depends on whatever version the registry happened to serve that day. A release built this way is not reproducible, and the manufacturer cannot answer the "which versions are affected" question when a vulnerability is disclosed.

  • Not including documents in the change control process. Source code goes through pull requests; design documents get edited directly in a shared drive. The two drift, the documentation stops reflecting the code, and the audit finds the gap. Documents under the same change control as code is the fix.

  • No release record. The team tags a release in git and ships. No document captures the decision, the authorisation, the verification evidence, or the SBOM. The audit asks for the release record and the manufacturer has to reconstruct it from logs.

  • Configuration management plan that does not match reality. A plan that describes a heavy process the team does not run is worse than no plan — it is a documented non-conformity. The plan has to describe the workflow the team actually runs, at the depth the team actually runs it.

The Subtract to Ship angle

Configuration management is one of the clauses where Subtract to Ship saves the most work because the engineering team is usually already doing the right thing. The subtraction move is to document the existing engineering workflow as the configuration management approach instead of building a parallel regulatory process.

What this looks like in practice: one configuration management plan, five pages at most, that describes the git workflow, the branching model, the pull-request and review process, the dependency lockfile practice, the SBOM generation, the toolchain pinning, the release record template, and the mapping of each element to clause 8. The plan references the actual tools the team uses by name. The plan is reviewed and updated when the tooling changes. That is the entire regulatory artefact for clause 8 at the plan level.

The evidence is collected automatically. Pull-request histories, CI run logs, release tags, dependency lockfiles, SBOMs, and build environment pins are all machine-readable artefacts that already exist in the engineering tool stack. The regulatory file references them; it does not duplicate them. A release record script that queries the git history and the CI system and produces a one-page release record per release is a two-day engineering investment that eliminates the single largest source of clause 8 audit pain.

Every activity in the configuration management approach traces back to a specific sub-clause of EN 62304:2006+A1:2015 clause 8 and through it to MDR Annex I Section 17. Activities that do not trace come out. For the broader methodology, see post 065.

Reality Check — Is your configuration management ready for an MDR audit?

  1. Can you produce the exact source code, dependencies, and build environment used to build any released version of your software?
  2. Is every configuration item — source, documents, third-party components, build scripts, toolchain — covered by a documented identification scheme?
  3. Does every change to a controlled item run through a documented change-control process with recorded authorisation, verification, and traceability?
  4. Do you have a current SBOM for every release, generated automatically from the build process?
  5. Is the toolchain — compilers, runtimes, build environment — pinned and reproducible, or does it drift with whichever developer built the release?
  6. Do your design documents, requirements, and test plans live under the same change control as your source code?
  7. For each release that has shipped, do you have a release record capturing the version, commit, SBOM, build environment, changes, verification, and authorisation?
  8. Does your configuration management plan describe the workflow your engineering team actually runs, or does it describe a process that exists only on paper?
  9. When a vulnerability is disclosed in a third-party library, can you answer within an hour which of your releases are affected?
  10. If the lead engineer who built the last release left tomorrow, could the next engineer reproduce that release from the configuration record alone?

Any question you cannot answer with a clear yes is a gap. Configuration management gaps compound — a gap today becomes an audit finding in a year and a field-report reconstruction exercise in two.

Frequently Asked Questions

Is git alone enough to comply with EN 62304:2006+A1:2015 clause 8? For source code, git with a disciplined pull-request workflow covers configuration identification and change control well. For the full clause, git needs to be paired with documented change-control practice, dependency lockfiles, SBOM generation, toolchain pinning, document version control, release records, and a written configuration management plan. Git is the foundation; the rest layers on top of it.

What is a software configuration item under EN 62304:2006+A1:2015? A configuration item is any element whose version affects the released product. This includes source code files, build scripts, requirements and design documents, test plans and test data, third-party libraries and frameworks, the toolchain used to build the release, and the release record itself. If changing the version of the item can change the released product, it is a configuration item.

How detailed does the configuration management plan need to be? The plan needs to describe the identification scheme, the change control process, the status accounting approach, the roles responsible, and the tools used. For a small team with a modern git-based workflow, the plan is typically three to five pages. Longer plans are usually signs that the plan describes process the team does not actually run, which is worse than a short plan that matches reality.

What is a release record and why does the audit ask for it first? A release record is a per-release document that captures the version number, the exact source commit, the dependency lockfile or SBOM, the build environment reference, the list of changes since the previous release, the verification evidence, and the authorisation. The Notified Body asks for it first because it is the fastest way to test whether the whole configuration management system actually works — a complete release record means the system is running; a missing or partial release record means it is not.

Does clause 8 apply to Class A software? Yes. Clause 8 applies to all software safety classes under EN 62304:2006+A1:2015. The activities scale with the class — Class C runs the full set with the highest rigour, Class B runs a reduced set, Class A runs configuration identification and basic change control. Even Class A software has to be uniquely identified and under documented change control.

Do we need a separate tool for SCM if we already use git and a CI system? No. The modern engineering tool stack — git, a pull-request platform, a CI system, dependency lockfiles, containerised builds, SBOM generation — already provides most of what clause 8 requires. The regulatory work is documenting the workflow, closing the gaps around documents and release records, and producing the plan that ties the tools to the clause. A second SCM tool on top of the existing stack usually adds confusion, not compliance.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17. Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), Clause 8 — Software configuration management process. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for the QMS under MDR Article 10(9) and Annex IX.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on clause 8 of EN 62304:2006+A1:2015 and the configuration management obligations that apply to medical device software under MDR Annex I Section 17. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the harmonised tool that operationalises the configuration management requirement, not an independent authority. For startup-specific regulatory support on software configuration management, release records, and technical file scoping, Zechmeister Strategic Solutions is where this work is done in practice.