CC8.1 Change management: SOC 2 requirements and evidence

What CC8.1 change management asks for in a SOC 2

If you are the compliance lead or engineer who has to show an auditor how changes reach production, the short answer is this: CC8.1 is the only change management criterion in the 2017 Trust Services Criteria, and it covers the full life of a change to infrastructure, data, software or procedures. The auditor will not accept a deployment log on its own. They will ask you to follow a change from the moment someone authorized it, through design or acquisition, configuration, documentation, testing, approval and implementation, and to show that each stage happened the way your own process says it should.

The risk behind the criterion is easy to state. A change that nobody authorized, that skipped testing, or that was pushed straight into production can break a system or expose customer data, and the people who made it may not know what they broke. CC8.1 also asks you to think about changes that are not planned at all. Its points of focus include changes needed in emergency situations, managing patch changes, maintaining a baseline configuration of IT technology, and considering system resilience. Your change procedure should therefore define an emergency path with its own review step, a patch path that can move quickly without skipping approval, and a documented baseline that deviations can be measured against. The 2017 criteria also add confidentiality and privacy points of focus to this criterion, so the procedure should say how personal and confidential data are protected while a change is being made.

This criterion is hard because the evidence has to connect records that usually live in different tools. For each sampled change, the auditor will expect to trace a ticket that states the reason and scope, a design or pull request that shows what changed, a review or approval recorded before deployment, test results, and a deployment record that matches the approved change. Confirm with your auditor which change sample sizes and evidence formats they will accept before you choose tools, because a gap in any link breaks the trail. An illustrative case: a configuration change approved in a ticket but deployed through a manual console edit cannot be traced back to the approval, and it will show up as an exception even if the change itself was harmless.

Which changes and systems CC8.1 covers in scope

CC8.1 applies to every change the auditor can trace to the system in scope, so the scoping decisions made early determine how much change work the examination samples. The cards below separate the change types that most often surprise teams, from production infrastructure to third-party changes, and note where the confidentiality and privacy points of focus apply.

Production infrastructure changes

Changes to servers, clusters, network devices, load balancers and cloud resources that run the in-scope system. Auditors expect each change to carry an authorization, a record of what was altered and an approval before it reaches production. Check whether manual console edits are covered by the same process as code-driven changes, because undocumented console work is a common exception.

Application code changes

Feature work, bug fixes and dependency updates that reach production through a repository and pipeline. The evidence normally comes from a tracked ticket, a reviewed merge request and a record of testing before release. Confirm that branch protections prevent direct pushes to the production branch and that the pipeline cannot be bypassed by a single person.

Database schema and data migrations

Schema changes, backfills and bulk data corrections alter the data the system processes, so they belong in scope even when no application code changes. Auditors look for the same authorization, testing and approval steps as code releases, plus evidence of a rollback path. Decide who may run ad hoc data fixes in production and how those fixes are logged.

Infrastructure as code

Terraform, Ansible and similar definitions that create or configure infrastructure. When a change is made through code, the reviewed and merged definition often serves as the change record, which simplifies evidence. Check that drift between the code and the live environment is detected and treated as an unauthorized change until explained.

Configuration baselines

The approved settings for operating systems, containers, databases and network devices, and the process for changing them. Auditors ask how a baseline is defined, who approves a deviation and how the organization detects systems that have drifted from it. Document the baseline owner and the schedule for reviewing it.

Procedures and third-party changes

Changes to policies, runbooks and the vendors or subservice organizations that touch the system, such as a hosting provider changing its platform. Decide which vendor changes you must track and how you learn about them, because a provider's change can alter your controls without any change on your side. Confirm the scope with your auditor before the observation period begins.

How an SOC 2 auditor tests change management

This table compares how an auditor tests CC8.1 at a point in time (Type 1) and over an observation period (Type 2), along with the evidence requested per sampled change and the findings that most often appear. Read each row as what the auditor checks and what your records must show, because the auditor tests the controls your organization has described, not the controls it intends to have.

