Is a SOC 2 or ISO 27001 certification enough on its own?

No. A certification tells you a vendor's general practices meet a defined standard — it doesn't tell you how the specific system built for you behaves. A certified vendor can still hand an agent an admin-level credential and no audit log if nobody asks the project-specific questions. Treat a badge as a starting point, not a substitute for this checklist.

We're not in a regulated industry — do we still need to ask these questions?

Yes. HIPAA, PCI, and similar rules raise the stakes, but the underlying risks — broad access, no audit trail, no defined failure behavior — exist in any AI system handling real customer data or taking real actions, regulated industry or not. The cost of skipping the questions shows up later, as an incident, rather than as a compliance finding.

What's a sub-processor, and why does it matter more than people think?

A sub-processor is any third-party service a vendor relies on to deliver their product — a model provider, a hosting platform, a transcription service. Your data can pass through several of them without you ever dealing with them directly, and a vendor's own security promises don't cover what happens once data leaves their hands and enters a sub-processor's system.

What if a vendor won't answer these questions directly?

Treat that as the answer. A vendor who deflects to a certification, a generic security PDF, or "trust us, we're secure" either hasn't mapped their own system this closely or would rather you didn't look. Either reason is worth knowing before you sign, not after.

How long should this review take?

A vendor who has genuinely built with these questions in mind can walk through most of them on one call. If it's taking multiple rounds of escalation to get straight answers to basic questions about data and access, that's useful information about what working with them will be like once something actually goes wrong. Bring this checklist to your next vendor call — ours included — and use it on us too. Book a free 30-minute strategy call and we'll answer every question on it specifically, system by system, rather than pointing you at a badge.

AI Vendor Security Checklist

The short answer

A good vendor can answer every question below in plain language, specific to what they'd actually build for you, in one conversation. A vendor who can't — who redirects to a certification, a generic PDF, or "our platform is fully secure" — has told you something important even if they don't realize it. None of these questions require you to understand the underlying technology. They require the vendor to explain their own system clearly enough that a non-technical buyer can follow the answer and notice when it doesn't hold together.

The questions cluster into six groups: where your data goes, what the system can access, whether you can reconstruct what it did, what happens when it's unsure, the risks unique to AI systems that a standard IT questionnaire never asks about, and who owns what when the contract ends. None of them are exotic. All of them get skipped more often than they should, usually because the conversation stops at a badge instead of continuing into the specifics.

Why a certification isn't the same as an answer

Certifications like SOC 2, ISO 27001, HIPAA, or PCI DSS are worth something — they mean an outside auditor checked that a vendor's general controls meet a defined standard. What they don't tell you is how a specific system, built for you, actually behaves. A vendor can hold a real certification and still hand the AI agent they build you an admin-level credential and no audit log, because the certification covers the company's baseline practices, not the judgment calls made on your particular project. Asking "are you certified" is a fair question. It is not a substitute for asking the questions in this guide, and a vendor who treats it as one is skipping the part that actually protects you.

This matters just as much on the buyer's side of the table. We don't hold SOC 2, ISO 27001, HIPAA, PCI, or Cyber Essentials certification ourselves, and we say so plainly on our security page rather than let a sales conversation imply otherwise. What we do instead is answer these exact questions, system by system, for every engagement, and walk through them as part of how a project actually runs rather than as a one-time sales document. A vendor without a badge who answers every question below concretely is often a safer choice than one with a badge who can't.

Data handling: where does your information actually go

This is the group most buyers think they've covered by asking "is our data safe," which isn't specific enough to get a useful answer. Ask instead:

Where does our data go once it enters the system? A good answer names the actual systems and services involved — this database, that model provider, this hosting region — not "our secure cloud infrastructure." A vague answer usually means nobody has mapped it.
Is our data used to train or improve your models? A good answer is a direct yes or no, with the setting that controls it named specifically. A bad answer is "we take privacy seriously," which answers a different question.
How long is our data retained, and can we get it deleted on request? A good vendor can state a retention period and describe what deletion actually removes — logs, backups, cached copies included. "We'll look into that" during a sales call is a preview of the support experience you'll get after you sign.
Which sub-processors are involved? This is the question buyers forget most often, and it's the one that matters most. Almost no AI system is one company end to end — there's usually a model provider, a hosting platform, sometimes a transcription or embedding service, sometimes a monitoring tool, each of which sees some slice of your data. A vendor's own policies don't cover what a sub-processor does with what passes through it. A good answer names the sub-processors and what each one sees. A vendor who has never been asked this will often need to go check — which tells you the mapping doesn't exist yet, not just that they haven't recited it before.

Access: what does the system need, and why

Every AI system needs credentials to do its job — the question is whether it needs the credentials it's actually been given.

What can this system do with the access it has? A good answer maps directly to the job: read access to a calendar for a scheduling agent, not write access to your entire CRM. A bad answer is an admin account "to keep setup simple," which trades a day of configuration time for an open-ended risk that outlives the project.
Is that the minimum access the task requires, or the easiest access to set up? These are often different, and a vendor who has genuinely thought about it can explain the gap between them and why they landed where they did.
How are credentials stored, and are they rotated? A good answer describes a secrets management practice and a rotation cadence. "They're in the code" or "we haven't needed to change them" are answers worth writing down verbatim before you decide anything.
Can access be revoked immediately, from your side, without the vendor's cooperation? If the only way to cut off a system is to ask the vendor nicely and wait, that's a dependency worth knowing about before launch, not after a dispute.

