SOC 2 Change Management Controls: Why Skipping Approval Steps Fails Audits

Introduction

Of all the control categories auditors examine during a SOC 2 audit, change management is the one that most consistently reveals the gap between how an engineering organization thinks it operates and how it actually operates. Access controls can be verified through configuration exports. Encryption can be confirmed programmatically. But change management is a process control, and process controls are only as strong as the consistency with which people follow them under normal operating conditions, not just during audit preparation.

The failure mode is familiar. An organization builds a change management process for the audit, documents it carefully, and follows it diligently during the observation period setup. Then six months in, a critical bug needs to be fixed before a customer call. An engineer pushes a fix directly to production without opening a ticket. The next week, the same thing happens with a configuration change. By the time the audit arrives, the ticketing system shows a change management process that looks functional, and the production deployment logs show a different story.

Auditors are experienced at finding exactly that discrepancy. They do not just review your change management policy and accept that it reflects reality. They compare your documented change records to your actual deployment history and look for changes that happened outside the process. Those undocumented changes are findings, and in environments where the pattern is systemic rather than isolated, they represent one of the most common sources of qualified opinions in SOC 2 Type II reports.

This guide explains what change management means under SOC 2, what specific artifacts auditors require as evidence, the most common gaps that produce findings, and how to design a change management process that engineering teams will actually follow because it fits how they work rather than fighting against it.

---

What Change Management Means Under SOC 2

Change management under SOC 2 sits within the Common Criteria, specifically CC8.1, which requires that the organization authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. That sentence is dense, and unpacking it reveals the full scope of what auditors are evaluating.

The requirement is not simply that changes go through a ticket. It is that changes follow a lifecycle with distinct, evidenced stages: authorization before work begins, documentation of what the change entails, testing before deployment to production, approval from an appropriate party, and implementation in a controlled manner. Each stage needs to leave a record that an auditor can examine and verify.

The underlying security rationale is straightforward. Unauthorized or untested changes to production systems are one of the leading causes of both security incidents and service outages. A change that introduces a misconfiguration, opens an unintended network path, or modifies access controls in a way that violates least privilege principles creates security risk that accumulates over time if not caught. The change management process is the mechanism for catching those issues before they reach production rather than after.

For SOC 2 purposes, change management applies to three categories of change that organizations sometimes treat differently but that auditors treat with equivalent scrutiny.

Application code changes are the changes most engineering teams think of first: feature development, bug fixes, dependency updates, and API modifications. These are typically well-covered by existing development workflows because they go through code review and deployment pipelines naturally.

Infrastructure changes are where coverage becomes inconsistent. Changes to cloud resource configurations, network rules, IAM policies, database parameters, and environment variables are infrastructure changes. Organizations that have excellent change management for application code but allow engineers to modify security groups or IAM roles directly in the AWS Console without a corresponding ticket and approval have a systematic gap.

Configuration changes cover changes to application configuration outside of code, environment variable updates, feature flag modifications, secret rotations, and changes to monitoring and alerting rules. These are frequently the least well-covered category because they feel operational rather than developmental and do not always follow the same workflow as code deployments.

Understanding that auditors examine all three categories, not just application code deployments, is essential for designing a change management process with complete coverage.

---

What Artifacts Auditors Actually Require

Knowing what auditors look for as evidence of change management control operation allows you to design the process around producing that evidence naturally rather than generating it as a post-hoc documentation exercise.

The Change Record

Every change to in-scope production systems should produce a change record. For application deployments, this is typically a ticket in a project management or ITSM tool, or a pull request in a version control system, or both. For infrastructure changes, this is a ticket that references the specific resource being modified, the nature of the change, and the business or technical justification.

Auditors look at change records for completeness and timing. A change record that was opened after the deployment occurred is not evidence of an authorization and approval process. It is evidence of retroactive documentation, which is a different thing. Timestamps matter, and auditors check them against deployment logs.

A complete change record contains: a description of the change, the system or resource affected, the requestor, the justification, test results or a test plan, the approver and approval timestamp, and the deployment date. Records that omit any of these elements are incomplete evidence.

Approval Evidence

The approval is the control that change management is designed to enforce, and it is the element auditors scrutinize most carefully. An approval from a second engineer who reviewed the code or configuration change before it was deployed to production is the baseline expectation. The approval should come from someone with appropriate authority, which typically means a peer or senior engineer for routine changes and a manager or security team member for changes that affect security controls.

