COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control

For SOC 2 reporting, Principle 9 sits in the “Risk Assessment” component and tends to fail in practice for a simple reason: teams treat change management as an IT process instead of an enterprise internal control requirement. Auditors are looking for evidence that your organization spots changes that matter (new products, acquisitions, leadership shifts, new regulations, cloud migrations, new third parties, major system releases) and deliberately reassesses whether existing controls still work.

Operationalizing this requirement is less about writing a policy and more about building an intake and decision system. You need clarity on (1) what qualifies as a “significant change,” (2) who must be notified, (3) what analysis must occur before and after the change, and (4) what proof you will retain.

This page gives requirement-level implementation guidance for the coso principle 9: the entity identifies and assesses changes that could significantly impact the system of internal control requirement, with a practical workflow, evidence list, exam questions, common hangups, and a 30/60/90 plan you can execute without turning your GRC program into a bureaucracy.

Regulatory text

Requirement (SOC 2 / Trust Services Criteria): “COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control.” ¹

Operator interpretation: You must (1) detect relevant changes, (2) evaluate how those changes affect risks and controls, (3) update the system of internal control accordingly, and (4) retain evidence that this happens consistently. Under SOC 2, “system of internal control” includes the policies, processes, roles, systems, and oversight that support the Trust Services Criteria in scope.

Plain-English interpretation (what the auditor expects)

Auditors generally expect a demonstrable loop:

1. You notice change (not just IT changes; also org, regulatory, financial, operational, and third-party changes).
2. You assess impact on risks and on existing controls (design and operation).
3. You decide and act (add/modify controls, change ownership, adjust monitoring, update documentation).
4. You verify and preserve evidence (so it’s auditable).

A good mental model: if your company can materially change how it builds, sells, hosts, or supports the service, then your control system must adapt on purpose, not by accident.

Who it applies to (entity and operational context)

This applies to the service organization undergoing a SOC 2 examination, across:

• Executive and governance changes: leadership turnover, board oversight changes, reorganizations, rapid hiring, layoffs, new compensation plans that shift incentives.
• Business and product changes: new product lines, significant feature launches, new customer segments, changes to SLAs, entering regulated markets, M&A, divestitures.
• Technology and architecture changes: cloud migrations, new identity provider, new data stores, encryption/key management changes, major CI/CD pipeline changes.
• Third-party changes: new critical third parties, changing sub-processors, major contract/SLA modifications, outages that trigger architectural shifts.
• Regulatory and external environment changes: new legal obligations, emerging threats, industry incidents that alter your threat model.

Your operational challenge: changes originate everywhere, but control ownership is often concentrated in security, IT, finance, and compliance. Principle 9 forces you to connect those dots.

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

Step 1: Define “significant change” in operational terms

Create a short decision standard that a non-compliance stakeholder can apply. Include categories and examples. Keep it crisp.

Practical criteria you can use:

• Changes that affect in-scope systems, in-scope data, or control owners.
• Changes that alter how controls are performed, automated, monitored, or evidenced.
• Changes that introduce or modify critical third parties or sub-processors.
• Changes driven by new contractual, regulatory, or customer commitments.

Deliverable: “Significant Change Criteria” (1–2 pages) owned by the control owner team and approved by compliance/CCO.

Step 2: Build a change intake mechanism (single front door)

You need a consistent way to learn about change early enough to assess it.

Common intake channels:

• IT change management (tickets/approvals for production changes).
• Product release governance (release notes, launch checklists).
• Third-party onboarding/procurement (intake forms, security reviews).
• Legal/compliance tracking (new regulatory obligations, DPAs, contract changes).
• HR/Finance signals (reorgs, key role turnover, new incentives).

Operational tip: don’t invent five new forms. Add a small set of compliance impact questions to existing workflows.

Deliverable: a documented “Change Intake Sources” map that lists each channel, owner, and how compliance is notified.

Step 3: Perform a documented impact assessment for each significant change

For each qualifying change, complete an assessment that answers:

• What changed? (scope, systems, data, third parties)
• What risks change? (new risks, increased likelihood/impact, risk ownership)
• What controls are affected? (control IDs/descriptions, automated vs manual controls)
• What updates are required? (control design updates, monitoring, evidence, training)
• What validation will occur? (testing, metrics, post-implementation review)

Use a standard template so assessments are comparable and auditable.

Deliverable: “Change Impact Assessment” record per change event.

Step 4: Update the system of internal control (not just documentation)

Your impact assessment must drive action. Typical outputs:

• New or revised control activities (e.g., additional monitoring, new approvals, segregation of duties updates).
• Updates to policies and procedures (e.g., incident response changes due to architecture changes).
• Updates to control ownership and RACI.
• Updates to evidence strategy (what proof is produced, where it is stored).
• Targeted training or communications to operators.

If you only update your narrative/control matrix and do not change how teams operate, auditors will treat Principle 9 as weak.

Deliverable: linked work items showing controls were updated and implemented.

Step 5: Validate operating effectiveness after the change (where needed)

For changes that materially affect critical controls, perform a targeted check:

• Confirm the control still operates (or the new version operates).
• Confirm evidence is produced and retrievable.
• Confirm exceptions are handled.

This can be done via internal testing, peer review, or compliance sampling, depending on how formal your program is.

Deliverable: post-change validation notes or test results attached to the change record.

Step 6: Establish governance and cadence

Principle 9 is continuous, but you also need periodic oversight:

• A recurring cross-functional forum (risk committee, change review board, GRC committee) that reviews significant changes, open assessments, and control updates.
• Escalation paths when change is rushed and controls lag.

