Overview

You're in an audit kickoff meeting with your external auditors. They're asking about your information security controls. Halfway through the presentation, someone asks: "What's your control environment around AI tools and large language models?" You realize you don't have a good answer. You know AI is important. You know your team is using it. But you've never documented how those tools fit into your compliance framework.

This is where operations professionals discover that compliance frameworks like SOC 2 and ISO 27001 weren't designed with AI tools in mind. The frameworks are older. They're written around traditional IT systems, vendor management, and access controls. When AI systems show up in your operations, the auditors squint at their control documentation and ask: "So how does this map to our framework?"

The good news is that SOC 2 and ISO 27001 aren't hostile to AI. They're flexible enough to accommodate it. But they require you to think about AI tools as part of your information security and risk management systems, not as standalone productivity tools.

This lesson walks you through how SOC 2 and ISO 27001 actually work, which controls are most affected by AI tools, what auditors will ask about, and how to build an operational framework that satisfies both the technology and the compliance requirements. We're not going to make you a compliance expert. We're going to give you enough understanding so you can have a productive conversation with your auditors and your security team about what needs to happen when you introduce AI tools into your operational environment.

What SOC 2 Actually Is (And Isn't)

SOC 2 stands for Service Organization Control 2. It's an auditing standard created by AICPA (American Institute of Certified Public Accountants). It's not a regulation. It's not legally required. But if you work in technology, SaaS, or any service-based business, your clients probably demand SOC 2 compliance, which means you probably have a SOC 2 audit.

SOC 2 is a trust report. Your organization gets audited by an external auditor who verifies that you have effective controls around five trust principles: CC (security), A (availability), PI (processing integrity), C (confidentiality), and PR (privacy). Most organizations pursue SOC 2 Type II for CC (confidentiality and security) and A (availability). Type II means the auditor spent a period of time (typically six months) observing your controls in action, not just asking whether they exist.

SOC 2 covers things like: access controls (who can access systems and data), change management (how you make sure changes don't break things), incident management (how you handle security incidents), vendor management (how you vet and monitor third-party tools), and data protection (how you protect sensitive information).

Here's why SOC 2 matters for AI: when you introduce an AI tool into your operations, it touches several of these controls. If the tool stores operational data, it's covered by "data protection" controls. If the tool is accessed by multiple people, it's covered by "access controls." If you update which data the tool can access or how it processes data, it's a "change" that should go through change management. If the tool has a security incident, you need to respond according to your "incident management" process.

The common mistake is treating AI tools as exempt from compliance frameworks. They're not. They're part of your control environment, and your auditors will ask about them.

ISO 27001: The Global Information Security Standard

ISO 27001 is an international standard for information security management systems (ISMS). Unlike SOC 2, which is a U.S.-centric trust report, ISO 27001 is used globally. If you have customers or operations in Europe, Asia, or anywhere outside the U.S., they probably care about ISO 27001.

ISO 27001 is certification-based, not audit-based. You implement an information security management system, document it, get it audited by a certified auditor, and receive a certificate saying you comply with ISO 27001. The certificate is valid for three years and requires annual surveillance audits.

ISO 27001 has 14 control objectives covering cryptography, access control, vendor relationships, incident management, security awareness training, compliance monitoring, and more. It's comprehensive and prescriptive. If you're certified to ISO 27001, you have a documented, audited, externally-verified information security program.

The intersection with AI is similar to SOC 2. ISO 27001 cares about how you manage third-party tools (which includes AI vendors), how you protect data (which includes data sent to AI systems), how you manage access (who in your organization can use which AI tools), and how you handle incidents (if an AI vendor has a security breach, what do you do).

If you're pursuing ISO 27001 certification, your auditor will specifically ask: "What tools are classified as information processing systems?" "Which ones are cloud-based?" "What data protection agreements do you have?" "How do you monitor vendor security?" These questions directly apply to AI tools.

The Control Categories That AI Affects

Rather than walking through every control in both frameworks, let's focus on the specific categories where AI tools create new or modified requirements.

1. Access Control and User Management

SOC 2 and ISO 27001 both require that you control who can access systems and data. For traditional software, this meant user accounts with passwords, authentication, and authorization levels.

AI tools often blur this. When you use a cloud-based AI system (ChatGPT, Claude, Copilot), the access control happens at the vendor level, not at your organization level. You don't get to define access levels. You don't get detailed audit logs showing who accessed what data. The vendor controls access.

SOC 2 and ISO 27001 auditors will ask: "How do you ensure only authorized people can use this AI tool?" The answer is: contractual controls with the vendor (they should only provide access to your employees), account-level controls (you manage who has the account password), and procedural controls (you train people on what data they can send to the tool).

The audit requirement is that you have a documented process for granting and revoking access. If an employee leaves, you need to remove their access. If a contractor's project ends, you need to remove their access. This applies to AI tools just like any other system.

2. Vendor Management and Third-Party Risk

This is the big one. SOC 2 and ISO 27001 require that you manage risks associated with third-party vendors, especially vendors who have access to your data or systems.

When you use an AI tool, the AI vendor becomes a third-party in your information security picture. SOC 2 requires that you assess vendor risks, establish contracts that define responsibilities, and monitor vendor performance. ISO 27001 requires similar vendor management: you need to document vendor contracts, assess their security, and monitor their compliance.

Specifically, auditors will ask: "Do you have a contract with the AI vendor?" "Does the contract include security obligations?" "Does it include a right to audit?" "Do you know their security certifications?" "If they have a data breach, what happens?" "Can you require them to delete your data?" "Do you monitor their security status?"

For consumer AI tools like free ChatGPT, many organizations can't answer these questions affirmatively. The vendor hasn't signed a security contract with you. You don't have a right to audit. You don't know their security practices in detail. This creates audit findings.

The solution is typically one of: (1) move to an enterprise version of the tool where the vendor has agreed to security obligations, (2) use a different tool where the vendor will sign a contract, (3) restrict the tool to non-sensitive data only, (4) don't use the tool and don't expose it to audit scope.

3. Data Protection and Encryption

Both frameworks require that you protect data, especially sensitive data. Protection typically means encryption (at rest and in transit), access controls, and audit trails.

When you send data to an AI system, you're handing data protection responsibility to the vendor. They need to encrypt it in transit and at rest. They need to control who can access it. They need to audit access. Most major AI vendors do this well. But auditors will ask for evidence.

Your responsibility doesn't disappear. You're responsible for ensuring the vendor implements adequate protection. You're responsible for not sending more data than necessary (minimize exposure). You're responsible for understanding what the vendor does with data after they process it.

SOC 2 auditors will ask: "What data protection requirements do you have for this vendor?" "How do you verify they're encrypting data?" "Do you have a contract requirement?" ISO 27001 auditors will ask similar questions and will look at your data classification scheme (which data is sensitive and why), your vendor contracts, and your monitoring practices.

4. Change Management

Both frameworks require that you have a change management process. When you make changes to your systems or processes, you should evaluate the risk, get approval, implement the change, and verify it didn't break anything.

When you introduce a new AI tool, that should go through your change management process. Why? Because it's a new system processing operational data. You need to: (1) document the business need, (2) assess security and compliance risks, (3) determine what data it will access, (4) verify the vendor's security practices, (5) get approval from appropriate stakeholders, (6) implement it, (7) monitor it.

This doesn't need to be bureaucratic. Many organizations have fast-track change processes for low-risk changes (like adding a new cloud tool with basic security controls). A new AI tool for analyzing non-sensitive data might take one day to approve. A new AI tool that will process employee or vendor data might take one to two weeks.

Auditors want to see that you're not randomly adopting tools without thinking. They want to see that someone evaluated the tool before you started using it.

5. Incident Management

Both frameworks require that you have a process for responding to security incidents. The process should include: detection, investigation, containment, response, and communication.

AI vendor incidents are in scope. If the vendor has a security breach, you need to know. If the vendor's service is compromised, you need to respond. If data sent to the vendor is exposed, you need to investigate.

Your responsibility is to maintain contact with the vendor so you get notified of incidents, to have a playbook for responding, and to have a way to quarantine or stop using the tool if needed.

Most major vendors have a security incident reporting mechanism. They'll notify you if there's a breach that affects your data. But you need to confirm this in their contract and you need to test that the notification actually happens (doesn't just sit in an email that no one reads).

AI-Specific Control Gaps in Traditional Frameworks

SOC 2 and ISO 27001 were written before large language models and generative AI became common. There are some control gaps that auditors are still figuring out how to address.

Model Bias and Fairness

If you're using an AI system to make operational decisions (hiring, vendor selection, employee scheduling), traditional compliance frameworks don't have specific controls for bias or fairness. They have access control and data protection, but not "verify the algorithm is fair" controls.

Auditors are starting to ask about this. If the AI system is making material decisions, they want to know: Is there a bias assessment? Are you testing for disparate impact on protected groups? How do you document decisions the system makes? Can you explain why the system made a specific decision?

The control you need is: (1) document the business case for using AI in the decision, (2) perform a bias assessment (does the system have a documented fairness evaluation?), (3) implement monitoring (do you track whether decisions seem biased?), (4) have a human review process (for material decisions, is there human oversight of the AI recommendation?), (5) maintain decision logs (can you show the data and the decision the system made?).

Model Transparency and Explainability

Many AI systems are "black boxes." You input data and get an output, but you can't explain exactly why the system made that recommendation. This creates audit and legal risk.

If you can't explain a decision the AI system made, and it affects a business outcome, you have a problem. Regulators (SEC, CFPB, EEOC) are increasingly requiring explainability for AI systems that make material decisions.

The control is straightforward: use AI systems where you can explain the output. For generative AI (LLMs), this is usually okay because you can see the input and the reasoning steps. For machine learning models making predictions, ensure the vendor provides explainability tools. For systems you can't explain, restrict them to advisory (AI suggests, human decides) rather than autonomous (AI decides).

Model Drift and Performance Monitoring

AI systems can degrade over time. The model trains on historical data. If the world changes and new data looks different from training data, the model's predictions get worse. This is called "model drift."

Auditors are starting to ask: "How do you know the AI system is still performing correctly?" "What happens if the model degrades?" "Do you monitor model performance?" "If performance drops, what's your response?"

The control is: (1) establish baseline performance metrics (accuracy, fairness, output quality), (2) set up monitoring to track performance over time, (3) define thresholds for acceptable performance, (4) establish a process to investigate and respond if performance degrades, (5) retrain or replace the model if needed.

For operations professionals, this typically means: establish success criteria for the AI tool, monitor whether it continues to deliver that success, and be prepared to decommission it if performance degrades.

The Vendor Contract is Your Compliance Foundation

For any AI vendor that will touch sensitive data or make material operational decisions, you need a contract that specifies: (1) what data they can access, (2) how they'll protect it (encryption, access controls, audit trails), (3) data retention and deletion obligations, (4) incident notification requirements, (5) audit rights (can you audit their security?), (6) liability limitations, (7) data processing obligations (do they train models on your data?). Without these contractual commitments, you can't satisfy SOC 2 or ISO 27001 controls around third-party risk.

Building Your AI Compliance Operating Model

Let's synthesize this into a practical framework for managing AI tools within your SOC 2 or ISO 27001 compliance program.

Step 1: Define Your Compliance Scope

Which compliance frameworks does your organization have to satisfy? Are you SOC 2 Type II? ISO 27001 certified? Both? Neither? This determines the level of rigor you need.

If you have external compliance requirements, AI tools are in scope. If you don't have external compliance requirements, you can still use compliance frameworks as a guide for good security practices.

Step 2: Create an AI Tool Inventory

Document all AI tools your organization uses. For each one, record: tool name, vendor, what it does, what data it touches, who uses it, when it was adopted, and whether it's a paid enterprise version or a free/personal version.

This takes a few hours but gives you visibility. Many organizations discover they have twice as many AI tools in use as they realized.

Step 3: Assess Vendor Security Posture

For each vendor, ask: Do they have SOC 2 or ISO 27001 certification? Do they have a Data Processing Agreement available? Do they provide encryption, access controls, and audit logs? What's their incident notification process? Can they commit to not training their model on your data?

You don't need all answers to be "yes." But the more boxes you can check, the lower your risk. For high-risk vendors (no certifications, no DPA, unclear practices), restrict them to non-sensitive data.

Step 4: Define Data Classification for AI

Classify your operational data: Public (no restrictions), Internal (employee-level access only), Confidential (need-to-know access), Restricted (minimal people, maximum controls). Then define which data classifications can be sent to which AI tools.

Example policy: "Public and Internal data can be sent to any approved AI tool. Confidential data can only be sent to vendors with SOC 2 Type II certification and a signed DPA. Restricted data cannot be sent to any third-party AI tool."

Step 5: Build an Approval Process

When a team wants to adopt a new AI tool, they should request approval. The approval process asks: What data will it touch? Is it on an approved vendor list? If not, what's the business case? Is the vendor's security acceptable? Are there compliance risks?

Simple tools that touch non-sensitive data can be approved in a day. Tools that touch sensitive data need more review. But the process should be fast enough that it doesn't become a blocker.

Step 6: Document Monitoring and Control Activities

For audit purposes, document what you're monitoring to verify that AI tools are operating securely. Examples: monthly review of who has access to each tool, quarterly review of vendor certifications and incident reports, monitoring of data handling practices, performance reviews of AI-assisted decisions.

This doesn't need to be complex. A monthly email saying "checked vendor incident status, no new incidents" is enough. The point is that you're demonstrating active management and oversight.

Step 7: Align with Your Auditors

Before you get audited, schedule a conversation with your auditors about AI tools. Show them your inventory, your approval process, your vendor contracts, and your monitoring activities. Ask: "Are we addressing your compliance concerns around AI?" This gives you an opportunity to get feedback before the formal audit.

Most auditors appreciate organizations that are proactive about emerging risks like AI. They'd rather see a documented, thought-through approach than discover tools randomly during the audit.

Create a One-Page "AI Tool Security Checklist"

For each AI tool, document: (1) vendor security certifications (SOC 2? ISO 27001?), (2) DPA available? (3) encryption in transit/at rest? (4) audit logs? (5) data retention policy, (6) incident notification process, (7) prohibition on training their model on your data, (8) data classification approved to use with this tool. This one-page checklist becomes your control documentation for audits and your risk assessment tool for adoption decisions.

What Your Auditors Will Specifically Ask About AI

Prepare for these questions in your SOC 2 or ISO 27001 audit:

"What AI tools does your organization use?" Have your inventory ready. Be specific. Auditors want to know tools, vendors, and what data they touch.

"How did you evaluate these tools before adopting them?" Show your approval process. Show the business case. Show the security assessment. Auditors want to see that you made a deliberate decision.

"Do you have security contracts with AI vendors?" Pull out your DPAs and vendor contracts. Highlight the security obligations and audit rights.

"How do you control access to these tools?" Explain your access management process. How do you grant access? How do you revoke it when people leave? Do you audit access logs?

"What data goes into these tools?" Be specific. Auditors want to understand whether sensitive data is exposed. Walk through concrete examples.

"How do you monitor vendor performance and security?" Show your monitoring activities. Incident tracking. Periodic security reviews. Performance metrics for tools making decisions.

"If a vendor has a security incident, how would you know and how would you respond?" Describe your incident response process. How will you be notified? What will you investigate? What's your response playbook?

You don't need perfect answers. But you need thoughtful, documented answers that show you're managing these tools as part of your information security program, not treating them as rogue tools outside your compliance framework.

What to Do Monday Morning

• Schedule an audit prep conversation: If you have SOC 2 or ISO 27001 compliance requirements, schedule a 30-minute call with your compliance team, security team, or auditors to discuss AI tools. Ask: "Are we addressing your concerns about AI in our compliance framework?" Get feedback on any gaps.
  - Create your AI tool inventory: List all AI tools your organization uses. Include vendor, purpose, and what data it touches. This takes 2-3 hours and gives you visibility for both compliance and security.
  - Pull your vendor contracts: For the top three AI vendors you use, get copies of their security data sheets or service agreements. Look specifically for: SOC 2/ISO 27001 certifications, encryption commitments, audit rights, incident notification, data retention/deletion policies, model training restrictions. Document what you find on a simple comparison spreadsheet.

Key Takeaways

• SOC 2 and ISO 27001 aren't hostile to AI, but they require you to manage AI tools as part of your compliance program: Access control, vendor management, data protection, change management, and incident response all apply to AI tools, not just traditional IT systems.
  - Vendor contracts are the foundation of AI compliance: Without a contract that specifies security obligations, you're taking on audit risk. For sensitive data, the contract needs to include encryption, access controls, audit rights, and incident notification.
  - Auditors will ask specifically about AI tools: Be prepared to describe what tools you use, why you chose them, what data they touch, how you monitor them, and what would happen if a vendor had an incident. Proactive disclosure beats discovery.
  - Create data classification for AI: Define which data classifications can go to which AI tools based on vendor security posture. This operationalizes your compliance framework.
  - Approval and monitoring processes don't need to be burdensome: A simple request form and monthly monitoring checklist are usually sufficient. The point is visibility and deliberate management, not excessive controls.
  - Emerging AI-specific risks (bias, explainability, model drift) aren't yet fully standardized in frameworks, but auditors are starting to ask: Be prepared to discuss how you're managing these risks even if your formal compliance framework doesn't have specific controls yet.

Frequently Asked Questions

Does using free ChatGPT automatically violate SOC 2 or ISO 27001?

No. Violating the framework requires more than just using the tool. It requires inadequate controls around sensitive data. If you're using free ChatGPT only for non-sensitive data (public information, general questions, tasks that don't involve company data), you're fine. If you're sending customer data, vendor contracts, or employee information to free ChatGPT, you have a control gap that auditors will flag. The solution is either to use an enterprise version with a DPA or to restrict the tool to non-sensitive use cases.

Do I need SOC 2 or ISO 27001 audit of my AI vendor?

For sensitive data, yes. The auditor will ask "What certification does your vendor have?" If the vendor has SOC 2 Type II or ISO 27001, you can rely on that audit as evidence of their controls. If they don't have certifications, you need other evidence (security assessments, contract commitments, your own testing). For non-sensitive data, certifications are nice to have but not essential.

What should I do if my AI vendor doesn't have a DPA?

Ask for one. Many vendors will provide a DPA if you ask, especially if they're enterprise vendors. The request is simple: "We need a standard Data Processing Agreement (DPA) that specifies your obligations around data protection, retention, and incident notification." If they refuse and the tool touches sensitive data, you have two options: (1) use a different vendor, or (2) restrict this tool to non-sensitive data and document that restriction in your controls.

How do I handle "shadow AI" in my compliance framework?

Create an approval process that's fast and low-friction for teams to request new tools. Have them fill out a form: tool name, vendor, business justification, what data it will touch. Approval for non-sensitive data can happen in a day. This addresses shadow AI by giving teams a fast path to use tools while giving you visibility. If you discover tools in use that weren't approved, work with the teams to either get them approved retroactively or stop using them.

What's the difference between SOC 2 Type I and Type II for AI compliance?

Type I is a point-in-time audit: auditor verifies you have controls designed and in place at one moment. Type II is a period audit (usually 6+ months): auditor verifies your controls are operating effectively over time. For AI tools, Type II is more valuable because it shows continuous monitoring and control operation, not just that you documented controls once. But Type I is still valuable as a baseline security indicator.