Compliance Implications of AI Features for SOC 2 and ISO 27001 Audits

Adding AI features to a SaaS product expands both its attack surface and its audit scope. SOC 2 and ISO 27001 already cover much of that exposure. Founders need controls that reach the models, tools, vendors, and code now handling company information, with evidence that those controls work.

Why AI features change what SOC 2 and ISO 27001 auditors look at

The operative SOC 2 standard in 2026 remains the 2017 Trust Services Criteria, with revised Points of Focus published by the AICPA in October 2022. No new version has been issued. Instead, auditors are applying existing risk assessment, access control, system operations, and vendor management criteria to AI systems, broadly through CC3, CC6, CC7, and CC9.

ISO 27001 has no AI carve-out either. When systems or employees process company information through AI tools, agents, or connectors, that processing falls within the information security management system, or ISMS. Auditors therefore assess whether the organization governs the information, access, and suppliers involved. With SOC 2 Type II now a baseline procurement requirement for most enterprise buyers, gaps can block a sale before technical evaluation begins.

The five Trust Services Criteria and which ones AI features directly implicate

Security and Confidentiality take the heaviest load, while Privacy becomes harder to exclude when AI tools receive customer personal information. Security is mandatory in every SOC 2 engagement. For AI features, it includes access controls for models and APIs, as well as the risks introduced by tools and agents. Availability covers how reliably AI services run and how steady their performance is.

Confidentiality reaches beyond the approved product integration. An employee who sends source code, customer data, or financial projections to an AI tool can put that information at risk too. Whether that transmission is a breach depends on the confidentiality policy, authorization, vendor contracts, and treatment of the tool as a sub-processor. CC6.1 and C1.1 address identifying and maintaining confidential information, while another criterion restricts access to authorized personnel. CC6.7 covers how information is protected during transmission, and another criterion covers how it is disposed of under the stated policy.

Processing Integrity requires processing to be accurate, complete, and prompt. AI pipelines can create a gap when they promote outputs based on thresholds without the approval and test artifacts expected from human change tickets. Privacy concerns the handling of personal information throughout the AI lifecycle. If customer PII reaches AI tools, it becomes harder to justify leaving that criterion out.

Two cross-cutting controls make these obligations concrete. CC9.2 covers vendor and business partner risk, so an AI vendor receiving confidential information needs more than an employee’s informal approval. There is a gap if the inventory entry, assessment, or contractual agreement is missing. CC2.2 covers communication of information security policies. Employees must know their AI-specific responsibilities.

The ISO 27001 controls most directly implicated by AI feature deployment

ISO 27001’s 2022 revision gives auditors a direct basis for examining AI data retention. Control 8.10, Information Deletion, applies to tools that keep conversation history. Those tools need set retention periods and proof that they can delete the data. A chat interface does not remove the obligation. Information retained there still needs governance.

Supplier governance extends that scrutiny to the vendor relationship. Auditors ask whether AI tools are in the supplier inventory, what the contracts promise about data handling, and which policies cover how employees use the organization’s information. Existing governance gives teams a head start. Organizations already aligned with ISO 27001 or PCI DSS often adapt more effectively because those structures exist. The gap is applying them to AI, while ISO 42001 addresses the additional AI governance obligations discussed later.

Shadow AI as the most common audit finding

The most common AI-related SOC 2 finding is unapproved use. Consider an engineer pasting proprietary source code into a consumer AI tool. That use may fall outside the supplier register, vendor assessment, protections in the contracts, and written controls for how data is handled. The same gap appears when customer success staff summarize support tickets or finance teams draft board materials in unreviewed products.

One action can cross several control boundaries. Shadow AI creates risks in vendor management, a possible gap in how CC6.7 is applied to transmission, and a gap in how policies are shared under CC2.2. Auditors therefore ask which tools are approved, under what conditions, and whether technical controls prevent unauthorized transfers of confidential data. A policy alone does not answer those questions. Organizations that lack written evidence can receive observations, management letter comments, or qualified opinions.

What AI-generated code means for CC8 Change Management and CI/CD pipeline security

CC8 Change Management applies regardless of who wrote the code. Before AI-generated code goes into production, it must pass the same workflow for authorization, testing, review, and approval as code written by people. SOC 2 Type II auditors increasingly ask about its provenance and security testing before deployment. The coding assistant does not replace the approval process.

The pipeline itself also needs scrutiny. Google patched a maximum-severity vulnerability in Gemini CLI in which headless CI/CD execution automatically trusted attacker-controlled workspace files. That trust allowed arbitrary command execution on build runners. The Clinejection disclosure in early 2026 showed another route through a single malicious GitHub issue title. Prompt injection enabled CI/CD cache poisoning and theft of npm credentials later used to publish a trojanized package.

IDEsaster showed that the problem extended across coding assistants. Researchers documented over 30 vulnerabilities across products including Cursor, Windsurf, GitHub Copilot, Cline, and Roo Code, with all tested AI IDEs vulnerable to prompt injection-based attack chains. These findings put code integrity and build infrastructure in the same risk picture. Under CC8, the evidence must still show that production changes were authorized, tested, and approved, including when AI pipelines promote outputs automatically.