Auditors look for: the identity of the approver, the timestamp of the approval relative to the deployment, and evidence that the approver is distinct from the person who made the change. Self-approval, where the engineer who wrote the change also approved it for production deployment, is a finding. It defeats the purpose of requiring approval as an independent review step.

In GitHub or GitLab workflows, pull request approval records with reviewer identity and timestamps provide this evidence automatically. In Jira or ServiceNow workflows, the approval field with timestamp and approver name serves the same purpose. The evidence needs to be exportable in a format that shows the approver's identity, not just a checkbox that indicates approval was recorded.

Test Evidence

Testing before production deployment is a requirement of CC8.1. What constitutes adequate testing depends on the nature of the change and should be defined in your change management policy, but the evidence requirement is consistent: there should be a record showing that the change was tested in a non-production environment before it was deployed to production.

For application code changes, automated test suite results from a CI pipeline attached to the pull request are excellent evidence. They show what was tested, when it was tested, and whether the tests passed. For infrastructure changes, a deployment to a staging or development environment before production is the testing equivalent. For configuration changes, testing might mean verifying the configuration in a lower environment or reviewing the change against a documented checklist.

Changes deployed to production without any test evidence are a finding. The risk is not theoretical. An untested change that breaks a security control, causes a data exposure, or creates a service outage is exactly the scenario that the testing requirement is designed to prevent.

The Deployment Record

Separate from the change ticket, auditors look for evidence of the actual production deployment: what was deployed, when it was deployed, and by whom. Deployment logs from a CI/CD platform, release records in a deployment management tool, or Git commit history showing when code was merged to the production branch serve this purpose.

The deployment record is compared against the change record to verify alignment. A deployment that occurred at 2:47 PM on Tuesday and a change ticket that was approved at 3:15 PM on Tuesday tells a story that the auditor will explore. The approval came after the deployment. That is an unauthorized change, regardless of whether the approval was eventually obtained.

---

The Most Common Change Management Gaps

Beyond the general pattern of incomplete coverage described above, specific gap types appear with high frequency across SOC 2 assessments. These are the issues most worth checking for before the observation period begins.

Direct console changes with no ticket

The AWS Console, GCP Console, and Azure Portal allow engineers to make infrastructure changes directly without going through any code review or ticketing workflow. A security group rule changed in the console. An IAM policy modified directly. An environment variable updated through the cloud provider's interface. These changes are reflected in CloudTrail or equivalent audit logs but have no corresponding change ticket, no approval record, and no test evidence.

This is the most common change management gap in cloud-native engineering organizations. Teams that have rigorous pull request processes for application code often have no equivalent discipline for console-based infrastructure changes because the console feels like an operational tool rather than a deployment mechanism.

The fix requires two components: a policy that explicitly prohibits direct console changes to production systems for categories of change covered by the change management process, and technical controls that either enforce the policy (read-only console access in production, enforced deployment through IaC pipelines) or detect violations (CloudTrail monitoring for console-based changes to sensitive resource categories that alerts when detected).

Emergency changes without retrospective documentation

Emergency changes, sometimes called hotfixes or break-glass changes, are legitimate. When a critical security vulnerability is being actively exploited, waiting for a normal change approval cycle creates more risk than it prevents. The SOC 2 expectation is not that emergency changes never happen. It is that emergency changes follow a defined expedited process and are documented retrospectively when the emergency has passed.

What auditors find frequently is emergency changes that were never documented at all. The fix happened, the incident was resolved, and the change record was never created because by the time the crisis was over, everyone had moved on. Those undocumented emergency changes show up in deployment logs with no corresponding ticket, and they are findings.

Defining an emergency change process with explicit retrospective documentation requirements, and checking that deployed changes in the emergency category have corresponding tickets opened within 24 hours, is the practical fix.

Infrastructure-as-code changes without PR review

Organizations that have adopted Terraform, CloudFormation, or Pulumi for infrastructure management sometimes treat IaC changes as code changes subject to pull request review, which is correct. But there are commonly exceptions that create gaps: engineers with direct Terraform apply access to production who run applies outside the pipeline, Terraform workspaces where the approval requirement is not enforced at the branch protection level, or CloudFormation stack updates made directly through the console rather than through a pipeline.

