AI Compliance Standards Lire ce guide en français

Security & Audit Frameworks

SOC 2

System and Organization Controls (SOC) 2, based on the AICPA Trust Services Criteria

SOC 2 is not a law, but for B2B software it is the de facto trust bar. Here is how employee use of external AI tools threatens the Confidentiality and Privacy criteria, and what auditors now ask about shadow AI in Type II audits.

United States origin; used globally as the B2B trust standardVoluntary attestation standard; 2017 Trust Services Criteria with revised points of focus (2022) are currentVerified 2026-08-31

What it means for AI and data privacy

SOC 2 is an attestation, not a law: an independent CPA firm examines whether your controls meet the AICPA Trust Services Criteria for Security (mandatory) and, as selected, Availability, Processing Integrity, Confidentiality, and Privacy. It has become the default evidence enterprise buyers demand before trusting a vendor with their data, which gives it more day-to-day force than many statutes. Employee use of external AI tools cuts directly against the criteria most customers care about: pasting customer data into a chatbot is a transmission of confidential information outside controlled channels (CC6.7), through access paths nobody provisioned (CC6.1), that monitoring never saw (CC7.2), landing at a vendor that was never risk-assessed as a subprocessor. Auditors increasingly probe AI usage policies, shadow AI, and AI subprocessor management in Type II audits, and a Type II opinion covers a review period of months, so AI usage that predates the audit is inside its scope. An organization that cannot show how it governs and technically controls AI-bound data flows is defending its exceptions list, not its opinion.

Who it applies to

SaaS and B2B software companies whose customers require a SOC 2 report before or during a contract
Service organizations handling customer data: MSPs, processors, hosting, analytics, and outsourced back-office providers
Startups entering enterprise sales, where a Type II report is a standing procurement checkbox
Organizations whose reports include the Confidentiality or Privacy criteria, the categories employee AI use threatens most directly
Companies whose own vendors and subprocessors now include AI services, which must be covered by vendor management controls

Enforcement and penalties

There are no fines: SOC 2 failure is priced in lost business. A qualified opinion, noted exceptions, or a missing report stalls enterprise deals, triggers security-questionnaire escalations, and can put existing contracts with SOC 2 covenants in breach. Renewal-time findings are visible to every customer who requests the report, so one auditor exception about unmanaged AI usage repeats itself in every sales cycle for a year. The underlying incidents carry their own costs: IBM measured in 2025 that breaches involving shadow AI added an average of $670K to breach costs, and that 97% of organizations that suffered an AI-related breach lacked proper AI access controls, which is exactly the gap a SOC 2 audit is designed to surface first.

Key provisions for AI and data privacy

CC6.7 (Trust Services Criteria, common criteria)

Restrict the movement and transmission of information

CC6.7 requires the organization to restrict the transmission, movement, and removal of information to authorized users and processes, protecting it during transmission outside system boundaries. It is the criterion covering data leaving controlled channels.

An employee prompt carrying customer data to an external AI tool is a transmission outside the system boundary through a channel the control set never contemplated. If the organization cannot show a control governing that path, CC6.7 has a gap regardless of how good its encryption and DLP story is elsewhere. IBM found in 2025 that only 17% of organizations have technical controls that redact or block sensitive data at the point of entry, so most CC6.7 narratives are silent exactly where auditors are now looking.

CC6.1 (logical access security)

Logical access controls over information assets

CC6.1 requires logical access security software, infrastructure, and architectures over protected information assets, so that only authorized users, processes, and devices reach them.

Shadow AI inverts CC6.1: instead of unauthorized users reaching protected data, authorized users carry protected data out to unauthorized systems. LayerX measured in 2025 that 71% of GenAI connections use personal, non-corporate accounts, access paths that provisioning, SSO, and offboarding never touch. A defensible CC6.1 position needs to account for browser-based AI tools as destinations, not just for who can log in to production.

CC7.2 (system monitoring)

Monitor systems for anomalies and security events

CC7.2 requires monitoring of system components for anomalies indicative of malicious acts, natural disasters, and errors, with events analyzed to determine whether they represent security incidents.

Monitoring that does not see AI-bound data flows cannot classify them as events, and LayerX found in 2025 that organizations have no insight into roughly 89% of AI usage. In a Type II audit, the question is not whether an incident occurred but whether your monitoring would have detected it during the review period. Visibility into which AI tools are used, and what categories of sensitive data were caught heading to them, turns an unanswerable question into an evidence request you can satisfy.

C1.1-C1.2 (Confidentiality criteria)

Identify, maintain, and dispose of confidential information

The Confidentiality category requires identifying and maintaining confidential information to meet the entity's confidentiality objectives and commitments, and disposing of it when no longer needed. Most B2B contracts make these commitments explicit.

Customer data pasted into an external AI tool sits outside every retention and disposal control the confidentiality commitments rely on: the organization can neither maintain nor dispose of what it no longer holds. Since most SaaS contracts promise confidentiality to customers, one careless prompt can put the company out of conformity with both its report and its contracts. Keeping confidential identifiers out of prompts is the control that keeps the commitment true.

P4.0-P6.0 (Privacy criteria); CC9.2 (vendor management)

Privacy criteria and management of vendors and business partners

The Privacy category imposes criteria on use, retention, disposal, and disclosure of personal information, including disclosure only to authorized third parties. CC9.2 requires the organization to assess and manage risks associated with vendors and business partners, the criterion auditors apply to subprocessors.