Test area	Type 1 design review	Type 2 operating effectiveness test
Primary question	Is the change management process designed to meet CC8.1 as of the report date?	Did the change controls operate as described across the full observation period?
Procedures	Walkthrough of the change lifecycle, review of the written procedure, and inspection of tool configuration such as branch protections and approval workflows	Sampling of changes across the period, inspection of records for each sampled change, and inquiry of staff about exceptions
Sampling basis	Usually a small number of representative changes used to confirm the design works in practice	Sample drawn across the observation period, with the population defined as all changes deployed in that window
Evidence per sampled change	Example request, approval, test results and deployment record to show the process as designed	Request, documented approval by someone other than the requester, test results, and deployment record, each dated and linked to the same change
Emergency changes and patches	Inspection that the emergency change path and patch procedure exist, define approval after the fact, and require review	Testing of every emergency change or patch in the population where available, checking for retrospective approval and follow-up testing
Typical findings	Procedure does not cover emergency changes, baseline configurations are undefined, or tool settings allow direct pushes	Missing approvals, self-approved changes where the author also approved, undocumented emergency fixes, and deployments with no matching request
What reduces findings	Written procedure that matches the tool workflow and names owners for each stage	Ticket and repository links that connect each change to its approval, test and deployment, reviewed on a regular schedule

Implementing change management step by step

This sequence turns CC8.1 from a policy statement into a working change process, where each change is authorized, built, tested, approved and deployed through records that an auditor can sample. Each step produces an artifact that the next step depends on, so the process holds together during the observation period of a Type 2 examination.

Define the change policy and categories
Management writes a change management policy that covers infrastructure, data, software and procedures, and defines three categories: standard changes that follow a pre-approved path, normal changes that need review and approval, and emergency changes that are made first and reviewed afterward. The policy names who may authorize each category and what evidence each must leave behind. The step is complete when management has approved the policy and every change type in the environment maps to one category.
Set up a single change record system
Choose one system of record for changes, such as an ITSM tool that follows ITIL change practices or a ticketing system linked to the code repository, and require that every change has a record. Each record should capture the request, the owner, the risk, the planned test, the approver and the deployment outcome. The step is complete when a sample of recent changes can be traced from request to deployment in one place, and the team confirms no production change happens outside that system.
Define approval rules and author and approver segregation
Write approval rules by category and risk level, and specify that the person who authors a change cannot be its only approver. Define who can approve production changes, how approvals are recorded, and what happens when the usual approver is unavailable. The output is a written approval matrix and role assignments in the change system that enforce it. The step is complete when a test change by an author without a second approver is blocked or flagged.
Enforce protected branches and deployment gates
Configure protected branches in the source repository so that roles are restricted on who can push or merge, direct pushes are blocked for production branches, and force pushes stay disabled unless explicitly allowed. Add deployment gates that require a linked, approved change record before a pipeline can deploy to production. The output is repository and pipeline configuration exported as evidence. The step is complete when a direct push to the protected branch fails and a deployment without an approved record does not run.
Establish baseline configurations
Document a baseline configuration for each class of system, covering operating system images, network devices, container images and cloud settings, and store it as version-controlled code where practical. Changes to the baseline go through the same change process as application code. The output is the baseline documents and the configuration definitions they describe. The step is complete when drift from the baseline can be detected and each deviation is linked to an approved change or raised as an incident.
Add testing and code scanning to the pipeline
Add automated tests and static analysis to the continuous integration pipeline so that each change produces test results before approval. Code scanning should cover the languages and infrastructure-as-code files the team uses, and results should attach to the change record. Confirm which languages your chosen scanner supports before committing to it. The output is pipeline definitions and stored test and scan results for each change. The step is complete when a failed test or scan blocks the change from advancing and the result is retained.
Document emergency and patch procedures
Write a short procedure for emergency changes that allows action first, requires notification to an approver at the time, and requires a retrospective review and record completion within a period the policy sets. Add a separate patch procedure that defines how vendor and security patches are assessed, prioritized, tested and deployed. The output is both procedures, with named roles and the records each step creates. The step is complete when the team has walked through one simulated emergency change and one patch cycle and the records match the procedure.
Run the first review cycle
Select a set of completed changes across all categories and check each against the policy: authorization, testing, segregation, approval, deployment and any emergency follow-up. Record exceptions, assign corrective actions and update the policy, records or pipeline settings where the review shows a gap. The output is a review report with exceptions and their remediation. The step is complete when management has reviewed the report and the next review date is set, so the cycle becomes routine before an auditor samples it.