IaC changes that modify security-relevant infrastructure, including VPC configurations, security groups, IAM policies, KMS key policies, and database parameters, are exactly the change category where the approval requirement matters most. Verifying that branch protection rules require at least one reviewer approval before merges to the production branch, and that production infrastructure deployments can only be triggered through the pipeline rather than directly, closes this gap.

Dependency and library updates without security review

Automated dependency update tools like Dependabot and Renovate create pull requests for dependency updates automatically. In many organizations, these are approved and merged quickly because they are seen as routine maintenance rather than security-relevant changes. However, dependency updates can introduce breaking changes, security regressions, or supply chain risks, and treating them as automatically safe is inconsistent with the change management control's purpose.

Auditors looking at change records from an organization using automated dependency tools will notice if hundreds of dependency update PRs were approved by a single reviewer who reviewed each one in under a minute. That pattern suggests rubber-stamping rather than genuine review. The fix is not to slow down dependency updates dramatically but to ensure that the approval process, even for routine updates, reflects genuine review of what changed.

Lack of coverage for configuration changes outside code

Feature flags, environment variables, application configuration files managed outside version control, and secrets rotation are all configuration changes that affect the behavior of production systems. In many organizations, these fall into a gray zone where the engineering team does not treat them as deployment events covered by the change management process but the auditor does.

Reviewing where these changes happen and ensuring they either flow through the ticketing and approval process or are handled through a documented operational procedure with its own approval requirement closes a gap that frequently goes unnoticed until an auditor raises it.

---

Building a Change Management Process Engineering Teams Will Follow

The most common mistake in designing a SOC 2-compliant change management process is treating compliance requirements and engineering velocity as inherently in tension. They are not. A well-designed change management process can enforce every requirement auditors look for while fitting naturally into how modern engineering teams work rather than adding bureaucratic overhead that teams route around.

Start with how the team already works

If your team uses GitHub pull requests for code review, the change management evidence for application code deployments is already being generated. The PR record shows the change description, the reviewer, the approval timestamp, and the merge time. The CI pipeline attached to the PR shows test results. Adding change management for application code means ensuring that these existing records are complete and meet the audit standard, not adding a parallel ticketing process.

The work is ensuring that PR descriptions include sufficient context for the change to be understandable to a reviewer who did not write it, that the CI test results are attached and show pass status before approval, and that self-approval is blocked at the repository settings level so that the person who opens the PR cannot be the only approver who merges it. These are configuration changes to existing workflows, not new workflows.

Make the process explicit for infrastructure and configuration changes

Infrastructure and configuration changes need the same discipline as application code changes, but they do not have the same natural workflow scaffolding. Defining the process explicitly for these categories means answering: where does the change get documented, who reviews and approves it, how is it tested before production deployment, and where is the production deployment logged.

For IaC changes, the answer typically mirrors the application code process: IaC changes go through pull requests with the same review and approval requirements. For console-based operational changes that cannot be avoided, the process might mean opening a ticket before making the change, having a second engineer on a call to observe and approve, and documenting the change and outcome in the ticket within a defined timeframe.

For organizations using a full infrastructure-as-code model, the right technical control is removing direct production console access entirely and enforcing all production changes through pipelines. This is both the strongest change management control and the approach that eliminates the category of undocumented console changes as a finding source.

Define the emergency change process explicitly

A written emergency change procedure that is separate from the standard change process acknowledges that emergencies happen and gives teams a defined path that does not require circumventing the entire change management framework. The procedure should specify what qualifies as an emergency change, who has authority to authorize one, what abbreviated approval steps are acceptable in an emergency, and what retrospective documentation is required after the emergency is resolved.

Having this procedure written and communicated means that when an emergency happens, engineers follow the defined process rather than improvising. It also means that when an auditor finds an undocumented emergency change in the deployment logs, you can show them the emergency change procedure and explain why this specific case is an exception rather than having no explanation available.

Build the evidence record into the tooling

The most sustainable change management evidence programs use tooling that generates evidence automatically as part of the process rather than requiring manual documentation steps. Deployment pipelines that record deployment events, approver identities, and test results to a centralized log as part of each deployment run create evidence without requiring engineers to take any additional action beyond following the normal deployment process.

