AI Vendor Security Questionnaire: What InfoSec Will Ask

Created time

Sep 23, 2026 10:47 AM

Title length (<60)

Author

Mike Heap

Last optimised

Ecomm?

Why doesn't a standard security questionnaire work for an AI support agent?

⚡

TL;DR: The generic questionnaire is a company audit. It confirms the vendor has controls, a certificate and a contract, and every question on it is about the company you are contracting with.

Start with what the form gets right, because most of it is right. Nearly every questionnaire we answer is built from a published instrument, and the Cloud Security Alliance publishes one of the big ones: the Cloud Controls Matrix and the CAIQ. Their page says the CCM "is currently considered a de-facto standard for cloud security assurance and compliance." Your InfoSec colleague will call the exercise an AI vendor risk assessment, and every row on it asks about the supplier.

Those instruments answer the question they were built to answer. AICPA and CIMA describe SOC as "a suite of service offerings CPAs may provide in connection with system-level controls of a service organization or entity-level controls of other organizations." Read that and the subject is the service organization.

Our certificate, like every SOC 2 report, describes the company you are contracting with. The software is out of scope, and so is the agent inside it writing the replies.

An AI agent adds a risk class the form does not ask about. That class already has a published name. I use OWASP's framing for it, where LLM means the large language model writing your replies: "Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM".

OWASP gives three root causes: too much functionality, too many permissions, too much autonomy. It frames these as both a vendor-build and a buyer-rollout problem, and the rollout half is decided on your side, long after the form comes back.

Breakdown diagram titled 'Three root causes the standard form has no row for', showing excessive agency risk splitting into: too much functionality, too many permissions, and too much autonomy.

I keep coming back to this point because it is the one that surprises buyers. Your macros never invented a sentence, and this thing does, so a vendor can clear every line of your standard form, certified, contracted, encrypted and insured. The agent still has write access to your order system, or it can lift a paragraph out of an internal article and put it in a customer's inbox. The generic form asks about neither, which is why we get both questions after signature.

The published AI-specific guides on vendor questionnaires are written for the security function doing the assessing. They are long, sorted by domain, and scored. If you are the one who wants the tool, a longer form in somebody else's order is not much help.

We fill these in from the other side, and the questions already on the standard form take us minutes to answer. The ones a buyer adds to it, the ones that decide whether the agent gets switched on, take a longer email and usually a call.

If a colleague wants the underlying definitions, our post on AI customer service security and compliance covers SOC 2, GDPR and encryption at rest properly.

Which nine questions should an AI vendor security questionnaire ask?

⚡

TL;DR: The three-block questionnaire is nine questions across the company, your customers' data, and the agent itself. Your form mostly covers the first two blocks. The third is the one that decides this.

The three-block questionnaire is how I work through every form we answer. Nine questions cover the ground, and two of the words in them come from your reviewer. A DPA is the data processing agreement you sign with a vendor. Sub-processor is the reviewer's word for any other company that handles your customers' data on that vendor's behalf (for us, that starts with the model providers).

Two-column comparison titled 'Six your form mostly covers, three you add'. Left column, 'Mostly on your standard form', questions 1 to 6: SOC 2 Type II certification, DPA and sub-processor list, Outage and status page, Data training policy, Data location and access, Model provider retention. Right column, 'Add these three', questions 7 to 9: What can the agent see?, What can the agent do to your systems?, How fast can you switch it off?

