SOC 2 for AI companies and AI-powered SaaS: what applies

Does SOC 2 for an AI company differ from SOC 2 for other SaaS?

A customer asking for a SOC 2 report while your product calls or hosts AI models is asking for the same examination a SaaS vendor would face. The report is built on the AICPA 2017 Trust Services Criteria, and the organization owns its controls. Only an independent CPA firm issues the report. What changes for an AI company is not the framework but the decisions that sit underneath it: what is in scope, which model providers and other parties count as vendors or subservice organizations, how customer data moves through prompts and outputs, and what logs and evaluation records prove the controls work.

Start with scope. Decide whether the model inference path, the retrieval store, the prompt and response logs, and any fine-tuning pipeline sit inside the system description. A model API provider that receives customer data is usually a vendor under CC9.2, which requires you to assess and manage vendor and business partner risk. If that provider's own SOC report covers the service you use, your auditor will want to see how you reviewed it and which complementary subservice organization controls you rely on. Confirm with your auditor early whether you will use an inclusive or carve-out approach for each model host, because that choice changes what the examiner tests.

Confidentiality deserves its own review. Confidentiality is only in scope if you include the C1 criteria, but customers that send regulated or proprietary data through prompts will usually expect it. Identify where prompt and completion data is stored, how long traces are kept, and who can read them. Open-source observability tools such as Langfuse record inputs, outputs and token usage for every operation in a request, which can help produce evidence of access and retention, but they also create a new store of customer data that must be protected and disposed of. Evaluation tools such as garak, which writes JSONL reports of every probe attempt and a hit log of successful attacks, can serve as evidence for testing, provided you retain the reports and show how findings were tracked to closure.

Which AI parts go in scope and how they are carried

Treating a model API provider as a vendor means the company relies on that provider for a service but does not ask the provider's controls to be tested inside the company's own report. The relevant criterion is CC9.2, which requires the organization to assess and manage risks associated with vendors and business partners. When confidentiality or privacy is in scope, the related points of focus add obtaining commitments from vendors and assessing compliance with them. The vendor is documented in the vendor inventory and risk register, and the company's controls cover how it selects, reviews and monitors that vendor.

Vendor record: Keep a current inventory entry for each model API, with the data sent, the data region and the contract owner.
Commitments: Collect the provider's confidentiality, data use and retention terms, and record whether prompts are used for training.
Review cycle: Review the provider's SOC 2 report or equivalent assurance on a set schedule and log exceptions.
Prompt data classification: Define which customer data may be sent in prompts, and enforce that rule in code or gateway policy.
Change monitoring: Track model version changes and deprecations that alter behavior or data handling.

Before the audit, confirm with your auditor whether the provider stays outside the system description or must be carved out, because that decision governs everything in the next tab.",

How confidentiality of customer data in prompts is tested

An assessor testing confidentiality for an AI product starts from a simple question: where does customer data go once it enters a prompt? Under C1.1, the organization must identify and maintain confidential information in line with its confidentiality objectives. For an AI company, that inventory usually includes user prompts, retrieved documents, uploaded files and model outputs, along with the embeddings, traces and evaluation datasets built from them. If confidentiality is in scope, the CC9.2 points of focus also apply, so the vendors that receive this data, including model API providers, hosting providers and observability platforms, need confidentiality commitments and a record that someone checked those commitments. Before the audit, build a data flow diagram that shows each place prompt data lands, and mark which copies are confidential.

The assessor will then walk that diagram and ask the same questions at each stop: where is the prompt stored, who can read it, how long is it retained, how is it disposed of, and which third parties receive it. For a self-hosted stack, the evidence is usually configuration and records rather than vendor documents. Trace logging is a common example. Langfuse, which is MIT licensed, captures inputs, outputs and token usage for each operation in a request, so the team must decide which fields are masked or excluded before traces are written, set a retention period in its deployment, and show that deletion runs. Evaluation tooling such as garak, which is Apache-2.0 licensed and writes JSONL reports and a hit log, can also hold sensitive prompts, so its output directories need the same access and retention rules. The reader should confirm each tool's own configuration options in its documentation.

For model providers, the question is what the organization has contractually and technically in place, not what a provider says in marketing material. Collect the current data processing terms, confidentiality commitments and any retention or training settings for each provider the product calls, record the date each was reviewed, and tie each one to the CC9.2 vendor review. Be ready to explain the difference between a provider that is a vendor and one that is a subservice organization, since that affects how its controls appear in your report. Ask the provider what it retains, for how long, and whether it uses customer inputs for training, then keep the written answers. Where a provider's terms cannot be confirmed in writing, document that gap and the compensating decision, because an assessor will look for it.

