AI SaaS security questionnaire template

An AI SaaS security questionnaire template is useful when it helps you connect each buyer question to evidence about your actual product. Use the worksheet below to prepare answers about AI providers, customer data, storage, isolation and deletion. Leave unsupported answers open instead of filling them with reassuring language.

At a glance

• Name the product, production environment and data flow before answering.
• Keep provider policy, account configuration and application behavior separate.
• Give every answer an evidence reference, observation date and scope limit.
• Use “not observable” when the necessary evidence is unavailable.
• Share a reviewed summary; keep credentials and sensitive implementation details private.

What belongs in the questionnaire?

An AI SaaS security questionnaire template should contain a question, a scoped answer, supporting evidence, a responsible owner and the date the evidence was checked. Add a separate field for unresolved gaps. A yes/no checkbox alone leaves the reviewer without the context needed to assess the answer.

Start with the questionnaire the buyer actually sent. Preserve its question identifiers and required response format, then use this worksheet to organize your supporting material. You do not need to replace the buyer's document with another framework.

For a broader cloud-control questionnaire, the Cloud Security Alliance publishes CAIQ v4.1. The worksheet here is narrower: it focuses on technical evidence for AI SaaS data-handling questions. It is an original working aid, not the CAIQ, an audit opinion or a certification.

Record which product and deployment you mean. An answer about a development environment should not silently become an answer about production. Likewise, a provider's general documentation should not become a statement that your particular account has an optional control enabled.

Copy the evidence worksheet

Use these seven rows as a starting point. The evidence examples describe what to collect; they are not pre-filled claims about your company. Add the buyer's other questions separately.

The downloadable CSV includes these fields for each row: answer, status, evidence reference, owner, checked on, limitations, next action. Give the evidence reference a stable identifier so the response can be traced without embedding the entire underlying artifact.

Use plain status labels such as supported, partially supported, not observable and not applicable. Reserve “not applicable” for a documented scope reason. A missing control and an irrelevant control are different situations and should have different explanations.

The evidence-to-answer mapping is the point of the worksheet. A polished answer without a traceable basis remains difficult to review. TrustData's technical methodology likewise distinguishes observable evidence from founder declarations and records limitations when evidence cannot be obtained.

Fill in one data flow at a time

Start with the system you can inspect, then write the narrowest answer that its evidence supports. Complete one data flow before moving to the next. Avoid starting with the answer you would like the buyer to hear.

First, identify the relevant production feature. For an AI document assistant, that might include an upload, extraction step, model request, stored response and deletion path. This is a hypothetical example, not a description of a verified customer deployment.

Second, gather evidence for each component in that flow. Record where the evidence came from and what it establishes. A configuration record can show a setting; a test can show the result for the path exercised. Neither automatically describes every path in the product.

Third, write the response beside the evidence. Prefer a bounded description such as “the tested customer role could not read the second test tenant's record” over an unqualified claim that all customer data is isolated. Keep the test environment and limitations visible.

For Supabase, consult the RLS documentation and inspect the policies and authorization context involved in the request. A test using a privileged database role does not establish the behavior of an ordinary customer request.

For GitHub webhooks, the validation documentation describes checking signatures with a webhook secret. Your evidence should address the actual receiver and how it rejects invalid deliveries. A provider offering signatures does not prove your application validates them.

What can provider policies prove?

Provider policies establish published terms and documented service behavior within their stated scope. Provider policies alone do not establish your application's configuration, all account-specific agreements, or how your own database stores customer content.

OpenAI's data controls distinguish model-training use, abuse-monitoring logs and endpoint application state. The documentation says API data is not used for model training by default unless sharing is opted into. That statement should not be shortened into “the API stores nothing.”

Anthropic's retention guidance describes a standard API retention timeframe with exceptions, including some services, separate agreements, enforcement and legal requirements. Check the service your product actually uses before applying a general statement to it.

Keep three evidence fields separate: the policy you read, the account setting you could verify and the application behavior you inspected. If one is unavailable, leave that field unresolved. Also record the date you checked the policy so a later reviewer can identify an outdated answer.

Your own storage needs its own explanation. A provider-side retention control does not describe whether your application saves prompts, responses or uploaded files elsewhere in the data flow. Trace those stores independently in the worksheet.

How should you record an unverified answer?

Record an unverified answer by naming the missing evidence, limiting the claim and assigning a next action. “Not observable” is useful when a setting or fact cannot be checked through the available access. It should not disguise a control you know has failed.

For example, a hypothetical response could say: “The provider's published policy has been reviewed. The account-specific retention setting has not been verified. The account owner will confirm the applicable configuration before we make a claim about it.” Adapt the wording to the actual facts.

Do not invent a completion date or imply that a planned change already exists. Keep the current answer and the remediation plan in separate fields. When new evidence arrives, update the answer and retain enough history to explain the change.

Broader AI risks may need separate work. The OWASP risk list includes concerns such as prompt injection and excessive agency that this data-handling worksheet does not fully assess. The voluntary NIST AI RMF provides broader risk-management guidance; citing it is not proof that a particular control operates.

Before you share the buyer response

Read the completed response as if you were the buyer. Can you identify the product, understand what was checked, locate the supporting reference and see the remaining uncertainty? Remove any sentence that claims more than the evidence establishes.

Use the public vs private trust center guide to decide which supporting documents belong with which audience. Keep the buyer-facing summary separate from private implementation material. Review attachments for secrets, customer content and unnecessary source details. Share the relevant conclusion and its scope, then arrange an appropriate review of supporting material when needed.

If your product fits TrustData's supported stack, you can start with a private product check and review what is observable before choosing what to share. The publication plans concern sharing and monitoring; payment does not turn an unsupported technical answer into a verified one.

Choose an owner for the worksheet and revisit it when the deployment, provider, endpoint or data flow changes. Reuse the evidence that is still applicable, replace what has changed, and keep each answer tied to the product the buyer is evaluating.