SOC 2 for AI Companies: A Practical Guide

Executive summary

SOC 2 for AI is not a separate certification. It is the same rigorous, widely recognized security attestation that enterprise buyers have demanded of software vendors for a decade — applied to a company that now ships AI features. The framework does not change. What changes is your scope, your controls, and the evidence you must produce, because models, prompts, training data, and third-party model providers introduce risks that a conventional SaaS control set does not fully address.

This guide is written for the founders, engineering leaders, and security owners of AI startups and SaaS companies who have just heard the phrase "we'll need your SOC 2 report before we can sign." It explains what SOC 2 is with precision, distinguishes Type I from Type II, and shows exactly what an AI product adds to the picture — from scoping your AI systems to treating model APIs as subprocessors. It then lays out a practical roadmap to readiness and maps SOC 2 to the two frameworks most likely to appear alongside it: the NIST AI Risk Management Framework and the EU AI Act.

What SOC 2 actually is

SOC 2 stands for System and Organization Controls 2. It is an attestation report governed by the American Institute of Certified Public Accountants (AICPA) and performed under the AICPA's attestation standards (the SSAE 18 framework). The word attestation is the key to understanding everything else: a SOC 2 report is an independent CPA firm's professional opinion about whether your controls meet a defined set of criteria. It is not a checklist you fill out yourself, not a badge you buy, and not a certificate a software tool can print. It is an examination conducted by licensed auditors who gather evidence, test your controls, and put their professional name behind the conclusion.

Because it is an opinion rather than a pass/fail certification, a SOC 2 report reads more like an audit report than a certificate. The final deliverable typically runs dozens of pages: a description of your system, management's assertion about that system, the auditor's opinion, and — in the case of a Type II — a detailed table of every control tested, the tests performed, and the results. Enterprise buyers and their security teams read these reports carefully. That is precisely why the report carries weight.

The Trust Services Criteria

SOC 2 is built on the AICPA's Trust Services Criteria (TSC) — the standards against which your controls are evaluated. There are five categories, and understanding which ones apply to you is the first real decision in any SOC 2 program:

• Security (also called the Common Criteria) — the only mandatory category. Every SOC 2 report covers Security. It addresses protection of the system against unauthorized access, disclosure, and damage, and is organized around the categories of the COSO internal-control framework: the control environment, communication and information, risk assessment, monitoring, and control activities, plus logical and physical access controls, system operations, change management, and risk mitigation.
• Availability — whether the system is available for operation and use as committed. Relevant if you make uptime or resilience commitments to customers.
• Processing Integrity — whether system processing is complete, valid, accurate, timely, and authorized. Relevant when the correctness of what your system produces is central to the service.
• Confidentiality — whether information designated as confidential is protected as committed. Highly relevant to AI companies handling customer data, proprietary prompts, or sensitive business information.
• Privacy — whether personal information is collected, used, retained, disclosed, and disposed of in line with your privacy commitments and criteria. Relevant when you process personal data of individuals.

Security is required; the other four are optional and are added based on the promises you make to customers and the nature of your service. Most software companies start with Security alone, then add Availability and Confidentiality as buyers ask for them. For a company shipping AI features that touch customer data, Confidentiality is often worth including early, because it maps directly to the assurances your buyers most want about how their data is handled inside your AI systems.

What a SOC 2 is not

It helps to be clear about the boundaries. SOC 2 is not ISO 27001 (an international certification of an information security management system, issued by an accredited certification body). It is not a government authorization like FedRAMP. It is not a penetration test, though a pen test is commonly one piece of evidence within a SOC 2. And it is not, on its own, proof that your AI is safe, unbiased, or accurate — it attests to the security and, optionally, availability, integrity, confidentiality, and privacy of the system, not to the ethical quality of your model's outputs. Recognizing these boundaries keeps a SOC 2 program honest and helps you set accurate expectations with buyers who sometimes ask a SOC 2 report to answer questions it was never designed to answer.

Type I vs Type II: the distinction that matters most

Almost every practical decision in a SOC 2 program flows from one choice: Type I or Type II. The two report types cover the same criteria but answer different questions.

