How to Document Change Management for SOC 2 Auditors

What CC8.1 Actually Requires

SOC 2 CC8.1 states: the entity authorises, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

In practice, auditors are looking for: a documented process for changes (especially production deployments), evidence that changes were approved by an authorised person before deployment, evidence that changes were tested before deployment, and a record of what was deployed and when.

You do not need a heavyweight ITIL-style change advisory board. Most SaaS startups can satisfy CC8.1 with a simple pull request review process and a deployment checklist.

Designing Your Change Management Process

Define what constitutes a "change" requiring documentation. Typically: all code changes to production systems, all infrastructure configuration changes (Terraform, CloudFormation), all database schema changes, and all security configuration changes.

Define the approval requirement. For production deployments: require at minimum one peer review (GitHub pull request review/approval) before merge to main. For infrastructure changes: require an additional sign-off from an engineering lead or CTO.

Define the testing requirement. At minimum: unit tests pass in CI/CD pipeline, code linting passes, and the deploying engineer attests the change has been tested in a non-production environment.

Change Ticket Template

Create a change ticket template in Jira or Linear that captures: Change Description (what is changing and why), Risk Assessment (low/medium/high, with brief justification), Testing Performed (what was tested and in which environment), Approval (name and date of approver), Deployment Plan (steps to deploy, rollback plan), and Post-Deployment Verification.

For GitHub-native teams: add a pull request template to your repository that requires developers to fill in testing evidence and risk level. Link the PR to a Jira/Linear ticket for the formal change record.

Production Deployment Gates

Automated gates in your CI/CD pipeline provide strong evidence for CC8.1. Configure: branch protection on your main/production branch (require pull request reviews, require CI status checks to pass before merge), deployment approvals in your CI/CD tool (GitHub Actions environments with required reviewers, CircleCI approval gates).

The CI/CD configuration itself is evidence. Export the GitHub repository settings or your CI/CD configuration as periodic screenshots throughout the observation period.

For infrastructure as code: require that all Terraform/CloudFormation changes go through a pull request with plan output reviewed before apply.

Emergency Changes

Define an emergency change procedure: when a production incident requires immediate action, you may need to bypass the normal approval workflow. This is acceptable for SOC 2 — the key is post-hoc documentation.

Emergency change process: deploy the fix, create a Jira ticket retroactively within 24 hours documenting the change, obtain retroactive approval from an engineering lead or CTO, and conduct a post-incident review.

Document the emergency change process in your Change Management Policy. Auditors understand that emergencies happen — they are looking for evidence that emergency changes are documented and reviewed.

Evidence Collection

Primary evidence: export your Jira or Linear change tickets for the observation period, filtered to production deployments. Each ticket should show the required fields (description, approval, testing). Auditors typically sample 5–10 change tickets.

Secondary evidence: GitHub pull request history showing required reviews were completed before merge, CI/CD deployment logs showing automated tests passed, and branch protection settings screenshots.

For infrastructure: Terraform state history, CloudFormation change sets, or AWS Config change timeline serve as evidence. Pair this with your change ticket records.