SOC 2 CC8.1: Authorizes, Designs, Tests, Approves, and Implements Changes

SOC 2 CC8.1 is the change management criterion: the single criterion in the CC8 series, covering how changes to infrastructure, data, software, and procedures are authorized, tested, approved, and implemented. It carries 14 points of focus, more than any other criterion in the Trust Services Criteria, and it is where auditors examine everything from pull request approvals to emergency change handling and patching.

What does SOC 2 CC8.1 require?

The criterion's verb chain is the control set: authorize before building, design and develop securely, document what changed, test before production, approve before deployment, and implement with segregation so no single person can push an unauthorized change end to end. CC8.1 applies to every kind of change, which surprises teams that think of change management as a software topic. Firewall rule updates, database schema changes, new infrastructure, patches, and even procedure changes all fall inside it.

CC8.1 does not prescribe a tooling model. A pull-request workflow with pipeline gates satisfies it, and so does a work-order process with maintenance windows. Auditors evaluate whether changes are controlled and evidenced, and whether the process matches how the organization operates.

What are the CC8.1 points of focus?

The AICPA defines 14 points of focus for CC8.1 that apply to all engagements, plus additional points for engagements that include the Availability, Confidentiality, and Privacy categories. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Lifecycle governance. Changes are managed through the full system life cycle, and the objectives a change affects are identified and evaluated as it moves through design, development, and deployment.
• Authorization and approval. Changes are authorized before design or acquisition begins, approved before implementation, and deployed with segregation of responsibilities so a single person cannot develop, test, and release unilaterally.
• Secure design, documentation, and tracking. Changes are designed and developed securely, documented for maintenance and users, and tracked prior to implementation.
• Testing. Internally developed and acquired changes are tested before they reach production, through approaches such as unit, integration, regression, static and dynamic source analysis, or continuous automated testing.
• Configuration and baselines. Software configuration parameters are selected, maintained, and monitored, and a baseline configuration of IT and control systems is created and kept current.
• Incident-driven and emergency changes. Changes required to remediate incidents feed into the change process, and a defined path exists for authorizing, testing, and approving urgent changes.
• Patching. Patches are identified, evaluated, tested, approved, and implemented in a timely manner across infrastructure and software.

Availability engagements add a point of focus on designing and testing for system resilience; Confidentiality and Privacy engagements add points on protecting confidential and personal information during design, development, testing, and change, including privacy by design.

How do you meet CC8.1 in cloud environments?

Cloud and SaaS teams satisfy CC8.1 by making the deployment pipeline the change control system, so the evidence generates itself:

• Pull requests as the authorization record. Protected branches, required approvals, and a PR template that captures what changed and why give the auditor authorization, documentation, and tracking in one artifact.
• Pipeline gates as the testing control. Static analysis (SAST), software composition analysis (SCA), and secret detection run on every change, with deployments blocked on critical findings. Scan results attached to the pull request become automatic audit evidence.
• Environment separation. Development, testing, and production live in separate accounts or projects, and promotion between them goes through the pipeline rather than manual copies.
• Infrastructure-as-code as configuration control. Playbooks and templates version every infrastructure change and demonstrate a controlled, repeatable baseline. For a Type 2 audit, add a periodic drift check confirming the running state still matches the code.
• A documented emergency path. Hotfixes still get a ticket, a post-deployment review, and an approval record, even when the approval happens after the fact.
• Patch automation. Managed runtimes and dependency-update tooling handle much of the patching point of focus; the evidence is the update log and the SLA for applying critical patches.

How do you meet CC8.1 on-prem?

On-prem environments satisfy CC8.1 with work orders and maintenance windows instead of pipelines, and the model passes audits just as cleanly when it is documented:

• Change tickets as the system of record. Every change to servers, network devices, and databases gets a ticket capturing the request, the authorization, the implementation plan, and the outcome. A lightweight approval step (a designated approver rather than a full change advisory board) fits small teams.
• Maintenance windows and rollback plans. Scheduled windows for disruptive changes, with a documented rollback path, cover the deployment and resilience expectations.
• Tiered configuration baselines. A basic secure deployment standard applies to everything in the production and management network (default passwords changed, password policy set, logging enabled, anti-malware installed), while CIS benchmark scanning is reserved for sensitive and internet-facing systems such as firewalls and web servers. Scanning only the critical tier is a defensible position for a Type 1 audit, expanding during the Type 2 observation period.
• Patch cycles with evidence. A monthly or quarterly patch cadence, tracked through the same ticketing system, with an accelerated path for critical vulnerabilities.
• Written test sign-off. Verbal QA (someone calls to say the release looks good) produces no evidence. A short written sign-off with a name and timestamp turns the same activity into an artifact an auditor can verify.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC8.1?

How the compensating control is written matters as much as how it works. SOC 2 reports are read by enterprise procurement teams, and a description that opens with due to organizational constraints reads as an admission. Describing the same mechanism as approvals enforced through mandatory automated security scanning and periodic management review presents a deliberate architecture instead of a limitation.

How does CC8.1 map to ISO 27001:2022?

Organizations pursuing both frameworks can reuse CC8.1 evidence directly for these Annex A controls. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC8.1 executes the changes that other criteria govern. CC3.4 covers assessing the risk of significant changes before they happen, CC7.1 covers detecting configuration changes and vulnerabilities after deployment, and the hardening baseline that changes must respect is established under CC6.1 logical access security. The Trust Services Criteria guide summarizes every series, and the configuration baselines guide for bare metal and the self-hosted GitLab SDLC guide cover two on-prem implementations in depth.

Frequently Asked Questions

What does SOC 2 CC8.1 mean?

SOC 2 CC8.1 requires an organization to authorize, design, develop or acquire, configure, document, test, approve, and implement changes to infrastructure, data, software, and procedures. It is the sole criterion in the CC8 Change Management series and covers software releases, infrastructure changes, configuration baselines, emergency changes, and patching.

What evidence satisfies CC8.1?

Typical CC8.1 evidence includes a change management policy, change tickets or pull requests with approvals, security scan results attached to changes, written test sign-offs, environment separation configuration, baseline configuration records with drift checks, patch reports, and an emergency change log with post-change reviews.

Does SOC 2 CC8.1 require peer code review?

No. CC8.1 requires that changes are tested and approved with segregation of responsibilities, and small teams can meet that with compensating controls: automated pipeline gates (static analysis, dependency scanning, secret detection) that block on critical findings, plus periodic management review of security-relevant changes.

How do you meet CC8.1 without CI/CD?

On-prem and low-automation environments meet CC8.1 with a ticket-based process: documented change requests, a designated approver, maintenance windows with rollback plans, written test sign-offs, and patch cycles tracked in the same system. Auditors evaluate whether changes are controlled and evidenced, not which tooling is used.

What is the difference between CC8.1 and CC3.4?

CC3.4 covers identifying and assessing the risks of significant changes before they are made, as part of risk assessment. CC8.1 covers the operational process of making changes: authorization, development, testing, approval, and deployment. A major change typically touches both, with CC3.4 evidence feeding the CC8.1 authorization step.