A medical software development environment is regulated infrastructure. Source control, CI, issue tracker, and build system are not "dev tooling" — under EN ISO 13485:2016+A11:2021 clause 4.1.6 and EN 62304:2006+A1:2015 clauses 5.1 and 6.1, they are the evidence chain. Set them up once, correctly, and your audits become boring.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN ISO 13485:2016+A11:2021 clause 4.1.6 requires that software applications used in the QMS — including development tools — be validated for intended use, with validation proportional to risk.
  • EN 62304:2006+A1:2015 clause 5.1 requires a software development plan, and clause 6.1 (software configuration management) requires identification, change control, and status accounting for all configuration items, including the build environment.
  • Your source control history, CI logs, and issue tracker are design history file artefacts under EN ISO 13485 clause 7.3.10 when linked to design inputs, outputs, and changes.
  • Tool validation scales with risk. Git itself does not require formal validation; a custom deploy script that moves binaries to production does.
  • The goal is environment-as-evidence: every regulated artefact is generated, versioned, and auditable without a human remembering to copy a file.

Why this matters

Felix has watched this movie more than once. A startup ships a working prototype, raises a seed round, hires its first RA lead, and six months later gets its first audit finding: "No evidence of configuration management for the development environment." The team is bewildered. "We use Git. Everything is in Git." The auditor was not asking about Git. The auditor was asking how the team decided which version of the compiler produced the binary that went to the verification test lab, and how they would reproduce that binary in two years if a post-market issue required it.

That gap — between "we use good tools" and "we can prove which tool, which version, which commit, which test run, on which day" — is where audit findings live. And the fix is not bureaucracy. The fix is setting up the environment so that the evidence emerges automatically.

This post is the setup checklist. It is opinionated on purpose.

What MDR actually says

MDR itself is not prescriptive about development environments. It delegates to standards.

MDR Annex I §17.2 requires that software be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management, verification and validation. MDR Annex II §6.1 requires the technical documentation to contain information allowing the design and manufacturing processes to be understood. Your development environment is the manufacturing process for software.

The operative standards are harmonised.

EN 62304:2006+A1:2015 clause 5.1 requires a documented software development plan that addresses, among other items, the development environment, the development standards and methods, and the tools to be used. This is not a paragraph to gloss over. Clause 5.1.7 specifically requires that the manufacturer "include or reference" in the software development plan a description of the development environment.

EN 62304:2006+A1:2015 clause 6.1 (software configuration management) requires that the manufacturer establish a scheme for the identification of configuration items and their versions, manage changes to configuration items, and maintain configuration status accounting. Clause 8.1.2 extends configuration management explicitly to tools: "The manufacturer shall document the configuration of the software lifecycle support tools."

EN ISO 13485:2016+A11:2021 clause 4.1.6 requires that the manufacturer "document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software." This is the tool validation clause. It applies to any software used for QMS activities — including the issue tracker if you use it to manage CAPAs, the source control system if you use it to store design history records, and the CI system if it generates verification evidence.

EN ISO 13485:2016+A11:2021 clause 7.5 (production and service provision) applies to software manufacture. Your build pipeline is a production process.

A worked example

A three-person SaMD startup is building a Class IIa image analysis tool. They want to set up their development environment once, right. Here is the setup Tibor would pass at Stage 2 without a finding.

Source control. A single Git repository per device, hosted on GitHub or GitLab under an organisation account (not a personal account). Branch protection on main: no direct pushes, pull requests require at least one reviewer, CI must pass. Every commit is signed. Every merge is squashed or linearised so the history is readable. Tags mark every release — not just the binary release, but every build submitted to verification or validation. The repository includes a top-level /docs or /design-history folder where design inputs, design outputs, test protocols, and test reports live as Markdown or PDF alongside the code.

Issue tracker. Linear, Jira, GitHub Issues — the tool is less important than the discipline. Every design input, every change request, every anomaly, every verification task has a ticket. Tickets are linked bidirectionally to commits (via commit message references) and to pull requests. The issue tracker is validated under clause 4.1.6: a one-page validation record stating the intended use (design input management and anomaly tracking), the risk (medium — loss of traceability), the validation approach (scripted test covering create, update, link, export), and the validation result. This record is approved by the PRRC or equivalent.

CI system. GitHub Actions, GitLab CI, Jenkins — again, choose one and document it. Every push triggers a build. Every build runs unit tests, integration tests, static analysis, and dependency scanning. Build artefacts are stored with a retention policy long enough to cover post-market surveillance (typically the device lifetime plus the retention required by MDR Article 10(8) — at least 10 years after the last device is placed on the market, 15 for implantables). The CI configuration file lives in the repository and is itself a configuration item under EN 62304 clause 6.1.

Build reproducibility. The build environment is pinned. Containerisation (Docker) with a hash-pinned base image is the cleanest approach. The Dockerfile is in the repo. The container registry stores every image used for a release build. If you cannot rebuild the binary from last Tuesday in two years, you have a configuration management gap.

