The IEC 62304 documentation that writes itself: our CI/CD pipeline

IEC 62304 documentation has a bad reputation among developers: Word documents maintained by hand, always one release behind the code, filled in the night before the audit. That is the symptom of a documentation-architecture mistake. The correct principle: documentation is born from the code. Every requirement of the standard that bears on a verifiable fact — which dependencies, which tests, which version, who reviewed what — must be produced by the pipeline, not retyped by a human.

Why generate the documentation rather than write it?

Definition: generated documentation is a build artifact — produced automatically on every release from single sources of truth (Git repository, lockfiles, ticket tracker, test reports) — as opposed to written documentation, maintained manually. IEC 62304 requires accurate life-cycle records. But a hand-maintained document diverges from the code by the second week. A generated document is accurate by construction: if it is wrong, then the build is wrong, and that shows.

A hand-written 62304 document is out of date the moment you sign it. A generated document is accurate by construction.

What mapping between 62304 requirements and CI artifacts?

The SOUP list from the lockfiles

Every third-party dependency is a SOUP (Software Of Unknown Provenance) in the 62304 sense. The pipeline generates a CycloneDX SBOM from the lockfiles (Syft, Trivy, or your ecosystem’s native plugin), then reconciles it with a SOUP registry maintained in the repository: for each component, functional requirements, exact version, known anomalies. The build fails if a dependency appears in the SBOM without an entry in the registry. As a result, the SOUP list structurally cannot be incomplete.

Traceability from ticket IDs

Simple convention: each software requirement has an ID (Jira/Linear/GitHub ticket), each test that verifies it carries that ID (annotation, tag or test name), each commit references its ticket. The pipeline parses the test reports and produces the matrix requirement → tests → result → version. A requirement without a test fails the traceability job. It is the matrix the auditor asks for first — and it is always up to date.

Reviews via PR

62304 requires documented verifications. A PR with mandatory review, named approval and green checks is a verification record: approver, date, content reviewed, criteria passed. You just configure branch protection (no merge without approval or green CI) and export the PR metadata into the release package. No separate review form to fill in.

What does the pipeline look like?

Stages named after what they prove:

stages:
  - build              # reproducible artifact, version = Git tag
  - sbom               # CycloneDX SBOM + SOUP registry check
  - unit-tests         # 5.5 report + coverage
  - integration-tests  # 5.6 report
  - system-tests       # 5.7 report, tagged by requirement ID
  - traceability       # requirements <-> tests matrix, fail on gap
  - security-scan      # SCA/SAST (also: 81001-5-1)
  - release-package    # version manifest, release notes,
                       # known anomalies, PR approvals export

The release-package job assembles everything into a versioned, immutable archive: this is your 62304 release record, ready to be filed in the QMS. The release note itself is generated from the commits and linked tickets — changes, fixed anomalies, residual anomalies.

What cannot be automated?

Everything that involves judgment stays human, and that is normal:

• Intended use and classification: regulatory decisions, not build artifacts.
• ISO 14971 risk analysis: the pipeline can link a test to a risk control measure, but hazard identification and acceptability assessment are cross-functional team work.
• The justification of the software safety class (A/B/C) and the segregation strategy.
• The evaluation of each SOUP: the tool detects the component, a human judges whether its known anomalies are acceptable for the intended use.
• The plans (development, maintenance, configuration): written once, versioned in the repository, reviewed via PR like code.

Automation does not replace these activities: it strips them of the paperwork so they get the time they deserve.

What gains have been observed?

On the projects where I have set this up, three effects recur:

1. The marginal cost of a documented release tends towards zero. Shipping an auditable version no longer takes a week of writing: it is a Git tag. Teams that shipped twice a year can ship every month without documentation debt.
2. Audits become demonstration, not archaeology. Showing a pipeline that fails when traceability has a gap is more convincing than a binder — auditors quickly understand that the system cannot produce an undocumented release.
3. Developers stop suffering quality. When compliance runs through the same tools as the rest of the work (Git, CI, tickets), it stops being a parallel chore and becomes a property of the system.

Start with the SBOM and the traceability matrix: they are the two most-requested artifacts in an audit and the simplest to generate. The rest is added release after release.