This design principle applies across the change management evidence categories. If collecting the evidence requires engineers to do something extra after the deployment, the evidence will be inconsistent because the extra step gets skipped under pressure. If the evidence is generated automatically as a byproduct of the deployment, it is consistent because it does not depend on anyone remembering to do it.

---

Tying Change Management to Your Broader Compliance Program

Change management does not operate in isolation from other SOC 2 controls. The change management record is often the evidence that connects other control areas, and gaps in change management can cascade into gaps in related controls.

The relationship with vulnerability management is direct. Patches and security fixes are changes subject to the change management process. A vulnerability management program that requires critical patches to be applied within a defined SLA needs the change management process to be fast enough to support that SLA. If the standard change approval cycle takes five days and the vulnerability SLA requires patching within 72 hours of a critical disclosure, the processes are misaligned in a way that will produce findings in both control areas.

Before your observation period starts, run the checks that will tell you whether your change management coverage is complete. Pull the deployment logs for your production systems covering the previous 90 days. For each deployment event, verify that there is a corresponding change ticket with an approval record predating the deployment. For each change ticket, verify that test evidence is attached and that the approver is distinct from the change author. The gaps you find in this exercise are the gaps the auditor will find.

For organizations that are also looking at their gap analysis for cloud infrastructure, the change management controls for infrastructure changes are directly relevant. Undocumented console changes that introduce misconfigurations often surface in a cloud infrastructure gap analysis before they appear in a change management audit, and connecting these findings helps prioritize remediation. If you are working through a comprehensive pre-audit review, the SOC 2 Gap Analysis for Cloud Infrastructure guide covers the infrastructure side of these same controls in detail.

Similarly, for teams concerned about how control failures in change management intersect with engineering velocity, the approach to remediating those failures without pulling engineers off product work is covered in depth in the How to Fix SOC 2 Control Failures Without Slowing Down Your Engineering Team guide.

---

What a Passing Change Management Control Environment Looks Like

A passing change management posture is not one where every change took two weeks to approve and required ten signatures. It is one where the evidence for each change tells a consistent, coherent story: the change was documented before it was deployed, it was reviewed by someone other than the author, it was tested before it reached production, and the production deployment occurred after all of those steps were complete.

In GitHub-centric engineering organizations, this looks like: pull requests with descriptive titles and change summaries, CI pipelines running and passing before merge, at least one non-author reviewer approval, branch protection rules preventing self-merge and requiring passing CI, and deployment pipeline runs triggered by merges with timestamps that follow the merge event rather than preceding it.

For infrastructure changes, it looks like: Terraform changes reviewed and approved through the same PR process as application code, no direct console deployments to production for change categories covered by the policy, CloudTrail logs showing no unmatched infrastructure changes that lack a corresponding ticket.

For emergency changes, it looks like: a small number of expedited changes clearly marked as emergency in the ticketing system, retrospective documentation tickets opened within 24 hours, and a clear audit trail of who authorized the emergency and what the business justification was.

That combination of evidence tells the auditor that your change management process is real. Not that it is perfect. Not that it never has exceptions. But that it operates consistently and that the controls are doing what change management controls are supposed to do: ensuring that changes to production systems are authorized, reviewed, tested, and traceable.

---

Conclusion

Change management findings are among the most avoidable in a SOC 2 program. Unlike some control categories where the gaps are subtle or technically complex, change management gaps are visible in the data: a deployment without a ticket, an approval that came after the deployment, a change ticket approved by its own author, an infrastructure modification in CloudTrail with no corresponding record in the ticketing system.

These findings occur not because engineering teams do not understand the requirement but because the processes designed to meet the requirement were built for the audit rather than for the way engineering actually works. When the process fights the workflow, engineers route around it. When the process fits the workflow, compliance is a natural byproduct of normal operations.

Build change management controls that integrate with your existing development and deployment tooling. Define explicit coverage for the change categories that fall outside the normal code deployment workflow. Create a written emergency change procedure so that expedited changes follow a process rather than bypassing one. And verify your coverage before the observation period begins rather than discovering the gaps when the auditor compares your deployment logs to your change records.

A change management program built this way does not slow engineering down. It creates the traceability and accountability that good engineering practice already values, documented in a form that auditors can verify.