Validated Delivery: CI/CD Under GxP Change Control

Table of Contents

The validation auditor asked for the change record behind a production change made two weeks earlier. The honest answer was a Slack thread, a terraform apply from someone’s laptop, and a Jira ticket with no attachments. None of that is a change record.

GxP change control and modern CI/CD look incompatible until you stop treating the pipeline as the thing auditors object to and start treating it as the change-control system. The PR is the change record; the pipeline is the evidence machine. This post is a mapping you can hand to a teammate—and to your quality team, because none of this works without them agreeing to it. As always: engineering guidance, not regulatory advice.

The PR is the change record

A change record needs: what changed, why, risk assessment, approvals, test evidence, rollback plan. Map it onto the PR template and enforce it in CI:

  • PR template body mirrors the change-record fields—what/why/risk/rollback, in writing, not in review comments.
  • CODEOWNERS requires both an engineering approver and a quality/process approver for regulated paths.
  • Branch protection: no direct pushes to main, required checks, no self-approval (GitHub blocks reviewing your own PR by default—keep it that way).
  • Risk classification in the PR (low/medium/high) drives the evidence the pipeline must produce before merge.

The pipeline is the evidence machine

Every promotion produces an evidence bundle, archived automatically:

  • terraform plan output attached to the PR for infra changes—the reviewer approves the diff they were shown.
  • Test and validation results (unit, integration, and for validated components the IQ/OQ/PQ style evidence your quality team defines).
  • Image digests and artifact hashes—the exact bytes that will run in the validated environment.
  • Signed tags or provenance attestations for released versions.
  • The bundle lands in a versioned, Object-Locked S3 bucket: enduring and attributable, like any other record.

E-signatures: what actually counts

21 CFR Part 11 e-signatures need identity, intent, and a timestamp, bound to the record. You likely have most of it already:

  • Identity: SSO-backed GitHub accounts with enforced MFA; no shared accounts, ever.
  • Intent: the PR approval is the signature act—your quality team’s agreement that a GitHub approval constitutes the e-signature must be written down (this mapping document is the deliverable people forget).
  • Record binding: signed commits or a signature manifest in the evidence bundle linking approver, PR, and artifact hash.
  • Timestamp: you don’t control GitHub’s clock—record it, don’t trust your memory of it; CloudTrail covers the AWS-side actions.

Segregation of duties

  • The pipeline deploys via short-lived OIDC roles, not human credentials—deployer identity is the pipeline’s, approver identity is human.
  • Promotion gates between environments are explicit pipeline approvals, not kubectl from a workstation.
  • Break-glass prod access exists, is alarmed, and requires creating the change record afterward—the retrospective record is the control, not the hope that it never happens.
  • CloudTrail covers who assumed what when; the audit trail assembles itself from Git + CloudTrail + the evidence bucket.

Environment promotion under validation

  1. Non-prod: CI merges deploy automatically; evidence accumulates.
  2. Validation/staging: promotion requires the quality approver on the PR.
  3. Prod: same pipeline, different OIDC role, same evidence shape—never a separate manual process, because parallel processes drift and drift fails audits.

What this buys you

Audit day becomes: “Here is the change record (PR), the approvals (reviews), the evidence (bundle), the deployment (pipeline run), and the audit trail (CloudTrail).” One story, four systems, already joined.


If you only do one thing: make quality approval a required CODEOWNERS rule on the regulated paths this sprint—it forces the PR-as-change-record conversation with your quality team, and everything else builds on that agreement.

Next: observability as audit evidence.

Previous: Should your raw instrument zone become Iceberg?.

Share :

Related Posts

The ALCOA+ Field Guide for Platform Engineers

The auditor asked a simple question: “How do you know this file was not modified after upload?” The team had versioning off, a shared transfer credential, and a fourteen-second silence that felt much longer.

Read More

Hybrid Lab-to-Cloud: a Go-Live and Recovery Checklist

The pilot worked for one instrument on a quiet Tuesday. Cutover week added three instruments, a VPN blip, and a KMS key rotation—and the only recovery plan was “call the person who built the agent.”

Read More

Instrument Ingestion Patterns: Poller, DataSync, or S3 Events

Three instruments, three capabilities. One writes finished runs to a Windows share. One can call the S3 API directly. One ships files over SFTP to wherever you point it. The team forced all three through one custom poller—and spent a year paying for it in special cases.

Read More