Auditability: can you reconstruct what happened

An AI system that takes actions — drafting messages, updating records, moving money, closing tickets — needs to leave a trail good enough to answer "why did it do that" three months later, after everyone involved has forgotten the details.

What gets logged, and for how long? A good answer covers every consequential action, not just errors, and states how long the logs are kept. A system that only logs failures can't explain the actions that succeeded and shouldn't have.
Can you show us, concretely, what the system did on a specific ticket or transaction? Ask for this during evaluation, not after go-live. A vendor who can pull up a real trace in the demo has built the thing you're asking about. A vendor who has to build a report first hasn't.
Is the log tamper-evident? For anything touching money, compliance, or customer disputes, a log that could plausibly be edited after the fact isn't much of a log.
Who inside the vendor's organization can see our data and our logs, and is that access itself tracked? The audit trail has to cover the vendor's own staff, not only the AI system.

Failure behavior: what happens when it's unsure

This is where a lot of AI deployments get quietly dangerous — not because the system is wrong often, but because nobody defined what it should do when it doesn't know.

What does the system do when it's not confident in an answer? A good answer describes a specific behavior — escalate, ask a clarifying question, decline to act — not "it's usually right." Confidence in the sales pitch is not the same as the system knowing when to stop.
What can it do without a human in the loop, and what always requires approval? A good vendor draws this line deliberately, usually putting anything touching money, contracts, or an external customer relationship behind a human check until the system has a track record. A vendor who hasn't drawn the line at all hasn't thought about failure, only about success.
How do we stop it — right now, mid-task, without a support ticket? You need a kill switch you control, not a promise that the vendor will respond quickly if you email them.
What happens to the work already in progress when it's stopped? Ask what a half-completed action leaves behind — a partially updated record, a half-sent message — and how that gets cleaned up.

The AI-specific risks a standard questionnaire misses

A generic IT security questionnaire was written for software that doesn't read untrusted text and decide what to do next. An AI agent does exactly that, which creates a handful of risks that don't show up on the standard form at all.

Prompt injection. If the system reads content it didn't write — an inbound email, a web page, a document someone uploaded, a customer's message — that content can contain instructions aimed at the AI itself, not at you. Ask what stops the system from following instructions buried inside data it's supposed to be merely reading. A good answer describes specific boundaries between "content to process" and "instructions to follow." A bad answer is "our model is trained to resist that," stated with no further detail.
Data leaking across boundaries. In a multi-tenant product, ask what actually stops one customer's data from surfacing in another customer's session — and inside your own organization, what stops the system from pulling information across a permission boundary a human user would respect. A good answer names the isolation mechanism. A bad answer assumes the question is about hacking rather than about the system doing exactly what it was built to do, just across the wrong boundary.
Confident answers without grounding. Ask what stops the system from stating something as fact when it doesn't actually know. A good answer describes how outputs are tied back to real data — a lookup, a document, a record — rather than generated from a general impression of what a plausible answer sounds like. A bad answer treats "it's usually accurate" as sufficient for a system your customers or staff will rely on.

None of these three show up on a checklist built for traditional software, because traditional software doesn't read arbitrary text and act on it. Any vendor selling you an AI system should be able to talk through all three without treating them as edge cases.

The commercial questions

Security and ownership are related more than most vendor conversations admit — who controls the code and the configuration determines how much of your own risk posture you actually control.

Who owns the code and the configuration once it's built? A good answer is unambiguous. If the honest answer is "we do," ask what that means for your ability to change providers later.
What happens to the system and our data at the end of the contract? A good vendor can state this before you sign, not negotiate it after you've decided to leave. Ask specifically about data export, deletion timelines, and whether the running system stops immediately or keeps operating on your data after the relationship ends.
Could we run this ourselves, or does it only exist inside the vendor's platform? You don't have to choose self-hosting to ask the question. The answer tells you how dependent the system is on one company continuing to exist, price fairly, and stay interested in your account size.
What's the clear price for changes after launch, not just for the initial build? A vendor who can't describe how ongoing changes get scoped and priced is asking you to sign an open-ended commitment.

A checklist you can bring to your next vendor call

Print this, or paste it into the email you send before the call:

Where does our data go, system by system, once it enters yours?
Is our data used for model training, and is that setting something we control?
What's the retention period, and can we get verified deletion on request?
Which sub-processors touch our data, and what does each one see?
What access does the system have, and is it the minimum the task requires?
How are credentials stored and rotated?
Can we revoke access ourselves, immediately, without the vendor's involvement?
What gets logged, for how long, and can you show us a real example right now?
What does the system do when it's not confident?
What can it do without a human, and what always needs approval?
How do we stop it mid-task, and what happens to unfinished work?
What stops it from following instructions hidden inside content it's only meant to read?
What isolates our data from other customers, and across our own internal permission boundaries?
What stops it from stating something as fact when it isn't grounded in real data?
Who owns the code and configuration, and what happens to both at the end of the contract?

If a vendor answers all fifteen clearly and specifically, that's a strong signal regardless of what badges sit on their homepage. This same rigor is worth applying before any AI project starts, which is part of why we treat vendor and architecture review as a normal part of an AI strategy engagement rather than an afterthought — and it pairs well with a broader look at how to choose an AI agency if you're still narrowing the shortlist.

The questions worth asking any AI vendor before you sign