CC8.1 Unpacked: What Change Management Means for Engineers

CC8.1 is the SOC 2 change management criterion. It requires that changes to system components be authorized, tested, documented, and implemented in a way that maintains security. For an engineering team, this translates to: you need a documented, consistent process for how code and infrastructure changes go from development to production — and evidence that the process ran during the audit period.

The good news: most engineering teams already have most of this in place via GitHub. The gap is usually documentation (policy doesn't match practice) and evidence (GitHub branch protection is configured but not documented for auditors).

Layer 1 — Code Changes: GitHub Branch Protection

Every code change should go through a PR review before merging to the main branch. For SOC 2, branch protection must be configured — not just practiced:

Minimum branch protection settings for main:

• Require pull request reviews before merging
• Required approvals: at minimum 1 (2 is stronger for SOC 2)
• Dismiss stale pull request approvals when new commits are pushed
• Require status checks to pass before merging (CI/CD pipeline)
• Require branches to be up to date before merging
• Do not allow bypassing the above settings for administrators

# Verify branch protection via GitHub CLI
gh api repos/YOUR-ORG/YOUR-REPO/branches/main/protection

Document in your Change Management Policy: "All code changes to production require a pull request with at minimum one peer review approval. The CI pipeline must pass including automated security scanning. Administrators are not exempt from review requirements."

Layer 2 — Deployment Pipeline: CI/CD Controls

The CI/CD pipeline is a change management control. It ensures that code doesn't reach production without passing defined checks. For SOC 2:

• Every deployment to production triggers from the CI/CD system, not manual git push or direct deployments
• The pipeline includes automated testing (unit, integration) and security scanning (SAST, dependency vulnerability scan)
• Deployment requires a successful pipeline run — no manual bypasses without documented exceptions

Document your CI/CD tools in your system description and reference them in the Change Management Policy. For GitHub Actions, retain pipeline run logs — these become your CC8.1 evidence for each production deployment.

Layer 3 — Infrastructure Changes: IaC Review

Infrastructure changes (Terraform, CloudFormation, CDK) carry the same risk as code changes — a misconfigured security group or IAM policy can expose production data. Apply the same PR review requirement to infrastructure:

• All infrastructure changes go through a PR with at least one reviewer who understands the security implications
• Terraform plan output is attached to the PR for reviewer inspection
• Infrastructure PRs have a specific label or template that prompts security review

For changes that affect security controls (IAM policies, security groups, encryption settings, audit logging), require a second reviewer from the security-aware team members.

Layer 4 — Emergency Changes

Emergency changes are the hardest part of change management for SOC 2. When production is down at 2am, the normal PR process creates delay. Define your emergency change procedure:

Emergency change process:

Documented criteria for what qualifies as an emergency (active P1 incident, data at risk, etc.)

Authorized emergency change approvers (specific named individuals, not just "anyone on-call")

Emergency change goes through modified review: oral approval from an authorized approver, or Slack message approval documented

Post-change review within 24 hours: a retroactive PR or change record documents what was done, who approved it, and why it was classified as an emergency

Every emergency change must be documented. Auditors specifically look for emergency change procedures and verify that emergency changes during the observation period were followed up with documentation.

What Auditors Test for CC8.1

Auditors sample production deployments from across the audit period and verify:

• The commit has an associated PR
• The PR has the required number of approvals
• The CI pipeline passed
• The reviewer is not the same as the author (no self-approval)

They also review your Change Management Policy and verify it describes what you actually do. If the policy says "2 required approvals" but PRs in the sample only have 1, that's a finding.

SecureSpect Change Management Module

SecureSpect's Change Management module provides a central log for change requests, approvals, and deployment records — supplementing your GitHub PR history with a structured record that includes the business justification, risk assessment, and approval chain for each change. For emergency changes, create a change record immediately after the fact with the post-change review attached. Auditors see the complete change record alongside the automated GitHub checks, without piecing together evidence from multiple systems.