Self-hosted open-source tools that produce change evidence

GLPI is licensed under GPL-3.0-or-later. Its Assistance module lets teams create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. This makes it a natural home for the change record: the request, the risk assessment, the approver, the scheduled window and the closure notes all sit on one object that an auditor can pull for a sampled change.

Change objects: Record each change with its type, description, affected system and approver so that every sampled change has a single authoritative entry.
Linked tickets and problems: Connect emergency changes to the incident or problem that triggered them, so the reason for the exception is visible.
Planning and statistics: Use the planning view and reports to show that changes were scheduled and reviewed, not added after the fact.
Recurring changes: Use recurrent tickets for patch cycles and baseline reviews so that the recurring work leaves a dated record each cycle.
Access to the record: Confirm who can edit closed changes and whether edits are logged, because an auditor will ask whether the record was altered after approval.

Confirm with your team which GLPI fields and workflow steps your change policy requires, and whether the auditor accepts the GLPI record as the system of record or wants it matched to another source.

Evidence that passes CC8.1 testing

An auditor testing CC8.1 samples changes and checks that each one followed the same path from authorization to deployment. The cards below describe the records that show that path, and the periodic checks that keep those records complete between audits.

Authorized change tickets

Each sampled change should trace to a ticket that records the request, the business or technical reason, the risk rating, the named approver and the date approval was given. Auditors look for approval before implementation, not a ticket opened after the change went live. Tickets can be kept in a helpdesk or ITSM tool such as GLPI, whose Assistance module follows tickets and changes using ITIL practices. Check that ticket numbers appear in commit messages and deployment records so the chain can be followed in both directions.

Design and requirement notes

For software and infrastructure changes, keep a short record of what is being built or altered and why, linked to the ticket. A design note for a schema change or a network rule should state the scope, the rollback approach and any effect on confidential or personal information, since CC8.1 also covers data and privacy points of focus. Auditors often sample larger changes first, so make sure those carry the most detailed notes.

Peer review and merge approvals

Code and configuration changes should show a reviewer who was not the author, recorded in the merge request before the change reached the protected branch. Export the approval history for sampled merges and confirm that the approver held the right role at the time. In GitLab, protected branches can restrict which roles may push or merge and block direct pushes, and those settings are themselves evidence of how the process is enforced.

Test and security scan output

Keep pipeline results for each sampled change, including unit and integration test runs and static analysis output. Semgrep Community Edition can run in CI/CD and scan repositories on every change across languages including Python, Go, TypeScript and Terraform. The auditor will want to see that failed scans blocked or were explicitly accepted with a recorded reason, so store the accepted-risk decisions alongside the scan reports.

Deployment and emergency change records

Deployment logs should show who released each change, when, to which environment and under which ticket. Emergency changes need their own records: the reason for bypassing normal approval, who authorized it, what was altered, and a documented after-the-fact review by someone independent of the change. Ask your auditor which emergency changes they expect to see in the sample period, since a gap here is one of the most common findings.

Patch and baseline configuration records

Patch records should show what was patched, when it was tested, when it was deployed and any exceptions with their approvals. Baseline configuration documents define the expected state of servers, containers and cloud resources. Run drift checks on a schedule and keep the reports, and record how each drift was either corrected or approved as a change. Infrastructure as code repositories often provide both the baseline and its change history in one place.

What meeting CC8.1 costs in money and effort

This table breaks down the cost components of running CC8.1 change management, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to scope a quote and to see where self-hosted open-source tools reduce license spend while still leaving engineering, process and audit effort in place. No prices are given because none are supplied for this topic.

