The entity authorizes, designs, develops or acquires, configures, documents, tests, approves changes

To meet the the entity authorizes, designs, develops or acquires, configures, documents, tests, approves changes requirement, you must run a formal change management process that covers in-house development, third-party acquisitions, and configuration changes, with clear approvals, testing, and retained evidence. Operationalize it by defining change types, enforcing pre-production testing, and keeping a complete audit trail from request through implementation.

Key takeaways:

• Treat code, infrastructure, SaaS settings, and third-party product updates as “changes” that require control.
• Require documented authorization and testing before production, with emergency change rules.
• Keep end-to-end evidence (ticket, risk/impact, approver, test results, deployment record) for auditor sampling.

SOC 2 change management failures rarely look dramatic in real time. They show up as small gaps: a production hotfix merged without peer review, a cloud security group changed in-console with no ticket, or a SaaS admin toggling a setting that disables logging. TSC-CC8.1 is the control criterion that forces discipline around those moments. It expects you to authorize changes, control how you design/develop or acquire them, configure them consistently, document what changed, test before release, and approve changes through defined roles.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to align Security, Engineering, IT, and Release Management on one “system of record” for changes (ticketing and/or version control), then define the minimum required fields and evidence for each change type. Your auditors will sample changes across the audit period and ask you to prove two things: (1) the process exists and is reasonable, and (2) it operated consistently, including during emergencies and third-party updates.

Regulatory text

SOC 2 Trust Services Criteria – TSC-CC8.1: “The entity authorizes, designs, develops or acquires, configures, documents, tests, approves changes.” ¹

Operator meaning: you need a controlled lifecycle for changes to systems in scope for SOC 2. The lifecycle must include:

• Authorization: changes are requested and allowed by the right role(s).
• Design/develop or acquire: your SDLC or procurement process produces a known, reviewable change.
• Configuration: changes are implemented in a consistent, repeatable manner (including infrastructure and SaaS configuration).
• Documentation: you can reconstruct what changed and why.
• Testing: you validate the change before production (or compensate with defined emergency procedures).
• Approval: you can show a final decision to release/implement, not just that work occurred.

¹

Plain-English interpretation of the requirement

TSC-CC8.1 requires you to prevent uncontrolled changes from creating security, availability, processing integrity, confidentiality, or privacy failures. Practically, auditors expect a closed-loop change process: a request is recorded, risk/impact is considered, the change is reviewed and tested, an authorized person approves it, and the organization can prove what was deployed and when.

This applies to:

• Application code (new features, bug fixes, hotfixes)
• Infrastructure changes (network rules, firewall/security groups, IAM policies, Kubernetes settings, IaC)
• Data layer changes (schema changes, replication settings)
• SaaS and platform configuration (SSO settings, logging toggles, retention policies)
• Third-party changes you introduce (new vendor product, version upgrades, patches, new integrations)

Who it applies to (entity and operational context)

This requirement applies to any service organization pursuing SOC 2 where systems are in scope for the report. In practice, it touches multiple teams:

Function	What they control	Typical evidence they produce
Engineering / DevOps	Code, CI/CD, infrastructure-as-code, deployments	PR reviews, build logs, deployment logs, change tickets
IT / Corporate systems	Endpoint tooling, directory services, email, MDM, internal SaaS	Change requests, admin logs, approvals
Security	Security tooling, IAM standards, segmentation, logging	Risk sign-off, exception approvals, security review notes
Procurement / Vendor owners	Acquired software/services and renewals	Due diligence notes, security addenda, onboarding approvals
GRC / Compliance	Policy, control design, audit readiness	Change management policy, sampling package, control narrative

You also need to scope “what counts as production.” Auditors will focus on changes that affect systems supporting the SOC 2 boundaries (for example: production environments, production data, security controls, customer-facing services).

What you actually need to do (step-by-step)

Use this as an implementation checklist you can hand to engineering and IT.

1) Define the change universe (your biggest early win)

Create a one-page “change classification” that covers:

• Standard changes (pre-approved, low-risk, repeatable; e.g., routine patching with an established playbook)
• Normal changes (default path; require ticket + testing + approvals)
• Emergency changes (break-glass path; allow expedited release with retroactive review)

