AI Vendor Security Questionnaire: 21 Questions, Scored (XLSX + Web Tool)
By Ernest Provo, founderLast reviewed: 2026-08-28
An AI vendor security questionnaire earns its keep through structure, not question count: for every question you also need to know what a good answer looks like, what evidence to demand, the red flag that ends the conversation, the compensating control if the answer is weak, and the contract clause that locks the commitment in. As of 2026-08-28, this page carries all six columns for 21 questions across seven domains — scoreable in your browser, rendered in full below, and downloadable as a spreadsheet.
Download the questionnaire as XLSX — generated from the same source data as the table on this page, with score and notes columns ready for a vendor review. The full content stays on this page either way; the file is a convenience, not the asset.
How this relates to the Regulation S-P addendum
The Regulation S-P AI vendor due-diligence questionnaire is the adviser-specific instrument: ten questions tied clause-by-clause to the amended safeguards rule. This page is the cross-vertical superset — the same diligence discipline generalised to any regulated buyer, organised by security domain rather than by one rule, and extended with the evidence, red-flag, compensating-control, and contract columns. If you are a smaller adviser, send that addendum; if you are building a standing vendor-review process, start here and keep the addendum as the sector overlay.
Score a vendor as you read
Work through the 21 questions with the vendor's answers in front of you. Scoring is transparent — every question weighs the same, every answer is worth 0, 1, or 2 — and runs entirely in your browser: no network calls, nothing stored, nothing collected.
Score: 0 / 42 — 0 of 21 answered
Answer all 21 questions for a verdict. Nothing you select leaves this page — the scoring runs entirely in your browser and stores nothing.
The full questionnaire, annotated
Every question with all six columns. Each domain notes what the questions support or map to; the cross-linked guides carry the primary sources behind those references.
| ID | Question | Good answer looks like | Required evidence | Red flag | Compensating control | Contract clause |
|---|---|---|---|---|---|---|
| Data flow and subprocessorsMaps to service-provider oversight through due diligence and monitoring (17 CFR 248.30 for advisers) and to the eight-plane data-flow analysis in the zero-retention guide. | ||||||
| DF-1 | Provide a data map for a single request: every system prompts, outputs, and uploaded files transit or land on — conversation store, gateway, file store and extracted text, embeddings, monitoring, backups, audit log — with the operator of each. | A per-store table or diagram naming each plane, its operator, and its purpose — produced without a meeting to negotiate what counts. | A current data-flow document or architecture diagram, dated within the last twelve months. | "Everything is encrypted" offered in place of a map. Encryption answers a different question than where the data goes. | A contractual store inventory with quarterly review until a full diagram exists. | Vendor maintains a current data-flow inventory, provides it on request, and gives advance notice of material changes. |
| DF-2 | List every subprocessor that receives prompts, outputs, or files — including model and inference providers — with each party's retention window and training-use terms. | A named list including the inference layer, with per-party retention and no-training terms, not just hosting providers. | The subprocessor disclosure or contract exhibit, plus each subprocessor's applicable terms. | An undisclosed inference provider — the most common gap in AI vendor stacks. | Contractual flow-down of retention and no-training obligations to every subprocessor. | No new subprocessor for content-bearing services without prior notice and an objection right. |
| DF-3 | In which jurisdictions does each content-bearing store operate, and can the region be fixed for our tenant? | A region named per store, with region pinning available for the stores that hold content. | Region configuration documentation or a configuration export for a comparable tenant. | "Global infrastructure" with no per-store answer. | A contractual residency commitment for content-bearing stores. | Content-bearing stores operated only in the agreed regions; relocation is a material change. |
| Retention and deletionMaps to the retention crosswalk: every store keeps its own clock, and the schedule — not a vendor default — should set each one. | ||||||
| RD-1 | State the retention clock on each store from the data map — the default, whether it is configurable, and who controls it. | A store-by-store table: default retention, configurable or fixed, and the role that can change it. | Product settings documentation or a settings export showing per-store retention controls. | One number offered for the whole system. Different planes keep different clocks, and a single answer means nobody checked. | Contractual retention maximums per store where product controls do not yet exist. | Retention defaults and maximums fixed in the agreement; changes require customer consent. |
| RD-2 | When we delete data — or terminate — what is destroyed, in which stores, on what schedule? Include derived copies (extracted text, embeddings) and backups. | Named propagation: deletion removes the conversation, files, extracted text, and vectors, with backups aging out on a stated window. | The written deletion procedure and a receipt or log from an actual test deletion. | Deletion described only going forward, silent on backups and derived stores. | A shortened backup window, or store-level cryptographic erasure for content stores. | Deletion completes across all stores within a stated number of days, including backup age-out; termination triggers return and destruction. |
| RD-3 | Can scheduled disposal be suspended for a defined scope — a legal hold by workspace, user, or date range — and how is that done mechanically? | A hold mechanism that stops disposal for the defined scope in the product, not a manual promise. | Documentation or a demonstration of the hold control. | "We would handle that manually if it came up." A hold that is only an email does not stop a scheduled job. | A full export of the in-scope records at hold time, held by the customer. | Vendor implements holds within a stated number of hours of notice and confirms the scope in writing. |
| Logging and audit exportMaps to the audit log schema template and the ten-control audit-trail checklist: attribution, coverage, export, and access to the logs themselves. | ||||||
| LA-1 | Show a sample per-request audit record. Does it carry the authenticated user identity, timestamp, model identity, and event type — on every access path, including the API? | A real record with stable user identity from the identity provider, request-time model identity, and identical coverage for UI and API traffic. | A sample log record, plus confirmation that API and integration paths land in the same log. | A shared API key that makes every request look identical. | Customer-side gateway logging in front of the vendor until per-request attribution exists. | The audit-record field set is specified in the agreement as a service commitment. |
| LA-2 | Can we export audit records ourselves — date-ranged, machine-readable, without filing a support ticket — and how long does an export take? | Self-service, date-ranged export in a structured format, demonstrated live during evaluation. | One export actually run and timed during the evaluation. | Export requires the vendor's support queue. Their queue becomes your response time. | Scheduled automated exports delivered to customer-controlled storage. | Export capability and format guaranteed; records for any date range available within a stated number of hours. |
| LA-3 | Is access to the audit logs themselves role-gated, and do grants and revocations of that access appear in the trail? | Log visibility and export as specific permissions, with permission changes recorded as events. | The role matrix, plus a sample of access-grant events from the trail. | Every workspace user can read everyone's prompts. The log concentrates the most sensitive content in the system. | Contractually restrict log access to named administrators until role gating exists. | Audit-log access limited to customer-designated roles; vendor-side access to the logs is itself logged. |
| Isolation and deployment boundaryMaps to the deployment-boundary question every architecture review ends on: which stores you can inspect directly, versus oversee contractually. | ||||||
| IB-1 | Describe the tenant isolation model on the shared tier: how is our data scoped from other tenants, and how is the boundary tested? | A written description of logical isolation — per-tenant scoping or keys — plus evidence the boundary is exercised by testing. | Architecture documentation and a recent isolation-testing summary. | A cipher name as the whole answer. Encryption strength says nothing about tenant boundaries. | A dedicated-instance option where shared-tier isolation cannot be evidenced. | Isolation commitments stated in the agreement, with notification if the isolation boundary is breached. |
| IB-2 | For each deployment option you sell, which systems run in your infrastructure and which run in ours? Answer per store, not per product. | A plain two-column list per offering — runs-in-vendor versus runs-in-customer — covering every store from the data map. | The deployment architecture document for the specific option under evaluation. | "Private" used without saying which plane is private. Marketing language where a boundary list should be. | Contractual controls and review rights for the stores that remain vendor-side. | The deployment boundary is described in an exhibit; moving a store across it is a material change. |
| IB-3 | In your customer-hosted option, what still leaves our environment — telemetry, licensing, updates — and is that egress list documented? | An explicit egress inventory, even if the answer is short — named endpoints, purposes, and payloads. | The egress inventory or network policy documentation. | "No data leaves your environment" with undocumented telemetry underneath it. | An egress allowlist enforced at the customer's own network boundary. | Egress endpoints documented in the agreement; no new egress without notice. |
| Model and training useMaps to the two separate promises in the zero-retention guide — retention and training are different axes — and to model-risk change control. | ||||||
| MT-1 | Is our content used to train or improve models — by you or by anyone in your chain — and where is that commitment written? | A contractual no-training commitment covering the vendor and every subprocessor, or a precisely scoped statement of any improvement use. | The contract term, plus the flow-down to subprocessors. | A verbal no-training assurance while the standard terms reserve improvement rights. | A verified opt-out in account configuration, plus a contract addendum. | No training or fine-tuning on customer content by vendor or subprocessors, stated without carve-outs you have not approved. |
| MT-2 | What does the model provider retain at the inference layer, and under what terms? Include any abuse-monitoring carve-outs. | Named provider terms: no persistence beyond the request, with any abuse-monitoring retention disclosed and bounded. | The provider agreement excerpt or an attested configuration statement. | A retention promise that covers the vendor while nobody asked the model provider behind them. | An inference option inside the deployment boundary, where the provider plane is under direct control. | Inference-layer retention terms flowed into the customer agreement, not referenced as a third party's policy. |
| MT-3 | How are model changes controlled: can versions be pinned per workspace, and what notice do we get before a swap? | Version pinning for workspaces that need it, advance notice of changes, and a public model changelog. | The model catalog with versions, plus a past change notice. | "We always serve the best model." Silent swaps break evaluation results and reproducibility. | Request-time model identity in the audit log, so swaps are at least visible after the fact. | A stated notice period for model changes, with a pinning right for designated workspaces. |
| Incident responseMaps to the incident-notification and cooperation duties regulated customers carry — advisers, for example, need the 72-hour service-provider term the amended safeguards rule expects. | ||||||
| IR-1 | If you become aware of unauthorized access to a system holding our data, how fast do you notify us, and is that number in the contract? | A hard outer bound in writing — for example, as soon as possible and no later than 72 hours after awareness — with the notice contents named. | The contract clause and the vendor's incident-response summary. | "Without undue delay" with no number attached. | Customer-side monitoring and alerting on anomalous access, where the deployment allows it. | Notification no later than a stated number of hours after awareness, including scope, affected records, and a named contact. |
| IR-2 | During our investigation, what do you provide — affected records, access logs, timeline, scope determination — and on what clock? | A committed artifact list with response times, written down before any incident exists. | The incident runbook excerpt or a tabletop-exercise summary showing the artifacts produced. | "We will cooperate reasonably" with no artifacts and no clock. Every day of vendor lag is subtracted from your own notification deadlines. | A standing scheduled export of audit records, so the customer already holds its own evidence base. | Investigation-support artifacts and response times enumerated in the agreement. |
| IR-3 | How would you detect a breach in your own planes — what monitoring runs on your side, and what wakes a human? | A description of detection controls on the vendor's own systems, with examples of alerts that page a person. | A summary of the detection and alerting design, and the vendor's disclosure practice for past incidents. | Incident response defined entirely as reacting to customer reports. | Periodic independent review rights, with summaries shared annually. | Vendor maintains monitoring of its own systems and shares an annual summary of its detection posture. |
| Access controlMaps to least-privilege expectations across every framework the cross-linked guides cover: who can touch content, and whether that touch leaves a record. | ||||||
| AC-1 | Which of your personnel can access our content, under what process, and is every access logged and visible to us? | Least-privilege, just-in-time support access, logged, with customer visibility into when it happened. | The access-control policy and a sample vendor-access log entry. | "Engineers can see production" as the normal operating mode. | A support-access consent gate the customer controls. | Personnel access to customer content is logged, reviewable, and prohibited as standing access. |
| AC-2 | Show the customer-side role model. Are admin actions — role grants, retention changes, deletions — recorded as events in the same trail? | A role matrix, with administrative actions appearing as audit events alongside requests. | Role documentation plus a sample admin-event record. | One admin role that can change retention or delete records without leaving a trace. | Two named administrators with periodic mutual review, until admin-action logging exists. | Administrative-action logging stated as a service commitment. |
| AC-3 | How do users authenticate — identity-provider-backed sign-in, enforced multi-factor authentication, session controls — and which of these are live today versus planned? | A plain today-versus-roadmap split, with identities tied to your directory and multi-factor enforcement available now or a stated date. | Authentication configuration documentation for the current release. | Shared accounts, or roadmap items presented in the present tense. | Network-level access restriction to managed locations until authentication hardening lands. | Authentication capabilities listed as current-release commitments, dated where they are roadmap. |
Three companion pages carry the depth behind the columns: the audit log schema template shows exactly what LA-1's sample record should contain, the prompt log retention crosswalk maps the clocks RD-1 asks about by record type, and the zero data retention vs no training guide explains why MT-1 and MT-2 are two questions rather than one. For the isolation and deployment-boundary domain in particular, the BYOC on AWS guide is IB-1 through IB-3 in architectural form — the role policies, egress inventories, and key-policy answers a good vendor response contains.
Where PrivateStack stands on five of these rows
We built PrivateStack to score well here without hedging: every request logged with user identity, timestamp, and model identity; audit logs export date-ranged and machine-readable from the console; hosted inference runs zero-retention through a disclosed subprocessor under contractual no-training terms; and the Enterprise deployment runs the data plane inside the customer's own AWS account, which moves the content-bearing stores under your direct control. The honest limits: some rows are roadmap for us too — single sign-on is on the roadmap, and AC-3 exists precisely so vendors say that plainly instead of in the present tense. Send us the questionnaire; scoring vendors, us included, is your program's job, and no vendor's self-assessment substitutes for it. The full control set is on the security page, and the audit trail requirements checklist covers the ten controls behind the logging domain.
Questions people actually ask
- How is this different from a generic vendor security questionnaire?
- Two ways. The domains are AI-specific — subprocessor chains that include model providers, retention clocks on embeddings and extracted text, model change control, training-use terms — which generic questionnaires miss entirely. And the structure does the work a question list cannot: each row tells you what a good answer looks like, what evidence to demand, the red flag, the fallback control, and the clause that locks the commitment into the contract.
- What does the score actually mean?
- It is a triage instrument, not a verdict on the vendor. Two points means the answer exists and the evidence is in hand; one means the commitment is promised but unevidenced; zero means no or unknown. The bands — strong from 85%, conditional from 60% — tell you whether to proceed to contract redlines, bound the rollout, or keep the tool away from sensitive content. Your own risk tolerance can and should move those thresholds.
- Do my answers get saved or sent anywhere?
- No. The scorer runs entirely in your browser as page state: no network requests carry your selections, nothing is stored, and reloading the page clears it. For a record you can keep, use the spreadsheet download and score in the file.
- Should every vendor get all 21 questions?
- Scale by exposure. A tool that never touches sensitive content can skip domains; a workspace where customer or regulated data flows through prompts deserves all seven, plus the sector overlay that applies to you — for advisers, the Regulation S-P addendum linked above. The one domain never to skip is data flow: every other answer depends on knowing where the content actually goes.
Comparing deployment models before the questionnaire ever goes out? The closed-API comparison covers what each architecture can and cannot answer honestly.