TSC-CC3.4 Guidance

TSC-CC3.4 (COSO Principle 9) requires you to identify changes that could materially affect your SOC 2 system of internal control, assess their risk impact, and update controls and evidence accordingly ¹. Operationalize it by formalizing “change detection + risk assessment + control update” across product, IT, security, and third parties.

Key takeaways:

• Define what “significant change” means for your services, systems, people, and third parties, then route those changes through a documented assessment workflow.
• Prove operation with tickets, meeting minutes, approvals, risk assessments, and post-change validation tied to in-scope controls.
• Auditors look for consistency: the same change categories recur, assessments happen on time, and outcomes update the control environment.

The tsc-cc3.4 guidance requirement is a governance control disguised as a process requirement: you must show that your organization detects meaningful change and evaluates its impact on internal control before that change creates a gap. This is broader than IT change management. It includes shifts in your operating model (new products, acquisitions), risk landscape (new threats, new regulations), technology stack (cloud migrations, new CI/CD patterns), workforce (reorgs, turnover in control owners), and third parties (new sub-processors, data residency changes, outsourced support).

For a SOC 2 audit, the practical test is straightforward: can you produce a repeatable mechanism that (1) identifies changes, (2) assesses whether they could significantly impact the system of internal control, and (3) drives updates to controls, control ownership, and evidence collection? If the process exists only in people’s heads, it will fail under audit sampling. If it exists but never triggers control updates, it will also fail.

This page gives requirement-level implementation guidance you can execute quickly: scope, workflow, roles, artifacts, and an execution plan you can run as a CCO, GRC lead, or control owner.

Regulatory text

Excerpt (TSC-CC3.4): “COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control” ¹.

What the operator must do:
You need a documented, operating process that detects relevant changes and evaluates their control impact. That evaluation must result in action when needed: updating policies, procedures, risk assessments, control design, control owners, and monitoring so the SOC 2 control system remains effective as the business changes ¹.

Plain-English interpretation

• “Identifies changes” means you have defined inputs (where changes are noticed) and owners accountable for surfacing them.
• “Assesses changes” means you make a recorded judgment about control impact, not an informal hallway conversation.
• “Significantly impact” means changes that could alter confidentiality, integrity, availability, processing integrity, or privacy commitments in your SOC 2 scope, including changes introduced by third parties that touch the system ¹.

Who it applies to

Entity types: Organizations undergoing a SOC 2 audit that include Common Criteria in scope ¹.

Operational context (where this shows up in real life):

• SaaS, fintech, health-tech, and B2B platforms with frequent product releases and infrastructure changes.
• Organizations with multiple control owners (Security, IT, Engineering, Support, People Ops, Procurement).
• Any environment where third parties provide hosting, logging, customer support, payment processing, identity, or other in-scope functions.

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

Step 1: Define “significant change” for your SOC 2 system

Create a one-page Significant Change Criteria standard. Keep it simple and auditable. Include categories and triggers relevant to your environment:

Change category	Examples	Why it matters to CC3.4
Business / org	Reorgs, new leadership over control functions, new support model	Ownership and accountability for controls can break
Product / service	New product line, major feature touching customer data, new data types	Scope and risk profile change
Technology	Cloud provider change, network redesign, new CI/CD, encryption changes	Control design and evidence sources change
Security / risk	New threat intel pattern, new vulnerability class affecting your stack	Risk assessment and monitoring updates may be required
Third party	New sub-processor, change in data location, outsourced admin	External dependencies can materially alter control environment
Compliance commitments	New customer contractual controls, new trust criteria in scope	Control set and testing plan change

Deliverable: a controlled document approved by GRC/Security leadership and referenced by your change workflows.

Step 2: Establish change “intake points” (where changes are detected)

List the systems and meetings where changes naturally surface, then make them auditable:

• Engineering: change tickets (Jira), release approvals, architecture review board notes.
• IT/Security: access system changes, SIEM/logging changes, incident postmortems.
• Procurement/Legal: third-party onboarding, sub-processor updates, contract changes.
• People Ops: role changes for privileged access teams, onboarding/offboarding process changes.

Practical rule: every intake point needs an owner and a path to GRC review when triggers match your Significant Change Criteria.

Step 3: Implement a lightweight “Change Impact Assessment” workflow

You need a repeatable assessment with recorded outcomes. Use a form embedded in your ticketing system or GRC tool:

Minimum fields to capture

• Change description and scope (system/service, in-scope vs out-of-scope).
• Trigger category (from the Significant Change Criteria).
• Impacted Trust Services Categories and control areas (map to your SOC 2 controls).
• Risk assessment: what could fail, what could be exploited, what evidence source changes.
• Decision: no control impact / control update required / scope update required.
• Approvals: control owner + security/GRC sign-off.
• Validation plan: what you will test after implementation (logs, access review, configuration checks).

Deliverable: a standardized template and workflow states (Draft → Under Review → Approved → Implemented → Validated → Closed).

Step 4: Tie assessment outcomes to control maintenance

This is where most teams fall down: they record the assessment, but do not update the control environment.

Create explicit “next actions” tied to each decision:

• Control update required: revise the control narrative, procedure, and evidence description; assign an updated owner; update testing steps.
• Evidence source changed: document the new system of record and update sampling instructions for auditors.
• Scope update required: update SOC 2 system description inputs and boundaries; inform your auditor early.

