SOC 2 change management: the unreviewed commit

A developer opens a pull request on Monday, and a colleague approves it that afternoon. On Tuesday, the developer pushes one more commit to fix a test, then merges. The repository’s settings let the earlier approval stand.

The commit that reached production was never reviewed. The auditor finds it in a sample of twenty-five changes.

Change approval is the part of compliance automation that covers what reaches production. The evidence has to cover every change, including the ones that went around the process.

What is SOC 2 change management?

SOC 2 change management is the control that every change to production is authorized, reviewed by someone other than its author, and tested before release. The evidence links each deployment to its ticket, its approval and its test results.

Why change evidence has gaps

1. Approvals don’t reset on new commits. An approval given before the last commit still counts.
2. Changes skip the ticket. A hotfix ships without one, so nothing links it to a request.
3. Authors approve their own work. Admin rights let someone merge without a second reviewer.
4. Evidence is assembled after the fact. Someone matches deployments to tickets and pull requests by hand before the audit.
5. Emergency changes get no follow-up. A change made at 3 a.m. is meant to be reviewed the next day, and nobody checks that it was.

What it costs

Each unreviewed change is an exception in the auditor’s sample. Assembling evidence by hand takes engineers away from their work for weeks. A change nobody reviewed can also be the one that causes the next incident.

What to fix first

1. Dismiss approvals when new commits arrive. Set it in the repository, and check that the setting stays on.
2. Check every deployment against its pull request. Flag any deployment with no approved, tested pull request behind it.
3. Require a ticket link. A pull request without one can’t merge.
4. Follow up emergency changes. Open a review task the next morning, with an owner and a deadline.
5. Record the evidence at deployment. Store the ticket, approval and test results together, and send them to the compliance tool.

The guide to building change approval evidence has the prompts for each step.

Where it fits

Change evidence joins the rest in audit evidence collection. Changes that fix a security finding also close the ticket opened by vulnerability prioritization.

For every part of compliance automation, from policy to audit evidence, see continuous compliance.