Change Management Evidence for SOC 2

Introduction

Change management evidence for SOC 2 is the dated proof that production (and other in-scope) changes were requested, reviewed, approved, tested where required, deployed, and, when needed, rolled back under a defined process.

Engineering teams already create most of this proof in GitHub, GitLab, Bitbucket, Jira, CI/CD systems, and cloud consoles. The audit problem is rarely "we never review code." The audit problem is incomplete populations, missing approvers on emergency changes, CI failures ignored, infrastructure edits outside the ticket trail, and last-minute screenshot packs that cannot explain who changed what during the audit period.

In plain language: this guide shows how to map everyday engineering artifacts (pull requests, reviews, pipelines, tickets, emergency and infrastructure changes) to SOC 2-ready audit evidence, without treating a green checkmark as a certificate.

This is an operating playbook for engineers, platform owners, and compliance partners. For the glossary definition of the control practice itself, see What Is Change Management?. Related guides include What Is SOC 2 Evidence?, audit evidence collection, SOC 2 Type 1 vs Type 2, how to prepare for a SOC 2 audit, and what is control drift.

What Change Management Evidence Means

Change management evidence is not a single PDF. It is a set of linked records that show, for in-scope systems:

• What changed (code, config, infrastructure, permissions, data fix)
• Why it changed (ticket, incident, product request)
• Who authored and who approved (segregation of duties where required)
• How it was validated (tests, peer review, staging checks)
• When it reached production (deploy timestamp, release tag, pipeline run)
• What happened if it failed (rollback, hotfix, follow-up)

Auditors sample from a population of changes across the period for Type 2 examinations. Your job is to make the population complete and the sample packets boring: every selected change has a clear trail.

Distinguish requirement (what your written controls and system description claim) from common practice (how many SaaS teams implement those claims with Git-based workflows). Do not invent AICPA quotes. Align evidence to the controls you actually asserted.

Why Engineering Teams Struggle

Common friction points:

• Compliance asks for "all production changes" but engineering tools split changes across repos, IaC projects, feature flags, and console clicks.
• Peer review exists culturally but branch protection was off for a month.
• CI is required "in policy" while Continue on error or admin bypasses are routine.
• Emergency hotfixes skip tickets and never get retrospective approval.
• Cloud IAM or network changes happen in the console with no linked change record.
• Evidence collectors screenshot one happy-path PR and hope sampling never hits the messy ones.

These gaps create control drift: the written change policy no longer matches how production moves.

Map Engineering Artifacts to Evidence

Use this mapping as a practical checklist. Adapt names to your stack.

Engineering artifact	What it often proves	Gaps to watch
Ticket (Jira/Linear)	Request, business reason, risk notes, linkage to PR	Tickets created after deploy; no link to commit
Pull request	Authorship, description, linked ticket, discussion	Empty descriptions; force-pushes rewriting history
Code review approvals	Independent review before merge	Self-approvals; rubber-stamp bots counted as humans
Branch protection rules	Required reviews and status checks as designed	Admins bypassing; rules not applied to all release branches
CI/CD pipeline run	Automated tests/checks associated with the change	Flaky skips; deploying from a failed pipeline
Deploy record / release	Production timestamp and environment	Manual deploys with no pipeline ID
Infrastructure-as-code PR	Cloud resource changes under review	Console drift not reflected in IaC
Emergency change ticket	Break-glass path with retrospective approval	Hotfix with no ticket and no post-approval
Rollback record	Recovery when change caused harm	Silent revert with no incident or change link

Systems named here (GitHub, Jira, Okta, AWS, Google Workspace) are common evidence sources, not product integration claims.

Examples by Change Type

Application code changes

Good packet: Ticket describes customer-facing bug; PR links ticket; two reviewers approve; required CI passes; deploy pipeline ID and production timestamp retained; monitoring quiet after release.

Weak packet: Direct commit to main; "LGTM" from the author; CI red but merged with admin rights; no ticket.

Configuration and feature flags

Config and flag flips can change production behavior as much as code. Evidence should show who changed the flag, why, approval if your control requires it, and when it took effect. If flags are controlled outside Git, export admin audit logs for the period and tie high-risk flips to tickets.

Infrastructure and cloud changes

Treat Terraform/CloudFormation/Pulumi changes like code: PR, review, plan output retained where useful, apply tied to pipeline identity. For unavoidable console changes, open a change ticket first (or immediately for emergencies), capture before/after, and reconcile back to IaC promptly so drift does not accumulate.

Database migrations and data fixes

Migrations need extra care: review of up/down scripts, backup or restore considerations, maintenance windows when relevant, and clear ownership. Data fixes that edit customer records may also implicate access control and need tighter approval.

