SOC 2 change management is criterion CC8.1 in the AICPA Trust Services Criteria. It asks that you authorize, design, develop, configure, document, test, approve and implement changes to infrastructure, data, software and procedures. You satisfy it with a written process plus records showing every production change followed it.
CC8 contains only one criterion, CC8.1, but the AICPA points of focus under it read like a checklist. This post turns each into a control idea a small team can run. We paraphrase the 2017 criteria with 2022 points of focus throughout.
What does CC8.1 actually list?
The points of focus include managing changes across the system life cycle, authorizing changes before work starts, designing and developing securely, documenting, tracking, configuring software, testing before production, approving, deploying with segregation of responsibilities, evaluating how changes affect objectives, handling changes needed to fix incidents, keeping a baseline configuration, and an emergency change path.
Control ideas, one per focus area
Authorize. Every change starts as a ticket or issue with a requester. Control: no pull request merges without a linked ticket. Evidence: the ticket and PR link.
Design and develop securely. Control: coding standard, required code review, dependency and secret scanning in the pipeline. Evidence: pipeline configuration and a sample of scan results.
Document and track. Control: the ticket, PR description and release notes together form the change record. Evidence: an export of changes for the audit period.
Configure software. Control: configuration lives in version control, including infrastructure as code. Evidence: repository history showing who changed what.
Test. The points of focus mention unit, integration, regression, static and dynamic testing, QA or automated testing, point in time or continuous. Control: required status checks before merge. Evidence: green check history on merged PRs.
Approve. Control: branch protection needing at least one reviewer who is not the author. Evidence: the protection rule export and PR approvals.
Deploy with segregation. The criteria describe restricting unilateral development, testing and implementation by one user. Control: the person who writes code cannot be the only approver, and production deploy rights are limited and logged. Evidence: role lists and deploy logs.
Baseline configuration. Control: a documented baseline for servers, containers and cloud accounts, with drift alerts. Evidence: baseline document and alert history.
Emergency changes. Control: a written break-glass path that allows deploy first, review within a set number of business days. Evidence: each emergency ticket with the after-the-fact review.
Incident-driven changes. Control: incident tickets link to the change that fixed them.
Where do teams get exceptions?
- Admins who can push straight to the main branch.
- Hotfixes with no record.
- Infrastructure changed in a console, outside Git.
- Review required in policy but not enforced by the tool.
- Approvals from the author's own account.
Auditors sample changes across the period, so one unreviewed change in a sample becomes an exception. Enforce rules in tooling instead of relying on habit.
What to do
- Write one change management policy, two pages at most, covering normal, standard and emergency changes.
- Turn on branch protection and required checks in every in-scope repository, and include admins.
- Move infrastructure into code, or log console changes with tickets.
- Define the emergency path and its follow-up review.
- Export a sample of changes monthly and check each has ticket, review and passing tests.
- Keep the baseline and drift evidence beside the change records.
Quick check
Is there more than one criterion in CC8?
No. CC8 has the single criterion CC8.1. The detail sits in its points of focus.
Do all points of focus have to be implemented exactly?
The points of focus are guidance for characteristics of the criterion, not a mandatory checklist. Your auditor judges whether your controls meet the criterion, so agree your approach with them.
How Safeguard helps automate this
Change management evidence usually means chasing pull request history by hand. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. Technical evidence comes from real code and dependencies: scans, SBOMs and reachability. For vulnerable dependencies, Safeguard's agent can open tested fix pull requests that still go through your review. Autonomous remediation 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 issues the report. Book a call to see it.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), criterion CC8.1, read from a local copy on 18 October 2026
Last reviewed: 18 October 2026.
