AI Data Leakage and SOC 2 Compliance: What IT Teams Need to Know

May 12, 2026 By ShadowLock Team SOC 2compliancedata securityAI governance

AI data leakage is the silent SOC 2 problem of 2026. When employees paste customer data, code, or credentials into ChatGPT, Claude, or Gemini, that data leaves your system boundary to a vendor that is not in your inventory, has no DPA, and was never assessed, a clear gap against CC6.1 (logical access), CC9.2 (vendor risk), and CC7.2 (system monitoring). Auditors are starting to ask about it. Below is exactly what they want to see, and how to put the controls in place before your next Type II.

Your SOC 2 audit passed last year. Since then, three engineers have started using ChatGPT to help debug production issues, your support team is using Gemini to draft customer responses, and someone in sales pasted a prospect list into Claude to prep for a call. None of this shows up on your vendor inventory. None of it has a DPA. None of it went through your vendor security review process. The underlying behaviour is what we cover in what is shadow AI, this post focuses specifically on the SOC 2 implications.

How SOC 2 Addresses AI Tool Usage

SOC 2 doesn’t have an “AI” section. But several of the Trust Services Criteria (TSC) directly apply to how sensitive data flows through third-party AI tools.

CC6.1, Logical and Physical Access Controls

This criterion requires that access to system resources (including data) be restricted to authorized users and uses. When an employee sends customer data to ChatGPT, they’re granting access to that data to a third party outside your approved system boundary.

The auditor question: “What controls prevent employees from sending restricted data to unapproved third-party services?”

If your answer is “we have a policy” without a technical enforcement layer, that’s a finding.

CC9.2, Vendor and Business Partner Risk Management

SOC 2 requires organizations to assess the risks associated with vendors who have access to company data and implement controls accordingly. This typically means:

  • A vendor inventory
  • A vendor risk assessment process
  • Signed data processing agreements (DPAs) for vendors who handle personal data

The auditor question: “Is OpenAI (or Anthropic, or Google) in your vendor inventory? Do you have a DPA with them?”

For employees using free-tier consumer AI products, the answer is almost certainly no. Free consumer products don’t come with a DPA. If your employees are using them for any work-related purpose involving personal data, that’s a vendor compliance gap.

CC7.2, System Monitoring

This criterion requires continuous monitoring of system activity to detect and respond to anomalies and security events. AI tool usage, especially when sensitive data is involved, is exactly the kind of activity that should be in your security monitoring pipeline.

The auditor question: “How do you detect when sensitive data is sent to external services?”

A1.2, System Availability Commitments (if applicable)

If your SOC 2 includes Availability, consider that shadow AI dependencies also introduce reliability risk. If a team’s workflow depends on an unapproved AI tool that goes down or changes its API, your commitments are suddenly at risk from a vendor you don’t manage.

The Practical Compliance Gaps

Here’s a concrete mapping of shadow AI behaviors to SOC 2 gaps:

BehaviorSOC 2 Gap
Employee pastes customer PII into ChatGPTCC6.1 (data access control), CC9.2 (no DPA)
Engineer uses Copilot with production codeCC6.1 (IP/code exposure), CC9.2 (vendor not assessed)
Support team uses Gemini for customer emailsCC9.2 (vendor not in inventory), CC7.2 (not monitored)
AI tool list not maintainedCC9.2 (vendor inventory incomplete)
No technical blocking of sensitive dataCC6.1 (controls are policy-only, not enforced)

What Auditors Are Actually Checking in 2025

SOC 2 auditors have adapted. Here’s what the sharper ones are asking about AI:

1. Do you have an AI tool use policy? A written policy stating which AI tools are approved, which are prohibited, and what data can be used with each. This is table stakes.

2. Is your AI tool policy technically enforced? Policy without enforcement is a SOC 2 weakness. Auditors want to see that you can demonstrate the control is working, not just that it exists on paper. “We tell employees not to use unapproved AI tools” doesn’t survive testing.

3. Which AI vendors are in your vendor inventory? If you’ve gone through an enterprise contract with OpenAI, Anthropic, Microsoft, or Google for AI services, those vendors should appear in your inventory with completed risk assessments and DPAs.

4. How do you detect data leakage through AI tools? Monitoring is increasingly required, not optional. Auditors want log evidence that you can detect and respond to sensitive data leaving your system boundary.

5. What is your incident response process for AI-related data exposure? If sensitive data goes to an unapproved AI tool, what happens? You need a documented process.

Building Compliant AI Governance

Here’s the minimum viable SOC 2-compatible AI governance programme:

1. Write an AI Acceptable Use Policy

Cover:

  • Which AI tools are approved (with links to the enterprise/business tier that includes a DPA)
  • Which AI tools are explicitly prohibited
  • What categories of data are never permitted in AI tools (regulated data, customer PII, credentials)
  • Consequences for violations

Keep it short and practical. A three-page policy no one reads is worse than a one-page policy that employees actually follow.

2. Build an AI Vendor Inventory

