SOC2 for Builders, Part 4: Change Control, CI, and Deploy Evidence
Auditors don’t want screenshots. They want a chain of evidence that says: this change was reviewed, tested, built, and deployed by an approved process. You can provide that chain without extra work if you wire it into the build.
SOC2 for Builders series
- Part 1: Treat It Like a Product Requirement
- Part 2: Data Classification and Logging Hygiene
- Part 3: Access Control and Least Privilege by Default
- Part 4: Change Control, CI, and Deploy Evidence (this post)
- Part 5: Incident Response, Backups, and Restore Proof
The chain we want to be able to show
- PR with required review.
- CI run tied to the exact commit.
- Build artifact or image tagged with that commit.
- Deploy workflow that takes that tag explicitly.
If that chain exists, change control is already done.
PR -> CI -> Artifact -> Deploy
Make deploys explicit
We avoid “latest” tags and manual deploys. A deploy workflow should take a specific image tag or SHA as input. That makes every release traceable and reversible.
We also log who triggered the deploy and from which commit. That closes the loop.
Keep evidence in the tools you already use
You don’t need a separate evidence system. The PR, the CI run, and the deploy workflow are the evidence. Link them together and you’re done.
Guardrails that matter
These are the guardrails that make the chain hold up under pressure:
- Main branch protected with required checks.
- CI runs on every relevant change.
- Deploys require a workflow run, not a shell command.
- Deploy permissions are scoped to a small, auditable group.
Next up
Part 5 covers incident response, backups, and restore proof. It’s where you demonstrate that you can recover, not just prevent.
Related reading
- Migrating to a Monorepo Without Coupling Deploys
- SOC2 for Builders, Part 5: Incident Response, Backups, and Restore Proof