Change management for SOC 2

By Sam Rivera, Founder, SentinelPanda · June 19, 2026 · 2 min read · SOC 2

You almost certainly already do change management — it is called code review. The SOC 2 work is mostly proving the review and approval happened.

What the control asks for

SOC 2 wants assurance that changes to production systems are authorised, tested, and reviewed before they ship — so a bug or a malicious change cannot reach customers unchecked. It does not prescribe a tool or a ceremony; it asks you to show that someone other than the author reviewed and approved each change and that it was tested.

Your PR workflow already does most of it

A standard pull-request flow maps almost one-to-one: the PR is the change request, the required reviewer approval is the authorisation, the CI run is the testing, and the merge + deploy is the implementation record. If you enforce branch protection (no direct pushes to main, at least one approval, passing checks), you are most of the way to the control already.

The evidence auditors sample

• A selection of changes across the period, each with its review, approval, and passing checks visible.
• Proof that the approver is someone other than the author (separation of duties).
• The link from change to deployment — what shipped, when, and by whom.

Where it breaks

The usual exception is the emergency path: a production incident, a hotfix pushed straight to main at 2am, no review. That is acceptable only if you have a defined emergency-change process and the change is reviewed and approved retroactively, with a record. An undocumented bypass that nobody signed off is exactly the gap an auditor flags.

Make the trail automatic

The least-effort path is to let the tools produce the evidence: branch protection enforces the control, and the PR history is the audit trail. SentinelPanda maps change management to that evidence and flags the direct-to-main pushes that would otherwise become exceptions.