Which logging and evaluation evidence from self-hosted tools supports the criteria

Self-hosted AI tooling can produce several kinds of records that an assessor may read against the Trust Services Criteria. Each source supports different criteria, and none of them proves a control works on its own. The organization must confirm how each store is configured, who can read it, and how long it is kept before the evidence is relied on.

Langfuse traces as monitoring logs

Langfuse traces record each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. These traces can support monitoring and anomaly review under CC7.2, and they show what a model did with a given request. Because inputs and outputs may contain customer personal or confidential data, confirm whether prompts are masked before storage and who can view them.

Garak probe reports as evaluation evidence

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. These records can support vulnerability testing under CC7.1 and, where data leakage is probed, the confidentiality objectives in C1.1. Keep each run tied to a model version and date so the assessor can match results to the system under review.

Access controls on the trace store

The trace store holds prompts, outputs and user identifiers, so it is itself in scope. Access controls over who can query, export or delete traces map to the logical access criteria in CC6.1 and CC6.3. Review the role assignments for the Langfuse project and the database beneath it, and record the review. Confirm that administrator access is logged and that the access list matches the joiner and leaver records.

Retention and deletion settings

Retention settings determine how long traces and probe reports exist, which affects both the evidence window for a Type 2 period and the data minimization duties tied to confidentiality and privacy. Retention relates to C1.2 when confidential prompts are disposed of, and to the privacy retention criteria when personal data is present. Set the retention period in writing, configure it in the platform, and test that deletion runs. The organization must confirm these settings itself, since the default values depend on the version and deployment.

Change records for prompts and models

Prompts, system instructions, model versions and retrieval settings change the behavior of an AI feature as much as code does. Recording each change with an author, approval and date supports the change management criteria in CC8.1. Store these records in version control or a change system the organization controls, and link each change to the evaluation run that tested it. Confirm that emergency changes to prompts follow the same approval path.

Where ISO 42001 and the EU AI Act fit beside SOC 2

SOC 2 is an attestation, ISO/IEC 42001 is a management system certification, and the EU AI Act is law, and an AI company may need to answer to all three. A SOC 2 examination tests whether the controls a company describes exist and work against the 2017 Trust Services Criteria, and a CPA firm issues the report. ISO/IEC 42001:2023 is a management system standard with 38 Annex A controls in nine areas (A.2 to A.10), covering topics such as impact assessment and data provenance, and it is certified by an accredited certification body rather than attested by a CPA. The EU AI Act sets legal obligations that depend on the role a company holds, so it is not a voluntary assurance choice. Each framework answers a different question for a different reader, and none of them substitutes for another.

The role question comes first. Under Article 3(3) and (4), a provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority outside personal non-professional use. A company that trains or fine-tunes a model and sells it under its own brand is likely a provider, while a SaaS company that calls a third-party model API inside its product may be a deployer, or both at once for different features. Write down which role applies to each product and feature, and record who made that determination, because customers and counsel will ask.

Have counsel confirm applicability and dates before you rely on any timeline. The consolidated text of Regulation (EU) 2024/1689 is published as amended by Regulation (EU) 2026/1744, and the EUR-Lex consolidated text is the starting point for that review. Ask counsel which obligations apply to your role, which transitional provisions still matter, and whether any of your systems fall into a risk category that triggers specific duties. Keep the SOC 2 report, any ISO/IEC 42001 certification scope and your AI Act compliance file as separate documents with separate owners, and do not describe a SOC 2 report as evidence of AI Act conformity.

How a SOC 2 for an AI product moves from scoping to the report

The sequence turns an AI product into a defined system, a set of tested controls and an independent opinion on those controls, with each phase producing a document the next phase depends on.

