SOC 2 CC8: one criterion, the heaviest sample
All of change management in SOC 2 sits under a single criterion. It is still the request that takes the longest to answer.
CC8 contains exactly one criterion, CC8.1, and it covers authorizing, designing, developing or acquiring, configuring, documenting, testing, approving and implementing changes to infrastructure, data, software and procedures. One criterion, eight verbs, and every production change you made during the observation window sitting in the population. It is routinely the largest sample an auditor pulls.
1 criterion The whole of CC8
4 change types Application, infrastructure, data, procedure
The four change types matter more than the criterion count. Companies evidence application changes beautifully, because pull requests are already there, and then discover the auditor also wants infrastructure changes, database migrations run by hand, and changes to the procedures themselves. Three of those four usually have no ticket trail at all.
What must a sampled change show?
| Verb in CC8.1 | What the auditor looks for | Where it comes from |
|---|---|---|
| Authorized | Someone agreed the change should happen | The issue or ticket the pull request references |
| Tested | Automated or manual testing ran before deployment | Pipeline run attached to the commit, or a test note on the ticket |
| Approved | Somebody other than the author approved it | Pull request approval, enforced by branch protection |
| Documented | What changed and why is legible after the fact | The pull request description and commit history |
| Implemented | What was approved is what went to production | Deployment record tying the merge to the release |
The one that fails most is approval, and specifically approval enforced by convention rather than configuration. If branch protection allows an administrator to merge without review, the control is that people are careful, and the auditor will find the merge where somebody was not. Turn on the setting, and screenshot the setting at the start and end of the window because the setting itself is evidence.
What if the team is too small to separate author and approver?
Say so, in writing, before the auditor finds it. In a three engineer company somebody will occasionally have to approve their own change, and a stated compensating control is treated very differently from a silent gap. The compensating control that holds up is retrospective review: a second engineer reviews the change within a stated period after deployment, and that review is recorded.
- Write the exception into the change management policy, naming the circumstances in which self-approval is permitted.
- Define the compensating control: who reviews after the fact, within how long, and where the record lives.
- Evidence it running. A compensating control with no records is worse than the original gap, because you have now failed a control you invented.
- Put the same language into the system description, so the report reader sees it in your words rather than in an exception.
The change management policy page has the clause wording, and the change evidence page covers how the sample is drawn and what a pull request has to show.
How do emergency changes work under CC8.1?
They are allowed, and they are the second most common CC8 exception. An emergency change process that exists in policy and has never produced a record means either you had no emergencies, which the incident log will contradict, or you had them and skipped the paperwork. Define the process so it is usable at three in the morning: deploy first, then within one business day open the ticket, record what was done and get the retrospective approval.
Infrastructure as code is a CC8 answer and a CC8 trap
Managing infrastructure through code puts it in the same pipeline as application changes, which is the cleanest possible CC8 evidence. The trap is the console. Any change made by hand in the cloud console bypasses the control entirely, and cloud audit logs will show the auditor exactly which ones they were. Either restrict console write access, or accept that every console change needs its own retrospective record.
Do database migrations and data fixes count?
Yes. CC8.1 names changes to data explicitly, and a manual production data fix run from somebody's terminal is a change to data with no authorization, no testing, no approval and no record. This is the change type companies forget entirely until an auditor asks how customer records get corrected. Route data fixes through a reviewed script in the repository, or through a ticket with a recorded approval, and stop doing them from a local shell.
0 of 6 done ·
Get change management evidence that samples cleanly
CC8 is one criterion and usually the largest evidence pull of the audit. Send your scope and compare firms that will get your tickets and approvals in order first.
Get matchedCommon questions
How many change management criteria does SOC 2 have?
One, CC8.1. It covers authorization, design, development or acquisition, configuration, documentation, testing, approval and implementation of changes to infrastructure, data, software and procedures. The single criterion is misleading about the workload.
How many changes will the auditor sample?
It depends on the population and the firm's sampling approach, but a company shipping daily should expect the change population to be the largest in the audit and the sample to be drawn from it accordingly, typically in the range of twenty to forty changes for a Type 2. Your job is to make the population complete rather than to guess the number.
Does continuous deployment fail SOC 2?
No. Deploying forty times a day is entirely compatible with CC8.1, because the control is the review and testing gate in the pipeline rather than a change advisory board. What fails is a pipeline anyone can bypass, and manual production changes made outside it. What to set up before the window opens is on shipping during the observation window.
Do configuration changes in third-party SaaS count?
If the system is in scope, yes. Changing the identity provider configuration or a security setting in a tool that enforces one of your controls is a change to infrastructure in the CC8.1 sense, and it is also the technology general control CC5.2 asks about.