CC9 Explained: Change Management Controls for SOC 2

The Engineering Team's Least Favourite Part of SOC 2

When Orion's CTO, Arjun, learned about the change management requirements, his first reaction was: "This is going to slow us down."

His second reaction, six months later: "Actually, it made us better."

Change management controls are where compliance intersects most directly with how your engineering team works. Done badly, they create bureaucracy. Done right, they formalise practices that great engineering teams already follow — and create audit evidence as a by-product.

CC8.1 — The Core Change Management Control

This control requires that changes to infrastructure, data, software, and procedures are: authorized, designed, developed (or acquired), configured, documented, tested, approved, and implemented in a controlled manner.

That's a long list. Let's break it into what it means in practice:

Authorized — Someone with authority approved this change before it happened. Not after.

Tested — Changes were tested before going to production. This typically means a dev or staging environment.

Approved — At minimum, a peer code review happened. For high-risk changes, additional approval may be required.

Documented — There's a record of the change — what was changed, why, who approved it, and when it was deployed.

What Auditors Actually Test

Expect the auditor to sample 15-20 production changes from your observation period and test each one:

• Was there a pull request (or equivalent)?
• Did at least one other person review and approve the pull request?
• Was the change deployed after approval (not before)?
• Is there evidence of testing (staging environment, automated tests)?

They will look for: Changes deployed directly to production without a PR. "Emergency hotfixes" that bypassed the review process. PRs that were self-approved (the person who wrote the code also merged it).

Building an Audit-Ready Change Management Process

The Basics (What Every Company Needs)

1. Branch protection rules in GitHub/GitLab

Configure your main/production branch to require:

• At least 1 reviewer approval before merge
• Status checks passing (CI/CD tests)
• No direct pushes to main

This creates automatic evidence. Every production deployment traces to an approved PR.

2. Separate dev/staging/production environments

Code should flow: feature branch → development → staging → production. At minimum: feature branch → staging → production.

This is both a security control (prevents testing in production) and a change management control (proves changes were tested before deployment).

3. Deployment approval records

If you use a CI/CD pipeline (GitHub Actions, CircleCI, etc.), configure it to require manual approval before deploying to production. This creates a timestamped record of who approved each deployment.

4. Change tickets

For significant changes (infrastructure, major features, database migrations), create a ticket before starting work. The ticket should include: what's changing, why, risk assessment, and rollback plan.

The Hotfix Problem

Every engineering team has the hotfix problem. Something breaks in production. You need to fix it in 20 minutes. There's no time for the normal PR review process.

Here's the important thing: SOC 2 doesn't prohibit emergency changes. It requires that emergency changes are handled in a controlled way.

Orion's emergency change process:

1. Emergency changes still require a PR (even if brief)
2. A second engineer must review and approve before deployment (can happen in a Slack DM — but it must happen)
3. The PR is labeled "emergency-change" in GitHub
4. Within 24 hours of the emergency change, a post-change review is documented in a ticket (what happened, why normal process was bypassed, what the impact was)

This gives the auditor what they need: evidence that even emergency changes had some oversight, and a documented exception process.

Infrastructure Changes: The IaC Advantage

If you manage infrastructure as code (Terraform, AWS CDK, CloudFormation), your change management evidence is largely automatic. Every infrastructure change is a PR. Every PR has a review. Every deployment traces to a merge.

This is one of the best arguments for investing in IaC before your SOC 2 audit. If your engineers are still clicking in the AWS console to make infrastructure changes, you have a significant evidence problem — there's no audit trail for console changes unless you're carefully logging and reviewing CloudTrail.

CC9.1 — Business Disruption Risk

Adjacent to change management, CC9.1 requires that you identify and manage risks arising from potential business disruptions. This covers your Business Continuity Plan (BCP) and Disaster Recovery (DR) procedures.

What auditors test:

• Do you have a documented BCP/DR plan?
• Does the plan define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO)?
• Has the plan been tested? (A plan that's never been tested is not a functioning plan)

Orion's DR setup:

• RTO: 4 hours (they can restore service within 4 hours of a major incident)
• RPO: 1 hour (maximum 1 hour of data loss in a worst-case scenario)
• Primary setup: AWS multi-AZ RDS with automated backups
• DR test: Conducted in November 2024 — simulated database failure, verified restore process, documented results

The key evidence item: A dated DR test record showing what was tested, the results, who was involved, and what follow-up actions were identified.

The Separation of Duties Question

One thing auditors look for in change management is separation of duties — the idea that the person who builds a change shouldn't be the only person who approves it.

For small teams, perfect separation of duties isn't always possible. You might only have 3 engineers. The auditor understands this. What they want to see is that you've made reasonable effort to compensate:

• Cross-reviews are required even if the reviewer is from the same team
• At least one other person approves every change
• Clear roles and responsibilities are documented (the person who merges can't also be the person who defined the requirement and did the development in isolation)

What Comes Next

With change management controls in place, we're going to tackle the control that most dramatically affects your audit outcome if it fails: incident response. CC7.3 is where auditors test whether your security monitoring is real — and whether you can demonstrate you responded appropriately to security events.