SOC 2 CC8.1: change management, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC8.1, the usual records are these.

• Branch protection settings requiring review
• Sampled pull requests with approvals and passing checks
• Deployment logs

What Polara asks about it

The free readiness assessment asks 5 questions that bear on CC8.1. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• Changes tracked in a ticket or PR system? If yes, show it: GitHub pull request showing code review and approval, Jira change ticket, GitLab merge request approval, or change log entry. If no, the fix: track every production change through a ticket or pull request and export a sample.
• Peer review required before deploy? If yes, show it: GitHub branch protection rules, GitLab merge request settings, Bitbucket branch restrictions, or continuous integration status checks screenshot. If no, the fix: require peer review before every production deployment and export a sample of the reviews.
• Separate dev, test, and prod environments? If yes, show it: architecture diagram showing separate cloud networks or accounts, network segmentation diagram, environment inventory, or account list. If no, the fix: separate production from development and test environments with distinct accounts or projects.
• Emergency change procedure documented? If yes, show it: emergency change procedure in runbook, post-implementation review ticket, emergency change log, or incident change record. If no, the fix: document an emergency change procedure with approval and post-change review steps in the secure development policy.
• Are production deployments approved by someone other than the author? If yes, show it: pull request showing an approving review before the merge, branch protection settings that require an approval, a pipeline approval record, or a change ticket approved before the release. If no, the fix: require approval from someone other than the author before a deployment reaches production, and export a sample of those approvals.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Secure Development Policy covers CC8.1.

Free templates that help, printed in full with Word, PDF or Excel downloads:

• Change management policy template

Connected systems that pull evidence for it:

• GitHub, Branch protection: default-branch protection rules, including required reviews and status checks.
• GitHub, CODEOWNERS: whether a CODEOWNERS file assigns review ownership per path.
• Linear, Completed issues: issues completed in the collection window, with their assignee and state changes.
• Jira, Resolved issues: issues resolved in the collection window, with their assignee and reporter.
• Jira, Projects: the projects on the Jira site.

If you also run ISO 27001, the Annex A controls A.5.3, segregation of duties, A.5.8, security in projects, A.8.4, source code access, A.8.9, configuration management, A.8.19, installing software, A.8.25, secure development, A.8.26, application security needs, A.8.27, secure architecture, A.8.28, secure coding, A.8.30, outsourced development, A.8.31, separate environments, A.8.32, change management and A.8.33, test data ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is change Management. The fix: use version control with branch protection for all production code changes. The proof: screenshot of repository branch protection settings showing required reviews.

An auditor asks two things about it. Is there a documented change management process for code and infrastructure? Is version control in use with branch protection and review requirements?

Is it in your scope?

Yes, always. CC8.1 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Change management: the criteria around it

CC8.1 stands alone in its group, change management. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• CC8.1, this page

Before it: CC7.5, incident recovery. After it: CC9.1, disruption risk. All the criteria are on the Trust Services Criteria page, grouped by category.