Cost component	Who is paid or who does the work	One-time or recurring, and main driver
Ticketing and change tooling (for example, GLPI or Zammad)	Internal staff or implementation partner to configure; the organization hosts the platform	Setup is one-time; hosting and upkeep recur. Driver: number of teams and approval paths modeled in the tool
Repository controls such as protected branches (for example, GitLab Community Edition)	Engineering to configure push, merge and force-push rules; platform owner to maintain	Configuration is one-time; periodic review recurs. Driver: number of repositories and branches under protection
Code scanning in CI/CD (for example, Semgrep Community Edition)	Engineering to integrate into pipelines and triage findings	Integration is one-time; rule tuning and finding triage recur. Driver: number of languages and repositories scanned
Process design and change policy writing	Internal owners, with an implementation partner or consultant if outsourced	Mostly one-time, with annual review. Driver: number of change types (standard, normal, emergency) and environments
Baseline configuration and infrastructure as code	Platform engineering to define baselines and version them	Build is one-time; drift checks and updates recur. Driver: number of environments and how many are managed by code
Ongoing change record upkeep	Each engineer who ships a change, plus change approvers	Recurring. Driver: change volume, and how much of the record is generated automatically from pull requests and pipelines
Periodic access and branch setting reviews	Security or compliance owner, with system owners attesting	Recurring on the cycle the organization sets. Driver: number of people with merge or deploy rights
External testing or review of change controls	Independent security testing firm or consultant if scoped	Recurring if scheduled. Driver: scope of production systems and integrations in the test
Auditor sampling and evidence requests	The CPA firm performs testing; the organization pulls and explains records	Recurs each examination period. Driver: number of changes in the period and how cleanly records link ticket, approval, test and deployment
Emergency change and patch handling records	On-call engineers and approvers after the fact	Recurring. Driver: frequency of emergencies and whether post-change review is documented on time

How emergency changes and patches fit the control

Emergency changes and patches are where CC8.1 findings most often come from, because they are the changes most likely to skip the normal path of authorization, testing and approval. The control does not forbid fast changes. An auditor expects a documented emergency path that is defined in advance, limited to genuine urgency, and followed the same way every time. Ask your team to write down who can declare an emergency, which approvals can be given after the fact, how the change is recorded, and the deadline for the retrospective review. If the procedure exists only in someone's head, the first emergency change that lacks a ticket becomes the exception in the report.

