SOC 2 change
management.

What the criteria actually say

SOC 2 is built on the Trust Services Criteria, and change management falls mainly under the common criteria covering change authorisation and the management of infrastructure and software changes. The language is deliberately outcome-based: it asks that changes are authorised, designed, developed, tested, approved, and implemented in line with your own stated objectives.

Note the phrasing. There is no mandated number of approvers, no required tool, and no specified workflow. The auditor tests whether you do what you say you do, and whether what you say you do is reasonable for your risk. This is why two organisations can both pass with very different processes — and why copying someone else's policy is a poor strategy.

This page is a practical summary for engineers, not compliance advice. Your auditor's interpretation governs.

Where teams actually lose points

Findings tend to cluster in the same few places, and they are rarely about the normal path. The normal path is usually fine, because it runs through a pull request and a CI pipeline that produce evidence automatically. The problems are at the edges.

• Emergency changes with no retrospective approval. The policy permits an emergency path, the path gets used, and nobody documents it afterwards.
• Direct production access outside the pipeline. Manual database changes and console operations that leave no change record at all.
• Self-approval. The engineer who wrote the change also merged and deployed it, on a small team where that is routine.
• Evidence that only exists inside a system the engineers administer. An auditor may accept it; a serious one will ask who could have altered it.
• Policy and practice diverging. The written policy describes a CAB meeting that has not happened since the company was founded.

Producing evidence without adding process

The efficient approach is to make the evidence a by-product of the control rather than a separate documentation exercise. If approving an emergency database change already produces a signed, timestamped record naming the approvers and the reason, there is nothing left to write up afterwards — and the record was created at the moment of the decision, which is exactly what an auditor prefers.

A TeamSigner delivery contains the action name, the threshold applied, the reason the initiator gave, the issue and expiry timestamps, and a signature from each approving member's device-held key. Because the exact signed pre-image is included, the record can be verified by anyone holding the member public keys, independently of us and of your own systems. Keep the payloads and the change-management evidence question largely answers itself.

A reasonable starting scope

Do not attempt to gate everything before your first audit. Pick the operations that are both high-risk and currently unevidenced, which for most teams means the emergency paths. Break-glass access, manual production database operations, deploys that bypass review, and changes to logging or retention settings cover most of the gap. Ordinary reviewed-and-merged changes are already evidenced by your pipeline.

Common questions

Related