Question	What a good answer sounds like	What should worry you
Are you SOC 2 Type II certified today, or going through it?	Certified today, with a named report and a named route to reading it	Aligned, ready, in progress, or a date some time next year
Will you sign our DPA, and who else touches our data?	Yes, here is the DPA, and here is the current sub-processor list	A DPA on request, and nothing about who else is in scope
What happens to our tickets when you have an outage?	A public status page, plus an availability commitment	Reassurance with nothing published behind it
Does our data train your AI, or anyone else's?	No, and it is written into the contract	Only aggregated, only to improve the service, or an opt-out you have to find
Where does our customers' data sit, and who at your company can read it?	A named location, a named encryption standard, and who has access	A general statement, with no specifics and no contract language
What do you send to the model providers, and what do they keep?	Which providers, what is sent, and how long each one holds it	We do not train on your data, offered as the entire answer
What can the agent see, and can it show a customer something it shouldn't?	You can mark a source internal-only, and see which source any reply came from	Everything you connect is treated the same way
What can the agent do to our systems, beyond what it says to our customers?	A written list of actions, each one switchable on its own	A capability list with no off switch described
How do we watch it, and how fast can we switch it off?	A draft mode before it replies directly, a record of every reply, and one off switch	Oversight described as a reporting dashboard

Block one: the company

Your form already asks these three, so keep them and sharpen two.

1. Are you SOC 2 Type II certified today, or going through it?

The discriminating word is today, and it is easy to skip straight past, because SOC 2 aligned, SOC 2 ready and in progress are three different answers against one yes-or-no box. A Type II report covers controls that ran over a period rather than a point-in-time snapshot, so your reviewer can close the item.

Our answer is certified today. My AskAI holds SOC 2 Type II, and our live trust center shows the current state. Then ask the follow-up your standard form does not have: can we see the report, and on what terms?

2. Will you sign our DPA, and who else touches our data?

Those are one question, because the second half is what the DPA exists for. GDPR Article 28 requires a processor to have authorisation before engaging another, which is the basis of your entitlement to see a sub-processor list. Article 28(4) adds the liability rule, specifying that where a sub-processor fails its data protection obligations, "the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations."

So the sub-processor list is something you are entitled to see, and a vendor who cannot produce one on request is telling you the list has never been written down. Ask for it by name, and check the model providers are on it, because that is where your ticket text actually goes.

3. What happens to our tickets when you have an outage?

One operational question belongs in a security review, because availability is the failure your team feels. An agent that goes down on a Saturday builds a backlog nobody sees until Monday, and your first reply time wears it.

A public status page is most of the answer, and ours is public. Our Enterprise plan adds a contractual 99.99% uptime commitment.

Block one takes minutes, and you can settle it yourself before the form goes anywhere.

Block two: your customers' data

Your standard form asks some of this, and one question is missing from almost every version I see.

4. Does our data train your AI, or anyone else's?

This is the easiest one to settle, and it takes two answers. The technique behind most AI support agents is called RAG (retrieval-augmented generation): it looks up your help articles when a customer asks, and uses them to build the reply, with no model retraining.

But RAG architecture is separate from a vendor's contractual commitment not to train on customer data at all, so check both. A vendor can be accurate about RAG and still reserve the right to train in the contract.

A hedge is the answer to chase, and the hedges are consistent: only aggregated, only to improve the service, only unless you opt out. Our answer is no. Customer data is never used for model training, that commitment is written into the contract, and each customer sits in an isolated container.

5. Where does our customers' data sit, and who at your company can read it?

Ask this one early, because the answer has two halves and the form field has room for one. A good answer names a location, says whether it can be pinned, and names the route to a contractual version. It also says who at the vendor can read your tickets.

My AskAI encrypts data at rest with AES-256 and in transit with TLS. Residency we treat as a DPA clause, so the trust center states where we stand today and the contract is what fixes it.

6. What do you send to the model providers, and what do they keep?

The standard form rarely has this one, though a reviewer asking about training is reaching for it. The gap is retention: how long each model provider holds what you send, and under what terms.

OpenAI's data page states that "data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)." The same page says: "By default, abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law, or is reasonably necessary to protect our services or any third party from harm." Anthropic's commercial terms say "Anthropic may not train models on Customer Content from Services."

Neither page describes the support vendor you are buying from, so ask yours for their version: which providers, what is sent, and the retention term each applies. We are multi-model, so our answer has to name more than one provider and a retention term that covers all of them. The list changes as we benchmark, so I hand the current one over in the review.