In practice, the evidence for an emergency change is a ticket in your change system (GLPI's Assistance module, for example, handles changes following ITIL practices) that links to the production action, the reason for urgency, the named approver, and a later review by someone who was not involved in the fix. Set the review window in your procedure and sample a few emergency tickets each quarter to confirm the review happened on time. Patches need the same discipline. Track each patch as a change with its scope, test result, approval and rollout record, even when it is routine. Where code or infrastructure definitions change, GitLab protected branches help show that changes reached production through reviewed merges rather than direct pushes.

The points of focus on baseline configuration and system resilience show up in evidence that is easy to overlook. For baseline configuration, keep a documented standard build for servers, containers and cloud accounts, and show that an emergency or patch change either leaves the baseline intact or updates it through an approved change. For resilience, record whether a change was checked for effects on capacity, failover and backups, and whether the rollback step was tested or at least defined. Confirm with your auditor which of these points they expect to see in your evidence for the period under examination, since points of focus are guidance rather than separate requirements.

Who owns change management and what to outsource

Your organization owns CC8.1 in full. Management decides which changes are authorized, who approves them, what risk classification applies, and when a change may go to production. Those decisions must be made by your people and recorded in your systems, because the auditor tests whether your controls operated, not whether a vendor performed them on your behalf. Your team also owns the change policy and the procedures under it, and it must run the process week to week long enough for an auditor to sample it during an observation period.

Change policy and procedures: Written rules for standard, normal and emergency changes, including who may approve each type.
Approvals and segregation: Named approvers for each change, with a rule that the person who builds a change is not the only person who approves it.
Change record: Tickets that show the request, risk assessment, testing, approval and deployment for each change.
Emergency and patch handling: Post-change review for emergency fixes so they do not bypass the process permanently.
Baseline configurations: Approved configuration standards that your team maintains and reviews.

Before engaging anyone, confirm that your own staff can run these steps without a consultant in the loop.

Where change management usually falls short

Most CC8.1 findings are not about missing policies. They appear where a change skips the path the organization describes, or where the path leaves no record an auditor can sample. The gaps below recur across environments, and each one has a concrete fix that produces evidence for the observation period.

Direct pushes to production

Engineers commit straight to the branch that deploys, so code reaches production without review or a linked approval. An auditor testing CC8.1 will ask who could make that push and whether the platform allowed it. Check that protected branches block direct pushes for all roles, that merges require review, and that force pushes stay disabled unless explicitly allowed. The branch settings themselves are evidence, so export and retain them.

Self-approved changes

The person who wrote a change also approves it, or the approval exists in a chat thread that nobody can tie to the deployment. Segregation between author and approver is what makes the approval mean something. Confirm that the tool records the approver's identity separately from the author, that approvers are not the same individuals who merge, and that exceptions for small teams are written down and reviewed rather than assumed.

Emergency fixes with no record

Urgent hotfixes go out during an incident, and the paperwork is promised for later and never completed. CC8.1 explicitly covers changes needed in emergency situations, so the auditor expects the emergency path to be defined and still traceable. Define a documented emergency procedure with a named approver, a ticket opened at the time of the fix, and a retrospective review. Confirm the review happens within the timeframe your own policy sets.

Tickets not linked to commits

Tickets close with a comment like "fixed" while the commits, merge requests and deployments sit in separate systems with no shared identifier. The auditor cannot trace a sampled change from authorization to implementation. Require a ticket reference in every commit or merge request title, link the change record to the pipeline run that deployed it, and confirm that a sample of closed tickets can be followed to a specific deployment.

Untracked console changes

Engineers adjust cloud security groups, IAM policies or server settings directly in a web console, so the running environment drifts from the code and the change history. Baseline configuration is a CC8.1 point of focus, and undocumented drift breaks it. Decide which changes must go through infrastructure as code, restrict console write access to break-glass roles, and review drift on a schedule. Ask your platform team which console actions are currently possible for everyday users.

Patches with no tracking

Operating system and dependency patches are applied through ad hoc commands or automatic updates that leave no change record, so the auditor cannot see when a patch was authorized, tested or deployed. CC8.1 includes managing patch changes. Treat patches as standard changes with a pre-approved template, log each rollout against the affected systems, and keep the scanner or inventory output that shows the patch landed.

No review evidence over the period

The change process works in the first month, then review becomes irregular, and the auditor sees gaps in the sample across the observation period. A Type 2 examination tests operating effectiveness over time, so the review must happen consistently. Set a recurring review of closed changes, sample them yourself before the auditor does, and keep the sign-off records. Ask your auditor early which population and sample sizes they expect.

CC8.1 change management questions buyers ask

How much effort does CC8.1 change management take in a SOC 2?

CC8.1 is the only change management criterion in the 2017 Trust Services Criteria, but it covers the full life of a change, so the effort sits in the process rather than in one document. Work scales with how many changes your teams make to infrastructure, data, software and procedures each month. The main effort is defining one change workflow, making every change pass through it, and keeping a record of each step. Teams with frequent deployments usually spend more time on evidence than teams that release less often, because the auditor samples from the whole population of changes. Ask any firm to estimate effort from your actual change volume and tooling, not from a generic template.

How long must change evidence be kept current before a Type 2 window?

A Type 2 report tests whether controls operated effectively over an observation period, so change records must exist, and be consistent, for the whole period, not only on the day the auditor arrives. Confirm the observation period length, and any sampling approach, with your chosen CPA firm, since those details are set in the engagement. Evidence should be retained continuously from the first day of the period. Starting the workflow late, or switching ticketing tools mid-period, creates gaps the auditor may record as exceptions. Plan to run the change process for at least one full cycle before the period begins so that the first sampled changes already follow the procedure.

Can an internal team handle CC8.1 without outside help?

Yes, an internal team can design, run and evidence CC8.1 if it has people who understand the change lifecycle and the time to maintain it. The common gaps are not technical. They are unclear ownership of approvals, emergency changes handled outside the process, and patches applied without tickets. An internal team usually needs to agree who authorizes changes, who may approve their own work and how baseline configurations are recorded. Outside help is most useful for preparing the control matrix, mapping existing tools to evidence and running a readiness review before the auditor begins. Only the independent CPA firm issues the report.

What does CC8.1 need from engineering and compliance teams?

Engineering owns the mechanics of change, and compliance owns the proof that the process is followed. Engineering typically needs to:

Route every production change through a tracked request, branch or pipeline run
Keep infrastructure and configuration under version control with reviewed merges
Record testing results and rollback steps for each release
Document emergency and patch changes after the fact, with approval

Compliance typically needs to define approval rules, set review frequency, sample changes for the evidence file and keep the policy current. Both teams should agree on definitions early, because what counts as a change decides what must be recorded.

What drives the cost of CC8.1 readiness and the examination?

Cost depends on the size and complexity of the system, the number of change sources, the state of current tooling and the report type. Readiness work costs more when change records are scattered across chat, email and spreadsheets, because they must be consolidated before the process can be evidenced. Examination fees are set by the CPA firm and depend on scope, number of trust services categories and sampling. Recurring costs include running the process, reviewing exceptions and renewing the report each cycle. Ask for a written quote that separates readiness work, tooling, examination fees and any retainer for ongoing support, and confirm whether each line is one-time or recurring. DeployOpen provides quotes from a written scope, not a price list.

Which parts of CC8.1 are usually outsourced, and which stay in house?

Organizations usually keep approval authority, production deployment and the decision to accept risk in house, because those decisions must be owned by people accountable for the service. Outside help is commonly used to design the change workflow, configure ticketing and version control tools, write procedures, build evidence collection and run pre-audit testing. The independent CPA firm performs the examination and issues the report. A quote should show who does each task, since an implementation partner prepares systems and evidence but does not attest to them.

Which self-hosted open-source tools can produce CC8.1 evidence?

Several open-source tools can generate records that support CC8.1, provided they are configured and used consistently. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, which can hold change requests and approvals. GitLab Community Edition supports protected branches that restrict who can push or merge and keep force pushes disabled unless explicitly allowed, which supports authorization and review of code changes. Semgrep Community Edition can run in CI/CD pipelines to scan repositories, which provides testing evidence for software changes. Confirm each capability against your own configuration and the auditor's expectations before relying on it for evidence.

Does DeployOpen guarantee a clean SOC 2 report if we implement CC8.1?

No. DeployOpen cannot guarantee any report outcome, because the report is issued by an independent CPA firm after testing the controls your organization operates. DeployOpen can plan and implement the change workflow on self-hosted open-source platforms inside your infrastructure, configure the supporting tools, document procedures and prepare evidence for the examination. Your organization owns its controls and the decisions behind them. Ask any provider to show the scope, deliverables and timelines in writing before work starts.

How DeployOpen prepares change management evidence

DeployOpen starts with a written, fixed-scope agreement that names the change workflow it will set up: which change types are covered (infrastructure, data, software and procedures), who requests and who approves each type, and which records the client's auditor will expect to see. Before any tooling is installed, the client should confirm in writing who owns the change advisory decision, who can approve emergency changes, and how baseline configurations are recorded. DeployOpen implements the ticketing side inside the client's own infrastructure, typically with GLPI's Assistance module, which supports tickets, problems and changes following ITIL practices, so that each change has a request, an approver and a status history. Where the client's helpdesk already handles customer requests, the scope should say whether a tool such as Zammad will be kept separate from change records. The organization still owns its controls and decides what counts as an approved change.

On the code side, DeployOpen configures GitLab protected branches so that the roles allowed to push or merge are set explicitly, direct pushes are blocked by setting push access to no one, and force pushes stay disabled unless a named exception is approved. These settings produce a repeatable record that every production change passed through a reviewed merge request. DeployOpen also wires Semgrep Community Edition into the CI/CD pipeline so repositories are scanned on each change, with rules chosen during scoping for the languages the client actually uses. The client should confirm that its own repositories, Terraform and infrastructure code sit inside this pipeline and that exceptions to the protected branch rules are logged.

For evidence, DeployOpen prepares an exportable set of records that maps each change to its ticket, approval, merge request, test results and deployment event, then documents how the workflow operates so the auditor can test it over the observation period. DeployOpen does not issue audit reports, attestations or certifications. The independent CPA firm decides what it will sample, whether the evidence is sufficient and what opinion to issue. Clients should ask their auditor early which change records it will request, how far back those records must go, and whether emergency and patch changes need separate evidence.