Type I — design at a point in time

A SOC 2 Type I report attests that your controls are suitably designed to meet the applicable Trust Services Criteria as of a single date. The auditor examines whether the right controls exist and are described accurately, but does not test whether they operated effectively over time. Think of it as a snapshot: on this date, the controls were in place and properly designed.

The advantage of a Type I is speed. Once your controls are designed and implemented, an auditor can produce a Type I relatively quickly, which is why many AI startups reach for it to unblock a single urgent enterprise deal. The limitation is equally clear: a snapshot says nothing about whether you actually run those controls day after day. Sophisticated buyers know this, which is why a Type I is best understood as a bridge rather than a destination.

Type II — operating effectiveness over a period

A SOC 2 Type II report attests that your controls were both suitably designed and operated effectively over a defined period — the observation window, commonly three to twelve months. During that window, the auditor gathers evidence that controls ran consistently: that access reviews actually happened each quarter, that every code change went through review, that alerts were triaged, that onboarding and offboarding followed policy. Instead of a snapshot, Type II is a video.

Type II is the report enterprise buyers ultimately want, because operating effectiveness over time is what actually protects their data. A well-designed control that no one follows protects no one. For that reason, the standard pattern for a company that needs SOC 2 quickly is to issue a Type I to satisfy an immediate requirement, begin the observation window on the same control set, and follow with a Type II covering the subsequent period. After the first Type II, companies typically renew annually, each report covering the year since the last.

Why enterprise buyers demand it — and how it unlocks deals

SOC 2 became a de facto standard for one simple reason: enterprises cannot individually audit every vendor they buy from, so they outsource that assurance to independent CPA firms. When a large company evaluates your AI product, its security, procurement, and legal teams need to know that your controls protect the data they are about to entrust to you. A SOC 2 Type II report answers that question in a form they already trust and know how to read, which lets them move without sending their own auditors into your environment.

In practice, the absence of a SOC 2 report shows up as friction at the worst possible moment — after a champion inside the buyer wants to move forward. The security review stalls. The vendor questionnaire runs to hundreds of rows. Legal asks for controls you cannot yet evidence. Deals that looked closed slip a quarter while you scramble to answer. A current SOC 2 report short-circuits much of this: it satisfies a large share of the security questionnaire on its own, gives the buyer's security team a document they can accept in lieu of a bespoke audit, and signals organizational maturity that makes the rest of the review go faster.

For an AI startup selling into regulated or security-conscious markets, this dynamic is even sharper. Buyers in financial services, healthcare, and the public sector frequently treat SOC 2 as a hard gate: no report, no deal, regardless of how good the product is. Shipping AI features into these markets without a plan for SOC 2 is, in effect, choosing to compete only for customers who do not ask — a shrinking pool. If your buyers are enterprises, the question is not whether to pursue SOC 2 but when, and the answer is almost always "before the pipeline forces the issue." Our companion overview of securing AI features for SaaS covers this go-to-market pressure in more detail.

What's AI-specific about a SOC 2 for a company shipping AI features

Here is the point that trips up many first-time teams. The Trust Services Criteria were written to be technology-neutral, and they do not contain an "AI section." There is no separate AI checkbox in the Common Criteria. This leads some founders to conclude that shipping AI changes nothing about their SOC 2. That conclusion is wrong. While the criteria are unchanged, an AI product materially changes three things: the scope of the system under examination, the controls you must design to satisfy the criteria, and the evidence the auditor will expect to see. A modern auditor evaluating an AI company will probe exactly these areas.

Scoping the AI systems and data flows

Scope is the foundation of any SOC 2, and for an AI product it is also the hardest part to get right. You must define precisely which systems are in scope and trace how data moves through them. For an AI feature, that means mapping the full path: where user input enters, how prompts are assembled, what internal or retrieved data is added to the context, which model processes the request, where the output goes, and what is logged or stored along the way. Retrieval-augmented generation, agent tool calls, vector databases, and fine-tuning pipelines all extend the boundary of the system in ways a traditional web-app diagram would miss. If your data-flow map does not represent these paths accurately, your controls will have gaps and your description will not match reality — the fastest route to audit findings.

