AI and Your SOC Report

How service organizations can address AI risks, disclosures, and internal controls in their SOC reports

AI has changed how many businesses operate. Service organizations, the companies that obtain SOC 1 and SOC 2 examinations, tend to be technology heavy, which puts them among the most affected. Some use AI to build and run the business. Others embed AI directly in the service their customers rely on. Many do both. That raises a practical question for every service organization heading into its next exam: what, if anything, should the SOC report say about AI? This article focuses on the two places where the answer shows up: the system description and the controls listed in Section 4 of your SOC report. 

AI risk on the brain

As industry learns more about AI and its capabilities, we also learn more about its risks, and there are many: 

• Training on user data – Many consumer AI products use prompts and uploaded files to train future models unless the user opts out. Once customer data becomes training data, it cannot be pulled back, and fragments of it can resurface in another user’s output. 

• Unpredictability – AI is non-deterministic, so the same input can produce different output, and it can state wrong answers with full confidence. That makes AI output hard to test, hard to reproduce, and hard to rely on without review. 

• Prompt injection – AI models have no reliable way to separate trusted instructions and internal reasoning from untrusted content. Text hidden in an email, a web page, a PDF, or a tool call result can be treated as if it is a user instruction or be interpreted as the model’s own internal reasoning. 

• Alignment – Model providers train AI to refuse harmful requests and follow safety rules, but these guardrails are highly imperfect. They can get in the way of legitimate work and still fail to protect your business when you need them most. 

• Data leakage – Employees paste customer data, source code, and confidential documents into whatever AI tool is handy, often a personal account on a consumer product with no enterprise agreement in place. Once that data leaves, you have no control over where it is stored or how long it is kept. 

• Numerous second- and third-order effects – like AI being used to find security vulnerabilities and write exploits based on those vulnerabilities to attack systems, persistently. AI hackers never get tired, never get hungry, and never complain. 

The security press is awash in stories that are raising the AI security awareness of risk managers everywhere, including the ones who read your SOC report. OpenAI, Anthropic, and Google have each acknowledged incidents involving their models inadvertently hacking companies and governments. And the everyday mishaps keep coming: a Meta AI alignment director watched her AI agent speedrun deleting her inbox while she ran to her computer to stop it, attackers talked Instagram’s AI support assistant into resetting passwords on accounts they did not own, Replit’s coding agent wiped a customer’s production database in the middle of a code freeze, and Google’s Antigravity agent erased a user’s entire hard drive while trying to clear a cache. 

Most people who use AI find these stories believable, because most have their own share of bizarre AI interactions. My own experiences include one in which an AI encouraged me to paste a private key (used to create OAuth tokens) into a public website, and in another instance where an AI instructed me to run a command that would have deleted my entire Applications folder (after which it tried to gaslight me, denying what it wrote, and then claiming there was some sort of interference between the screen and my eyes that was changing the text). 

Suffice it to say that between the relentless news articles and less than stellar personal AI experiences, AI risk is front and center in the minds of those who work and deal with enterprise risk, especially those who need to review your SOC report. 

A matter of trust

The purpose of a SOC report is to provide a foundation upon which a user organization can place trust in a service provider. The keystone guidance for SOC 2 reporting published by the AICPA is called the Trust Services Criteria for a reason. Enormous trust is placed in a service provider to provide complete and accurate transactions, financial reports, and to securely operate systems that handle user entity data, and more. Without some type of third-party assurance, user entities are left with the “trust me bro” model of third-party risk management, which might work in your corporate team building “trust fall” exercise, but is not a winning formula for enterprise risk management. 

Billy Joel, the greatest songwriter of the 20th century, said it best: 🎶It’s always been a matter of trust🎶… and those of us tight with Billy know he was extolling the virtues of SOC reporting. 

AI disclosures and controls in your SOC report

AI disclosures typically appear in two places within a SOC report. The first is the system description, a narrative that tells readers what services you provide and how you deliver them. Because it walks through the key systems and processes behind those services, the description can add color that the tersely written control activities do not. The second is Section 4, where those control activities are presented alongside the service auditor’s tests and results. 

