SOC 2 and ISO 27001 for AI Providers: What to Ask For

A SOC 2 report or an ISO 27001 certificate shows that an AI vendor runs a documented security program that an independent party has examined. It does not show how the AI behaves, what happens to your data inside a model workflow, or whether an agent is safe to connect to your tools. For a soc 2 ai vendor review, treat the certification as the entry ticket, then ask the AI-specific questions that follow.

Key takeaways

• SOC 2 and ISO 27001 describe how a vendor secures its own organization and systems, within a scope the vendor defines.
• Read the scope, the report type, the exceptions and the list of subservice providers before you read anything else.
• Neither framework tests model behavior, prompt injection resistance, output quality or what an agent is allowed to do in your systems.
• Ask in writing about training on your data, sub-processors, permissions, logging and exit terms, even when the certificate is clean.
• Certification lowers one kind of risk. Your own configuration and approval boundaries remain your responsibility to define.

What does SOC 2 actually cover for an AI vendor?

SOC 2 is an attestation report written by an independent auditor. The auditor examines a vendor's controls against a set of published criteria and gives an opinion. The criteria are grouped into categories: security, availability, processing integrity, confidentiality and privacy. Security is always included. The others are chosen by the vendor, so a report may say nothing about confidentiality or privacy at all.

There are two report types. A Type I report describes whether controls were suitably designed at a single point in time. A Type II report tests whether those controls actually operated over a stated period. For a buyer, Type II carries more weight because it shows the controls were used day after day, not only described well on one date.

The most important detail is scope. The vendor writes a system description that says which products, infrastructure and teams are inside the audit. A vendor can hold a valid report that covers its billing portal and its core platform while the newer agent product sits outside it. The report is true, and still not about the thing you are buying.

What does ISO 27001 cover, and how is it different?

ISO 27001 certifies an information security management system. That means the vendor has a managed process for identifying risks, choosing controls, reviewing them and improving them. A certification body audits the system and issues a certificate, then returns for periodic follow-up audits.

Two documents matter. The scope statement says which parts of the organization and which locations are covered. The Statement of Applicability lists which controls the vendor selected and which it excluded, with a reason. Reading the exclusions often tells you more than reading the inclusions.

The practical difference from SOC 2: ISO 27001 certifies that a management system exists and works, while SOC 2 gives you a detailed report on specific controls and the auditor's testing. Many buyers can request the SOC 2 report itself under a confidentiality agreement. With ISO 27001 you usually see the certificate and the scope, and you ask for the Statement of Applicability separately. Neither is better in every case. Some vendors hold both, and that is a reasonable sign of a mature security function, but it is still a statement about the organization, not about the AI.

What do these certifications not cover in an AI product?

The frameworks were written for service organizations in general. They do not test the things that make an AI agent different from ordinary software. Several gaps are worth naming plainly:

• Model behavior: whether outputs are accurate, consistent or appropriate for your process.
• Prompt injection: whether hostile text in an email or document can steer the agent into taking an action you did not intend. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) describes this class of risk and others specific to language model systems.
• Data use for training: whether your content improves the vendor's or the model provider's models. A clean audit can coexist with a permissive policy here.
• Agent permissions: what the agent can read, write, send or spend once connected to your tools. Authorization design is a separate discipline, covered well in the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html).
• Downstream providers: the model provider and other services behind the vendor may have their own, different assurances.
• Your configuration: a secure platform can still be set up with broad access and no approvals.

For a structured way to think about AI-specific risk beyond security controls, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a useful reference. It organizes risk around governance, mapping, measurement and management, which fits the questions a certificate leaves open.

How do you read a SOC 2 report or ISO certificate in practice?

Most buyers receive the document, see the word certified, and file it. A short reading routine turns it into evidence. Use this checklist, in order:

• Scope: does the described system include the exact product, region and environment you will use?
• Report type and period: is it Type I or Type II, and does the period end recently enough to be relevant?
• Auditor opinion: is it unqualified, or does it note a qualification on any control?
• Exceptions: did testing find deviations, and did management respond with a credible fix?
• Subservice organizations: which cloud, model or data providers are carved out of the audit, meaning their controls are not tested in this report?
• Complementary user entity controls: what does the report expect you to do on your side, such as managing your own user access?
• Criteria selected: are confidentiality and privacy included, or only security?
• ISO specifics: who issued the certificate, is it current, and what does the Statement of Applicability exclude?