Controls over models, prompts, and training data

Once the AI system is scoped, you need controls that address its specific components:

• Models — control over which models are approved for use, how they are configured, who can change model selection or parameters, and how model versions are tracked. When you host or fine-tune models, this extends to protecting model weights as sensitive assets.
• Prompts — system prompts and prompt templates are effectively production code and often contain sensitive logic. They should be version-controlled, access-restricted, and change-managed, not edited ad hoc in a console. Prompt injection defenses belong here too: controls that prevent untrusted input from hijacking model behavior.
• Training and fine-tuning data — if you train or fine-tune on data, you need controls over its provenance, its handling, and, critically, whether customer data is used for training at all. Many enterprise buyers require a contractual and technical guarantee that their data is not used to train models; your controls must be able to demonstrate that this guarantee holds.

Third-party model providers as subprocessors

Most AI companies do not run their own foundation models; they call an API operated by a third-party model provider. When that provider processes your customers' data on your behalf, it functions as a subprocessor, and it belongs squarely inside your vendor management program. Your SOC 2 controls should demonstrate that you evaluate such providers before using them — reviewing their own SOC 2 or equivalent attestations, their data-handling and retention terms, and whether they train on submitted data — and that you keep a current inventory of what customer data flows to which provider. Auditors increasingly expect to see this due diligence as concrete evidence, and enterprise buyers frequently ask for your subprocessor list by name. Vendor management is not a formality for AI companies; the model providers are often the single most consequential vendors in the system.

Data retention and confidentiality of customer data used with AI

AI features have a habit of creating new copies of sensitive data in new places: prompt logs, conversation histories, embeddings stored in vector databases, and caches. Each of these is customer data that must be governed. Controls should define how long AI-related data is retained, how it is protected in each store, who can access it, and how it is deleted when a customer leaves or requests erasure. The Confidentiality criterion is where much of this lives, and it is one reason we often recommend AI companies include Confidentiality in scope. Strong encryption underpins these controls; Deflected's platform applies post-quantum cryptography — ML-KEM-1024 (FIPS 203) for key encapsulation, hybrid X25519 alongside the post-quantum scheme, and AES-256 for data at rest and in transit — so that confidential customer data used with AI is protected against both current and future cryptographic threats.

Monitoring and logging of AI decisions

The Common Criteria require monitoring of the system, and for an AI product that means more than infrastructure metrics. You need an audit trail of what your AI systems actually did: the requests they received, the decisions or outputs they produced, the tool calls agents made, and the security events your defenses flagged. This logging serves two purposes at once. It is a control the auditor will test, and it is the raw material for incident response and for answering a customer who asks, months later, what your system did with a particular piece of their data. Immutable, access-controlled logs of AI activity are among the most valuable evidence an AI company can maintain.

Change management for models and prompts

Traditional change management governs code deployments. AI systems add two more change surfaces that behave like production changes but are easy to treat casually: model updates (a provider silently upgrading a model version, or your team switching models) and prompt changes (an edit to a system prompt that alters behavior across every user). Both can change how your product handles data and what it outputs, and both therefore belong under change management: reviewed, tested, approved, and logged. An auditor examining an AI company will look for evidence that a prompt change went through the same discipline as a code change. Teams that treat prompts as configuration to be tweaked freely will struggle to pass this test.

A practical roadmap to readiness

SOC 2 can feel amorphous until it is broken into stages. The path below is the sequence most companies follow, and it applies whether you are targeting Type I, Type II, or both. Remember throughout that the auditor performs the examination; the work in these stages is the preparation that makes the examination pass cleanly.