Across both questions in this block the answer you want is one sentence, and we give the same one: never trained on, never sold, and isolated per customer. The hedges in question four and the retention terms in question six are where that sentence usually breaks.

Block three: the agent itself

The three questions in this block decide whether the agent is safe to switch on, and each one needs an answer from the vendor before you go live.

7. What can the agent see, and can it show a customer something it shouldn't?

Your help center is public, and the agent is usually reading more than that, because internal runbooks and historic tickets are what make it good. Ask for two things: the ability to mark a source internal-only, and a way to see which source a reply was built from.

With My AskAI you can mark a document internal-only, and it stops showing up in customer replies while still informing your team's internal answers. Echo, our in-dashboard agent, is where your team asks why a reply came out that way.

8. What can the agent do to our systems, beyond what it says to our customers?

An agent that only reads can give a wrong answer, and an agent wired to act can change a real order, issue a refund, or update an account. Ask for a written list of the actions it can take, and whether each can be turned off on its own.

Video preview — AI Agent Tasks & Tools (Refunds, Orders)

Our answer: the agent acts through Tasks and Tools for actions, and reads live customer data through the User Data API. Tasks and Tools each carry a per-action approval toggle, so each action can run on its own or as a proposal a human approves. So you can have it look up an order and keep refunds as something a person signs off. Our post on adding AI to an existing helpdesk covers what it ends up wired into.

9. How do we watch it, and how fast can we switch it off?

If the agent runs in draft mode first, and one person can stop it without a developer, you have two facts a reviewer can sign off against. OWASP's prevention guidance for excessive agency asks for "human-in-the-loop control to require a human to approve high-impact actions".

With us, the agent can write every reply as an internal note first, so your team reads what it would have sent. When it goes direct, it hands over inside the same helpdesk with a written summary and stops replying until it is handed back. On most helpdesks the human can hand it back to the agent; on HubSpot the handover is one-way.

Every conversation keeps a record of the knowledge used. Our post on AI confidence thresholds and handoff covers what it should do when it is unsure.

Block three is the part your standard form does not cover, so the answers have to come from us, and from every other vendor you shortlist.

What does this look like in a real security review?

⚡

TL;DR: A certificate tells you the vendor has a management system. Every rollout below turned on what the agent could reach and what it was allowed to do, and both were set by the customer during the rollout.

We learned block three from these four rollouts. In every one the lever was the same: live account or order data the agent could read. More of them are written up in our case study posts.

Rollout	Helpdesk	What the agent could read	Result	Question it answers
Edel Optics	Zendesk	Live order, delivery and return data	20-30% to 75-79% resolution, 92% CSAT	Question five
RecruitCRM	Intercom	Plan, recent transactions, account events	68% resolution, 62 hours saved monthly	Questions five and six
YouGarden	Freshdesk	Recent orders, purchases, delivery information	66% resolution, 78% CSAT	Question nine
An iGaming operator	Intercom	Live player data, through two payments Tasks	44% resolution, 32% escalation (last 30 days, progressive rollout)	Question eight

Edel Optics: 20-30% to 75-79% resolution

Edel Optics sell designer eyewear across 53 countries on Zendesk, and their agent started before it could read live order data and resolved 20-30% of tickets. Connecting live order, delivery and return data lifted that to 75-79%, across roughly 4,000 tickets a month at 92% CSAT.

That is a block two story, because the change was in the data the agent could reach, and all of it was customer data. It is question five, and your standard form asks it too broadly to catch this, so we answer that one by naming the connected data sources.

RecruitCRM: 68% resolution, 62 hours a month

RecruitCRM run a recruitment platform on Intercom, and their agent went from about 35% resolution at go-live to 68%, saving 62 hours of agent time a month.

The lever again was live account data: plan, recent transactions, account events. That is customer data flowing into a reply, so a reviewer should want to know where it goes and who else touches it. Questions five and six are where that belongs, and we answer both, though only question five is already on your standard form.

YouGarden: 66% AI resolution, 78% CSAT

