IEC 62304 and FDA Design Controls in a CI/CD Pipeline: Requirement-to-Build Traceability
How to build an FDA software release pipeline that produces audit evidence as a side effect of shipping, instead of as a separate documentation project.
Executive brief
- Requirement-to-build traceability means you can start from any released binary and walk back to the exact requirements, risk controls, code changes, and test results behind it, and start from any requirement and walk forward to where it shipped. An IEC 62304 CI/CD pipeline makes that walk a query, not a research project.
- IEC 62304 and FDA design controls ask for the same underlying thing from different angles: controlled inputs, verified outputs, documented reviews, and a release you can reproduce. One pipeline can serve both if the trace data model is designed once.
- The FDA's Quality Management System Regulation (QMSR) took effect on February 2, 2026 and brings design and development requirements in through ISO 13485. The evidence you need didn't shrink. The vocabulary changed.
- The failure that hurts most is drift: trace links kept in a separate tool that stops matching what git and the build server actually did. Fix it by putting requirement IDs into commits, tests, and build metadata, then generating the trace matrix from those records on every build.
- The release gate is where compliance is decided. Build once, sign that artifact, verify the same hash you tested, and bundle the evidence with a human approval.
Why traceability breaks in CI/CD
Most medical device software teams didn't start out regulated. They started with a product, a Git repo, and a Jenkins or GitHub Actions setup that got faster every quarter. Then a 510(k) or a notified body audit showed up and someone opened a spreadsheet.
That spreadsheet is the problem. It's a hand-maintained trace matrix that was accurate the day someone built it. Every merge since then has made it a little less true, and nobody notices until an auditor picks a requirement at random and asks to see the test that covers it.
Continuous delivery makes this worse in a specific way. A team shipping twice a week can't refresh a matrix by hand twice a week, so the matrix gets refreshed before audits, and the gap between "what we tested" and "what we shipped" quietly widens in between.
The fix isn't slowing down. It's moving the source of truth. If the trace links live in the same records the pipeline already creates (commits, pull requests, test results, build metadata), they can't drift, because they're generated from what happened instead of from what someone remembered.
Pick a requirement ID at random and a released build number. Can someone on your team, without asking the person who wrote the code, show the commit that implemented it, the test that verified it, and the result of that test on that exact build, in under ten minutes?
How IEC 62304 and design controls map onto pipeline stages
IEC 62304 is a software lifecycle standard. It defines processes for development, maintenance, risk management, configuration management, and problem resolution, and it scales the required rigor by software safety class (A, B, or C, depending on how bad the worst credible harm is). The FDA's design control requirements are broader, covering the whole device, but software sits inside them and gets audited against them.
The two don't conflict. They describe the same discipline using different words, which is why a single pipeline can produce evidence for both if you map them once and stop thinking about it.
| Pipeline stage | IEC 62304 activity | FDA design control element (ISO 13485 clause 7.3) | Evidence the pipeline should produce |
|---|---|---|---|
| Requirements in version control or an ALM tool | Software requirements analysis | Design input | Versioned requirement records with review approvals |
| Architecture and design review | Architectural design, detailed design (class C) | Design output, design review | Design records linked to requirement IDs, review sign-off |
| Commit and pull request | Unit implementation | Design output | PR referencing requirement IDs, reviewer approval, static analysis results |
| Unit and integration test jobs | Unit verification, integration testing | Design verification | Test reports tagged by requirement, coverage data per safety class |
| System test on the release candidate | Software system testing | Design verification, input to validation | Signed report against a specific build hash |
| Release gate | Software release | Design transfer, final design review | Release record, residual anomaly evaluation, archived build |
| Change after release | Maintenance, problem resolution | Design changes | Change request, impact analysis, regression evidence |
Note the last row. Post-release changes are where teams get caught, because a hotfix under pressure skips the impact analysis that a planned release would have gone through. The pipeline should make the compliant path the only path, including for hotfixes.
The trace chain: what links to what
Before touching any tooling, decide what the chain looks like. Here's the one that works for most Class B and Class C software.
User need, then design input (system requirement), then software requirement, then risk control (where a hazard analysis says software must do something), then architecture item, then code change, then test case, then test result, then build artifact, then release record. Every arrow is a link that either exists or doesn't, and a missing one is a finding.
Where the IDs live
Requirements need stable, human-readable IDs that never get reused. SRS-0142 is fine. A Jira ticket number that gets recycled during a project migration is not.
You've got two workable options for storage. A dedicated ALM (Polarion, Codebeamer, Jama, and similar) gives you review workflows and e-signatures out of the box. Requirements as files in git (Doorstop and StrictDoc are the usual tools) gives you diffs, branches, and a history nobody can quietly rewrite. Either works. What doesn't work is a wiki page.
How the links get made
The link from requirement to code is a convention enforced by automation: every commit message or pull request must carry a requirement ID trailer, and a CI check rejects merges without one. The link from requirement to test is a tag or annotation on the test itself, in the test name, a marker, or a metadata field, so the test report can be grouped by requirement without a human doing it.
The link from test to build is the one people forget. A passing result is only evidence about one specific artifact. If the report doesn't carry the commit SHA and the artifact digest, it proves nothing about what shipped.
If a developer renames a test file, do you find out that a requirement just lost its coverage? Or does the matrix keep showing green from the last time someone generated it?
Playbook: building the FDA software release pipeline
This is the sequence we use when a team already has CI and needs to make it produce evidence. It assumes you're not starting from zero, and it works whether you're on GitLab CI, GitHub Actions, or Jenkins.
Give every requirement a stable ID and a home you can query
Put requirements in an ALM or in git, with immutable IDs and a recorded approval. Export them in a machine-readable form (JSON or YAML) that the pipeline can read on every run.
Assign safety classes and set the rigor per class
Classify each software item under IEC 62304 based on your hazard analysis. Class A asks for the least, Class C for the most, including more detailed design and stricter unit acceptance criteria. Encode those differences as pipeline policy, so a Class C module fails a build on missing unit tests that a Class A utility would be allowed to skip.
Link requirements to risk controls and architecture items
Where the risk file says software must mitigate a hazard, that control becomes a requirement with its own ID and its own test. Carry the hazard reference through, because reviewers at the FDA and at notified bodies read from the risk file outward.
Force the ID into every commit, pull request, and test
Add a commit-msg hook and a required CI check. Add a pull request template with a mandatory requirement field. Tag tests with the requirement they verify, using whatever your framework supports natively.
Generate the trace matrix as a build artifact and fail on gaps
A job collects requirements, commits, tests, and results, then produces the matrix and a gap report. Requirements with no test, tests with no requirement, and code changes with no requirement all fail the build for Class B and C items. Store the output next to the build, not in a wiki.
Build once, sign, and verify the exact artifact you ship
Run the compiler in a container pinned by digest. Sign the artifact and attach provenance (Sigstore cosign and in-toto attestations are practical choices). Every downstream test and the final release must reference the same digest.
Gate the release with a human approval and an evidence bundle
The pipeline assembles the bundle and stops. A named person with the authority to approve reviews it and signs. Deployment proceeds only after that record exists.
Step 5 tends to surface the ugliest surprises. The first time a real gap report runs against a mature codebase, expect hundreds of findings. Triage them by safety class, fix Class C first, and set the gate to warn-only for lower classes while you catch up. Don't switch it to blocking across the board on day one, or the team will route around it.
Anti-patterns that fail audits
These are the ones we've actually seen in pipelines that looked fine on a slide.
| Anti-pattern | What goes wrong | Fix |
|---|---|---|
| Trace links kept only in Jira or a spreadsheet | Links drift from what git and CI did; matrix is stale within weeks | Generate the matrix from commits, test tags, and build metadata |
| Squash merges that discard commit trailers | Requirement IDs vanish from history | Carry IDs in the PR title and squash message, enforced by a check |
| Re-running a failed test until it passes | Flaky results become "evidence"; failure history is lost | Keep every run, quarantine flaky tests visibly, fix the cause |
| Testing one build and shipping a rebuild | Verification evidence doesn't apply to the released binary | Build once; promote the same signed digest through every stage |
| Unpinned toolchain or base images | Compiler or library changes silently between builds | Pin by digest; treat a toolchain bump as a controlled change |
| Requirement edited after tests passed | Verified against a requirement that no longer exists | Version requirements; a change invalidates linked results until re-verified |
| Hotfix branch that bypasses gates | The riskiest change gets the least scrutiny | Same pipeline, same gate, shorter test scope justified by impact analysis |
| Evidence stored on a build server that rotates logs | Records gone when the auditor asks | Archive the bundle to immutable storage with a retention policy |
Last time a test flaked on your release branch, could you show the auditor every run, including the failures? Or only the green one?
The release gate and the evidence bundle
IEC 62304's release activity expects a few things: verification is complete, known residual anomalies have been documented and evaluated, the release procedure is documented, and the released software is archived so it can be reproduced. FDA design transfer asks a related question, which is whether what you're handing to manufacturing (or, for software, to the release channel) matches the approved design.
The evidence bundle answers both. For each release, generate a single package containing the following.
- The trace matrix and gap report for that build
- Test results tagged with the artifact digest and commit SHA
- Static analysis and coverage reports, at the thresholds for each safety class
- The SBOM, with SOUP items and their known anomaly review
- Open defects at release, each with a documented evaluation of residual risk
- Signed provenance for the build
- Who approved, when, and against which version of the release procedure
Approval is a person, not a job. If your quality system uses electronic records and signatures, this is also where 21 CFR Part 11 considerations come in, so the approval step needs authenticated identity and an audit trail that can't be edited.
Keep the bundle in immutable storage (object lock on S3-compatible storage works). The retention period should follow your quality system's record requirements, which for most devices means at least the expected life of the device.
Tool validation and SOUP
Two topics that teams treat as paperwork until an auditor treats them as findings.
Validating the tools that produce your evidence
Your CI system, trace generator, and test harness are software used in the quality system, and ISO 13485 expects software like that to be validated for its intended use, in proportion to risk. That doesn't mean a heavyweight qualification for Jenkins. It means a documented intended use, a check that the trace gap report actually catches a deliberately broken link, and a change control process for the pipeline itself.
A cheap and convincing technique: keep a small negative test suite for the pipeline. One requirement with no test, one test with no requirement, one commit with no ID. The pipeline must fail all three. Run it whenever the pipeline definition changes.
SOUP and the SBOM
Software of unknown provenance (SOUP) is IEC 62304's term for third-party code you didn't develop under its processes. That covers open source libraries, the RTOS, the vendor SDK. You need to identify each item, specify its functional and performance requirements as you use it, and review known anomalies.
Generate the SBOM in CI (CycloneDX or SPDX, with Syft or a similar tool) and diff it on every build. A new transitive dependency appearing in a Class C release without anyone reviewing it is exactly the kind of thing the pipeline should catch on its own.
If a CVE lands against a library in your product tomorrow, can you say which released versions contain it within the hour? If the answer needs someone to grep old build logs, your SBOM isn't a pipeline output yet.
The regulatory angle: QMSR, 524B, and what stays the same
The FDA's Quality Management System Regulation became effective on February 2, 2026. It amends 21 CFR Part 820 by incorporating ISO 13485:2016 by reference, and the agency changed its inspection process at the same time. Design and development requirements now come through ISO 13485 clause 7, with FDA-specific additions in Part 820. Terminology moved too: the design history file concept maps to the design and development file. You can read the agency's own summary on the FDA QMSR page.
For a pipeline, the practical effect is modest. The chain of design input, output, verification, validation, review, transfer, and change control is still what gets inspected. If your traceability was sound before, you mostly need to update the labels in your procedures and evidence templates.
Software-specific documentation expectations for premarket submissions are in the FDA's guidance on the content of premarket submissions for device software functions. If your device qualifies as a cyber device, section 524B of the FD&C Act adds cybersecurity expectations, including a software bill of materials, which is one more reason to produce the SBOM as a routine build output.
Stonetusker builds regulated release pipelines for exactly this environment. If you want to see how we approach IEC 62304 traceability for medical device teams, the Healthcare and MedTech transformation page covers the engagement model.
This article is engineering guidance, not regulatory or legal advice. Confirm classification, submission strategy, and quality system decisions with your regulatory affairs lead.
Concepts covered
- IEC 62304
- FDA design controls
- QMSR
- ISO 13485
- Requirement traceability
- Trace matrix automation
- Software safety classes
- FDA software release pipeline
- SOUP
- SBOM
- Signed artifacts
- Design transfer
- Evidence bundle
FAQ
Does IEC 62304 require a CI/CD pipeline?
No. The standard requires defined processes and the records that show you followed them. It says nothing about how you automate them. A pipeline is simply the most reliable way to produce those records at the speed modern teams ship, because it removes the manual step where evidence goes missing.
Can we keep requirements and traceability in Jira?
You can, but be careful about what Jira is authoritative for. If it holds the requirement text and approvals under change control, that can work. The trouble starts when links between Jira and git are maintained by hand. Generate the links from commit and test metadata, and treat Jira as one input to the matrix, not the matrix itself.
Will the FDA accept automated test results as design verification evidence?
Yes, provided the test protocols were defined and approved before execution, the tools are validated for their intended use, the results are tied to a specific build, and the records are controlled and reviewable. Automation doesn't weaken the evidence. Undocumented or unrepeatable testing does.
How did the QMSR change design controls for software teams?
The FDA's design control requirements are now met through ISO 13485 clause 7 as incorporated into Part 820, instead of the older standalone text. The activities are familiar: inputs, outputs, verification, validation, review, transfer, and changes. Most teams need to update terminology and procedure references, not rebuild their pipelines.
Do we re-run every test after every commit?
Run the full automated suite on every merge to the release branch if your infrastructure allows it, because that's cheap. Formal verification on a release candidate is a separate, deliberate event against a frozen build. For changes after release, a documented impact analysis can justify a narrower regression scope, as long as the reasoning is recorded.
How should open source dependencies be handled in the pipeline?
Treat them as SOUP. Generate an SBOM on every build, review new or changed components before they reach a Class B or C release, record the functional requirements you place on each item, and check known anomalies. Pin versions, and use a diff of the SBOM between builds to flag anything unexpected.
Getting audit-ready without slowing releases down
If your team ships medical device software and the trace matrix still lives in a spreadsheet, we can work with you to move it into the pipeline, starting with the highest safety class and the release gate.
Talk to us about your release pipeline