Add AI vendors to your vendor management system with:

  • Vendor name and product
  • Link to their DPA / data processing terms
  • Completed security questionnaire or SOC 2 report from the vendor
  • Date of last review
  • Approved data categories (what can be sent to this vendor)

For approved tools:

  • OpenAI Enterprise: DPA available
  • Anthropic Business: DPA available upon request
  • Google Workspace AI features: Covered under Google’s data processing amendment
  • Microsoft Copilot for M365: Covered under Microsoft’s data protection agreement

For free-tier tools: do not allow use with any work data until you have a DPA.

3. Implement Technical Controls

Policy-only controls are a SOC 2 weakness. Technical controls that an auditor can test are much stronger evidence:

  • Browser extension paste monitoring, blocks sensitive data categories from reaching unapproved AI tools at the point of input
  • Endpoint process blocking, prevents unauthorized AI desktop apps from running
  • Audit logging, creates a record that controls are operating

The log evidence is as important as the block itself. You need to show auditors that the control is running and producing events.

4. Monitor and Alert

Set up alerts for:

  • Sensitive data reaching an unapproved AI tool (high priority, potential incident)
  • High-frequency AI tool usage outside approved tools (medium priority, follow-up with manager)
  • New AI tool domains appearing in DNS logs (low priority, catalogue review trigger)

5. Include AI in Your Annual Risk Assessment

Your risk register should include:

  • Shadow AI as a data exfiltration risk vector
  • AI vendor reliability as an availability risk (if applicable)
  • AI-generated content in production as a quality/accuracy risk

Updating your risk register demonstrates to auditors that your risk management process is keeping pace with the threat environment.

The Audit Evidence Package

When your next SOC 2 audit comes around, you should be able to produce:

  1. AI Acceptable Use Policy (dated, approved, distributed)
  2. AI Vendor Inventory (list of approved vendors with DPA dates)
  3. Technical control evidence, screenshots or log exports showing the monitoring and blocking system is active
  4. Alert/incident log, any events that were triggered by the controls, and what happened next
  5. Employee training records showing awareness of the AI policy

If you can produce all five, you’ve turned shadow AI from a finding into a demonstrated control.


The SOC 2 auditors are not trying to catch you out on AI. But they are following the data. And right now, the data is going places your controls weren’t designed to see. Getting your AI governance in order before your next audit window is significantly cheaper than remediation findings on a completed report. ShadowLock’s AI DLP gives you the technical control and the audit log auditors are starting to expect.

Frequently Asked Questions

Does SOC 2 explicitly require AI controls?

Not yet, the Trust Services Criteria do not mention AI by name. But CC6.1 (logical access), CC9.2 (vendor risk management), CC7.2 (system monitoring), and CC8.1 (change management) all apply to AI tool usage because they govern how data flows to third parties. Auditors are interpreting the existing criteria to cover AI, and Type II audits in 2025–2026 are routinely asking AI-specific questions.

Is using ChatGPT a SOC 2 violation?

It depends on how it is used. ChatGPT use that goes through a corporate enterprise agreement with a DPA, is documented in your vendor inventory, and is covered by an acceptable use policy is compliant. ChatGPT use on a personal account, with customer or regulated data, with no agreement and no monitoring is a clear gap against CC6.1 and CC9.2.

What evidence do auditors want for AI controls?

The five-item evidence package most Type II auditors are starting to ask for: (1) a written AI acceptable use policy, (2) an AI vendor inventory with DPAs and security questionnaires, (3) screenshots or log exports proving a technical control (blocking, monitoring) is operating, (4) alert and incident logs showing the control produces events, and (5) employee training records on the AI policy.

Do free-tier AI products satisfy SOC 2?

Generally no. Free-tier consumer AI products do not come with a data processing agreement, do not provide vendor risk assessment documentation, and typically reserve broad rights to use submitted data. They cannot be in scope for SOC 2 unless your auditor explicitly accepts a written justification, which is unusual.

How is AI data leakage different from traditional data leakage?

Traditional DLP focused on email, file transfers, and removable media, egress points your tools were designed to watch. AI data leakage happens at the clipboard paste into a browser tab. None of your traditional egress tooling sees it, which is why AI-specific DLP and shadow AI detection have emerged as a separate product category.

What is the fastest way to close the AI gap before an audit?

Three steps, in order: (1) deploy a technical control that blocks sensitive data from being pasted into unapproved AI tools and produces audit logs, (2) publish a one-page AI acceptable use policy and have employees acknowledge it, (3) add the AI tools your organization formally uses to your vendor inventory with DPAs attached. ShadowLock customers typically complete all three within a single Type II observation window.

Does this apply to HIPAA and GDPR as well as SOC 2?

The underlying problem is the same, sensitive data leaving your control to an unassessed vendor, and the answer is the same: technical control, vendor inventory, audit logs. HIPAA expects equivalent technical safeguards under 45 CFR §164.312 (audit controls, access controls). GDPR expects Article 28 processor agreements and Article 30 records of processing. The same evidence package covers all three.

Stop shadow AI before it becomes a liability

ShadowLock detects and blocks unauthorized AI tool usage across every endpoint. Free 14-day trial.

Start Free Trial →