Tool validation proportional to risk. Git itself is not validated — it is a widely used tool with a strong defect history visible to the public, and its use is not safety-critical in the 4.1.6 sense. The issue tracker is validated lightly as described above. A custom deployment script that copies a signed binary to a production server is validated more rigorously, with documented test cases covering happy path and failure modes. A code generator that produces safety-relevant source from a model is validated formally under EN 62304 clause 5.1.8.

SOUP inventory. Every third-party dependency — every npm package, every Python library, every system library in the Docker base image — is tracked in a SOUP list with version, purpose, and a risk assessment. The CI pipeline updates this list automatically via a software bill of materials (SBOM) tool such as Syft or CycloneDX. Manual SOUP lists get stale in weeks.

Access control. The repository, CI system, and issue tracker have documented role-based access. New joiners are onboarded through a checklist. Leavers are offboarded through a checklist. Both checklists live in the QMS.

Total time to set this up from scratch for a greenfield project: one to two weeks of focused work by one engineer. Total time saved across the first audit and every subsequent audit: months.

The Subtract to Ship playbook

Here is the order of operations. Do not skip steps, and do not over-engineer any of them.

Step 1 — Write the software development plan first. Not after the code is written. Before. The plan is short: three to five pages. It names the tools, the repository, the CI system, the issue tracker, the build environment, the branching strategy, the review policy, the release process. EN 62304 clause 5.1 requires this document to exist before development starts.

Step 2 — Create the repository with branch protection from day one. Retrofitting branch protection into a repository that has been used without it for six months means your early history is not auditable. Start with protection.

Step 3 — Set up the issue tracker and write the 4.1.6 validation record. One page. Intended use, risk, validation approach, result, approval. File it in the QMS.

Step 4 — Configure CI to run on every push and every pull request. Unit tests, static analysis, SBOM generation. No exceptions, including for "quick fixes."

Step 5 — Containerise the build. Dockerfile in the repo, base image pinned by hash, image published to a registry with retention.

Step 6 — Define your configuration item list. What is under configuration management? Source code, build scripts, CI configuration, Dockerfile, documentation, test protocols, tool versions. This list is referenced by the SDP and reviewed at every release.

Step 7 — Tag every build that leaves the team. Every build submitted to verification, validation, clinical evaluation, or released to production gets a Git tag with a meaningful name and a signed release note.

Step 8 — Document tool validation proportional to risk. A short register: tool name, intended use, risk, validation approach, validation record reference. Review annually.

Subtract this: do not buy a compliance-specific ALM tool in year one. Well-configured mainstream tools (Git + GitHub/GitLab + Linear/Jira + GitHub Actions/GitLab CI) pass audits routinely. Buying Polarion or Codebeamer because you are scared of audits is a classic failure mode — and then nobody on the team uses it, and you fail the audit anyway because the real work happens in Slack.

Reality Check

  1. Does your software development plan exist, and does it name every tool in your environment?
  2. Can you rebuild the exact binary you shipped to the test lab six months ago, byte-for-byte, from a Git tag?
  3. Is every tool used in your QMS activities covered by a clause 4.1.6 validation record proportional to its risk?
  4. Is your CI configuration under version control and treated as a configuration item under EN 62304 clause 6.1?
  5. Do you have an automated SBOM that refreshes on every build, linked to your SOUP list?
  6. Is branch protection enabled on main, with required reviews and required CI checks?
  7. Can you show an auditor the link between a design input ticket, the commits that implemented it, the pull request that merged it, and the verification test that exercises it?
  8. Do leavers lose repository access on the day they leave, through a documented offboarding checklist?

Frequently Asked Questions

Do I need to validate Git itself? No. Git is a widely used, well-understood tool, and its risk in the sense of clause 4.1.6 is low provided you use it through a hosted service with access controls. Document the decision not to validate in your tool validation register, with rationale.

What about my IDE? Generally not validated. The IDE does not produce release artefacts — the CI system does. If you use IDE-specific code generators that touch safety-relevant source, those generators are validated, but the editor is not.

Is GitHub Copilot or any AI coding assistant a validated tool? Treat AI coding assistants as SOUP-like contributors to the development process. Document the policy for their use, review all generated code through the normal pull-request process, and do not allow unreviewed AI output into release branches. The responsibility for the code stays with the human author.

Do I need Polarion, Codebeamer, or Jama for an audit to pass? No. These tools can help at scale, but they are not required by EN 62304 or EN ISO 13485. Many successful Class IIa and IIb SaMD certifications use mainstream developer tools configured correctly.

How long do I have to keep build artefacts and CI logs? At least as long as MDR Article 10(8) requires for technical documentation: 10 years after the last device is placed on the market, 15 for implantables. In practice, "forever" is cheaper than deciding.

What if my issue tracker has an outage and I lose data? Your QMS should require regular exports or backups of the issue tracker, documented in the clause 4.1.6 validation record. If the tracker is cloud-hosted, review the provider's SLA and document the reliance.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2; Annex II §6.1; Article 10(8).
  2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clauses 5.1, 6.1, 8.1.
  3. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clauses 4.1.6, 7.3, 7.5.
  4. MDCG 2019-11 Rev.1 (June 2025) — Guidance on qualification and classification of software in Regulation (EU) 2017/745.