Define the system description including AI components
Management writes the system description for the in-scope service, covering infrastructure, software, people, procedures and data, and names each AI component: hosted or self-managed models, retrieval stores, prompt and response logging, evaluation pipelines and training or fine-tuning data where it exists. The description is prepared against the AICPA's 2018 description criteria, and the owner confirms which categories are in scope beyond security. The step is done when the description matches how the system runs in production, and the auditor has accepted it as the baseline for testing.
Decide vendor and subservice organization treatment
The team lists every model API provider, cloud host and tool that processes customer data and decides whether each is a subservice organization reported inclusively or carved out, and which complementary subservice organization controls the company relies on. Each vendor is assessed under CC9.2, with its confidentiality or privacy commitments obtained where those categories are in scope. The output is a vendor register with the treatment for each entry and a reviewed set of vendor reports or contract terms that support it.
Map controls to criteria and set the boundary
The company builds a control matrix that links each in-scope criterion, including the common criteria CC1 to CC9 and any additional categories, to a named control, an owner and a frequency. AI-specific controls such as prompt and output logging, access to model keys, evaluation runs before model or prompt changes, and handling of customer data in prompts are written as controls with defined tests. The output is an approved matrix, along with a list of complementary user entity controls that customers must operate.
Operate controls and collect evidence
Control owners run each control on its stated schedule and keep the records that show it ran, such as access review exports, change tickets linked to model and prompt releases, evaluation reports, incident tickets and backup restore logs. Self-hosted tools such as Langfuse for traces or garak for adversarial probe reports can produce some of this evidence, provided their retention and access settings are documented. The step is complete when each control has the records the auditor will sample, and gaps are logged with a remediation owner.
Choose Type 1 or Type 2 and engage the CPA firm
The company decides whether to start with a Type 1 report, which tests control design as of a date, or go directly to a Type 2 report, which adds an opinion on operating effectiveness over a period. An independent CPA firm is engaged under a written engagement letter that sets the criteria, categories and report type. The firm is the only party that issues the report. Confirm with the firm how it will treat AI vendors and whether it has experience testing AI-related controls.
Complete fieldwork and the auditor's testing
The service auditor requests evidence, samples control occurrences, walks through processes with control owners and records exceptions. The engagement follows AT-C section 205 as an assertion-based examination. Management answers the auditor's questions and corrects any exception it can explain, but the auditor decides what to test and how to evaluate results. The output is a set of documented test results, a list of exceptions and the draft report under review.
Sign management's written representations
Before the report is issued, management signs a representation letter confirming, among other things, that the system description is fair, that controls operated as described, and that the company has disclosed known instances of noncompliance, incidents and relevant vendor issues. The letter follows the AICPA's illustrative form for Type 2 reports. Signing it is management's responsibility and cannot be delegated to a consultant. The step closes when the letter is signed and dated, and the auditor issues the independent report.
Issue the report and plan the next period
The CPA firm issues the SOC 2 report with its opinion, and management decides how to share it, typically under an NDA for a SOC 2 report and as a SOC 3 for general distribution if one is produced. Exceptions and any changes to AI models, vendors or logging are recorded for the next examination period. Confirm with the auditor how long the report is treated as current by customers, since that is set by customer practice and not by the AICPA standard.

Who owns controls, who prepares evidence and who issues the report

This table compares four parties in a SOC 2 for an AI product: the company, an implementation partner, the CPA firm and the model API vendor. Read each row as a question of who decides, who builds, who attests and who answers for the provider's own controls. The main takeaway is that an implementation partner can prepare evidence but cannot sign for the company or stand in for the examiner.

Party	Role in the SOC 2	Boundary to keep in view
The company (service organization)	Owns the system description, the controls, the risk assessment and management's written assertion. Accepts responsibility for every control the report describes.	Cannot delegate ownership of controls to a partner, even when a partner configures the tools that run them.
Implementation partner such as DeployOpen	Prepares and hardens self-hosted logging, access and evaluation tooling, configures evidence collection, and assembles evidence packages for the auditor.	Prepares systems and evidence only. Does not issue reports, attestations or certificates and does not test the company's controls for the examiner.
CPA firm (service auditor)	Performs the examination under AT-C section 205, tests design and, for Type 2, operating effectiveness, and issues the report with its opinion.	Must be independent of the company. Cannot be the same firm that designed or implemented the controls it is testing, where independence rules forbid it.
Model API vendor (subservice organization)	Provides its own SOC report or contractual security and confidentiality commitments covering the infrastructure that processes prompts and outputs.	Its report covers its own controls only. The company must decide whether to use carve-out or inclusive treatment and address complementary subservice organization controls.
Customers (user entities)	Rely on the report and perform their own complementary user entity controls, such as managing their users and deciding what data they send.	Customers cannot be assumed to perform controls the report never mentions. Confirm each expectation in the system description.

What usually delays AI SOC 2 projects and how to avoid it

Most delays in an AI SOC 2 project do not come from the Trust Services Criteria themselves. They come from undocumented dependencies, data that was kept without rules, and scope that nobody drew clearly before the examination window opened. Each card below names one of these gaps and the step that closes it before the auditor asks.

