CI/CD pipelines as audit evidence, not just deployment automation
Practice · CI/CD & Change Control
A regulated CI/CD pipeline run is change control only if it leaves an immutable, attributable audit trail (who changed what, what passed, who approved it, what shipped) retained well past the 30 to 90 days most CI/CD platforms keep by default, because 21 CFR 820 change control is audited long after that.
When is a CI/CD pipeline run valid change-control evidence?
A pipeline run counts as change control only if it leaves an immutable, attributable audit trail: who changed what, what passed, who approved it, and what shipped. That record must be retained well past the 30 to 90 days most CI/CD platforms keep by default.
A pipeline run either produces an immutable, attributable evidence record — who changed what, what passed, who approved it, what actually shipped — or it produces nothing a regulator can rely on, no matter how fast or automated it is. Speed and evidence are not the same design goal, and a pipeline built only for the first one usually can't answer the second.
A green build is a signal, not a release record
A CI/CD pipeline that only reports pass/fail has done its job as automation, but not as change control. Regulated change control (see ISO 13485:2016 §7.3.4 Design Outputs, former 21 CFR §820.30(d), replaced under the QMSR) needs the pipeline run itself to be a durable, attributable record — reproducible enough that someone can answer, months later, exactly what shipped and why it was allowed to.
What a regulated pipeline run needs to capture
| Artifact | Why it matters | Where it comes from |
|---|---|---|
| Commit SHA and author | Ties the build to one specific, attributable change | Version control, captured automatically |
| Test results, per suite | The verification evidence this run is claiming — see Automated Testing Strategy | The CI test step's own structured output |
| Build provenance | Toolchain version and locked dependency set, for reproducibility and supply-chain traceability | Lockfile plus the CI environment's own recorded configuration |
| Approval gate record | Who signed off on the release, and when | The CI/CD platform's own audit log, or a linked change-management system |
| Deployment record | Closes the loop from commit to the environment it actually reached | The CD step's own output — environment, timestamp, deployed artifact hash |
"It passed CI" is not a release decision
A passing pipeline is one input to a release decision, not the decision itself — it says nothing about whether every risk control was verified or the traceability chain is closed. See Regulated Release-Readiness Assessment Protocol for the gate that actually makes the go/no-go call.
Retention: evidence you can't produce isn't evidence
The most common way this quietly fails isn't a missing step — it's retention. Most CI/CD platforms default to retaining logs and artifacts for 30 to 90 days, which is far shorter than a MedTech product's audit or retention window for its audit trail under 21 CFR 820. A pipeline that produces every artifact above but discards it before an auditor ever asks for it has produced nothing usable — retention policy has to be a deliberate, reviewed setting, not whatever the platform ships with by default.
Engineering reference only. Not a substitute for your own change- control procedure or your quality system's document-retention requirements.
Provenance & review state
- Last reviewed
- Sources
-
- ISO 13485:2016 §7.3 (former 21 CFR §820.30, replaced under the QMSR) — International Organization for Standardization
- Former FDA 21 CFR §820.30 (in force until February 2, 2026) — U.S. Food and Drug Administration
- SLSA (Supply-chain Levels for Software Artifacts) specification — Open Source Security Foundation
- Ingested from
-