YouGarden handle about 12,000 tickets a month on Freshdesk, at 66% AI resolution, with 78% CSAT measured across 11,785 tickets. Order status questions are part of that mix, so the agent reads recent orders, purchases and delivery information through a custom data connection.

They ran in Freshdesk notes mode for a month, reading what our agent would have sent, before switching to direct replies. That is question nine answered as a rollout plan, so ask any vendor whether their agent can do the same.

An iGaming operator: two payments Tasks, 55% of the mix

A high-volume casino and sportsbook, anonymized, runs on Intercom. In the last 30 days of a progressive rollout, two payments Tasks read live player data and covered 55% of the ticket mix, with 44% AI resolution across 4,687 conversations and 32% escalation.

This one is block three, and the agent reads real money-related account state and decides what to say about it, with a third of chats routed to a person. Which Tasks are live, what each one reads, and who turns them off are the three things worth writing into the form, and I have been on the rollout call where all three came up, weeks after the form came back clean.

The review itself

The reviewer usually appears two to four weeks into a trial, sent in by whoever holds the budget. Their job is to approve or block, and a deal the champion and the budget holder have both said yes to can still end here.

Most of the exchange happens by email, with one session if the thread stops converging. A well-run one is short, twenty minutes or so. The fastest sessions we join are the ones where the support lead arrives with the agent questions already written down.

Forms vary. Safe Security's own guidance says no single template fits every vendor relationship, and that right-sizing by vendor risk is normal. The AI-specific published guides that do ask the agent questions (Reco's forty-question set and Atlas Systems' control-verification version) are written for the reviewer. Reco's set exists because a vendor can pass a standard assessment and still carry a materially different risk.

In the reviews we have been through, a stall is usually one of two things. Either a document is requested that the vendor cannot produce quickly, or a question comes up about what the agent is allowed to do and nobody in the room owns the answer. The first is a vendor problem, and the second is usually a rollout decision nobody has made yet.

The My AskAI trust center page, headed 'My AskAI Trust Center', with a 'See compliance' button and the start of a Compliance section.

What should you do this week?

⚡

TL;DR: Answer block one yourself before you send anything, and add the block-three questions to the form at the same time. Neither of those needs the vendor's permission.

Close block one before the form goes anywhere - about half an hour with the vendor's security page and trust center open. Certification status, DPA availability, status page. Outcome: your reviewer opens the form with the first three rows already answered, and on our side that is the single thing that makes a review short.

Add the three block-three questions by hand - ten minutes, typed straight into the spreadsheet. Outcome: the answers come back in writing.

Ask what the agent can do, and who switches it off - five minutes to send, then the wait is on the vendor. Outcome: you know what the agent can change before you know what it costs, and from us that reply comes back as a written list where we can confirm it. Read it against OWASP's excessive agency entry if you want a second opinion.

Put block three on the technical agenda - the session itself takes about twenty minutes. Outcome: the time goes on the part of the review nobody has answered yet.

Do all four in the week you start the trial, because doing them in the week the vendor asks for a decision turns the review itself into the delay. Our vendor selection checklist covers the wider buying decision, the downloadable version is the form you can hand round, and the 30-60-90 day plan shows where the review comes in the rollout.

Process flow titled 'Start the review in the same week as the trial', showing four steps: 1. Close block one yourself, 2. Add the block-three questions by hand, 3. Ask what it can do, and who stops it, 4. Put block three on the technical agenda.

If you want to run these four against us, our certification status and our status page are both published, our own security answers are written up in one place, and the three block-three answers are in questions seven, eight and nine above. Your reviewer will also want the AICPA's description of what a SOC report covers and GDPR Article 28 to hand, because together they define what the first two blocks can tell you. You will still need to add block three to the form yourself.

How do I get AI to fill the gaps in our questionnaire?

Steps two and three are the ones that take the typing, and I hand that part to an AI. Paste your current form and whatever the vendor has sent so far into the prompt below, and you get back the missing rows plus a read on the answers you already hold.

