SOC 2 Change Management: Emergency Changes, PR Approvals and What the Auditor Actually Tests

SOC 2 change management trips up engineering teams for one reason: the policy they wrote down doesn't match how they actually ship code. The auditor doesn't care which git workflow you use. Under CC8.1, they sample your production changes and check each one against the process you documented. If your policy says every merge needs a review but your on-call engineer pushed a hotfix at 2 a.m. without one, that's a finding.

Most of the pain comes from copying a template policy that's stricter than your real practice, or from running a solid process that was never written down.

Either gap produces the same result during a Type 2 observation period (the key difference in SOC 2 Type 1 vs Type 2): exceptions the auditor can't reconcile.

The fix is to write the process you actually run, including how emergency changes get approved after the fact, and then defend it.

Key Points

• SOC 2 change management failures happen when the documented policy doesn't match how engineers actually ship code. If your policy requires two reviewers but your team merges with one, that contradiction becomes a finding even though the one-reviewer workflow itself can meet CC8.1 when the policy says one reviewer.
• The AICPA's Trust Services Criteria under CC8.1 require that the company authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes, but the standard never specifies how many approvers you need or which tools to use. A two-person startup and a 200-person engineering org can both meet it when each writes down a process that covers those steps and follows it.
• Emergency changes are auditable when your policy defines when skipping normal review is allowed, names who can authorize it, and requires a post-deployment review within a set number of days. If your on-call engineer merges a hotfix at 2 a.m., the policy should say that's allowed and the pull request should show the after-the-fact review happened.
• SOC 2 does not require every automated test to pass before merge, but if your policy says tests must pass and your team routinely overrides flaky tests, that pattern will be questioned by auditors unless your written rule allows the override and you record the decision in the pull request at merge time.
• AI tools can review or approve code under SOC 2 if you document a risk-based decision. You might let AI agents approve routine low-risk changes like patches and send anything touching customer data to a human reviewer. The control tests accountability, so name a person who owns each tier and answers for what the agent approves.
• The branch protection settings we ask clients to turn on include requiring code owner review, dismissing stale approvals when new commits are pushed, requiring approval of the most recent push, and keeping the bypass list empty or limited to one named break-glass team.

What is SOC 2 change management?

SOC 2 change management is the set of controls that govern how you authorize, test, approve, and deploy changes to infrastructure, data, software, and procedures.

The AICPA's Trust Services Criteria under CC8.1 ask that the company authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

The criterion does not name a tool, set a number of approvers, or require your CI pipeline to pass before merge.

CC8.1 gives you room to define what each of those steps means for your team.

The auditor tests you against your definition.

A two-person startup with a lightweight review process and a 200-person engineering org with tiered approvals can both meet CC8.1 when each writes down a process that covers those steps and follows it.

Where teams get this wrong

They copy a change management policy from a template library, hand it to the auditor, and then operate differently.

The template requires two reviewers on every change, your team merges with one, and the auditor records that gap as an exception.

Start by writing down how your engineers ship today, then tighten the process only where you see real risk.

Trust services criteria and control categories

A SOC 2 report covers one or more of five trust services categories.

Security is mandatory. Availability, Processing Integrity, Confidentiality, and Privacy are optional and depend on what your customers require and what risks your service creates.

Change management sits in the common criteria, which every SOC 2 report covers, under CC8.

CC8.1 is the only criterion in CC8. The AICPA's points of focus for it include authorizing, designing and developing, documenting, testing, approving and deploying changes, plus providing for changes needed in emergency situations. Your auditor will test whether you follow the process you documented.

Some organizations also map change management to Availability when deployments affect uptime, or to Processing Integrity when changes could affect data accuracy.

Use the points of focus as a coverage check for your policy. Your policy should address each one and your evidence should show you followed it.

SOC 2 controls and requirements

The core requirements include change authorization, where someone with appropriate authority approves the change before it reaches production. Testing requirements ask you to validate changes before deployment, but the depth and type of testing depend on the risk the change introduces.

Approval requirements ensure someone other than the author reviews and signs off. Deployment controls govern how changes move to production, including rollback procedures when something breaks.

Documentation requirements ask you to maintain records that trace each change from request through deployment.

CC8.1's points of focus include changes needed in emergency situations, so your policy should address them.

For separation of duties, the auditor expects the person who wrote the code and the person who approved it to be different. Small teams can satisfy this with a second-person review captured in the pull request, even if both engineers rotate on-call.

A pull request with a clear approval, a linked ticket explaining context, and a deployment record showing when the change went live is stronger than a policy document claiming you do these things. The auditor samples your changes and checks the evidence. If the records are incomplete or contradict your policy, that becomes a finding.

