Writing a change management policy for SOC 2

For a modern engineering team this policy is mostly a description of your pull request workflow. The two clauses that need thought are emergency changes and who approves when there are only three of you.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

A SOC 2 change management policy has to commit to four things: every production change goes through version control, changes are reviewed by someone other than the author before they reach production, changes are tested before release, and there is a defined path for emergency changes with approval recorded after the fact. If your team already uses pull requests with branch protection and a CI pipeline, you have the controls. The policy is the sentence that says so, and the evidence is your repository history.

That makes this the easiest policy in the set to write and one of the most common places to pick up an exception, because the gap between the written process and the merge that went straight to main at 2am is visible in a log the auditor can read.

25 to 40 Changes an auditor typically samples from your population for a 12 month window

What the policy commits to

1. Changes to application code, infrastructure definitions and production configuration are made through version control. Name the repositories, or name the rule that all of them count.
2. A pull request is reviewed and approved by someone other than the author before merge, enforced by branch protection rather than by agreement.
3. Automated tests run before deployment, and a failing pipeline blocks the release. Say what "blocks" means in your setup.
4. Deployment to production happens from the pipeline, not from a laptop.
5. Emergency changes may bypass the review requirement, but must be recorded and approved retroactively within a stated time.
6. Rollback is possible and the approach is written down.

Write nothing about a change advisory board, a change calendar, maintenance windows or release management committees unless you have them. Those clauses arrive in every template because the templates descend from enterprise IT, and each one invites a request for meeting minutes that do not exist.

How should the policy handle emergency changes?

Badly written, this clause is either absent or so restrictive that your first production outage creates an exception. The version that works has four parts: what qualifies as an emergency, who can declare one, what is allowed to be skipped, and what has to be done afterwards.

Define the emergency narrowly, as a change required to restore service or to remediate an active security issue. Say that any engineer on call may declare one, because requiring an executive at 3am guarantees the process gets ignored. Say that peer review before merge may be skipped, but that automated tests and deployment through the pipeline are not skipped, since those are cheap even under pressure. Then require a retroactive pull request or ticket with an approver, within one business day, and a note of what happened.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

What if the team is too small to separate duties?

Write the compensating control and name the constraint. In a company with two or three engineers, the person writing a change will sometimes be the only person who can approve it. Auditors deal with this constantly and it is not disqualifying. What is disqualifying is silence, because then the unreviewed merge looks like a process failure instead of a known limitation.

The wording that holds up commits to three specifics: that self-approval is permitted only where no other qualified reviewer is available, that every self-approved change is flagged, and that a second engineer reviews the flagged changes after the fact on a stated cadence, usually weekly, with the review recorded. That last piece is what turns an admission into a control. Add the monitoring side as well, since a small team's real defence is that production changes are visible: deployment notifications into a channel everyone reads are worth writing into the policy.

Once you pass roughly six engineers, remove the clause. A compensating control that outlives its cause reads as a company that has not revisited its documents, and the policy templates page covers why the annual review date matters more than the original approval date.

What gets a change management policy turned into a finding?

The policy text almost never fails on its own. What fails is a mismatch between the text and the repository, nearly always one of these.

"All changes are approved by a change advisory board." Cut this sentence. It is the single most common inherited clause and it commits you to minutes for every release. If your review happens in a pull request, say that.

A merge with no distinct approver. The auditor samples changes and checks the approver against the author. One self-approved merge with no emergency record and no compensating control is an exception, and it is usually found in the first ten samples. Turn on branch protection that forbids self-approval before the window opens, rather than trusting the team to remember.

Infrastructure changed outside the process. Companies write the policy about code and then change a security group by hand in the cloud console. If some infrastructure genuinely is managed by hand, write that honestly with a compensating control such as a monthly configuration review, rather than claiming everything is in code.

An incomplete population. Sampling starts from the list of changes you provide. Give a list drawn from one repository when three are in scope and the auditor will question the completeness of everything else you handed over. The checklist section on change management and the policy checklist both work from the same principle: define the scope of the population before you write the clause.

Common questions