Add a simple rule: if it affects production security, access, data flows, logging/monitoring, or customer impact, it is a controlled change aligned to TSC-CC8.1 ¹.

2) Establish the system of record and required fields

Pick where changes live:

• Engineering: Jira/Linear/Azure DevOps + Git provider + CI/CD
• IT: ServiceNow/Jira Service Management
• Cloud changes: IaC repo + pipeline logs, and/or a ticket linked to admin activity

Minimum required fields for each change ticket:

• Change description and systems in scope
• Business reason / driver (bug, feature, security fix, vendor update)
• Risk/impact statement (customer impact, security impact, rollback complexity)
• Test plan and results link(s)
• Approver(s) and timestamps
• Implementation time and deployment reference (release tag, pipeline run, change set)
• Backout/rollback plan (or a note why not applicable)

3) Put “authorization” and “approval” into workflow gates

Auditors look for more than a norm. They want enforced steps.

• Authorization gate: who can request vs who can implement. Keep permissions tight for production changes.
• Approval gate: required reviewer(s) for normal changes. Common patterns:
  • Engineering manager approval for production releases
  • Security approval for changes to IAM, encryption, logging, network exposure
  • CAB-style approval for high-risk changes (even if lightweight)

Document the approval matrix (role-based) so you can explain it consistently ¹.

4) Make testing non-optional, then define emergency compensating controls

Define what “tested” means for your environment:

• Unit/integration tests in CI for code
• Staging validation for high-impact releases
• Automated policy checks for IaC (linting, policy-as-code)
• For SaaS config, a checklist and peer validation (screenshots + second admin review)

Emergency change controls (the part auditors probe):

• Who can declare an emergency
• Minimum evidence required even under time pressure (ticket + approver + what was changed)
• Mandatory retrospective review within your defined internal SLA (your choice, but enforce it consistently)
• Post-change testing and monitoring confirmation

5) Control changes you “acquire” from third parties

TSC-CC8.1 explicitly includes acquiring and configuring changes ¹. Cover:

• New third-party onboarding (security review, contract/security addendum, architecture review)
• Version upgrades and major feature enablement
• New integrations and API scopes
• Patches that change behavior or permissions

Operational rule that works: treat vendor-driven material changes like internal changes. Require a ticket, risk notes, and approval before enabling in production.

6) Require documentation that reconstructs “what changed”

Your goal is re-playability for an auditor sample:

• For code: link ticket → PR → review → CI results → release tag → deployment
• For IaC: link ticket → PR → plan output (if available) → apply log → reviewer approval
• For console changes: link ticket → screenshots/exports → approver note → admin log extract (if your platform supports it)

7) Build the audit sampling package before the auditor asks

Create a repeatable export template:

• A list of changes in the period (from ticketing system)
• For each sampled change: a folder with the evidence set (see next section)
• A short narrative describing your workflow and enforcement points

If you use Daydream for third-party risk and control operations, use it as the workspace where change evidence expectations, exception tracking, and audit requests live, so teams stop rebuilding ad hoc evidence packets each audit cycle.

Required evidence and artifacts to retain

Keep evidence that proves both design (policy/process exists) and operation (it happened for real changes).

Governance (design evidence)

• Change Management Policy and/or SDLC policy referencing authorization, testing, approvals ¹
• Change classification and approval matrix
• Defined emergency change procedure
• Tooling workflow configuration (screenshots of required fields / approval steps, if applicable)

Operating evidence (sample-ready)

• Change ticket with required fields completed
• Linked PR or configuration record
• Evidence of review/approval (PR approvals, CAB approval, manager sign-off)
• Test evidence (CI test logs, staging validation notes, UAT sign-off where applicable)
• Deployment evidence (pipeline run, release record, change calendar entry)
• Backout plan and any post-implementation verification
• For emergency changes: incident record + retroactive approval + post-change review notes

Common exam/audit questions and hangups

Auditors commonly ask:

• “Show me how you ensure all production changes are captured.”
  Hangup: “out-of-band” console edits and untracked SaaS admin changes.
• “How do you handle emergency changes?”
  Hangup: no retrospective review evidence.
