A SOC 2 Type 2 auditor tests whether your change controls operated for the entire observation period, so every production change needs a traceable record: who proposed it, who reviewed it, what tests ran, who approved it and when it shipped. CC8.1 is the criterion. One missing record for a sampled change is a finding.
Why does the period change the game?
A Type 1 report describes the design of controls at a point in time and carries no opinion on operating effectiveness. A Type 2 report covers a period and includes tests of operating effectiveness. That is the difference that bites change management.
With Type 1, you show a documented change policy and a screenshot of branch protection. With Type 2, the auditor asks for a list of all changes in the window, picks a sample, and traces each one end to end. Your policy is the claim. The sample is the test.
What does CC8.1 ask for?
The criterion says the entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures. The AICPA points of focus spell out the characteristics auditors look for: managing changes through the system life cycle, authorization before design, secure development, documentation, tracking before implementation, configuration management, testing, approval, deployment with segregation of responsibilities so one person cannot push their own change unreviewed, and evaluating the effect on objectives.
Paraphrasing the segregation point: restrict unilateral development, testing and implementation by a single user, so unauthorized changes are prevented or detected.
What should each change record contain?
For a typical code change, the chain is a ticket or issue, a pull request, a review by someone other than the author, passing automated checks, a merge to a protected branch and a deployment log tying the commit to production. For infrastructure, replace the pull request with a change in version controlled configuration, or a ticket with an approval if changes are made by hand.
Make sure the ticket and the commit can be linked. Auditors waste time, and so do you, when they cannot connect "deployment at 14:02" to a reviewed change.
How do auditors sample, and how do you prepare?
Auditors usually ask for a population: every change deployed during the period, with dates and identifiers. They then select a sample, with larger populations producing larger samples. They will not tell you which ones in advance.
So prepare the population report now, not in the audit week. If your deployment tool can export every production release with commit IDs, test yourself monthly: pick five at random and trace them. Fix gaps while the period is still running.
What about emergency changes?
Emergencies happen, and the framework does not forbid them. Define an emergency path in your change policy: who can authorize it, what minimum review is required, and a rule that a retrospective review happens within a set number of days. Then follow your own rule every time, and keep the follow up evidence. The auditor judges you against the procedure you wrote.
Where do teams fail?
- Branch protection is on, but admins can bypass it and did so without a note.
- Direct commits by bots or service accounts with no review path.
- Infrastructure changes made in a console with no ticket.
- Approvals given by the author's own account or a shared account.
- Policy says two reviewers, practice says one.
- Tool changes mid period, for example a switch of deployment pipeline, leaving a gap in logs.
- Rollbacks and hotfixes missing from the population.
What to do
- Write a change policy that matches how you actually ship, including the emergency path.
- Enable branch protection with required reviews and checks, and restrict or log admin bypass.
- Make deployments reference a commit or ticket ID automatically.
- Produce a monthly population export of production changes and store it.
- Sample five changes per month and trace each end to end. Record the result.
- Note any tooling change with its date, and keep logs from both tools.
- Review exceptions in a short monthly meeting and keep the minutes.
Quick check
Can the same person write and approve a change?
CC8.1 points of focus call for segregation of responsibilities so that unilateral development, testing and implementation by one user is restricted. A second reviewer, or a documented compensating control, is the usual answer.
Do infrastructure changes count as changes?
Yes. The criterion covers infrastructure, data, software and procedures, so cloud configuration changes need the same traceable record as code.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): criterion CC8.1 and the Type 1 and Type 2 definitions.
How Safeguard helps automate this
Change evidence is a collection problem, and screenshots do not scale across a whole period. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. Evidence is collected from connected systems and code, and monitoring runs between audits, so a gap shows up in week six, not in the audit week. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability that record what each release contained. The remediation agent can open tested fix pull requests for vulnerable dependencies, which then flow through your normal review. It is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. Your independent auditor still performs the test. Book a call to see it.
Last reviewed: 18 October 2026.
