SOC 2 Is Getting an Update: What the Revised Trust Services Criteria Mean for Your Organization

SOC 2 reports are soon going to look different. The AICPA has opened a revised Trust Services Criteria (TSC) for comment with an expectation to release in 2027. While organizations should pay attention, similar to the changes in HIPAA’s Safeguards, these are still very much in draft and are subject to change prior to official release.

In its current state, the changes extend beyond cosmetic edits. Some criteria have been consolidated, others were split apart, and a few were removed entirely. If your organization undergoes a SOC 2 examination, now is the time to understand what is changing and how it may affect your next audit so you can prepare accordingly.

The new criteria will apply to any report issued after December 31, 2027. That date gives organizations time to prepare, but it is not a long runway. Control mapping, gap analysis, and readiness work all take time, so it’s best practice to start early.

What Will Stay the Same After the Next SOC 2 Updates

Before diving into the details of what will change, it helps to know what will not change. The five trust services categories will remain Security, Availability, Processing Integrity, Confidentiality, and Privacy. Processing Integrity and Privacy are mostly unchanged in substance, so most organizations with those categories in scope will see less disruption.

Clearer Criteria Titles with the SOC 2 Update

Every criterion now carries a short title that describes its primary objective. Instead of reading through a long paragraph to figure out what a criterion is about, auditors and management can understand its purpose at a glance. This makes it easier to map controls, plan testing, and explain your program to customers.

The reference to the COSO Principles has also been removed from the criteria. Organizations that used COSO as a structure for their internal control program can continue to do so, but the SOC 2 criteria no longer point to it directly.

Major Changes to the Common Criteria

The Common Criteria, which are the CC series, account for most of the revisions, consolidating from 33 criteria down to 21 in its current draft. One negative is that many of the criteria references have shifted. For example, Logical & Physical Access is currently covered via CC6.1-CC6.8, but now it’s CC5.1-CC5.6 (which is comical for us “seasoned” in GRC since Logical Access held the CC5 reference prior to the 2017 update).

At the end of the day, the changes are beneficial, reducing duplication and reducing the overall number of criteria.

Control Environment

CC1.0 shrinks from five criteria to two. The language about the Board of Directors has been replaced with the term “Those Charged with Governance.” This designation recognizes that oversight may sit with a board, committee, or another body depending on how an organization is structured.

Risk Assessment

CC3.0 is now split into three criteria that follow the life cycle of a risk management program. The first establishes the program, the second executes it, and the third monitors and improves it. This structure gives organizations a clearer roadmap for what auditors will expect at each stage.

Control Activities

The existing CC5.0 criteria have been removed. Their substance was already covered by other criteria, so this is more of a cleanup than a loss of coverage. Organizations should still confirm that their control activities map to the remaining criteria.

Incident Response

The former CC7.2 through CC7.5 are now consolidated into a single criterion, CC6.2 Incident Response Programs. Teams that previously tracked four separate criteria for incident response will now have one criterion to address going forward.

System Development and Change Management

The former CC8.0 is now split into three criteria that address different components of the system under audit:

• CC7.1 covers Infrastructure Development & Change Management.
• CC7.2 covers Acquired Software Development & Change Management.
• CC7.3 covers Internally Developed Software Development & Change Management.

Organizations that buy software and organizations that build it will now see their obligations separated more clearly.

Changes to Availability and Confidentiality

The Availability criterion A1.2 is separated into two criteria:

• A1.2 covers Environmental Protections
• A1.3 covers Resilience Capabilities

This gives physical and environmental safeguards their own focus, apart from the broader resilience planning that supports system availability.

The Confidentiality criterion C1.1 is also separated into two criteria:

• C1.1 covers Classification and Inventory, which asks how confidential data is identified and tracked.
• C1.2 covers Maintenance of Confidential Data, which focuses on how that data is protected over time.

Major Changes to the Common Criteria

How the Revised Criteria Addresses AI

Although the AICPA did not add AI-specific criteria, the revised framework includes AI-specific points of focus, which ask organizations to consider the risks introduced by AI components within their systems. Examples include training data manipulation, adversarial inputs, and model misuse. They also cover reliability concerns, bias, unintended consequences of AI outputs, prompt manipulation, and data poisoning.

These points of focus do not create a new checklist but rather guide how organizations think about AI risk within the criteria that already apply to their system.

Why SOC 2 Does Not Include Specific AI Criteria

The AICPA has been clear that it is not the expert on artificial intelligence. Rather than build AI requirements into the baseline criteria, the AICPA chose to leave that work to frameworks designed for it.
For organizations with customers asking about their AI, two options stand out. The first is a SOC 2 examination combined with an AIUC-1 report, which addresses AI-specific assurance needs alongside the SOC 2 controls.

The second is to adopt reputable AI governance frameworks such as ISO 42001 or the NIST AI Risk Management Framework and fold them into your security and risk management programs. Either path gives customers a clearer view of how AI is governed without forcing AI controls into criteria that were not built for them.

Preparing for the Transition to the New SOC 2 Version

The revisions are significant enough that organizations should not wait until the last months before the effective date. Start by comparing your current control set against the new criteria titles and identifying which controls will need to be split, merged, or relabeled. Review your risk management program to see whether it already follows the establish, execute, and monitor structure. Confirm that your incident response, change management, and data classification processes are documented in a way that maps to the new criteria.

If you use AI in any part of your service, begin evaluating those systems against the new AI points of focus now. Customers are already asking these questions, and having a credible answer ready will help during both sales conversations and your examination.

The updated framework brings more structure to SOC 2 and makes the expectations of each criterion easier to understand. Organizations that prepare early will find the transition far more manageable.
To learn more about what to expect, how to prepare, or how to navigate SOC 2, contact us today.