You are helping me review an AI customer support vendor's security answers.

Our current vendor security questionnaire: [paste the questionnaire, or list the rows it already has]
The vendor and what they have sent us so far: [paste their replies, trust center links, DPA status, certification status]
Our setup: [helpdesk, monthly ticket volume, and whether the agent will be allowed to take actions in our systems]

Do three things.

1. Map our existing rows onto the three-block questionnaire.
   Block one, the company: are they certified today rather than aligned or in progress; will they sign our DPA and who else touches our data; what happens to our tickets during an outage.
   Block two, our customers' data: does our data train their AI or anyone else's; where does our customers' data sit and who at their company can read it; what do they send to the model providers and what do those providers keep.
   Block three, the agent: what can the agent see and can it show a customer something it shouldn't; what can it do to our systems beyond what it says to customers; how do we watch it and how fast can we switch it off.
   Tell me which of the nine we already ask, and which we do not.

2. Write every missing question as a row I can paste straight into the spreadsheet, worded for the vendor to answer.

3. Grade each answer the vendor has already given as strong, thin or missing, and say what to ask next for anything that is not strong.

Output one table with these columns: Block | Question | Do we ask it today | Vendor's answer so far | Strong, thin or missing | What to ask next.

Rules: use only the text I pasted. Where the vendor has not answered, write "unverified, ask the vendor" rather than guessing. Never assume a vendor holds a certificate, will sign a DPA, or publishes a sub-processor list unless the text I gave you says so. Desk work cannot judge whether the agent behaves as described, so keep block three as questions to put to the vendor in writing.

When does this not apply?

⚡

TL;DR: Three cases. No security function to satisfy, a procurement policy that already sets a harder bar than any questionnaire, and an agent that can only read.

Below roughly fifty people there is often no security function at all, so the person choosing the tool also signs for it, and the review is a link to a trust center and twenty minutes of reading. Running a nine-question process against yourself is theater, so read block three, ask the vendor the two questions that apply to your setup, and get on with the trial.

The second case is a buyer whose procurement policy already sets a higher bar than any questionnaire, which is common in regulated industries and is the one case where our answers change nothing. The policy names what a supplier must hold, the shortlist is settled before the form goes out, and the questionnaire confirms a decision the policy already made.

If that is you, start with the policy and shortlist against it, because the form cannot help, a longer version of it cannot either, and neither can we.

In the third case an agent that only reads has a much smaller block three. No writes, no actions, no connection to anything transactional, so question eight shrinks to a sentence and question nine becomes a content question.

OWASP's advice on minimizing extension permissions points the same way, and its worked example is an agent that needs read access to one table and no ability to insert, update or delete.

I agree with the reviewer who calls block three overkill for a read-only agent. A month in notes mode, as YouGarden ran it, answers question nine on its own. Question seven is the one I still put in writing.

The takeaway

⚡

TL;DR: Keep the form. Add the third block. The company and data questions tell you whether the vendor is safe to contract with, and the agent questions are the ones that tell you whether the agent is safe to switch on.

Your questionnaire audits a company well, so keep sending it. The software that will be reading your customers' tickets and writing back needs a review of its own.

The three-block questionnaire fixes that with nine questions: block one is the company, block two is your customers' data, and block three is the agent itself. Your standard form covers most of the first two, and block three is the one you add yourself, typically two to four weeks into the trial when the reviewer arrives.

If you do one thing, write those three questions into the form before you send it: what can the agent see, what can it do, and how fast can we switch it off?

Four things are worth having open before your next review. Start with OWASP's excessive agency entry and NIST's AI Risk Management Framework. AICPA's description of the SOC suite explains why the first block stops where it does, and our roundup of SOC 2 compliant AI customer service tools answers the which-vendors-clear-it question. Our own answers to all nine are above, and My AskAI is where a trial starts if you want to test them against your own tickets.

FAQs

What security questions should I ask an AI customer support vendor?

