wealthschema
wealthschema/resources/templates
Template

Synthetic-Data Vendor Security Questionnaire Template

Published May 10, 2026

Most fintech procurement cycles stall at the synthetic-data vendor's security questionnaire — not because the answers are bad, but because the questions weren't right. This template ships the questionnaire most InfoSec / legal / procurement teams should send to any synthetic-data vendor. Pre-filled with the structurally important questions; the buyer customizes the firm-specific ones.

What you walk away with

~15 min · 6 slots · 20 blocks
  • A complete vendor security questionnaire calibrated against fintech procurement patterns 2022-2025.
  • Coverage of data lineage, PII / NPI attestation, license terms, refresh cadence, BAA need.
  • Inline guidance on what each answer should look like — what to accept, what to push back on.
  • A populated document the procurement team can attach directly to the vendor evaluation.
0 / 6 filled0%

Variables

Your firm's legal name.

The synthetic-data vendor being evaluated.

The date this questionnaire is being sent.

What the firm intends to use the corpus for.

Which regulators read the firm's outputs of features built against this corpus.

Live document preview

Vendor Security Questionnaire — [VENDOR_NAME]

This questionnaire is issued by [FIRM_NAME] on [EFFECTIVE_DATE] for the procurement evaluation of [VENDOR_NAME]. The questions cover the structural areas an InfoSec / legal / procurement review should clear before contracting. Answers from [VENDOR_NAME] should be returned within 10 business days; gaps will be discussed in the InfoSec review meeting.

Why this questionnaire is shorter than your usualguidance — delete before sending

Synthetic data has a structural property most third-party data does not: it contains no real PII / NPI by construction. That removes ~60% of a standard vendor questionnaire's questions. The remaining questions focus on the synthetic-data-specific risks: lineage, attestation, license, and refresh cadence.

1. Vendor profile

  1. Provide vendor's legal name, registration jurisdiction, and parent / holding-company structure.
  2. Provide a list of all subprocessors, their function, and the data classes they handle.
  3. Provide the most recent SOC 2 Type II report or equivalent third-party attestation.
  4. Disclose any material security incidents in the last 36 months and the remediation outcome.

2. Data lineage and provenance

What good looks likeguidance — delete before sending

A defensible vendor publishes the calibration source for its corpus (SCF, peer book, internal anchor). Generic 'we use a generative model' responses are insufficient — push back for the specific calibration source and the validation methodology.

  1. Describe the corpus generation methodology: what is sampled, what is modeled, what is rule-based.
  2. Identify the calibration sources used (e.g. Survey of Consumer Finances, internal anchors, peer benchmarks).
  3. Describe the consistency / validation gate every record passes before it enters the shipped corpus.
  4. Confirm: no real customer data of any party is used in generation, attestation under penalty of contractual default. Per [REGULATOR_SCOPE] scope, this attestation is required.

3. PII / NPI attestation

  1. Provide a written attestation that the corpus contains no real personal information of any actual individual.
  2. Describe the procedure used to verify this attestation (e.g. probabilistic re-identification testing).
  3. Confirm: the corpus is not subject to GLBA, GDPR, CCPA, HIPAA, or other PII-protective frameworks because it contains no real PII.
  4. Provide a sample legal memo the firm can adapt for its internal data-classification policy team.

4. License terms

  1. Specify license terms: per-seat, per-environment, per-corpus-version, perpetual or subscription.
  2. Confirm permitted uses: internal evaluation, internal testing, demo / sales, training of internal models, training of external public models.
  3. Specify restrictions: redistribution, sublicensing, productization (re-selling derived corpora).
  4. Specify license persistence on subscription cancellation: do prior-version corpora survive cancellation, or revert?

5. Refresh cadence and versioning

  1. Describe the corpus refresh cadence (annual, quarterly, on-event).
  2. Identify the regulatory / tax / SS COLA / FinCEN updates that drive ad-hoc refreshes.
  3. Describe corpus versioning: how a buyer pins a version to a release and references it in audit evidence.
  4. Provide the deprecation policy for older corpus versions (how long are they accessible after a refresh).

6. BAA / contractual security

BAA likely not required — but askguidance — delete before sending

If the corpus contains no real PII, a Business Associate Agreement is structurally not needed (HIPAA does not apply). But ask: if the corpus is ever co-processed with the firm's real customer data in a shared environment, the BAA may apply to the joint processing.

  1. Confirm: BAA is or is not required given the corpus contains no real PII.
  2. Provide the standard MSA + DPA with synthetic-data-specific language.
  3. Confirm: the firm has audit rights against the vendor's security controls during the contract term.

7. Use case-specific (vendor responses)

Use case scope: [USE_CASE_SCOPE]. Per this scope, the vendor should be able to answer:

  1. Has the vendor's corpus been used by a directly-comparable buyer (similar regulator scope, similar product line)?
  2. Are there published case studies, reference customers, or audit evidence the firm can review?
  3. Will the vendor agree to a 14-day evaluation against the buyer's specific test cases at no cost?

Unfilled slots show as [VARIABLE_NAME] so the partial document still reads. Filling in the form on the left substitutes them inline.

What to do with this

Send the populated questionnaire to the vendor's security or sales contact. Allow 10 business days for response. Use the answers in your standard vendor risk review meeting; gaps become questions for the InfoSec sign-off block. Once approved, file the questionnaire + responses with the firm's vendor risk register, refresh annually.

ChecklistSOC 2 Readiness ChecklistComparisonSynthetic vs. Anonymized Comparison
Calibrated against: SIG (Standardized Information Gathering) v2024 + observed fintech procurement patterns 2022-2025Calibrated against Shared Assessments' SIG framework (synthetic-data-relevant subset) plus observed fintech procurement questionnaire patterns 2022-2025. Synthetic-data-specific sections (lineage, attestation, license) are above and beyond SIG.

FAQ

Why so much shorter than our usual SIG?

Synthetic data has no real PII by construction, which removes about 60% of standard SIG questions (data minimization, breach notification of customer data, privacy rights, etc.). The remaining questions focus on the lineage, attestation, license, and refresh issues that are specific to synthetic data.

Can we add questions to it?

Yes. Add firm-specific compliance, jurisdictional, or product-line questions in section 7. Keep the structural sections 1-6 — they're calibrated against published examination focus areas and removing them weakens the procurement record.

ShareShare on X (Twitter)Share on LinkedInShare by email