1. Readiness / gap assessment. Start by comparing where you are against the applicable Trust Services Criteria. A readiness assessment inventories your existing controls, identifies gaps, and produces a prioritized remediation list. For an AI company, this is also where you first map your AI systems and data flows in detail, because you cannot assess controls over a system you have not accurately described. The output is a clear picture of the distance between today and audit-ready.
2. Define scope and control objectives. Decide which Trust Services Criteria are in scope (Security always; Confidentiality, Availability, Processing Integrity, and Privacy as your commitments require), which systems and environments are covered, and what your control objectives are. Scope is a deliberate decision with real consequences: too narrow and the report will not satisfy buyers; too broad and you commit to operating controls you may not need. For AI products, be explicit about which AI features and data stores are inside the boundary.
3. Implement controls. Close the gaps. This is the substantive work: standing up access controls and reviews, formalizing change management, implementing logging and monitoring, writing and adopting policies, hardening your vendor management to cover model providers, and putting the AI-specific controls above into practice. Controls must be real and operated, not documented and ignored — the observation window will expose the difference.
4. Collect evidence. A SOC 2 is proven with evidence: access review records, change tickets, logs, alerts, onboarding and offboarding records, vendor assessments, policy acknowledgments, and more. Establish how each control produces evidence as a byproduct of normal operation, so you are not manufacturing artifacts at audit time. Good evidence discipline is the single biggest determinant of how smoothly the audit goes.
5. Run the observation window (for Type II). For a Type II, your controls must operate over the observation period — commonly three to twelve months — while evidence accumulates. This is where design becomes operating effectiveness. Discipline during this window is what a Type II ultimately certifies, and there is no shortcut: the time has to pass with controls genuinely running.
6. The audit. An independent, licensed CPA firm conducts the examination: reviewing your system description, testing controls, sampling evidence, and forming its opinion. You will answer questions and provide artifacts. If the preparation was sound, the audit confirms what you already know. The firm then issues the report — the document you hand to buyers. Deflected does not perform this step and cannot; choosing and engaging a reputable CPA firm is yours to do, and we help you arrive at it fully prepared.

Timelines vary with your starting maturity. A company with sound engineering hygiene — real code review, managed access, existing logging — can reach Type I readiness in one to three months, then run the Type II window from there. A company building controls from scratch should expect longer. The observation window is the one part you cannot compress, which is why starting early is the highest-leverage decision you can make. For a fuller treatment of governance and audit readiness across frameworks, see our compliance overview.

How SOC 2 maps to the NIST AI RMF and the EU AI Act

SOC 2 rarely arrives alone. As AI-specific governance expectations grow, buyers and regulators increasingly ask about the NIST AI Risk Management Framework and, for anyone touching the European market, the EU AI Act. Understanding how these relate to SOC 2 lets you build one coherent control program rather than three disconnected ones.

NIST AI Risk Management Framework

The NIST AI Risk Management Framework (AI RMF) is a voluntary framework for identifying and managing AI risk across the model lifecycle, organized around four functions: Govern, Map, Measure, and Manage. It is complementary to SOC 2, not overlapping. Where SOC 2 attests to the security and confidentiality of the system that runs your AI, the AI RMF addresses the trustworthiness of the AI itself — its validity, reliability, safety, fairness, transparency, and accountability. The two reinforce each other: the governance, risk-assessment, and monitoring work you do for SOC 2's Common Criteria produces artifacts that also satisfy the Govern and Manage functions of the AI RMF, and the data-flow mapping you do for SOC 2 scoping feeds the Map function directly. A company that runs both well finds significant reuse between them. We cover the framework in depth in our guide to the NIST AI RMF.

EU AI Act

The EU AI Act is the European Union's risk-based regulation of AI systems. Unlike SOC 2 and the AI RMF, it is binding law, and it imposes real obligations that scale with the risk category of your AI use case — with the heaviest requirements falling on systems classified as high-risk. It is not a security attestation, and a SOC 2 report does not make you compliant with it. But there is meaningful overlap in the underlying practices: the Act's expectations around risk management, data governance, logging and record-keeping, transparency, and human oversight rest on the same operational foundations as a strong SOC 2 and AI RMF program. Robust logging of AI decisions, disciplined data governance, and clear vendor management all serve both a SOC 2 examination and the Act's record-keeping and oversight requirements. The practical lesson is to build controls once, at the level of underlying practice, and map that single control set to each framework — rather than treating SOC 2, the AI RMF, and the EU AI Act as three separate projects competing for the same engineering time.

Common pitfalls

Most SOC 2 pain is predictable. These are the failure modes we see most often in AI companies, and each is avoidable with foresight.