The AI-specific attack surface that standard pen tests miss entirely

A web-only penetration test leaves the model layer untested. The OWASP Web Security Testing Guide has 115 checklist tests, but none tests a prompt, model, or agent. AI testing must reach model-facing inputs and actions, including prompts, retrieved documents, tool calls, agent memory, and rendered output. It must also cover the web and API layers.

Prompt injection explains why that distinction is necessary. It occurs when attacker-controlled or untrusted content changes an LLM application’s behavior in unintended ways. The OWASP GenAI LLM Top 10, 2026 edition, places Prompt Injection first, followed by Sensitive Information Disclosure, Excessive Agency, Supply Chain, and Data and Model Poisoning. Its prompt injection definition covers more than typed user requests. Retrieved content, tool output, images, audio, video, intermediate reasoning, and persistent memory can all fall within scope.

For agentic applications, testing needs to cover direct and indirect prompt injection, retrieval-augmented generation poisoning, sensitive-data disclosure, model extraction, and guardrail bypass. Agents add another set of control questions. Testing must examine least privilege, tool allowlists, human approval gates, credential scope, memory poisoning, output handling, and emergency-stop behavior.

The resulting findings need precise evidence too. To make probabilistic behavior retestable, each behavioral finding should state successes over attempts, the model version, required attacker capability, authority reached, and whether existing controls would have detected it. Whitebox access to source code, cloud configurations, system prompts, and retrieval configuration supports complete coverage. A blackbox test can miss the retrieval layer, tool call chain, and agent memory entirely.

What evidence auditors actually require for AI systems in 2026

Auditors expect eight concrete evidence categories for AI systems. They are a control inventory, an AI bill of materials, a per-request risk-scoring methodology, content-free audit logs, hash-chained logs, policy enforcement at execution time, an AI-specific incident response runbook, and a framework mapping. A well-designed control can still fail the audit evidence test.

The control inventory and AI bill of materials establish what is governed. The risk-scoring methodology documents how requests are assessed, while evidence of execution-time policy enforcement addresses whether rules apply when actions occur. The incident response runbook covers AI incidents, and the framework mapping connects the controls to compliance obligations.

Time is part of the evidence requirement. Auditors are more often questioning static screenshots and asking for continuous-monitoring exports with timestamps that span the full audit window. A screenshot can show a setting at one moment. Evidence that a control operated throughout the period under review is especially important when AI tools, models, and integrations change.

ISO 27001 supplier evidence adds another practical requirement. Auditors ask which AI tools are used, how vendor security is assessed, what data-handling commitments exist, and what logging and monitoring cover their use. Entries in the supplier register, copies of the data processing agreement, written policies, and training records back up those answers. Without documented evidence, organizations face nonconformities. Auditors request more proof because the AI risk surface is newer and less understood.

The ISO 42001 layer and what it covers that SOC 2 alone cannot

ISO 42001 addresses AI governance obligations that SOC 2 alone cannot cover, including system impact assessments, bias, transparency, and human oversight. ISO 27001’s controls remain relevant, with those AI-specific obligations outside its scope. The frameworks share much of their control base, so organizations already governing AI tools under ISO 27001 have a substantial head start.

A certificate is not a model security test. ISO 42001 shows that an organization has a working AI governance system, while testing establishes whether a particular model is accurate, an agent resists prompt injection, or a feature behaves as designed. Integration avoids treating governance and security as separate projects. The same AI bill of materials that answers an ISO 27001 auditor’s supplier governance question also feeds the penetration test scope.

Building controls that satisfy auditors and reduce real risk at the same time

The practical response is to build one set of controls with usable evidence. Register every model API, AI tool, and coding assistant, then map each to its data-handling commitments. That inventory supports CC9.2 vendor management and ISO 27001 supplier governance. It also defines what security testing needs to reach. An omitted tool is a gap in both efforts.

To close shadow AI exposure, the acceptable use policy should name the approved tools, when and how they may be used, and which data classifications are allowed. Employees need that policy communicated under CC2.2. Data loss prevention or cloud access security broker controls help enforce the written rules. Approval alone does not prevent unauthorized transmission. The control needs to reach the point where information leaves.

For AI-generated code, the existing review and approval workflow remains the baseline. Pull-request security scanning helps catch vulnerabilities that the code adds before it is deployed. Continuous-monitoring exports with timestamps then provide evidence across the audit window. An AI-specific incident response runbook should document detection, containment, and reporting for incidents involving tools, model outputs, and agent behavior.

A whitebox assessment with access to system prompts, retrieval configuration, and cloud infrastructure can examine exposures a web-only test leaves untouched. When certified human reviewers check every finding and back it with working-exploit proof, engineers and auditors both get evidence they can use. Tests run once a year cannot keep up with model drift, new integrations, or code changes made by AI assistants. Continuous pull-request scanning and on-demand retests close that interval and identify the gaps before the auditor asks for proof.