Deliverable: meeting agendas/minutes with decisions and follow-ups.

Step 7: Make it auditable (evidence design)

Map each step to evidence. A strong program makes evidence generation a byproduct of work, not a scramble before the audit.

If you use a GRC workflow tool like Daydream, configure an intake form, impact assessment template, and evidence requests that link directly to each change event and control owner. The goal is a clean chain: change event → assessment → control update → proof.

Required evidence and artifacts to retain

Minimum artifacts auditors commonly request under this requirement ¹:

• Significant Change Criteria document, with owner and approval.
• Change intake map (sources, owners, notification path).
• Change log of significant changes during the period (can be a report from tickets plus classification).
• Impact assessments for sampled changes, with dates, approvers, and conclusions.
• Control updates: revised control narratives, updated procedures, updated RACI.
• Implementation evidence: tickets, PRs, deployment approvals, procurement approvals, contract amendments, training attestations (as applicable).
• Validation evidence: test scripts/results, screenshots, monitoring output, internal review sign-off.
• Governance records: meeting minutes, action tracking, escalations.

Keep evidence in a system where you can prove completeness and integrity (versioning, timestamps, approvals).

Common exam/audit questions and hangups

Auditors will usually probe:

• “How do you define ‘significant change’ and who decides?”
• “Show me the list of significant changes in the period.”
• “Pick two changes. Show the impact assessment and what you updated.”
• “How do you ensure non-IT changes are captured (reorgs, new markets, new third parties)?”
• “How do you know your updated control is operating, not just documented?”

Hangups that cause findings:

• Only IT change tickets are assessed; business/third-party/regulatory changes are ignored.
• Impact assessments exist, but they don’t map to specific controls or produce control changes.
• Evidence is scattered; teams can’t retrieve approvals, rationale, or testing.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating Principle 9 as an annual risk assessment.
   Fix: keep annual/quarterly risk assessment, but add an event-driven change assessment trigger tied to intake channels.

2. Mistake: “Significant change” is undefined or too vague.
   Fix: write criteria with concrete triggers (systems, data, third parties, control ownership).

3. Mistake: No closed-loop tracking from assessment to remediation.
   Fix: require an “actions” section in the impact assessment and track actions to closure with owners and due dates.

4. Mistake: Compliance learns about launches after they happen.
   Fix: embed compliance impact questions into product launch and procurement workflows.

5. Mistake: Evidence is retrospective and inconsistent.
   Fix: standardize templates and store everything in one evidence repository tied to the change ID.

Enforcement context and risk implications (practical, SOC 2-facing)

No public enforcement cases were provided in the supplied source catalog. For SOC 2, the immediate consequence is typically an audit finding (control design gap or operating effectiveness gap) that can drive report qualifications, increase auditor testing, and create customer escalations during security reviews. Operationally, the risk is predictable: major changes break controls quietly (access, logging, incident response, third-party oversight), and you discover the gap during an incident or during the audit.

Practical 30/60/90-day execution plan

Days 0–30: Stand up the mechanics

• Name an owner (often GRC lead) and define stakeholders (IT, Security, Product, Legal, Procurement, HR/Finance).
• Draft and approve Significant Change Criteria.
• Inventory change intake sources and add a lightweight compliance notification step to each.
• Build a Change Impact Assessment template and approval workflow.
• Pilot the process on a small set of known recent changes to validate the template.

Days 31–60: Make it operational across the org

• Train intake owners (product ops, IT change manager, procurement, legal) on what to route.
• Start maintaining a Significant Change Log with consistent classification.
• Run the first governance review meeting; track actions to closure.
• Update control narratives and evidence instructions so operators know what to save.

Days 61–90: Prove operating effectiveness

• Perform targeted validation on a sample of changes: confirm revised controls operate and produce evidence.
• Close gaps: missing owners, missing evidence, unclear thresholds, weak approvals.
• Prepare an audit-ready package: criteria, change log, sampled assessments, linked control updates, meeting minutes.
• If using Daydream, connect change records to control statements and evidence tasks so retrieval is one click per sample.

Frequently Asked Questions

What counts as a “change” under COSO Principle 9 for SOC 2?

Any internal or external event that can materially affect risks or control performance counts. That includes system changes, new third parties, reorganizations, new regulatory obligations, and major product or customer-segment shifts ¹.

Do we need a formal Change Advisory Board (CAB) to meet this requirement?

No specific governance structure is mandated, but you do need a consistent mechanism to identify significant changes, assess impact, and document decisions. A lightweight cross-functional review works if it produces repeatable evidence ¹.

We already have IT change management. Is that sufficient?

IT change management is usually necessary but rarely sufficient, because it may not capture business model changes, third-party changes, or compliance-driven changes. Expand intake to non-IT channels and require explicit control impact mapping ¹.

How do we show auditors that we didn’t miss significant changes?

Maintain a significant change log tied back to upstream sources (ticketing, procurement, launch governance, legal tracker) and document your classification decision. Auditors look for completeness logic, not perfection ¹.

What’s the minimum evidence for an impact assessment?

The assessment should identify the change, affected systems/data, risks impacted, controls impacted, required control updates, approvals, and follow-up validation. Without mapping to specific controls and actions, it reads as a memo rather than control operation ¹.

How should we handle emergency changes?

Allow emergency changes, but require a documented post-implementation impact assessment and validation step to confirm controls still operate. Track exceptions and ensure emergency paths don’t become the default ¹.

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