Keep a short control maintenance checklist that must be completed before the change ticket closes.

Step 5: Add monitoring and periodic review

CC3.4 expects ongoing awareness, not annual scramble ¹. Put two routines in place:

• Monthly change review (GRC + Security + Eng/IT): sample closed changes tagged “significant” and confirm impact assessments were completed and actions closed.
• Quarterly environment scan: review org changes, third-party changes, major roadmap shifts, and security risk changes for anything that bypassed intake points.

Step 6: Maintain an audit trail end-to-end

Auditors test operation through evidence. Your goal is a clean chain: Change identified → assessment completed → approval recorded → control updates performed → post-change validation recorded.

If you use Daydream, set it up as the control hub: link each “significant change” record to the impacted control(s), the evidence source, and the testing notes so you can answer auditor samples without cross-tool archaeology.

Required evidence and artifacts to retain

Keep artifacts in a place you can export for the audit period:

1. Policy/standard: Significant Change Criteria and the requirement to complete impact assessments ¹.
2. Procedure/workflow: documented steps, approvers, and routing rules.
3. Completed assessments: tickets or forms showing the analysis and approvals.
4. Control maintenance records: updated control narratives, mapped evidence sources, ownership changes.
5. Review cadence proof: agendas, minutes, and action trackers from monthly/quarterly reviews.
6. Validation evidence: post-change testing results, configuration screenshots, system reports, or runbook sign-offs.
7. Third-party change artifacts: updated due diligence records when a third party change is significant (for example, new sub-processor review package, contract change approvals).

Common exam/audit questions and hangups

Auditors typically probe consistency and coverage. Expect questions like:

• “Show your definition of significant change and how staff know when to escalate.”
• “Provide a population of significant changes in the audit period and the related impact assessments.”
• “Pick three changes: show approvals, control updates, and validation.”
• “How do you capture third-party changes that affect your system?”
• “What happens if engineering ships without completing the assessment?”

Hangups that cause exceptions:

• No reliable population of changes (you cannot prove completeness).
• Assessments exist but are superficial (“no impact” with no rationale).
• Evidence sources changed mid-period and the control narrative stayed stale.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating CC3.4 as only IT change management.
   Fix: include business model, org, compliance, and third-party change categories in your Significant Change Criteria.

2. Mistake: no documented thresholds for “significant.”
   Fix: define triggers and require a written rationale for “not significant” decisions.

3. Mistake: approvals happen in chat.
   Fix: require approvals in the ticket or assessment record.

4. Mistake: control owners are not involved.
   Fix: route assessments to the mapped control owner; make them accountable for control updates.

5. Mistake: evidence retention is an afterthought.
   Fix: add “attach validation evidence” as an exit criterion before closing the change.

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so public enforcement actions are not typically tied directly to TSC-CC3.4 ¹. Your practical risk is an audit finding: a control design gap (no defined process) or operating effectiveness exception (process exists but does not run consistently). Operationally, weak change impact assessment increases the chance that a material system change breaks access controls, logging, incident response, or third-party oversight without anyone noticing until a customer asks or an incident occurs.

Practical 30/60/90-day execution plan

Days 1–30: Define, route, and pilot

• Draft and approve the Significant Change Criteria standard.
• Inventory current change intake points across Engineering, IT, Security, Procurement, and People Ops.
• Build the Change Impact Assessment template in your ticketing system or GRC platform.
• Pilot on a small set of change types (for example: infrastructure changes and new third parties).
• Train control owners and approvers with a short internal playbook.

Days 31–60: Operationalize and connect to controls

• Expand the workflow to all significant change categories.
• Map assessment outcomes to control maintenance tasks (control narrative updates, evidence source updates).
• Start the monthly change review meeting and track action closure.
• Build an auditor-ready change population report (filters, tags, or exports).

Days 61–90: Prove consistency and audit readiness

• Perform a self-test: sample completed significant changes and verify the evidence chain end-to-end.
• Close gaps: missing approvals, missing validation, stale control narratives.
• Run the quarterly environment scan and document results.
• If using Daydream, centralize linkage: change records ↔ controls ↔ evidence ↔ testing notes, so audit sampling becomes a retrieval exercise, not a reconstruction project.

Frequently Asked Questions

What counts as a “significant change” for TSC-CC3.4?

Any change that could materially affect your SOC 2 control environment, including technology, people, process, product, and third-party changes ¹. Define categories and triggers in writing so teams escalate consistently.

Do I need a separate process from engineering change management?

Not necessarily. Most teams embed a Change Impact Assessment step into existing change tickets and add routing to GRC/control owners when triggers are met ¹.

How do I show auditors a “population” of changes?

Tag or classify significant changes in a system of record (ticketing or GRC tool) and be able to export the list for the audit period. Auditors need to see completeness and then sample items for evidence.

How should third-party changes be handled under CC3.4?

Treat third-party changes as first-class change events. If a third party affects in-scope systems or data, document the change, assess control impact, and update due diligence and monitoring as needed ¹.

What evidence is most persuasive for operating effectiveness?

Completed assessments with rationale, documented approvals, and post-change validation artifacts linked to the impacted controls. Meeting minutes showing periodic review help show the process runs consistently.

What if teams move fast and skip the assessment step?

Auditors will see gaps between your policy and actual operation. Fix it with workflow guardrails (required fields, approval gates) and a monthly review that catches bypasses quickly and drives remediation.

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 Trust Services Criteria 2017