Nine, in three blocks, and they are the nine we answer from the vendor side of the form. Block one is the company: certification today, the DPA and sub-processor list, and what happens to your tickets in an outage. Block two is your customers' data: training, where it sits and who can read it, and what goes to the model providers. Block three is the agent itself: what it can see, what it can do to your systems, and how fast you can switch it off.

Our InfoSec team sent a security questionnaire to an AI support vendor: what should the answers look like?

I read each answer against a good version and a worrying version. Good is certified today with a named report, a flat no on training written into the contract, named providers with named retention terms, and a written list of actions each switchable on its own. Worrying is aligned or in progress, a hedge about aggregated data, and a capability list with no off switch described. A vendor who has answered the question before gives you a specific artifact and a route to it, while one who has not gives you reassurance.

How do I get an AI customer service tool through our security review?

Close block one yourself before the form leaves your desk, because in the reviews we answer, the ones that move are the ones that start with documents, and certification status and status page are both published and findable in about twenty minutes. Then put block three in writing, and book one short technical session with those three questions on the agenda. Safe Security's guidance tells the reviewer to right-size the form to each vendor's risk.

What does an AI support vendor need to provide for vendor due diligence?

Six artifacts, and the sixth is the one I would add to any standard pack: current certification status, the report itself with reading terms, a signed DPA, a current sub-processor list covering the model providers, a trust center your reviewer can check without emailing anybody, and a written list of the actions the agent can take in your systems. The first five are standard. Under GDPR Article 28 a processor cannot engage another without your authorisation, and has to tell you about any addition or replacement. A sub-processor list is therefore a general buyer entitlement, and any vendor who cannot produce one on request has not written it down. Ask for all six in one message, because a vendor who has answered these before will have them in one place.

Artifact	Why your reviewer wants it
Current certification status	Closes the first row before any call
The report, with its reading terms	Evidence the controls ran over a period, not just a point in time
A signed DPA	The contract that binds the processor
A current sub-processor list	Names every other company in scope
A trust center your reviewer can check	Removes a round of email from the review
A written list of the agent's actions	Shows what can change in your systems

Does an AI support agent train on our customer data?

This is the question I get asked most from the vendor side of the form, and the short answer is usually no. Most AI support agents look up your content and paste it into a prompt, with no model retraining involved. AWS describes RAG as working "all without the need to retrain the model." That is an architecture point about how RAG works. The privacy question is separate: does the vendor or any model provider use your data for training at all, and is that written into the contract? For My AskAI, your data is never used for model training, never sold to third parties, and never used for anything beyond serving your tickets, with each customer in an isolated container.

Where is our customer data stored if we use an AI support agent?

This question is on almost every security questionnaire, and the answer varies by vendor, which is exactly why it needs to go into writing and into the DPA. We encrypt data at rest with AES-256 and in transit with TLS, and whatever vendor you are evaluating, a complete written answer should name where data is held, confirm whether processing can be restricted to a particular region or cloud environment, and say who on the vendor's staff can read your tickets. Make sure the route to getting those terms into your DPA is also spelled out, because a verbal commitment that never reaches a contract is not a commitment at all.

Which security standards matter most when ai platforms are processing customer and deal data?

The two I get asked about answer different questions. A SOC 2 Type II report covers the vendor's controls over a period, a sustained test rather than a point-in-time snapshot, and AICPA puts the service organization itself at the center of what SOC covers. GDPR tells you what the vendor may do with personal data and who else may touch it. Both describe a management system, and neither tells you what the agent can read in your helpdesk, what it can change, or how fast you can stop it. NIST's AI Risk Management Framework is a public frame for governing AI risk that sits alongside them. The framework is under active revision, so check for the current version when you need it.

Standard	What a reviewer learns from it
SOC 2 Type II	The vendor's controls ran over a period, not just a snapshot
GDPR	What may be done with personal data, and by whom
NIST AI Risk Management Framework	A public frame for governing AI risk (under revision)

AI Vendor Security Questionnaire: What Your Security Team Will Ask

Why doesn't a standard security questionnaire work for an AI support agent?