An AI tool that receives personal information is a disclosure recipient and, functionally, a subprocessor, whether or not procurement ever saw it. Auditors increasingly ask for the AI usage policy, the approved-tools list, and evidence that AI vendors passed vendor risk review; 63% of organizations have no AI governance policy at all (IBM, 2025). Unapproved AI tools receiving personal data are undocumented third-party disclosures under P6 and unmanaged vendors under CC9.2 at the same time.

Practical compliance steps

1Write an AI acceptable-use policy and an approved AI tools list, and make both part of the policy evidence set for the next audit
2Inventory actual AI usage across the organization, including browser tools on personal accounts, before the auditor asks
3Classify the data types covered by confidentiality and privacy commitments, and state explicitly which must never enter external AI tools
4Deploy a technical control at the point of entry that catches confidential and personal data in prompts, so CC6.7 has an operating control rather than a policy statement
5Feed AI usage and interception data into security monitoring so CC7.2 coverage includes AI-bound flows
6Run AI vendors through vendor management: contracts, no-training terms, and subprocessor listings where customer data is involved (CC9.2)
7Retain usage and interception reports across the review period, since a Type II audit tests operating effectiveness over months, not a point in time

How Sanitized AI maps to this

CC6.7 data transmission

Sensitive data in prompts is redacted before submission, giving the organization an operating control over the AI transmission path that a Type II auditor can test across the review period.

CC7.2 monitoring and CC6.1 access paths

Administrators see which AI tools employees actually use and what categories of sensitive data were caught, turning the blind spot around browser AI usage into monitored, reportable events.

Confidentiality and Privacy criteria

Redaction of customer identifiers, personal information, and other confidential data in prompts keeps commitments about use, disclosure, and disposal true, because the data never lands in tools outside the organization's retention controls.

CC9.2 vendor management

Usage reporting shows when employees adopt AI tools the organization has not risk-assessed, so vendor management can catch de facto subprocessors before an auditor or a customer does.

Frequently asked questions

Does using ChatGPT violate SOC 2?

Not automatically. SOC 2 tests whether your controls meet your commitments, so governed use of an AI tool under contract, policy, and technical controls can be fully consistent with a clean report. Ungoverned use is the problem: customer data flowing to an unapproved tool implicates CC6.7 (transmission), CC6.1 (access paths), CC7.2 (monitoring), the Confidentiality criteria, and CC9.2 (vendor management) all at once, and gives the auditor an exception to write.

Do SOC 2 auditors ask about AI usage now?

Increasingly, yes. Common requests in Type II audits include the AI acceptable-use policy, the approved-tools list, evidence of technical enforcement, how shadow AI is detected, and whether AI vendors went through vendor risk management. With IBM reporting in 2025 that 63% of organizations have no AI governance policy, the questions separate prepared vendors from the rest quickly.

Is SOC 2 required by law?

No. SOC 2 is a voluntary attestation under AICPA standards, not a statute. Its force is commercial: enterprise customers require the report in procurement and often by contract, so failing or lacking one costs deals rather than fines. For many B2B companies that makes it more operationally binding than most privacy laws.

What is the difference between SOC 2 Type I and Type II for AI risk?

Type I evaluates control design at a point in time; Type II tests operating effectiveness over a review period, typically 3 to 12 months. That period is what makes AI usage dangerous: months of unmonitored prompts containing customer data are inside scope, and a policy adopted the week before fieldwork does not retroactively cover them. Continuous evidence of enforcement is what a Type II needs.

Does an AI vendor need to be listed as a subprocessor?

If customer or personal data reaches it, treat it that way. Under CC9.2 and the Privacy criteria, third parties receiving covered data must be risk-assessed, contracted, and, where your customer agreements require it, disclosed as subprocessors. The awkward cases are the tools employees adopted informally: they receive data without any of that scaffolding, which is why discovery of actual usage comes before the paperwork.

Can shadow AI cause a failed SOC 2 audit?

It can produce exceptions or a qualified opinion, which is what failure looks like in practice. If the auditor finds sensitive data flowing to unapproved AI tools with no control, no monitoring, and no vendor review, that is evidence a relevant control did not operate effectively. It can also become a real incident: IBM found in 2025 that 20% of breached organizations were compromised via shadow AI, and 97% of organizations with AI-related breaches lacked proper AI access controls.

Primary sources

This guide summarizes the cited primary sources as of the verification date. It is general information, not legal advice.

The gap in every framework is the prompt box.

Sanitized AI catches sensitive data in prompts before it leaves and shows administrators which AI tools employees actually use.

Get a demo

Related standards

ISO/IEC 27001

The world's leading certifiable standard for information security management, read here through an AI lens: what employee use of external AI tools means for your ISMS, your risk assessment, and controls like information transfer and data leakage prevention.

ISO/IEC 42001

The first certifiable international management-system standard for AI. Explained here through its risk and impact assessment requirements, and what they mean for data privacy when employees use AI tools at work.

NIST AI RMF

The US government's voluntary framework for managing AI risk, built around four functions: Govern, Map, Measure, and Manage. Explained here as it applies to data privacy and everyday AI use at work.

AIDA (Bill C-27)

Canada's proposed AI law died when Parliament was prorogued in January 2025, and no successor AI act has been tabled since. What AIDA would have required, what actually governs Canadian AI use now, and what to watch next.