• “Who can approve changes to security controls like IAM and logging?”
  Hangup: approvals exist, but approver role is not defined or is inconsistent.
• “Demonstrate that changes are tested.”
  Hangup: “tested” is asserted verbally; evidence is missing or not linked to the change.
• “How do you manage third-party product changes you enable?”
  Hangup: vendor releases are treated as outside change management.

Frequent implementation mistakes and how to avoid them

1. Relying on Git history alone.
   Fix: require a ticket link in PR templates and enforce it through repository rules.

2. Treating infrastructure and SaaS settings as exempt.
   Fix: define “configuration changes” explicitly and require tickets for admin console edits or move changes into IaC where feasible.

3. Approvals exist, but not for the right risk.
   Fix: tie approvals to change categories (security-impacting, customer-impacting, high-risk) with named roles.

4. Emergency changes become the norm.
   Fix: require post-implementation review and trend “emergency” usage. If a team repeatedly uses emergency flow, treat it as a control issue.

5. Evidence is scattered and rebuilt for audits.
   Fix: standardize an evidence packet format and store it consistently. Daydream can act as the control hub to track requests, exceptions, and evidence across teams.

Enforcement context and risk implications

No SOC 2 “enforcement” body publishes penalties the way regulators do, but this control still carries real risk: weak change control is a common root cause of outages, security misconfigurations, and unauthorized changes. For SOC 2, the practical consequence is audit findings: exceptions in testing/approval evidence can lead to qualified opinions or carve-outs that affect customer trust and sales cycles. The operator goal is consistency and proof, aligned to TSC-CC8.1 ¹.

A practical 30/60/90-day execution plan

Days 1–30: Stabilize and define “done”

• Confirm systems in SOC 2 scope and define “production.”
• Publish change classification and approval matrix (one page).
• Standardize required change ticket fields and update templates.
• Implement quick workflow controls: require ticket link in PRs; require approvals for merges to main; define emergency change steps.
• Start an evidence folder structure for sampled changes.

Days 31–60: Enforce and close coverage gaps

• Add security review triggers for IAM/network/logging/encryption changes.
• Bring infrastructure changes under control: IaC preferred; otherwise ticket + approval + admin logs.
• Document third-party acquisition/change workflow (new tools, upgrades, integrations).
• Run an internal “mini-sample”: pick recent changes and verify evidence completeness.

Days 61–90: Make it audit-ready and repeatable

• Run a full mock audit sampling exercise across teams.
• Tune exception handling: define what counts as an exception and how it is approved and tracked.
• Build dashboards or recurring reports (change volume, emergency changes, missing fields).
• Centralize control narratives and evidence tracking in Daydream so audit requests do not become a cross-team scramble.

Frequently Asked Questions

What counts as a “change” under the entity authorizes, designs, develops or acquires, configures, documents, tests, approves changes requirement?

Treat any modification to production code, infrastructure, security settings, logging/monitoring, data handling, or enabled third-party functionality as a controlled change ¹. If it can affect customer impact or control performance, capture it.

Do we need a formal Change Advisory Board (CAB) for SOC 2?

SOC 2 does not require a CAB by name ¹. You do need defined approvals aligned to risk, and you must show they occurred for sampled changes.

How should we handle emergency hotfixes without failing audit samples?

Allow an emergency path, but require a ticket, an authorized approver, and a documented retrospective review with test evidence captured after the fact ¹. Auditors mainly look for discipline and traceability under pressure.

Our team makes SaaS admin-console changes. How do we evidence testing and approval?

Create a change ticket, attach screenshots/exports of before-and-after settings, record who approved, and document a validation checklist (for example, confirm SSO still works and logs still flow). Where possible, turn on admin audit logs and retain the relevant entries.

Are third-party software upgrades part of CC8.1?

Yes. The criterion includes changes you acquire and configure, so major upgrades, new integrations, and enabling new modules should follow the same ticketing, risk review, testing, and approval expectations ¹.

What evidence is usually missing in SOC 2 change management samples?

The most common gaps are missing approval timestamps, missing test artifacts linked to the change, and untracked configuration changes made outside the normal workflow. Fix this by requiring linkages (ticket ↔ PR ↔ deployment) and a defined evidence packet.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017