Undocumented model provider dependencies

Teams often call several model APIs, embedding services and hosted vector stores without a single register of them. Auditors looking at CC9.2 expect the organization to know which third parties receive customer data and why. Build an inventory of every model endpoint, its region, the data it receives and the contract that governs it, and keep it current as the product changes. Check that each provider appears in the vendor list used for the examination.

Prompt logs without retention rules

Tracing tools record prompts, completions and tool calls, and prompts often contain customer personal data or confidential records. Without a written retention period and a deletion routine, the logs become a confidentiality exposure that sits outside the confidential information inventory described in C1.1. Set a retention period for each log class, redact or hash sensitive fields where possible, and document who may query the store and how deletion is evidenced.

Evaluation runs with no recorded results

Teams run prompt tests, red-team probes and regression suites during development, then discard the outputs. When the auditor asks how the organization tests model behavior before release, there is nothing to show. Store each evaluation run with its date, model version, configuration and pass or fail results, and tie the run to the change ticket that released the model or prompt. Use a fixed schedule so the records cover the whole observation period in a Type 2 examination.

Unclear scope between the AI feature and the platform

An AI assistant often shares authentication, storage and logging with the rest of the product, so teams are unsure whether it belongs in the system description. An unclear boundary leads to late scope changes and gaps in the controls that were tested. Draw a data flow diagram that marks where customer data enters the AI component, which services it touches, and where outputs are stored. Agree that boundary with the auditor early and record it in the system description.

No vendor review for model providers

Model providers are often accepted by a developer signing up for an API key, with no security review, no record of their SOC reports and no check of their data use terms. This leaves CC9.2 unevidenced for the most sensitive third party in the stack. Collect each provider's current SOC report or equivalent assurance, review its exceptions and complementary user entity controls, confirm whether customer prompts are used for training, and file the review with a date and owner.

Access to model keys and prompt stores

Model API keys, vector database credentials and log stores are often shared among engineers and kept in configuration files. Auditors test logical access under CC6, and a shared key used across environments is hard to explain. Issue separate keys per service and environment, store them in a managed secrets service, rotate them on a schedule, and review who holds access to prompt logs at the same cadence as other production access reviews.

Questions AI companies ask before a SOC 2

Is a model API provider's SOC 2 report enough for my own SOC 2?

Usually not on its own. A provider's report covers the provider's controls, and your auditor will want to see how your organization manages that provider as a vendor under CC9.2, which asks you to assess and manage risks from vendors and business partners. Your auditor will decide whether the provider is a subservice organization carved out of your report or included under inclusive reporting, and that choice changes what you must document. Ask the provider for its current report, its listed complementary user entity controls, and its data retention terms for prompts and outputs. Confirm with your auditor how the report will be used before you rely on it.

Does self-hosting a model change my SOC 2 scope?

It can, because the controls you operate move inside your system boundary. If you run open-weight models on your own cloud accounts, you take on the infrastructure, access, logging, change management and vulnerability duties that a hosted provider would otherwise carry, and those controls appear in your description and tests. The drivers are where the model weights, inference servers and prompt stores run, who can reach them, and how changes to model versions are approved and deployed. Confirm with your auditor which components fall under the system description and which fall under a cloud provider's report.

How long does a company need before a SOC 2 Type 2?

A Type 2 needs time for the controls to operate, not only time to write them. A Type 2 report adds an opinion on operating effectiveness over a period, so the length of that observation window and the amount of evidence produced during it set the schedule. Most teams first complete a Type 1 to confirm design, then run controls through the observation window. The drivers are how many controls already produce evidence, how many systems are in scope, and how quickly the auditor can sample. Ask prospective auditors for their evidence requests and observation period expectations in writing.

Does a SOC 2 cover EU AI Act obligations?

No. A SOC 2 examines controls against the Trust Services Criteria, and it does not test compliance with the EU AI Act. The Act sets obligations for providers and deployers of AI systems and general-purpose AI models, depending on the role you hold and the risk category of the system. Some evidence you produce for a SOC 2, such as access records, logs and change records, may also support AI Act documentation, but the mapping must be done deliberately. Confirm your role and obligations with counsel, and treat the SOC 2 as one input rather than a substitute for an AI Act assessment.

Can we run a SOC 2 readiness program in-house?