Your policy should define who can merge to production branches, who can override branch protection, and how you grant and revoke those permissions. The auditor will test whether your access lists match your documented roles.

Rollback procedures are part of the control set. If a deployment causes an outage, your policy should explain how you revert, who can authorize the rollback, and how you document what happened. The auditor may sample incidents during your observation period and check whether you followed your own rollback process.

Configuration management overlaps with change management when infrastructure changes affect security or availability. If your team uses infrastructure as code, the same review and approval process should apply to Terraform or CloudFormation changes as it does to application code.

SOC 2 Type I vs Type II reports

A SOC 2 Type I report evaluates whether your controls are designed appropriately at a single point in time. The auditor reviews your policies and system configurations but does not test whether you operated those controls over a period.

A SOC 2 Type II report tests whether your controls operated effectively over an observation period. The auditor samples changes, reviews evidence, and confirms you followed your documented process consistently.

Most customers require Type II because it tests whether you ran the policy you wrote. Type I can be a stepping stone if you need to show progress while you build operating history, but it carries less weight in procurement.

For change management, Type I means the auditor checks your branch protection settings and reads your policy. Type II means they pull a sample of merged pull requests and verify each one was reviewed, tested, and approved according to your rules.

If you're preparing for Type II, focus on building consistent evidence during the observation period.

Comparing SOC 2 to other frameworks

ISO 27001 is an international standard for information security management. Its current 2022 edition covers change management under Annex A control A.8.32, which requires changes to information processing facilities and information systems to follow change management procedures. The structure is similar to SOC 2, but ISO 27001 is certification-based rather than attestation-based. You get certified by an accredited body, and the certificate is public. SOC 2 produces a report you share with customers under NDA.

ISO 27001 tends to be more prescriptive about documentation and requires a formal Information Security Management System. SOC 2 gives you more flexibility to define your own controls.

The NIST Cybersecurity Framework 2.0 organizes outcomes into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Change management shows up in Identify (ID.RA-07: changes and exceptions are managed, assessed for risk impact, recorded, and tracked) and in Protect (PR.PS-01: configuration management practices are established and applied).

NIST CSF is a voluntary framework often used by organizations in critical infrastructure or those working with U.S. federal agencies. It is less formal than SOC 2 and does not result in a report or certification. Instead, it provides a structure for assessing and improving your security posture. Many teams use NIST CSF as a foundation and layer SOC 2 on top when customers require an audit.

PCI DSS applies to organizations that store, process, or transmit payment cardholder data, or could affect its security. Requirement 6 covers secure development and change management, including code reviews and testing before deployment.

PCI DSS is more prescriptive than SOC 2. It specifies that you must review custom code, test changes in a non-production environment, and maintain an inventory of system components. If you handle payment data, you need PCI DSS compliance regardless of whether you pursue SOC 2. A strong SOC 2 change management process covers much of the change control and code review in PCI Requirement 6. Its vulnerability management and web application protection items need their own work.

HIPAA applies to covered entities (health plans, healthcare clearinghouses and healthcare providers that transmit health information electronically in covered transactions) and their business associates. The Security Rule at 45 CFR 164.308(a)(8) requires a periodic technical and nontechnical evaluation, including in response to environmental or operational changes that affect the security of electronic protected health information.

HIPAA does not prescribe specific change management workflows, but the Security Rule requires a risk analysis at 164.308(a)(1)(ii)(A) and audit controls at 164.312(b) that record and examine system activity. If you are a SaaS company serving healthcare customers, you may need both HIPAA and SOC 2. The change management controls overlap significantly, so one documented change process can usually produce the evidence for both.

FedRAMP certifies cloud services for government-wide use by U.S. federal agencies. Its Rev5 path, which FedRAMP is replacing with FedRAMP 20x, builds on NIST SP 800-53 controls, including CM-3 (Configuration Change Control) and CM-4 (Impact Analyses).

FedRAMP is far more rigorous than SOC 2. It expects significant ongoing assurance after certification, and Rev5 change control requires documented change decisions and retained records of each configuration-controlled change. If you are pursuing FedRAMP, your SOC 2 change management process is a starting point, but you will need to add layers of formality and evidence.

GDPR is a data protection regulation that has implications for change management. Article 32 requires you to put in place appropriate technical and organizational measures to ensure data security, including the ability to restore availability and access to personal data in a timely manner after an incident.

If your changes affect how you process EU personal data, your change management process should check whether the change needs a data protection impact assessment, which Article 35 requires when processing is likely to result in a high risk to people's rights and freedoms. SOC 2 does not require this, but combining SOC 2 with GDPR compliance often means adding privacy review steps to your deployment workflow.