The carve-out and the user entity controls are the two items most often missed. The first tells you where assurance stops. The second tells you which part of the work was always yours.

Which follow-up questions should an AI buyer still ask?

Once the certificate is read, move to the questions it cannot answer. Ask them in writing and keep the answers with the contract. They fall into five groups.

Data handling. Does the vendor or any model provider retain prompts, files or outputs, and for how long? Is any of it used for training or evaluation? Where is it stored and processed? The article on getting training and data use terms in writing covers the wording to request.

Sub-processors. Which providers touch your data, in what role, and how will you be told when the list changes? Can you object to a change?

Agent permissions. What is the default access of the agent, how is it narrowed, and who approves an expansion? Are actions such as sending messages or changing records gated by a human approval?

Logging and evidence. Can you see who or what did what, with which inputs, and can you export those records? Retention and access to logs should be stated, not assumed. The audit trail requirements article explains what regulated teams typically need.

Incidents and exit. How quickly will the vendor notify you of an incident affecting your data? What do you receive on termination, in what format, and how is your data deleted afterward?

An illustrative scenario: a clean report with the wrong scope

This is an illustrative scenario, not a real case. A distribution company plans to give a vendor's AI agent access to its shared inbox and order records. The vendor sends a SOC 2 Type II report, and the buyer's operations lead reads the scope section before forwarding it to the board.

The system description covers the vendor's web dashboard and data storage. The agent runtime, the part that reads email and calls tools, is described as a separate service launched after the audit period began. The report also carves out the model provider as a subservice organization. Two questions follow: is the agent runtime planned for the next audit, and what assurance does the model provider hold?

The vendor answers both openly. The runtime will be included in a later period, and the model provider's terms say customer content is not used for training. The buyer does not walk away. It proceeds with a narrower pilot: read-only access to the inbox, no sending without approval, and a clause that requires notice if sub-processors change. The certificate was not wrong. It simply described less than the buyer first assumed.

A five-step review plan before you sign

A review does not need to be long. It needs to be ordered, with owners. This plan fits a mid-sized company where legal, IT and operations share the work.

• Step 1: Request the SOC 2 report or ISO certificate, the scope statement and, for ISO, the Statement of Applicability, under a confidentiality agreement if needed.
• Step 2: Run the reading checklist above and write down every gap between the scope and the product you plan to use.
• Step 3: Send the five question groups in writing and ask for answers that can be attached to the contract.
• Step 4: Test what you can. Ask for a demonstration of logging, permission settings and data deletion rather than accepting a description. The guide on testing an AI vendor's claims shows how.
• Step 5: Decide the starting boundary: which data, which tools, which actions need approval. Review it after the first period of real use.

Who checks what also matters. Legal looks at data terms and liability, IT at access and integration, finance at commercial terms. The procurement review breakdown sets out those roles in more detail.

How Be Human approaches assurance in a managed engagement

Be Human does not treat a vendor's certificate as the end of the review. In a managed engagement, we help the client document which providers sit in the stack, what data each one receives, and which assurances each one has published. We define the agent's role, tool access and approval boundaries with the client, keep logs reviewable, and schedule permission reviews so access does not drift. The client keeps control of the boundaries. The shared responsibility model describes where the provider's duties end and the company's begin.

Frequently asked questions

Is SOC 2 or ISO 27001 better for an AI vendor? Neither is better in every case. SOC 2 gives you a detailed report with tested controls, which is easier to inspect, while ISO 27001 shows a managed security system and is widely recognized across regions. What matters more is whether the scope includes the exact product you will use.

Does a SOC 2 report mean my data will not be used for model training? No. The report examines security and related controls, not the commercial terms about training. Ask for the training and retention policy of both the vendor and any model provider behind it, and get the answer into the contract.

What if a promising AI vendor has no certification yet? Many young vendors are still working toward one. Ask whether an audit is planned and for which scope, then compensate with narrower access, a limited pilot, stronger contract terms and direct testing of logging and deletion. Do not read the absence as proof of poor practice or the presence as proof of good practice.

How often should I revisit a vendor's assurance? Review it when the report or certificate is renewed, when the vendor adds a new product or sub-processor, and when your own use expands. A short annual check against the original checklist is usually enough for stable setups, with an extra review whenever the agent gains new permissions.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.