Often yes, if you have someone who owns the control set and enough engineering time to produce evidence. The organization owns its controls and the independent CPA firm issues the report, so the in-house question is about who maintains the control matrix, collects evidence and answers auditor requests. The work recurs every period, not only before the first audit. Drivers include the number of systems in scope, whether logging and access reviews are already automated, and whether anyone has run an examination before. An implementation partner can prepare systems and evidence, but it does not issue the report.

What does a SOC 2 need from engineering and legal?

Engineering owns most of the technical evidence and legal owns the contractual commitments. Engineering needs to produce access reviews, change approvals, logging and monitoring records, vulnerability management output, and environment inventories, and to keep them consistent across each review period. Legal needs to review customer agreements, data processing terms, confidentiality commitments, and the terms with model providers and other vendors, including retention and training-use clauses. The drivers are how many customer contracts reference SOC 2 and how often model or vendor terms change.

What should we ask an outside firm before hiring help?

Ask what the firm will deliver in writing, who performs each task, and what it will not do. A firm that prepares systems and evidence is not the same as a CPA firm that issues the report, and a DeployOpen engagement, for example, prepares systems, controls and evidence but does not issue reports or attestations. Ask for a fixed scope, the list of deliverables, the owner of each control, and how evidence will be handed over. Quotes should follow from that written scope and name the one-time items, such as the initial build, separately from recurring items, such as evidence collection and retesting.

What to check before hiring a consultant or CPA firm

Start with the CPA firm, because only a licensed CPA firm can issue the SOC 2 report that your customers will read. Ask the firm to define in writing which AI components fall inside the system description: the model API calls your application makes, any self-hosted model servers, the prompt and retrieval store, the logging and evaluation pipeline, and the customer data that flows through each. A firm that is comfortable with service organization examinations should be able to explain how it would treat a third-party model API, whether that provider is a subservice organization reported on an inclusive or carve-out basis, and what evidence it will request from that provider. Ask for named examples of similar engagements in general terms, confirm who on the team will perform fieldwork, and ask how the firm handles independence, including whether it or an affiliate sells you any tooling or prepares your controls. Those answers decide whether the same firm can attest to controls it helped design.

The engagement letter is where scope, fees and responsibilities become binding, so read it before signing. Confirm which Trust Services Criteria categories are in scope, whether confidentiality and privacy are added, the observation period for a Type 2, the population and sampling approach the firm expects, and how it will treat exceptions. Ask what management representations you must give, since a SOC 2 examination is assertion-based and the firm will require written representations under AT-C section 205. Clarify fee structure, what is billed for re-testing, and what recurs each year. Confirm the reporting timeline with the firm rather than assuming it. The AICPA's SOC 2 for service organizations page is a useful reference for the report types the letter should name.

An implementation partner is paid to prepare systems and evidence, not to opine on them, and the contract should say so. Ask who will configure logging, access reviews, change records and evaluation outputs, who keeps the control matrix current, and which deliverables are evidence packages the CPA firm can test directly. For AI-specific work, ask how the partner captures prompt and model-version records, how self-hosted tracing tools retain and protect customer content, and how red-team or prompt-injection test results will be documented as evidence rather than as an assurance opinion. Ask whether the partner will ever sign management's assertion or speak to the auditor on your behalf, and whether it will hand over the configuration and records so you can run controls after the engagement ends. Confirm in writing that all work happens inside your own accounts and that you keep the evidence.

How DeployOpen prepares AI systems and evidence for a SOC 2

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares the controls and evidence an AI company or AI-powered SaaS provider needs for a SOC 2 examination. We do not issue reports or attestations; the independent CPA firm that examines your controls does that.

How we scope

We agree a written scope listing the AI services, data flows and Trust Services Criteria categories before any work starts.
The scope names which model API providers, hosting vendors and tools are subservice organizations, and which are carved out.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work begins.

How we build

We deploy self-hosted logging and tracing tools such as Langfuse so prompts, outputs and tool calls leave an audit trail.
We configure access controls, secrets handling and change workflows for model serving and evaluation pipelines.
We run security tests such as garak against model endpoints and retain the JSONL reports as evaluation evidence.

How we hand over

We document the system description inputs, control designs and owners so your management can write its own assertion.
We deliver a control-to-evidence map that shows which records the CPA firm will sample and where they are stored.
We train your staff to run evidence collection so the program continues after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the first examination.
We help your team review vendor SOC reports and keep subservice organization assumptions current as models and providers change.
We can re-run evaluations and update evidence before each Type 2 observation period, so the auditor has current records to sample.

SOC 2 for AI companies and AI-powered SaaS