Access-affecting changes

Changes that grant production credentials, widen security groups, or alter SSO app assignments sit at the intersection of change management and access control. Keep both stories: the change ticket/PR and the access justification. Periodic user access reviews (see how to run a SOC 2 user access review) do not replace change evidence for the moment access was granted.

Vendor or third-party production hooks

New webhooks, reverse proxies, or production integrations are changes. Include security review notes when your process requires them, and retain the deploy or config evidence.

Emergency and Break-Glass Changes

Every mature program needs a fast path for Sev-1 production failure. The control story is not "never break the glass." The control story is:

1. Define when emergency path is allowed.
2. Record who authorized the bypass (even if after the fact within a stated window).
3. Capture what changed (diff, commit, console event).
4. Require retrospective ticket completion and review.
5. Feed serious events into incident management and, when systemic, into a corrective action plan or CAPA.
6. Track repeated bypasses as exception management candidates if the normal path is chronically unusable.

Auditors often sample emergency changes specifically because that is where documentation fails.

CI/CD as Evidence, Not Theater

CI/CD helps when:

• Required checks are enforced on protected branches
• Pipeline definitions are themselves change-controlled
• Deploy jobs are attributable to a commit SHA
• Secrets and environments are restricted

CI/CD fails as evidence when:

• Anyone can click "Deploy" to production from a laptop with no record
• Failed checks are optional
• Production can be updated by a second, undocumented path (legacy scripts, hot SSH)

Document the authorized path to production in your system description and procedures. Then make unauthorized paths rare, monitored, and exception-tracked.

Type 1 vs Type 2 Implications

For Type 1, auditors focus on whether change controls are suitably designed at a point in time: policies, branch protection screenshots/exports, CAB or approval matrices, and example tickets showing the designed flow.

For Type 2, auditors test operating effectiveness over the period: they select a sample from the population of changes and evaluate whether each sample followed the control. Incomplete populations (missing repos, missing IaC, missing console changes) are a frequent finding theme in practice discussions.

Details on report types: SOC 2 Type 1 vs Type 2. Period discipline: keep collecting continuously rather than rebuilding history in the last two weeks (continuous compliance, and the longer continuous compliance guide).

Building the Population for Sampling

Before fieldwork:

1. List in-scope systems and the repos/pipelines that can change them.
2. Export merge and deploy populations for the period (or generate from your evidence platform).
3. Include infrastructure projects and significant config systems.
4. Identify emergency and revert subsets.
5. Reconcile known production incidents to related change records.
6. Note out-of-band console changes from cloud audit logs and attach tickets.

A clean population beats a beautiful single example.

What Good Looks Like

• Written change policy/procedure aligned to how Git and CI actually work
• Branch protection and required reviewers enforced on release branches
• Tickets linked to PRs for in-scope production changes
• Deploy timestamps retrievable without archaeology
• Emergency path documented with retrospective approval SLA
• Infrastructure changes primarily through IaC with drift review
• Control owners who can explain samples without guessing
• Evidence stored with dates and IDs, not anonymous screenshots

Common Mistakes

• Defining "change" so narrowly that config and infra are invisible
• Counting bot approvals as independent human review
• Allowing admin bypass without logging and retrospective tickets
• Keeping change evidence only in Slack threads
• Regenerating tickets after the auditor requests a sample list
• Ignoring failed deploys and rollbacks in the population story
• Assuming a SOC 2 report from a vendor covers your own change controls (vendor management is separate)
• Treating change management glossary definitions as enough without an evidence operating model

Operating Model: Steps to Run Year-Round

1. Publish the authorized path. Document how code and infra reach production, including emergency rules.
2. Enforce in tooling. Branch protection, required checks, deployment environments, and least-privilege deploy credentials.
3. Link work items. Require ticket keys in PR titles/templates for production-bound work.
4. Capture deploys. Prefer pipeline-produced release records over manual notes.
5. Review monthly. Spot-check a small sample yourself before the auditor does; fix process gaps early (gap analysis habits help).
6. Reconcile incidents. Every significant production incident should point to related changes and follow-ups.
7. Track exceptions. Chronic bypasses become owned exceptions with end dates.
8. Prepare the packet. For each auditor sample, assemble ticket, PR, approvals, CI, deploy, and any rollback notes using evidence collection discipline.
9. Stay continuous. Do not pause collection after Type 1; Type 2 is a period sport.

SOC 2 Connection and Trust Criteria Themes

Change management evidence most often supports Security criterion themes (and Availability when unstable releases drive downtime commitments). Your exact control wording lives in your control set and system description, mapped through control mapping. For how criteria scoping works at a program level, see SOC 2 Trust Services Criteria Explained.

