Why SOC 2 CC8.1 fails at the evidence stage
Change management is consistently one of the top five SOC 2 findings. Not because SaaS engineering teams don't do code review — almost all of them do. The failure is evidence: the auditor asks for proof that a specific change was reviewed before deployment, and the team can't produce it within the time window expected.
SOC 2 CC8.1 requires that changes to infrastructure, data, software, and procedures are authorised, designed, developed, tested, configured, and implemented to meet change management controls. The key word is "authorised" — someone (or something) must have approved every production change before deployment, and you must be able to demonstrate this retroactively for a 6–12 month period.
Here's how to build a system that generates audit evidence automatically rather than trying to reconstruct it under time pressure.
What SOC 2 CC8.1 actually covers
CC8 is the "Change Management" criterion within the Common Criteria (Security). It maps to COSO Principle 12 (changes controlled and implemented). CC8.1 is the primary control point. What auditors are testing:
- Change authorisation: Was every production change reviewed and approved by someone other than the author before it was deployed?
- Testing: Was the change tested in a non-production environment before production deployment?
- Documentation: Is there a record of what changed, why, and what tests were run?
- Emergency changes: Is there a documented process for urgent changes that bypass normal review, including retroactive review?
- Scope: Does change management cover infrastructure changes (not just code)?
The PR-as-change-record model
The most efficient change management evidence system for SaaS companies is to make the pull request (PR) the primary change record. When done correctly, this satisfies all CC8.1 evidence requirements:
| CC8.1 Requirement | PR Evidence | Where to Find It |
|---|---|---|
| Change authorisation | PR approval from reviewer other than author | GitHub PR → approvals tab; merge event shows approver identity + timestamp |
| Testing evidence | CI/CD status checks (passing) shown on PR | GitHub status checks on PR; GitHub Actions workflow runs linked to commit |
| Change documentation | PR description: what changed, why, affected systems | PR body; linked issue/ticket |
| No self-approvals | Branch protection: author cannot approve own PR | GitHub Settings → Branches → branch protection rules screenshot |
| Deployment record | Merge timestamp + CI/CD deployment log | GitHub merge commit; CI/CD pipeline run (GitHub Actions / CircleCI) |
GitHub branch protection: the exact settings auditors look for
Branch protection rules are the technical enforcement mechanism for change management. Auditors will ask for a screenshot of your branch protection settings. Here's what should be enabled on your main/master branch:
- Require a pull request before merging — no direct pushes to protected branch
- Require approvals: minimum 1 (minimum 2 for high-sensitivity repos — auth, payments)
- Dismiss stale pull request approvals when new commits are pushed — re-review required after changes
- Require review from Code Owners — configure a CODEOWNERS file for security-critical paths
- Require status checks to pass before merging — CI pipeline must be green
- Require branches to be up to date before merging — prevents stale branch deploys
- Restrict who can push to matching branches — only deploy pipeline service accounts
- Allow force pushes: DISABLED
- Allow deletions: DISABLED
Screenshot these settings and store in your evidence repository. Auditors will ask "what prevents someone from merging without a review?" — your answer is this configuration, plus CI enforcement.
GitLab equivalent: Protected Branches → Allowed to merge: Developers+Maintainers, Require approval before merge. GitLab Ultimate has approval rules equivalent to Code Owners.
CI/CD log retention: what you actually need
CI/CD pipeline logs are critical SOC 2 evidence. They prove that tests ran and passed before deployment. Common mistakes:
- GitHub Actions: default log retention is 90 days. SOC 2 Type II audit periods are 6–12 months. You will lose evidence. Fix: use GitHub's log retention setting (Settings → Actions → Artifact and log retention) — set to 400 days minimum. Alternatively, export logs to S3 or artifact storage.
- CircleCI: default retention varies by plan. Export pipeline artifacts to S3 with a 12-month lifecycle policy.
- Heroku Review Apps / simple pipelines: often no log persistence. Add log drain to Papertrail or Datadog with 12-month retention.
What each CI/CD run log must show: commit SHA, branch, test results (pass/fail), security scan results, deployment timestamp, deployer identity (service account). If a log is missing any of these, it is incomplete evidence.
Auto-deploy and SOC 2: does it satisfy CC8.1?
Many SaaS teams use continuous deployment — auto-deploy to production on every merge to main. Auditors sometimes question whether auto-deploy constitutes "authorisation." The answer: yes, when configured correctly.
The key principle: in a properly configured continuous deployment pipeline, the PR approval IS the change authorisation, and the CI/CD pipeline IS the deployment gate. This satisfies CC8.1 when:
- Branch protection requires at least one approving review before merge
- No self-approvals are permitted
- CI/CD status checks must pass before merge is permitted
- The pipeline deploys — not individual engineers — so authorisation is the PR, not a separate deployment trigger
- Pipeline logs are retained as deployment evidence
Document this model explicitly in your Change Management Policy and in your SOC 2 system description. Auditors who understand modern DevOps will accept it. If you have a more traditional auditor, be prepared to walk through the logic.
Infrastructure changes: don't forget IaC
A common SOC 2 CC8.1 gap: change management covers application code but not infrastructure. If an engineer can manually create an S3 bucket, modify a security group, or update an IAM policy through the console without any review, that's a finding.
Infrastructure as Code (IaC) change management requirements:
- All infrastructure changes made via Terraform/CloudFormation/Pulumi — not the cloud console
- IaC changes go through the same PR review process as application code
terraform planoutput reviewed and attached to the PR before approval (CI generates this automatically)- Drift detection (AWS Config, Terraform Cloud, Driftctl) alerts on any manual console changes
- Cloud Console direct changes: prohibited for production, except in documented emergency incidents
Evidence: IaC PR history + Terraform plan/apply logs. For AWS: AWS CloudTrail logs showing all API calls (who changed what, when) as a supplementary control.
Emergency change procedure: the non-negotiable
"What happens when production is down and you need to deploy a fix immediately?" — auditors will ask this. The absence of a documented emergency change procedure is itself a finding. The good news: the procedure can be simple.
Minimum viable emergency change procedure:
- Declare emergency: On-call engineer logs emergency in incident management (PagerDuty / Opsgenie / incident Slack channel)
- Emergency authoriser: Designated approver (CTO / on-call lead) verbally approves — documented in incident ticket
- Deploy: Normal review requirement bypassed; change deployed to resolve incident
- Immediate documentation: PR raised post-deploy or incident ticket updated with what was changed and why
- Retroactive review within 24–48 hours: Normal reviewer reviews the change; approves or raises concerns
- Root cause analysis: Document why the change was necessary and what normal process covers future similar changes
Emergency change tracking: maintain a log of all emergency changes (date, description, approver, retroactive review completed). Report monthly — emergency changes above 5% of total change volume trigger a process review. SOC 2 auditors will sample emergency changes and verify the retroactive review happened.
The 7 common CC8.1 audit failures
| Failure | Why It Happens | Fix |
|---|---|---|
| PRs merged without review | Branch protection not configured; exceptions for urgent fixes | Enable and enforce branch protection; no exceptions without emergency process |
| No emergency change process | "We've never needed one" is not an answer | Document 6-step process; test it once; include in Change Management Policy |
| CI/CD logs deleted after 90 days | Default log retention; audit period is 12 months | Set log retention to 400+ days; export to artifact storage |
| Infrastructure changes via console | "Easier" than IaC for small changes | IaC-only policy; drift detection alerts; CloudTrail as compensating control |
| Production DB access by all engineers | Legacy access from startup phase | Restrict prod DB access; require approval + log for any direct access |
| Self-approvals on PRs | Branch protection not configured; small team "everyone reviews everything" | Configure branch protection: dismiss PR author from approver list |
| No change management for third-party updates | Dependabot auto-merges; SaaS integration updates not tracked | Require Dependabot PRs to go through normal review; security scanning required |
Generate your Change Management Policy
Use the Change Management Policy Generator to create a customised policy aligned to your CI/CD setup, deployment model, and compliance frameworks.
Related generators: Information Security Policy, Secure SDLC Policy, Vulnerability Management Policy, SOC 2 Gap Assessment.
Related reading: Change Management Policy Guide, Secure SDLC Policy Guide, SOC 2 Gap Analysis Guide, Vulnerability Management Policy Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or compliance advice. SOC 2 audit scoping and evidence requirements vary by auditor and engagement. Always work with your qualified SOC 2 auditor to confirm evidence expectations before your audit period begins.