SOC 2 change management controls are flexible enough to serve as a foundation for most other frameworks. If you build a solid SOC 2 process, you can extend it to meet ISO 27001 or PCI DSS requirements without starting over. Document your process clearly and operate it consistently, because SOC 2, ISO 27001, PCI DSS and FedRAMP assessments all check your evidence against your documented controls.

What will the auditor sample?

Auditors take a system-generated list of every production change in your observation period, check it is complete, and sample from it. For each sampled change, they inspect the change ticket, the pull request approval, test evidence, and the deployment record. They confirm the approver is not the author.

The clause they ask about most is emergency changes.

The most common gap is a policy that contradicts real engineering practice. For example, the policy says every change needs review while hotfixes routinely bypass it.

Your job during audit prep is to make sure every change in the period has a matching record, because you won't know in advance which ones the auditor samples.

That sampling pattern comes from our own audit-preparation playbook, and it belongs on your SOC 2 audit checklist.

How should emergency changes work?

Write an emergency change procedure that covers three things: when skipping normal review is allowed, who can authorize it, and a post-deployment review within a set number of days.

Each emergency change still needs a record. That record is the after-the-fact review itself.

You don't need a separate justification for every incident. The procedure covers the category. Link each emergency change to the incident that triggered it, and the after-the-fact review proves you followed the procedure.

What auditors accept for emergency changes

Auditors accept an emergency change process as long as emergencies are rare and every one was reviewed afterward.

If your on-call engineer merges a fix at 2 a.m., the policy should say that's allowed, name who reviews it and within how many days, and the pull request should show that review happened.

Is requiring tests to pass before merge a SOC 2 requirement?

No.

SOC 2 does not require every automated test to pass before merge. But if your policy, or a platform control you adopted into your control set, says they must, the auditor tests you against that rule.

A flaky test that fails intermittently and gets overridden on every merge creates a pattern the auditor will question.

The written rule has to match what engineering does. If your team merges knowingly with a failing test, record that decision in the pull request at merge time. A decision written before the merge is stronger evidence than a justification added later.

What to do when your compliance platform flags merged pull requests

Give each flagged merge a recorded reason.

If your compliance platform gives flagged changes a justification field, use it for merges that already happened, and record future decisions in the pull request at merge time.

• Start with the current observation period, as that's what the auditor samples. Don't go back and justify six months of old merges unless your auditor specifically asks.
• Keep after-the-fact justifications in one place every time: the platform's field if it has one, otherwise the PR description. Inconsistency raises questions.
• Agree on the approach with your auditor early. A short conversation about how you handle flagged merges saves back-and-forth during the audit.

If you're working through SOC 2 requirements for the first time, have that conversation before your observation period starts.

Can an AI tool review or approve code?

SOC 2 has no rule for or against AI code review. What the auditor accepts is a risk-based decision you wrote down and can defend.

We worked with a software company that wanted AI agents to approve some of its code changes. We had the team sort changes into risk tiers instead of listing every case where an agent could act.

Routine low-risk changes like patches and configuration updates could be approved by an agent. Anything touching customer data went to a human reviewer. The tiers and the reasoning went into the change management policy. A written, risk-based rule like that gives the auditor something to test.

Keeping a human in the loop for AI code review

A human still owns every approval, because the control tests accountability. Where an agent approves inside its tier, name in your policy the person who owns that tier, so every approval in your audit trail traces back to someone accountable.

NIST's AI Risk Management Framework points the same way: its GOVERN 2.1 outcome asks organizations to document roles and responsibilities for managing AI risks and make them clear to the people and teams involved.

A vCISO can help your team make these judgment calls and write them into the policy.

A change management policy your team will actually follow

Branch protection settings for SOC 2

For your main branch, require a pull request with at least one approval before merging, then turn on these settings.

• Require code owner review, so any pull request that touches code with a designated owner needs that owner's approval.
• Dismiss stale approvals when new commits are pushed. An approval from yesterday shouldn't cover code added today.
• Require approval of the most recent reviewable push, so someone other than the last person to push code must approve the pull request.
• Keep the bypass list empty or limit it to one named break-glass team. Never allow a blanket exemption. In classic branch protection, administrators bypass these rules unless you turn on the setting that blocks bypassing.

With these settings on, GitHub blocks a merge to the main branch until the required approvals are in, except for anyone allowed to bypass them.

What belongs in the written policy

Your change management policy should cover normal changes, emergency changes, and who can approve each type. Include the review timeline for emergency changes and how you record decisions when tests are overridden.

Your policy probably doesn't need to mention a penetration test vs vulnerability scan directly. Your release process should say where security testing fits, and our SOC 2 compliance services include writing that into the policy.

To check the rest of your SOC 2 scope, grab our free SOC 2 Readiness Checklist. Change management is one of its ten sections.

Common challenges and best practices

