What the 2027 SOC 2 Trust Services Criteria would change
A proposal out for comment, not criteria in force. It cuts the common criteria from 33 to 20, gives vendor management its own series, and adds points of focus for AI.

The 2027 SOC 2 Trust Services Criteria are a proposal, not a standard in force. The AICPA published them as an exposure draft dated October 27, 2026, prepared by the SOC 2 Working Group of its Assurance Services Executive Committee, with comments requested by January 15, 2027. If the AICPA issues them as final, they apply to engagements beginning on or after December 31, 2027, and early implementation is permitted.1
The draft cuts the common criteria from 33 to 20 and the full set from 61 to 50. It regroups the common criteria into eight series, gives vendor management a series of its own, and adds points of focus for AI and other emerging technology. The criteria stay outcome based. Points of focus stay optional.
Nothing here asks a company preparing for SOC 2 today to rebuild anything. The 2017 criteria with the 2022 points of focus remain the ones examinations use until final 2027 criteria exist.2
What the exposure draft is
The draft comes from the SOC 2 Working Group of the AICPA’s Assurance Services Executive Committee, the body that sets the Trust Services Criteria. It states two objectives. The first is to reduce complexity and make SOC 2 reports easier to use, by combining similar criteria, removing unnecessary ones, adding criteria where that helps clarity, and tightening the wording. The second is to modernize the criteria for systems that now rely on automation and artificial intelligence.1
It is narrower than the 2017 document in one respect. The draft is designed specifically for SOC 2 and SOC 3 engagements. The 2017 criteria with the 2022 points of focus stay in place for SOC for Cybersecurity and SOC for Supply Chain.1 So after any final issue there would be two current versions of the criteria, each for different SOC products.
The AICPA published a clean draft and a redline against the 2017 text. The redline shows the old wording and the new wording together, but it does not say which old criterion became which new one. The mapping further down is our reading of the two documents side by side.
From 61 criteria to 50
The cut comes from the common criteria, the set every SOC 2 report covers. The category criteria barely move: availability and confidentiality each gain one, and processing integrity and privacy keep the same count.1 The 2017 figures are counted in full on how many criteria SOC 2 has.
| Category | 2017 criteria | 2027 draft |
|---|---|---|
| Common criteria | 33 | 20 |
| Availability | 3 | 4 |
| Confidentiality | 2 | 3 |
| Processing integrity | 5 | 5 |
| Privacy | 18 | 18 |
| Total | 61 | 50 |
Security still needs no criteria beyond the common set. A report that adds availability, confidentiality, processing integrity or privacy still adds that category’s own series on top.1
The eight common criteria series
The 2017 common criteria ran from CC1 to CC9, and the first five series followed the structure of the COSO internal control framework, principle by principle.2 The draft drops that alignment and never mentions COSO. Its eight series are control environment, information and communication, risk assessment, monitoring activities, logical and physical asset protection, system operations, system development and change management, and vendor management.1
| 2027 draft | Heading in the draft | Closest 2017 criteria (our reading) |
|---|---|---|
| CC1 Control environment | ||
| CC1.1 | Integrity and ethical values | CC1.1, CC1.2 |
| CC1.2 | Commitment to competence | CC1.3, CC1.4, CC1.5 |
| CC2 Information and communication | ||
| CC2.1 | System documentation | CC2.1, policy points from CC5.3 |
| CC2.2 | Communication of policies, system components, and responsibilities | CC2.2, CC2.3 |
| CC3 Risk assessment | ||
| CC3.1 | Establish and structure the risk management program | CC3.1 |
| CC3.2 | Execute the risk management program | CC3.2, CC3.3 |
| CC3.3 | Monitor and improve the risk management program | CC3.4 |
| CC4 Monitoring activities | ||
| CC4.1 | Monitoring and communication of deficiencies | CC4.1, CC4.2 |
| CC5 Logical and physical asset protection | ||
| CC5.1 | Logical access over system resources | CC6.1, CC6.2, CC6.3 |
| CC5.2 | Data center and facility management | CC6.4 |
| CC5.3 | Management of information technology devices and software | CC6.1, CC6.5, CC6.8 |
| CC5.4 | Network integrity and boundary protection | CC6.6, CC6.7 |
| CC5.5 | Encryption of data | CC6.1, CC6.7 |
| CC5.6 | Vulnerability identification and management | CC7.1 |
| CC6 System operations | ||
| CC6.1 | Monitoring and operation of system components | CC7.2, CC7.3 |
| CC6.2 | Incident response programs | CC7.3, CC7.4, CC7.5 |
| CC7 System development and change management | ||
| CC7.1 | Infrastructure development and change management | CC8.1 |
| CC7.2 | Acquired software development and change management | CC8.1 |
| CC7.3 | Internally developed software development and change management | CC8.1 |
| CC8 Vendor management | ||
| CC8.1 | Vendor management | CC9.2 |
Most common criteria identifiers that survive now mean something else. CC6.1 in the draft is system monitoring, which was CC7.2 in 2017. CC7.1 is infrastructure change management, which was part of CC8.1. A control mapping keyed on criterion numbers will point at the wrong criterion for most of the common criteria, so map by content.
The 2017 criteria that disappear
Seventeen 2017 identifiers have no counterpart in the draft: CC1.3, CC1.4, CC1.5, CC2.3, CC3.4, CC4.2, CC6.3 to CC6.8, CC7.4, CC7.5, CC9.1, CC9.2 and P3.2. Their content mostly moved rather than vanished.1 Roles, responsibilities and accountability, once covered by CC1.3 and CC1.5, appear as points of focus under commitment to competence. External communication, once CC2.3, joins internal communication in CC2.2. Change assessment, once CC3.4, becomes the recalibration point of focus in CC3.3.
The six retired logical and physical access criteria, CC6.3 to CC6.8, spread across the new CC5 series. Incident response and recovery, once CC7.4 and CC7.5, become one incident response criterion, CC6.2. Vendor risk, once CC9.2, becomes CC8.1. The explicit consent criterion, P3.2, moves into the choice and consent group as P2.2.
CC9.1 is the one to read twice. In 2017 it was a common criterion about mitigating business disruption, with a point of focus on insurance. In the draft, the business disruption planning point of focus appears under A1.3, an availability criterion that applies only when availability is in scope, and the insurance point of focus is gone.1
Availability gains a criterion by splitting. The old A1.2 combined environmental protection with backup and recovery. The draft separates them into A1.2 for environmental protections and A1.3 for resilience, so recovery testing moves from A1.3 to A1.4. Confidentiality splits its old identify and maintain criterion in two, so classification is C1.1, maintenance is C1.2, and disposal moves from C1.2 to C1.3.
Vendor management becomes its own series
Vendor risk was the last 2017 common criterion, CC9.2, under a risk mitigation heading. In the draft it is CC8.1, a series of its own. The criterion sentence is close to the old one. The points of focus grow.1
A new point of focus calls for an inventory of the vendors and business partners that matter to the in-scope system. Another adds evaluation of external components, naming hardware, software, AI models, APIs and plugins, before use and as they are updated. A third covers subservice organizations: obtaining and reviewing SOC or other assurance reports where they exist, identifying complementary controls, and closing gaps in coverage. Termination procedures now mention exporting data in a usable format as well as returning and removing it.1
The AI and emerging technology points of focus
The draft singles out AI because of its capacity for autonomous decisions, its reliance on large datasets, and the difficulty of explaining and monitoring it. It adds points of focus for AI across the common criteria and the category criteria, written to cover technology not yet in wide use as well as what exists today.1 The table restates each one in plain terms.
| Criterion | What the point of focus asks for, paraphrased |
|---|---|
| CC1.2 | Training for technical staff accounts for emerging and maturing technologies such as AI. |
| CC2.2 | People who run AI components are told how to operate them, and users are told when output came from AI. |
| CC3.2 | The risk assessment covers AI risks: manipulated training data, adversarial inputs, model misuse, bias, prompt manipulation and data poisoning. |
| CC3.3 | The risk framework is recalibrated when AI or blockchain arrives, including model drift and weak validation data. |
| CC5.1 | Access design considers robotic process automation and AI agents, and access reviews catch AI accounts that do not need access. |
| CC5.3 | Unsanctioned AI platforms and unauthorized AI tools or models are detected and dealt with. |
| CC5.6 | AI platforms are protected against prompt injection, jailbreak chaining and data poisoning. |
| CC6.1 | AI components are monitored for drift, degradation, bias amplification and unexpected outputs, and malicious prompts are a detection target. |
| CC7.2, CC7.3 | Where you can train a model, changes to training and fine tuning data are authorized and validated, and adversarial inputs are detected. |
| CC8.1 | Third party components, including AI models, APIs and plugins, are evaluated before use and again when they change. |
| A1.1 | Excessive or malformed inputs, such as floods of API calls or AI prompts, are detected and mitigated so they do not degrade availability. |
| PI1.1 | Data used to train, fine tune or run a model is accurate, complete, relevant and authorized. |
| PI1.3 | Models that influence processing are validated before deployment, tested for bias and revalidated after retraining. |
| PI1.4 | Outputs a model generates or influences are monitored, checked for drift and open to human review or override. |
| P4.1 | Personal information is not improperly retained or exposed by AI models. |
Other additions sit beside these. Vulnerability scanning under CC5.6 and patching under CC7.1 may use traditional or AI-enabled techniques. A point of focus under CC5.3 covers internet of things and edge devices, and CC3.3 names blockchain risks such as smart contract changes and signing key custody. The glossary also defines a maturing technology: one established in an industry but new to the organization, so experience with it is still developing.1
One piece is missing. The draft refers to further AICPA guidance on applying the criteria to systems with AI components, and marks that reference as a document still under development.1
What does not change
The criteria still describe outcomes, not controls. The draft says there is no predetermined set of controls that can mitigate every risk, so each organization designs its own and the criteria are used to evaluate them.1 The five categories are the same. Security is covered by the common criteria alone, and each other category adds its own criteria.
Points of focus stay optional. Using the criteria “does not require an assessment of whether each point of focus is addressed,” and each point of focus does not require a specific control. Management may tailor points of focus that do not fit, or add its own.1 The new AI points of focus inherit that status. They help management and the service auditor evaluate controls. They are not a checklist.
The 2017 criteria do not go away either. They remain the SOC 2 criteria until a final 2027 version is issued and in use, and the draft keeps them for SOC for Cybersecurity and SOC for Supply Chain after that.1
What to do if you are preparing for SOC 2 in 2026 or 2027
Nothing to rebuild now. The draft’s criteria are mostly existing material regrouped and renumbered, its new points of focus are optional, and none of it is final. A control that meets a 2017 outcome does not stop working because the criterion it maps to changes number. What would change is the mapping, and that can wait for final text.
Ask your service auditor which version a 2027 engagement will use. The proposed effective date turns on when an engagement begins, and early implementation is permitted once the criteria are final.1 An engagement that starts late in 2027 is the case to settle in writing before the period begins.
Keep an inventory of AI components and AI vendors. Several of the new points of focus assume you already know where AI sits in your system: risk identification is informed by an inventory of assets, and vendor management names AI models, APIs and plugins as components to evaluate.1 A list of which models you run, which you call through a vendor, and what data reaches them is useful under either version. If AI is part of what you sell, see SOC 2 for AI companies.
Wait for the final text. The draft is out for comment, and the final criteria may differ from it. Treat the criterion numbers, headings and points of focus on this page as proposals until the AICPA issues the final criteria.
What Polara does with the 2027 criteria
Every current Polara engagement is performed against the 2017 criteria with the 2022 points of focus, and the examination itself is performed by an independent partner auditor. When the AICPA issues final 2027 criteria, we will publish our control mapping to them. That is the whole commitment. There is no date attached, and nothing on this page should be read as support for criteria that do not exist yet. Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
If you want to know which categories belong in your report today, the scoping tool works through it, and the criteria guide covers what each current category asks for.
Questions
When do the 2027 SOC 2 criteria take effect?
How many criteria are in the 2027 draft?
Does a SOC 2 audit in 2026 use the 2027 criteria?
Does the draft add AI requirements to SOC 2?
Do SOC for Cybersecurity and SOC for Supply Chain change too?
Sources
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.