Service organizations should expect SOC report readers to look for disclosures about AI. How much you disclose depends on how you use it. Even if you do not use AI at all, say so. Silence leaves readers guessing, and they will send you a questionnaire to find out.  

This is not an exhaustive list of potential SOC description additions, but here are some ideas to consider: 

• AI Policy – All the rage these days – everyone is asking everyone if they have an AI policy. This is the lowest hanging fruit. Consider creating a policy and describing its key elements in your description. 

• Risk assessment – Your annual risk assessment should specifically address AI: where and how it is used, what could go wrong, and which controls respond.  

• Human in the loop – If you use AI within your internal controls, a person should review critical output before relying on it. 

• Separation of duties and least privilege – Separate an AI agent’s ability to read untrusted content from its authority to take consequential actions, such as posting transactions or changing production systems. Restrict external communications for agents that can access sensitive data. Where these capabilities must coexist, use explicit approval steps and enforce access restrictions outside the model. Combining these capabilities without safeguards creates a risk of destructive actions or sensitive data disclosure through prompt injection or a momentary hallucination. 

• Software development – AI in software development can range from simply using AI to assist in code writing that largely maintains a human review to full-bore, spec-driven development composed of multi-agent swarms, agentic developers, code reviewers, source-code security scanners, and testers. Your description should say where on that spectrum you sit and how your change management controls apply to AI-written code. If an AI agent reviews or approves code, be careful about calling that an independent review; for the time being, most readers will still expect a human to approve changes before they reach production in enterprise systems. 

• AI in your service – If you embed AI functions in your service, disclose any AI-specific vendor risk management practices, for example, whether or not your contractual relationships with inference providers restrict training on user data and whether or not they limit routing prompts to domestically-owned and operated companies. 

• Enterprise controls – Identify enterprise controls configured and enforced in your AI platform of choice that help enforce your organization’s security requirements, such as, allowlisting model context protocol (MCP) servers, enforcing SSO, logging, and other relevant feature toggles. 

• Change management – If you embed AI into your product, you probably have your own system prompts that accompany the API requests to the inference providers, and you may change the underlying models used by your platform. Changes to system prompts and models should be treated like source code and undergo testing and validation before deploying. 

• Self-hosted models – If you perform the inference yourself and host the models on your own infrastructure, then you will almost certainly need significant additional disclosures and controls related to sandboxing and network isolation, model testing and validation, monitoring and logging, resilience against prompt injection, and more. 

Service organizations should review their descriptions and their control matrices to identify key areas where disclosures and additional controls make sense for their organization. Where the controls are significant enough, they should be added to the control matrix and tested by your service auditor. 

There are a lot of AI security best practices emerging from NIST, CIS, OWASP and others, but service organizations should avoid the temptation to add it all. Try to limit the disclosures and controls to those most relevant to the readers of your SOC reports. 

Rapid change

Throughout the history of computing and the Internet, security best practices have been in a slow but continuous state of change. Password security practices have evolved over decades. In the very early days, it was acceptable to store passwords in plain text, then encryption became the standard, then password hashing, then advanced hashing with built-in salts and work requirements, and now we are transitioning (slowly) again, this time to passkeys. 

By contrast, AI, its effects on business, and the security practices surrounding it are changing at a pace unlike anything in recent history. Even the AICPA, which has an intentionally slow and deliberate process for releasing new standards, is expected to update the Trust Services Criteria in 2027. The timing and final language remain unconfirmed, but the anticipated updates are likely to address AI risks explicitly. In the meantime, service organizations need not wait for those changes to consider what report readers already expect to learn about their service provider’s use of AI. 

Strengthen your AI governance and SOC reporting

Keiter’s Risk Advisory Services team can assist with your organization’s AI governance strategy. Our team can identify risks created by your current or planned use of AI, propose internal controls to help mitigate those risks, and craft relevant policies and procedures. Contact us: Email | Call: 804.747.0000 | Request a proposal