Challenge: emergency changes bypass the documented process

Your policy requires review before merge, but production is down and your on-call engineer pushes a fix without waiting.

Define an emergency change procedure that allows the merge and requires a post-deployment review within a set number of days that you write down. Document who can authorize an emergency change and make sure the after-the-fact review is captured in the pull request or a linked ticket.

Challenge: flaky tests get overridden routinely

Your CI pipeline has tests that fail intermittently. Engineers override them to keep shipping. The auditor sees a pattern of failing tests and approved merges.

Record the override decision in the pull request at the time of merge. A comment explaining why the test failure was acceptable is stronger evidence than a justification added weeks later. If a test is flaky enough to override regularly, fix or disable it so the pattern stops.

Challenge: tool sprawl makes evidence hard to trace

Your team uses Jira for tickets, GitHub for code review, a CI tool for tests, and a compliance platform for tracking. The auditor asks for evidence and you spend hours stitching together a narrative across four systems.

Standardize where each decision lives. Approvals in pull requests, context in tickets, exceptions in one designated system.

Challenge: separation of duties is hard with a small team

You have three engineers. They all rotate on-call and they all ship code. The auditor asks how you enforce separation of duties when the same person might author and approve a change.

Define a small group of eligible reviewers and make sure your audit trail shows who authored and who approved. A second-person review captured in a pull request is usually enough, even if the reviewer is also on-call.

Challenge: the observation period includes a migration or reorganization

You switched from GitLab to GitHub halfway through the observation period. Or you reorganized teams and changed who could approve what. The auditor samples changes from both sides of the transition and the evidence looks inconsistent.

Pick an observation period where your process is stable. If you must include a transition, document the change in your policy and make sure the evidence quality is consistent on both sides.

Frequently asked questions

What are the 5 principles of SOC 2?

The AICPA calls them trust services categories, and older guidance called them principles: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most startups start with Security and add others based on customer requirements and risk. Your change management controls typically map most directly to the Security category, and sometimes Availability.

What is SOC 1 and SOC 2 and SOC 3?

SOC 1 focuses on controls relevant to financial reporting. SOC 2 focuses on the Trust Services Criteria for handling customer data and systems. SOC 3 is a public, high-level version of a SOC 2-style report. If you are a SaaS company being asked about engineering controls like deployments and access, SOC 2 is usually the right framework. SOC 3 is less common in procurement because it has fewer details.

Is SOC 2 legally required?

SOC 2 is generally a market and customer-driven requirement used to prove you have appropriate controls. Some industries or contracts may effectively make it mandatory to win deals or serve certain customers. It is best to confirm what your customers require versus what your legal obligations are in your specific jurisdictions.

Who typically performs a SOC 2 audit?

A SOC 2 audit is performed by an independent, licensed CPA firm. In practice, you will work with an engagement team led by a CPA, supported by auditors who test controls and review evidence. Your internal security and engineering leads own the process, but the auditor must remain independent.

How do we choose an observation period length that will not create avoidable change management exceptions?

Agree on the length with your auditor and with the customers asking for the report. Pick a window where your process is stable and your logging and ticketing are consistent. Many teams avoid periods with major reorganizations or large platform migrations. If you just changed tooling or policies, allow time for habits and evidence quality to stabilize before the period starts. Align the start date with your auditor so sampling reflects your best-operating state.

What evidence is strongest for proving separation of duties when the same engineers rotate on-call and ship hotfixes?

The cleanest evidence is a second-person approval captured in a durable system of record. A pull request review by someone other than the author, plus a linked ticket or incident record showing context. If rotations make this hard, define a small group of eligible reviewers and ensure your audit trail clearly shows who authored, who approved, and when. When true separation is not feasible for a tiny team, discuss compensating controls with your auditor early.

How can teams prevent audit issues caused by tool sprawl across Jira, GitHub, CI, and a compliance platform?

Write down which system holds approvals, ticket context and exceptions. Reduce manual copying by linking artifacts rather than duplicating text, and keep naming conventions consistent so auditors can trace a change end-to-end quickly. Periodic internal spot-checks during the observation period can catch missing links before the auditor does.

Write the process you actually run

Document the process your team actually runs, make sure it covers CC8.1, and follow it every time.

The auditor checks two things: whether your process is designed to meet CC8.1, and whether your evidence matches what you wrote down.

When a team runs one process and documents another, the auditor records exceptions, and a Type 2 report lists them for your customers to read.

Get help with SOC 2 change management

Cycore builds and runs SOC 2 programs for SaaS companies, including the change management policies and audit prep for the observation period.

If your compliance platform is flagging merges and you're not sure what to fix first, talk to an expert.

Cancel anytime.

If you're not saving 100+ hours, you don't pay.