Scoping the AI system too narrowly — or inaccurately

The most consequential mistake is a system description that does not match reality. Teams draw a diagram of their core application and forget the prompt logs, the vector database, the fine-tuning pipeline, or the analytics store that quietly holds conversation data. When the auditor discovers a data flow the controls do not cover, it becomes a finding. Invest heavily in an accurate, complete data-flow map before anything else — it is the foundation everything rests on.

Treating prompts and models as configuration, not code

Engineering teams that have excellent code review sometimes let system prompts and model choices change freely, edited in a console or a config file without review. Because these changes alter how the product handles data and what it outputs, auditors treat them as production changes. Bring prompts and model configuration under version control and change management from the start, or the observation window will surface a stream of unreviewed changes.

Ignoring the model provider as a subprocessor

Companies often perform diligence on their infrastructure vendors while treating the foundation-model API as a given. But the model provider is frequently the single most sensitive subprocessor in the system, because customer data flows to it on every request. Failing to assess it, review its data-handling terms, and inventory what data it receives is both an audit gap and a genuine risk. Give model providers the same scrutiny you give any critical vendor — often more.

Building controls for the audit instead of for operation

Controls that exist only to pass the audit — followed the week before fieldwork and abandoned afterward — fail a Type II, whose entire purpose is to test operation over time. They also fail their real job of protecting data. Design controls you can genuinely operate every day with minimal friction, and let evidence accumulate as a byproduct. Sustainable beats impressive.

Confusing readiness with the attestation

Finally, some teams believe that adopting a compliance tool or completing a readiness project means they "have" SOC 2. They do not. Readiness is preparation; the report exists only after an independent CPA firm completes its examination. Being clear about this internally prevents the awkward moment when a buyer asks for the report and there is nothing to send. Plan for the audit as a distinct, budgeted step with real lead time.

Starting too late

Because the Type II observation window cannot be compressed, the cost of starting late is measured in quarters, not weeks. Companies that wait until a large deal demands SOC 2 discover that even flawless execution cannot produce a Type II covering a period that has not yet elapsed. The teams that never feel this pain are the ones that began readiness before the pipeline forced the question.

How Deflected helps

Deflected helps AI companies reach SOC 2 readiness — and stay there — without turning compliance into a project that consumes the engineering roadmap. To be precise about the boundary: we are not an auditor, we do not issue SOC 2 reports, and no software can. An independent, licensed CPA firm performs the examination and signs the opinion. What we do is get you fully prepared for that examination and keep your AI-specific controls operating between audits.

Our AI Governance & Compliance engagement is built for exactly this. It brings policy, controls, and evidence together and maps them to the frameworks that matter — SOC 2, the NIST AI Risk Management Framework, and the EU AI Act — so your AI program is audit-ready, not merely secure. In practice that means we help you accurately scope your AI systems and data flows, design and implement the AI-specific controls this guide describes, stand up the logging and monitoring auditors expect over AI decisions, harden your vendor management to cover third-party model providers as subprocessors, and assemble the evidence that makes the CPA firm's fieldwork straightforward rather than painful.

Because so much enterprise friction shows up as security questionnaires and evidence requests, we also help you answer them: turning your control set and audit artifacts into fast, consistent responses to buyer questionnaires, so a signed report accelerates deals instead of merely satisfying a gate. And because confidentiality of customer data used with AI is central to any SOC 2 for an AI company, the underlying protection is quantum-grade by default — ML-KEM-1024 (FIPS 203) key encapsulation, hybrid X25519, and AES-256 encryption — so the data your controls govern is protected against both today's threats and the cryptographic threats of the coming decade. You can read more about our approach to governance and audit readiness on our compliance page, and see how it fits the broader platform on our platform overview.

Getting started

If SOC 2 is on your horizon — or already blocking a deal — the most valuable first step is an honest readiness assessment: an accurate map of your AI systems and data flows, a gap analysis against the Trust Services Criteria, and a prioritized plan to close the distance. From there, the roadmap in this guide becomes a concrete, sequenced project with a realistic timeline. The earlier you begin, the more the observation window works in your favor rather than against you.

Frequently asked questions