How do I write a change management policy for SOC 2?

What Change Management Means for SOC 2

Change management (CC8.1) proves that changes to your systems don't happen randomly. Auditors want evidence that code changes are reviewed, approved, and deployed through a controlled process — and that your policy describes that process accurately.

For most SaaS startups, change management is just your existing GitHub workflow, formalized into a policy.

What to Include

Section	Content
Scope	Which systems the policy covers (production application, infrastructure, configurations)
Change types	Standard changes (PRs), emergency changes (hotfixes), infrastructure changes
Approval process	Who reviews and approves changes (e.g., one engineering peer)
Testing	How changes are tested before production (CI pipeline, preview deployments)
Deployment	How approved changes reach production (merge to main triggers Vercel deploy)
Emergency changes	How hotfixes bypass normal process and what documentation is required after
Rollback	How to revert a problematic change

Example Policy Statements

• "All application code changes require a GitHub pull request with at least one approving review before merge to the main branch."
• "Branch protection rules on the main branch enforce required reviews and prevent force pushes."
• "Merging to main automatically triggers deployment to production via Vercel's GitHub integration."
• "Emergency changes may bypass the standard review process. A post-deployment PR with review must be created within 24 hours, documenting the reason for the emergency change."

What Auditors Look For

Auditors will pull a sample of recent deployments and check:

1. Was there a PR for each deployment?
2. Did someone other than the author approve it?
3. Did automated tests run before merge?
4. Was the change linked to a ticket or description?

If your policy says "two approvals required" but your GitHub settings only require one, that's a finding. Write the policy to match your actual settings.