There's a problem with relying on your vendors' SOC 2 reports to establish the security of your SaaS product. Every provider involved could have perfectly respectable security controls, and you could still have a serious vulnerability sitting right where those systems connect.
Take an AI assistant that retrieves customer documents from a database and sends them to a third-party language model. The model provider might have a clean SOC 2 report. So might the database provider. But if your application fails to check which documents the customer is authorized to access, either of those services could be operating exactly as intended while your assistant hands someone another customer's confidential information.
That's the kind of problem that makes the AICPA's proposed 2027 changes to the SOC 2 Trust Services Criteria worth paying attention to.
The AICPA wants to consolidate the existing 61 criteria into 50, give vendor management its own Common Criteria category and introduce more explicit considerations for AI governance. Some of the proposed changes are organizational, but others address questions that have become increasingly complicated as SaaS products incorporate external models, APIs and automated agents.
And there are some interesting implications for companies that already have SOC 2 reports. For example, vendor risk management is currently covered under CC9.2, but the proposal would move it into a dedicated CC8 category with additional attention to individual components, subservice organizations and vendor relationships. That could change how companies document the risks associated with the third-party services they're already using.
Current status, November 8, 2026: The proposed 2027 SOC 2 Trust Services Criteria are still an exposure draft. The AICPA is accepting public comments until January 15, 2027. If approved, the revised criteria would apply to engagements beginning on or after December 31, 2027, with early adoption permitted. Companies should continue using the criteria applicable to their current examinations while the proposal is under review.
What is the AICPA proposing to change in the 2027 SOC 2 criteria?
The current SOC 2 framework uses the 2017 Trust Services Criteria, with points of focus revised in 2022. Those criteria are used by independent CPAs to evaluate controls related to Security, Availability, Processing Integrity, Confidentiality and Privacy.
Security is addressed through the Common Criteria, while the other four Trust Services Categories have additional criteria that apply when they're included in an examination's scope.
The American Institute of Certified Public Accountants (AICPA) announced the proposed revisions on October 28, 2026. Its Assurance Services Executive Committee wants to make the framework easier to interpret, reduce overlapping requirements and account for changes in how organizations develop and operate information systems.
The proposal includes some fairly significant structural changes.
Most of the reduction would happen within the Common Criteria, which would go from 33 criteria across nine groups to 20 across eight. Some existing criteria would be combined, while others would be separated into more specific requirements.
That distinction matters because the number of criteria doesn't tell you how many controls a company needs to operate.
A company might currently have several controls mapped to overlapping criteria. Consolidating those criteria could make the documentation easier to manage without changing the underlying security responsibilities.
On the other hand, separating a broad criterion into several narrower ones could make it easier for auditors to evaluate different processes independently.
Both approaches appear in the proposed framework.
Current vs. proposed SOC 2 criteria
Criteria groupingCurrent criteriaProposed 2027Common Criteria (Security)3320Availability34Processing Integrity55Confidentiality23Privacy1818Total6150
Source: Independent comparisons of the October 2026 exposure draft published by SOC2Auditors.org. Counts remain subject to final AICPA approval.
One interesting change involves the way the proposal separates different kinds of system development and change management.
Under the current framework, CC8.1 covers changes to infrastructure, software, data and procedures. The proposed criteria would move change management into CC7 and divide it into three areas: infrastructure, acquired software and internally developed software.
That makes sense when you consider how differently those activities can work.
An engineering team deploying code it developed internally might use pull-request reviews, automated tests and deployment approvals. Updating a purchased software platform could involve evaluating a vendor release and testing whether it affects existing integrations. Infrastructure changes might require reviewing cloud configurations, access permissions or network settings.
Those activities can involve completely different processes, even though they're all considered change management.
The proposed structure would allow them to be evaluated more specifically.
Availability and Confidentiality would also gain additional criteria. The Availability revisions would separate environmental protections from resilience capabilities, while Confidentiality would distinguish classification and inventory, maintenance and disposal of confidential information more clearly.
There's no established reason to assume that reducing the total number of criteria will automatically make SOC 2 examinations cheaper or easier. That depends on the systems being examined, the controls involved and how the final criteria are applied.
Why the CC8 renumbering could create confusion
Companies with existing SOC 2 programs should be particularly careful about the proposed changes to CC8.
Right now, CC8.1 addresses change management. Under the proposed framework, CC8.1 would address vendor management.
Meanwhile, current vendor risk management under CC9.2 would move into that new CC8 category.
Several other groups would also be reorganized.
Current criteriaProposed criteriaWhat changesCC8.1CC7.1–CC7.3Change management separated by system componentCC9.2CC8.1Vendor management becomes its own categoryCC6 seriesCC5 seriesLogical and physical access reorganizedCC7 seriesCC6 seriesSystem operations reorganized
This is an illustrative draft crosswalk based on independent analyses. The proposed mappings should be verified against the final AICPA criteria before implementation.
Imagine a company with several years of SOC 2 documentation. Its change-management policy references CC8.1, its evidence tracker references CC8.1 and its auditor's testing workpapers use the same number.
Replacing those references with the proposed CC8.1 would suddenly make them point to vendor management.
And because some criteria are being consolidated or divided, a simple replacement of the old numbers wouldn't produce an accurate crosswalk anyway.
Companies can start identifying the affected documentation now, but there's little reason to replace current references before the new criteria are finalized.
Maintaining separate mappings for the existing and proposed versions would make it easier to understand what changed without disrupting an examination that's still using the current framework.
Proposed CC8 vendor management: Why approving a vendor isn't always enough
Vendor management has been part of SOC 2 for years, so the proposal isn't introducing the concept of third-party risk assessment.
Current criterion CC9.2 already addresses how organizations identify, assess and manage risks associated with vendors and business partners.
What's interesting about the proposed CC8.1 is its additional attention to the individual components companies acquire and integrate into their systems.
Consider how a SaaS company might evaluate a new vendor.
The security team reviews the provider's documentation, checks its SOC 2 report, evaluates the risks and approves the relationship. The vendor gets added to an inventory, and someone is assigned responsibility for keeping the assessment current.
That might be entirely appropriate for the service the company originally intended to use.
But suppose the provider offers several products, and the engineering team gradually adopts more of them.
An AI vendor could supply a language model for summarizing customer documents, an embeddings model for search and an API that allows automated agents to interact with external systems.
The provider hasn't changed, but what the SaaS application does with its technology has changed considerably.
A security assessment covering one integration won't necessarily address the risks introduced by the others.
Vendor inventories need to account for individual components
Published analyses of the proposed CC8.1 describe additional points of focus involving the evaluation of third-party components, including software, AI models, APIs, plugins and other technology.
For SaaS companies, that could make component-level documentation particularly useful.
A vendor inventory that records a provider's name, contract date and most recent assessment tells you something about the relationship. It doesn't necessarily tell you which services the application uses or what those services can access.
Take an AI provider that processes confidential customer documents.
You'd want to know which API is being used, what information reaches the provider, whether requests are retained under the applicable agreement and configuration, and what permissions the integration has within your application.
If the company uses several models from the same provider, those details might be different for each one.
The assessment also needs to reflect what would happen if the service failed or were compromised.
A provider with access to production credentials deserves different scrutiny from one that handles information already intended for public distribution.
The AICPA proposal doesn't establish one mandatory questionnaire or risk-scoring formula for every vendor. Companies still need to evaluate the relationships according to the risks they introduce and the commitments associated with their services.
NIST's Cybersecurity Supply Chain Risk Management guidance provides a useful framework for evaluating risks associated with acquired products and services.
Although NIST's guidance isn't part of the SOC 2 criteria, it addresses an important problem with complex software supply chains: companies often have limited visibility into how external technology is developed, integrated and operated.
For SaaS teams using multiple external models and APIs, understanding those dependencies can be just as important as evaluating the companies that supply them.
A clean vendor SOC 2 report doesn't answer every security question
There's another issue that deserves attention when evaluating third-party assurance.
A SOC 2 report describes a particular system and the controls examined during a defined period. It may provide useful assurance about the provider's operations, but that assurance only extends as far as the report's scope.
Some reports also identify controls the provider expects its customers to operate.
These are called complementary user entity controls, or CUECs.
For example, your cloud provider might maintain appropriate controls for physical security, infrastructure operations and administrative access.
Your company could still be responsible for configuring application permissions, protecting credentials and determining which users are allowed to retrieve particular records.
The provider's report might even identify some of those responsibilities.
A SOC 2 report can also use a carve-out method that excludes certain controls operated by subservice organizations. If your application relies on one of those excluded services, you may need additional information to evaluate the relevant risks.
That's why reviewing the report itself matters.
A meaningful assessment looks at which services are covered, the examination period, any testing exceptions, complementary controls and the limitations of the assurance provided.
And sometimes a vendor won't have a SOC 2 report at all.
Depending on the service and its importance, a company might use other security documentation, contractual commitments or independent assessments to understand the risks.
The proposed vendor-management points of focus reportedly give additional attention to reviewing subservice organization assurance and identifying gaps that companies still need to address.
What happens when a provider changes or a relationship ends?
Annual vendor reviews are useful, but they can miss changes that happen between assessments.
An AI provider might introduce a new model version with additional capabilities. An API could change the information it collects or the tools it can access. A software update might create a vulnerability in an integration that previously passed security testing.
Those changes can affect the risks associated with the service, even when the company's contract and vendor relationship remain unchanged.
The company needs some way to recognize meaningful changes and determine whether they require additional review, testing or approval.
Ending the relationship introduces another set of questions.
Can you export your data in a usable format? What information will the provider retain? Can you revoke the credentials used by the integration? How will you verify that the service no longer has access to your systems?
Those questions become especially important when a third party handles confidential customer information or supports a critical part of the application.
The proposed CC8.1 includes additional attention to vendor termination and the handling of data when a relationship ends.
For companies with established vendor-management programs, some of these practices may already be familiar. The proposed changes would make certain responsibilities more explicit within the criteria.
AI governance in SOC 2: What the proposed points of focus would address
The AICPA's October announcement identifies several AI-related concerns receiving additional attention in the proposed criteria, including model monitoring, prompt manipulation, data poisoning, training-data management, output transparency and automated decision-making.
Interestingly, the proposal doesn't introduce a separate Trust Services Category for AI.
Instead, AI-related considerations would appear as points of focus under existing criteria.
According to independent analyses of the exposure draft, AI-related language appears under 17 of the 50 proposed criteria. Twelve are within the Common Criteria, with the remaining five distributed across Availability, Processing Integrity and Privacy.
That doesn't mean every SaaS company would suddenly need 17 new AI controls.
Points of focus help explain considerations relevant to a criterion. They aren't individually mandatory requirements, and the AICPA doesn't prescribe one universal method for addressing every risk.
The relevance of a particular point depends on the system being examined and what that system actually does.
A SaaS company using a language model to summarize internal support notes has a different set of concerns from one using an automated agent to make changes to customer accounts.
And there's another complication: AI can affect a company's security and compliance processes even when the product itself doesn't contain any AI features.
AI governance includes the tools your employees use
An engineering team might use an AI coding assistant with access to proprietary repositories. A support department might use a third-party service to summarize customer conversations. A product team might enable AI features inside software the company already uses.
Those tools may never appear in a customer-facing product, but they can still process confidential information or affect the systems included in a SOC 2 examination.
A company could have a perfectly reasonable policy governing AI use and still have limited visibility into which services employees are actually using.
That's one reason an inventory of relevant AI systems is useful.
The company needs to understand what each tool does, which information it can access, what permissions it has and who is responsible for evaluating changes.
Published comparisons of the proposed criteria associate AI-related access considerations with proposed CC5 and risk-management considerations with proposed CC3.
The exact documentation a company needs will depend on its systems and the controls already in place. But identifying the tools being used is a fairly obvious prerequisite to evaluating the risks associated with them.
What happens when AI agents start writing production code?
An August 2026 discussion in Reddit's r/soc2 community raises an interesting question for development teams.
An engineer from a company with approximately 12 developers explained that AI agents were writing a substantial portion of its code. The company had a SOC 2 Type II examination approaching, and the engineer wanted to know what auditors would expect.
Would they need a separate AI policy? Agent activity logs? Evidence that AI-generated code had gone through normal review procedures?
A commenter identifying as an auditor explained that the existing change-management requirements still applied. The commenter described clients updating their control descriptions to clarify that code generated by AI was subject to review and approval.
That's an individual practitioner's account rather than formal AICPA guidance, but it illustrates the distinction between using a new development tool and changing the controls governing development.
If an engineer uses AI to generate code, and that code still goes through appropriate testing, review and deployment approval, the company may already have much of the relevant evidence.
The situation gets more complicated when an AI agent has permission to perform actions that previously required human involvement.
Suppose an agent can write code, create a pull request and run automated tests. That's one level of access.
If it can also approve its own changes, merge them and deploy directly to production, the company has a different security problem to evaluate.
It needs to understand how those permissions are restricted, whether appropriate approvals are still enforced and how the agent's actions are recorded.
The proposed separation of change management into infrastructure, acquired software and internally developed software could provide more specific criteria for evaluating those processes.
For companies already using AI coding tools, the important thing is to examine how those tools affect the controls they're relying on today.
Why AI model monitoring is more complicated than ordinary application monitoring
An AI-powered application can be functioning normally from an infrastructure perspective while producing results that create serious problems for customers.
Imagine a support assistant that's responding to requests within the expected time, generating no unusual API errors and showing normal resource usage.
Meanwhile, customers have started reporting that the assistant is retrieving information from unrelated accounts.
Your infrastructure monitoring might show that everything is working. The problem is in what the system is doing with the information it processes.
The AICPA specifically identifies model monitoring among the AI-related topics addressed by the proposed criteria.
Published draft comparisons associate these considerations with proposed CC6.1, which addresses monitoring of system components.
Model drift and unexpected outputs
Model drift can refer to changes in the data a model encounters or in its performance relative to its intended task.
For example, an AI system trained or evaluated on one kind of customer-support data might become less accurate as the product begins serving customers with substantially different needs.
A managed model could also change following a provider update, affecting how an application performs even when the company hasn't changed its own code.
The important question is which changes could affect the service and how the company would recognize them.
For an AI search feature, it may be useful to test whether the system consistently retrieves relevant documents while respecting customer permissions.
For a support assistant, the company might monitor customer reports of inaccurate or inappropriate responses.
For an agent that performs actions, relevant monitoring could include the actions it requests, whether those actions were authorized and whether unusual behavior was investigated.
Those activities don't necessarily require an entirely separate monitoring platform. Existing logs, testing procedures, incident-management processes and customer feedback may already provide useful information.
But someone needs to know which failures matter and be responsible for investigating them.
The NIST AI Risk Management Framework offers a voluntary approach to evaluating AI risks through governance, mapping, measurement and management.
Its Generative AI Profile provides additional considerations for organizations developing or deploying generative AI systems.
Neither document establishes SOC 2 requirements, but both can help companies think through what meaningful AI monitoring should involve.
Prompt injection, data poisoning and the risks of giving AI agents too much access
Prompt injection is one of the security concerns the AICPA explicitly mentions in its October announcement.
It involves instructions placed in information an AI model is expected to process, potentially influencing its behavior in ways the application developer didn't intend.
An attacker might put those instructions in a customer-submitted document, a support ticket, a webpage or another source the model retrieves while completing a legitimate task.
The consequences depend heavily on what the model is allowed to access and do.
An assistant that only drafts responses for a human reviewer presents one level of risk. An agent with permission to retrieve confidential documents, modify records or send messages can create much more serious problems if it follows malicious instructions.
The application needs to enforce the relevant permissions regardless of what the model has been instructed to do.
For example, telling an AI agent that it must ask for permission before deleting a record won't provide reliable protection if the connected tool allows deletion without enforcing that approval.
The authorization needs to exist in the application or tool itself.
Data poisoning affects the information models rely on
Data poisoning involves manipulating information used to train, fine-tune or otherwise influence a model's outputs.
The risks vary depending on how the SaaS company uses AI.
A company that trains its own models may need to evaluate the integrity and provenance of its training data.
A company using an external language model might have limited visibility into the provider's training process. But it can still control many of the documents, databases and retrieval systems supplying information to its application.
Suppose a support assistant relies on an internal knowledge base. If unauthorized users can modify the material the assistant retrieves, they may be able to influence its answers.
That creates an information-integrity problem even if the foundation model itself hasn't been modified.
The OWASP Top 10 for Large Language Model Applications, 2026 edition, released August 4, identifies prompt injection, sensitive information disclosure, excessive agency, supply-chain weaknesses and data and model poisoning among its major concerns.
OWASP's guidance is developed by the security community, so it serves a different purpose from the AICPA's examination criteria. It provides technical context for understanding the kinds of failures companies may need to address.
AI-generated outputs and automated decisions
The proposal also includes points of focus involving the transparency of AI-generated outputs and risks associated with automated decision-making.
These considerations become more significant when an AI system's outputs have consequences beyond generating information for someone to review.
A support assistant that suggests a response might need a process for identifying inaccurate or sensitive content.
An automated system that approves transactions or modifies customer accounts may require additional validation and authorization controls because its decisions directly affect customers.
Companies also need to understand the difference between training a model and using one for inference.
A SaaS company calling a third-party model API may never train that provider's foundation model. It still needs to understand the data it transmits, how the provider handles that information and how its own application uses the resulting outputs.
Published draft comparisons associate additional AI considerations with Processing Integrity criteria involving input quality, processing validation and output monitoring.
Those criteria become relevant when Processing Integrity is included in an examination's scope. They don't automatically apply to every Security-only SOC 2 examination.
And the proposal doesn't establish universal requirements for a particular AI disclosure statement, an annual bias audit or human approval of every generated response.
The appropriate controls depend on the system, its risks and the commitments the company makes to customers.
How vendor management and AI governance overlap in a real SaaS application
Consider a fictional B2B support platform that serves several business customers.
Each customer has its own users, support tickets and confidential documents. The company introduces an AI assistant that can search those records and draft responses for support agents.
The application uses a retrieval service and vector database to locate relevant information, then sends selected material to an external language-model API.
Initially, the assistant only drafts responses. Support agents review the suggestions before sending them.
There are already several security considerations.
The application needs to determine which documents the requesting user is authorized to access. The retrieval system needs to enforce those permissions before passing information to the model.
The company also needs to understand which information reaches the external provider and how the provider handles it under the applicable agreement and configuration.
AWS explains an important part of this in its SaaS tenant-isolation guidance.
Authenticating a user doesn't automatically establish that the user can access only the resources belonging to the correct tenant.
In a multi-tenant application, the system needs mechanisms that prevent users from reaching another customer's information, even when the underlying infrastructure is shared.
For the support assistant, an appropriate technical test could involve attempting to retrieve documents belonging to another customer and verifying that access is denied.
Now suppose the engineering team introduces a new feature.
Instead of simply drafting support responses, the assistant can create tickets automatically.
The company hasn't necessarily changed model providers, but it has introduced a new capability that affects the application's security.
The assistant now needs permission to perform an action. The application needs to determine which actions are authorized, whose permissions apply and whether additional approval is required.
If the next release allows the assistant to modify existing tickets or send messages to customers, those permissions deserve another review.
This is where vendor management, access controls, change management and AI governance begin to overlap.
What would useful evidence look like?
The company could preserve different records to demonstrate how the relevant controls operate.
AreaWhat the company needs to establishPossible evidenceModel providerWhat service is used and what information it receivesVendor assessment, contract review and data-flow documentationDocument retrievalUsers cannot retrieve another tenant's recordsTenant-isolation tests and authorization configurationsAI-agent permissionsThe assistant can perform only authorized actionsPermission matrix and tool authorization testsChange managementNew capabilities receive appropriate reviewChange tickets, testing results and deployment approvalsMonitoringSignificant failures are detected and investigatedRelevant logs, incident records and corrective actionsVendor terminationAccess and data can be managed when the relationship endsExit procedures and credential revocation records
These are examples of supporting documentation, rather than a prescribed AICPA evidence package.
The appropriate evidence depends on the controls the company operates and what those controls are intended to accomplish.
There's also a practical reason to have this information available before an auditor asks for it.
Enterprise customers are beginning to raise more specific questions about AI-enabled products.
In a July 2026 r/SaaS discussion, someone selling an AI-agent product to regulated companies described receiving additional security questions after completing the conventional SOC 2 portion of an enterprise review.
The customer wanted information about agent activity logs, personal information reaching model providers, tenant isolation and what would happen if a connected tool were compromised.
The poster said the company initially struggled to answer those questions and its deal remained in procurement for six weeks.
A commenter suggested maintaining a reusable set of technical evidence, including a data-flow diagram, tool-permission matrix, tenant-isolation test and sample agent action trace.
It's an unverified account from a public forum, so the reported timeline shouldn't be treated as an industry benchmark. But the questions themselves illustrate the kind of information enterprise customers may want when evaluating AI features.
And they're questions a SaaS company should be able to answer about its own architecture.
What should SaaS companies do before the 2027 criteria take effect?
The proposed changes are worth reviewing now, particularly for companies with complex third-party dependencies or AI features in production.
But there's little reason to rebuild an established SOC 2 program around criteria that haven't been finalized.
A more useful approach is to identify where the proposed changes intersect with risks and controls the company already needs to manage.
Confirm the scope and timing of your current examination
Start with the Trust Services Criteria version and categories applicable to your existing SOC 2 examination.
If your next examination may overlap the proposed transition, discuss the timing with your independent CPA firm.
The AICPA's proposed effective date applies to engagements beginning on or after December 31, 2027, rather than automatically applying to every report issued after that date.
Review the third-party components actually used in production
Compare your vendor inventory with the services, APIs, models and integrations deployed by your engineering teams.
Pay particular attention to components introduced after the vendor's most recent assessment.
If an integration now processes different information or has additional permissions, determine whether another review is warranted.
Examine what your vendors' assurance reports cover
Review the scope of relevant SOC 2 reports, including complementary user entity controls, subservice organizations, exceptions and other limitations.
Identify any important dependencies that fall outside the available assurance and determine how those risks are addressed.
Include AI changes in your existing risk and change-management processes
Review what happens when a team introduces a new model, changes an API, enables another tool or gives an agent additional permissions.
Those changes may affect authorization, data handling, monitoring or deployment procedures.
The company should understand the implications before treating a new capability as equivalent to the one it replaces.
Test the controls that protect customer information
For a multi-tenant AI application, that might include attempting unauthorized retrieval, verifying tool permissions and evaluating how the system responds to unusual model behavior.
Choose tests that reflect what the application actually does and the risks associated with those operations.
Maintain records of the testing performed, the results and any corrective actions.
Prepare a provisional criteria crosswalk
Document how existing control references might map to the proposed framework.
Keep the current references intact, identify changes requiring further review and record questions for your CPA firm.
That gives the organization a starting point for the eventual transition without creating inconsistencies in documentation supporting current examinations.
Frequently asked questions about the proposed 2027 SOC 2 criteria
Are the 2027 SOC 2 criteria final?
No. As of November 8, 2026, the revisions remain an AICPA exposure draft. Public comments are due January 15, 2027, and the proposed wording may change before approval.
When would the new criteria take effect?
If approved, the revised criteria would apply to engagements beginning on or after December 31, 2027, with early adoption permitted.
Companies should confirm the applicable version with their independent CPA firms.
Does the proposal make AI governance mandatory for every SaaS company?
The proposal introduces additional AI-related points of focus within existing Trust Services Categories.
It doesn't create a separate AI category or require every company to implement an identical AI-governance program.
Relevant controls depend on the examined system, its risks and the applicable criteria.
Is vendor management a new SOC 2 requirement?
No. The existing criteria already address vendor and business-partner risks under CC9.2.
The proposed revisions would move vendor management into a dedicated CC8 category and give additional attention to third-party components and related assurance responsibilities.
Would SaaS companies need a separate SOC 2 examination for their AI models?
The proposal doesn't establish a universal requirement for a separate AI examination.
Relevant AI components can be evaluated within an appropriately scoped SOC 2 engagement. The company may also consider other assurance frameworks depending on its systems and customer requirements.
Will reducing the number of criteria make SOC 2 easier?
Consolidating overlapping criteria could simplify some control mappings and documentation.
The amount of work involved will still depend on the organization's systems, relevant risks and controls being evaluated. Fewer criteria don't necessarily mean fewer responsibilities or less testing.
What the proposed changes mean for SaaS companies
There are some good reasons for SaaS companies to pay attention to the proposed 2027 criteria even if their next SOC 2 examination is still a long way off.
Third-party services now handle substantial parts of application infrastructure and functionality. AI models can process confidential information, retrieve records and perform actions through connected tools. And a change to one component can affect how several others operate.
The proposed criteria would make some of those responsibilities more explicit, particularly around third-party components and AI-enabled systems.
Companies with established SOC 2 programs may find that many of the relevant controls are already in place. Others may discover gaps between what their vendor assessments cover and what their applications actually allow external services to do.
That's worth investigating before the revised criteria are finalized.
If an AI assistant can access customer information, the company should understand how those permissions are enforced. If an agent can modify records or perform other actions, someone needs to know what prevents it from doing something unauthorized.
And if a vendor changes a model, API or service the application depends on, there should be a way to determine whether that change affects security.
The AICPA may revise the proposed criteria before approving them, and companies should continue using the framework applicable to their current examinations.
But understanding where your application depends on external services, what those services can do and which controls protect the information moving between them is already part of operating a secure SaaS product.
You don't need to wait for a new SOC 2 criterion to find out whether those controls actually work.
Sources and further reading
AICPA and proposed criteria
AICPA: Proposed SOC 2 Trust Services Criteria announcement, October 28, 2026
AICPA: Current 2017 Trust Services Criteria with revised 2022 points of focus
SOC2Auditors.org: Proposed 2027 Trust Services Criteria comparison
Schellman: What the revised Trust Services Criteria mean for organizations, November 6, 2026
Technical guidance
Practitioner discussions
Research note: The AICPA's announcement and current criteria were checked directly. The complete proposed 2027 exposure-draft PDFs require AICPA account access, so the draft criterion counts and mappings are based on independent comparisons and should be confirmed against the original redlined document before being used as an authoritative audit crosswalk.
Last reviewed: November 8, 2026.
