Skip to content
compliancebase
SOC 2CC8 — Change Management

CC8.1

Change Management

SOC 2 · 2017 TSC (2022 Revised Points of Focus) · Last verified July 2026

Objective

The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

Points of focus

  • Authorizes changes prior to implementation
  • Tests changes prior to implementation where appropriate
  • Approves changes prior to implementation
  • Documents changes
  • Configures infrastructure and software changes under change control

Implementation notes

Under AICPA Trust Services Criteria, CC8.1 covers authorizing, testing, approving, documenting, and implementing changes to infrastructure, software, data, and procedures. Protect main and release branches; require peer review for application and infrastructure-as-code repos that can affect production. Deploy only through CI/CD pipelines so commits, tests, approvals, and release records link end to end. Ban standing cloud-console changes for in-scope resources — or ticket and reconcile them. Define emergency (break-glass) change rules with logging, notification, and mandatory post-implementation review within a set window. For Type II, export a complete population of production deploys for the period and retain samples that show authorization, test evidence, approval, and implementation timestamps auditors can trace.

Audit tip: Provide a population of production changes and samples showing request/PR, review, tests, and deploy record.

Evidence auditors typically request:

  • Change / deployment policy
  • PR approval rules on production repos
  • CI pipeline configs and test gates
  • Deployment logs linking commits to releases
  • Emergency change retrospective records

Common gaps

  • Direct pushes to main / production
  • Missing approvals on infrastructure-as-code
  • Hotfixes without post-implementation review
  • Config changes in cloud consoles outside IaC

Cross-Framework Mapping

FrameworkRequirementImplementation note
SOC 2CC8.1This control
ISO 27001A.8.32, A.8.9Change management & configuration
HIPAA164.308(a)(5)(ii)(C)Log-in monitoring related ops; change via security mgmt
GDPRArticle 32(1)Integrity and availability of systems

Primary sources

Frequently Asked Questions

Yes when they alter production behavior or risk posture. Manage flag flips under change policy proportionate to risk — high-impact flags should have the same authorization and review trail as code deploys, even if the binary did not change.

Yes. Infrastructure and configuration changes that affect the in-scope system are part of CC8.1. Apply branch protection, reviews, and pipeline deploys to Terraform/CloudFormation/Kubernetes manifests the same way you do application code.

Allow break-glass paths for genuine incidents, but require logging, stakeholder notification, and a mandatory follow-up review that documents what changed and whether lasting controls need updates. Unreviewed hotfixes are a frequent Type II finding.

Sample size depends on firm methodology and period volume. Your job is a complete, exportable population of production changes and clear evidence packets so any sample traces request → review → test → deploy without gaps.

Automated tests are strong evidence that changes were tested prior to implementation, which aligns with common CC8.1 points of focus. If some change types use manual testing, document the procedure and retain dated test evidence equivalent in quality to pipeline artifacts.

Framework versions referenced in this page:

  • SOC 2 — 2017 TSC (2022 Revised Points of Focus)

Last verified: July 2026 · Primary sources linked above