This guide describes common practice for evidence readiness. It does not quote AICPA standards, does not assert that any specific control is mandatory for every company, and does not replace your auditor's testing approach.

Sample Packet Anatomy

When an auditor selects a change ID from your population, a ready packet usually includes:

1. Population row identifiers (repo, PR number, deploy ID, timestamps)
2. Ticket link and summary of why the change existed
3. PR URL with author, reviewers, merge time, and base/target branches
4. CI/CD run URL showing required checks and result
5. Deploy or release evidence for the production environment
6. For emergencies: retrospective approval and incident link if applicable
7. For rollbacks: the forward change and the revert, with reason

Store packet components as links to systems of record first. Export PDFs only when the tool cannot guarantee retention for the full period. Avoid rebuilding the story from memory after sampling day.

Roles: Who Owns Which Proof

Clarify ownership so evidence does not become "compliance's problem" the week before fieldwork:

• Engineering leads / control owners: enforce branch protection, review quality, and deploy path integrity.
• Platform / DevOps: pipeline definitions, environment protections, deploy credentials, IaC gatekeeping.
• Security: high-risk change criteria, break-glass monitoring, and review of access-affecting changes.
• Compliance / GRC: population exports, sample coordination, policy alignment, and exception tracking.
• Product / support: ticket quality for customer-driven changes so "why" is auditable.

RACI can be light. What matters is that someone can produce each artifact class without a scavenger hunt.

Monthly Self-Sampling Habit

A practical mid-period habit:

1. Export last month's production deploys for one or two critical services.
2. Pick five changes at random, including at least one revert or hotfix if present.
3. Score each against your written control (ticket, review, CI, deploy attribution).
4. Log misses as exceptions or process bugs with owners and due dates.
5. Fix tooling gaps (branch rules, templates, required checks) before the next month.

This is internal readiness work, not an audit. It surfaces control drift while remediation is still cheap and supports continuous compliance better than an annual scramble.

How AuditFlo Helps

AuditFlo (auditflo.co) helps teams collect and organize change-related control evidence across the audit period so engineering proof stays tied to controls instead of landing in a last-minute zip file.

With continuous evidence collection, control mapping support, and audit-period history, you can preserve dates, ownership, and links across common systems such as GitHub, Jira, Okta, AWS, and Google Workspace. That reduces interrupt-driven evidence hunts when samples arrive.

AuditFlo is framed here as evidence and readiness support for the change management process your organization defines. It does not approve changes for you, does not replace code review, does not issue a SOC 2 report, does not certify compliance, and does not replace auditors.

If you want to see how change evidence can stay organized for your stack, request a demo.

Final Thoughts

SOC 2 change management evidence is mostly disciplined engineering hygiene: complete populations, enforced review paths, attributable deploys, honest emergency handling, and dated packets that match your written controls. Glossary definitions explain the practice; this playbook explains how to prove it. Start from the authorized path to production, close the side doors, sample yourself monthly, and keep collecting through the full audit period so Type 2 fieldwork is confirmation rather than archaeology.

FAQ

Do we need a CAB for SOC 2 change management?

Not necessarily. Many software companies meet change objectives with ticketed PRs, required reviews, and CI/CD controls instead of a classical change advisory board. What matters is that your written control matches your real path and that evidence supports it. If you claim a CAB, you need CAB records.

Are pull request approvals enough evidence?

Often they are a core part of the story, but samples usually also need the request context (ticket), CI results if required by your control, and proof the change reached production. Approvals alone may not show deployment or business reason.

How should we handle emergency hotfixes?

Define the break-glass path, record the change quickly, obtain retrospective approval within your stated window, link any incident record, and review whether the emergency path is being overused. Missing retrospective documentation is a frequent sample failure.

What population should we give auditors for Type 2?

Agree scope with your auditor, then provide a complete list of in-scope production changes for the period from your systems of record (merges/deploys/IaC applies), including emergencies and rollbacks as applicable. Do not hand-curate only "pretty" changes.

Do infrastructure console clicks count as changes?

If they alter in-scope production systems, yes for practical evidence purposes. Prefer IaC, and when console changes happen, ticket them and reconcile drift.

How is this different from the change management glossary page?

The glossary page defines the practice. This resource is an engineering-facing evidence playbook: artifact mapping, change-type examples, sampling, mistakes, and operating steps.

Where does incident response fit?

Incidents often trigger emergency changes. Keep separate records: the incident timeline and the change/fix evidence. Serious or recurring issues may escalate into CAPA-style work after the immediate fix.