SOC 2 CC3.4: Identifying and Assessing Significant Changes

SOC 2 CC3.4 requires an entity to identify and assess changes that could significantly affect its system of internal control. It closes the CC3 series (Risk Assessment), and a frequent finding under it is a risk register that was built once before the audit and then never touched when the business, the systems, or the vendors around it changed.

What does SOC 2 CC3.4 require?

CC3.4 keeps the risk assessment alive over time. The risks identified under CC3.2 reflect the business as it was when they were written, and CC3.4 requires the entity to reassess when something changes enough to move that picture. It is the criterion that turns risk assessment from a one-time document into an ongoing process.

The criterion names the kinds of change to watch. It covers changes in the external environment, such as regulation or the economy; changes in the business model, such as new products, acquisitions, rapid growth, or new geographies; and changes in leadership. For the trust services criteria it adds changes in systems and technology, changes in vendor and business partner relationships, and changes in threats and vulnerabilities.

CC3.4 is where risk assessment meets change management and vendor management. A significant system change assessed here is the same change that runs through the change management controls under CC8.1, and a change in a vendor relationship is the trigger for the vendor risk assessment under CC9.2. CC3.4 is the risk-assessment side of those events.

What are the CC3.4 points of focus?

The AICPA defines 6 points of focus for CC3.4. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Assesses changes in the external environment. The process considers changes to the regulatory, economic, and physical environment the entity operates in.
• Assesses changes in the business model. The process considers new or dramatically altered business lines, acquisitions or divestitures, rapid growth, changing reliance on foreign geographies, and new technologies.
• Assesses changes in leadership. The process considers changes in management and their effect on attitudes toward internal control.
• Assesses changes in systems and technology (trust services addition). The process considers changes in the entity's systems and technology environment.
• Assesses changes in vendor and business partner relationships (trust services addition). The process considers changes in the vendors and business partners the entity relies on.
• Assesses changes in threats and vulnerabilities (trust services addition). The process assesses changes in internal and external threats and vulnerabilities and the resulting likelihood and magnitude of risk.

The first three points come from COSO. The last three are added for the trust services criteria and are the ones a service organization touches most, because systems, vendors, and the threat picture change far more often than the business model or the board.

How do you meet CC3.4 in cloud environments?

Cloud environments meet CC3.4 by wiring change into the risk process so the register moves when the environment does:

• Change-triggered risk reviews. Significant system and infrastructure changes trigger a look at whether the risk register needs updating, rather than waiting for an annual cycle.
• A monthly cadence that catches drift. Registering new risks, reassessing residual risk, and evaluating new vendors happen on a set cadence, so change is picked up as routine work rather than a scramble.
• Vendor changes flow into the assessment. Onboarding a new subservice provider, or a material change to an existing one, triggers a vendor risk assessment feeding the register.
• Threat and vulnerability changes update ratings. New vulnerabilities and shifts in the threat picture prompt a re-rating of the affected risks rather than leaving stale scores in place.

A GRC platform does not satisfy CC3.4 on its own. It can flag review dates and hold the updated register, but the control is the entity noticing change and reassessing risk; the platform tracks the cadence rather than performing the assessment.

How do you meet CC3.4 on-prem?

On-prem and hybrid environments assess a wider set of changes, because hardware, facilities, and long procurement cycles add change events a cloud provider would absorb. The risk management guide for hybrid and on-prem environments covers the detail; the shape is:

• Hardware and facility changes. New hardware, a data center or colocation move, or a change in provider is assessed for its effect on the control picture and reflected in the register.
• Firmware and supply-chain changes. A vendor security disclosure or a firmware update on management controllers is a change in the threat picture that prompts a re-rating, not just a patch.
• Vendor and subservice changes. A change in the colocation or hosting provider, or in its own SOC 2 posture, triggers a reassessment, since the data center is part of the system.
• A review cadence and event triggers. The register has a review cadence and named triggers, so residual risk ratings do not sit at whatever an assessor wrote a year or more ago.

The point of CC3.4 is that a risk register earns audit credit only when it reflects the entity as it is now. A register frozen at readiness time fails the criterion even if it was accurate the day it was written.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC3.4?

How does CC3.4 map to ISO 27001:2022?

ISO 27001 requires the risk assessment and treatment under Clauses 6.1.2 and 6.1.3 to be maintained rather than run once, and Annex A 5.8 requires information security to be integrated into project management, which is where system and business changes get assessed. Together they line up with CC3.4's requirement to reassess risk when things change, so the change-triggered reviews and register update cadence carry across both frameworks. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC3.4 keeps the risk register from CC3.2 current against the objectives set in CC3.1, and it picks up new fraud exposures assessed under CC3.3 as the business changes. It is the risk-assessment counterpart to two criteria elsewhere in the Common Criteria: system changes assessed here run through the change management controls under CC8.1, and vendor changes assessed here trigger the vendor risk management under CC9.2.

Frequently Asked Questions

What does SOC 2 CC3.4 mean?

SOC 2 CC3.4 means an entity must identify and assess changes that could significantly affect its system of internal control. It covers changes in the external environment, the business model, and leadership, and for the trust services criteria adds changes in systems and technology, vendor relationships, and threats and vulnerabilities.

What evidence satisfies CC3.4?

The core evidence is a risk register with an update history showing it changes when the environment does, change-triggered risk reviews, a vendor risk assessment process, a risk assessment policy that defines the review cadence and triggers, and management or committee minutes. Auditors look for a living register, not one frozen at readiness time.

How often should a SOC 2 risk register be updated?

On a defined cadence plus whenever a significant change occurs. Many programs review the register monthly for new risks and vendors and reassess residual risk at least quarterly, with additional reviews triggered by significant system, vendor, or threat changes. The cadence matters less than the register reflecting the entity as it is now.

How is CC3.4 different from CC8.1?

CC3.4 is the risk-assessment side of change: deciding whether a change to the business, systems, vendors, or threats affects internal control and updating the risk register. CC8.1 is the change management side: authorizing, designing, testing, approving, and implementing the change itself. A significant system change usually touches both.

How does CC3.4 relate to vendor risk?

Changes in vendor and business partner relationships are one of CC3.4's points of focus, so onboarding a new vendor or a material change to an existing one triggers a risk reassessment. The vendor assessment itself is carried out under CC9.2. Classifying vendors by the data they touch keeps reassessment effort focused on the relationships that affect the control picture.