AI supply-chain question set

Provide your current sub-processor list. For each sub-processor, include its legal name, processing purpose, country/region of data processing, and the specific categories of customer data it may process (e.g., content, metadata, telemetry). This can be provided as a public URL or a direct attachment.

Buyers need a current, detailed sub-processor inventory to complete data-protection impact assessments and vendor risk reviews. Understanding the location, purpose, and data access for each sub-processor is essential for this.

Edited on review: invented threshold, invented threshold, opinion as fact.

Describe how customers receive advance notice of new or replacement sub-processors, including the notification channel and minimum notice period before the sub-processor goes live.

GDPR Article 28(2) requires controllers to be informed of changes to sub-processors with an opportunity to object. The notification channel (email, RSS, portal) and notice window materially affect a buyer's ability to act before processing begins.

Edited on review: invented threshold.

Describe the customer's right to object to a new sub-processor, including the consequences if the objection cannot be resolved.

An objection right is meaningless without a defined process and remedy (e.g. termination right, alternative configuration). Buyers need to understand what leverage they retain when a sub-processor change is unacceptable.

Confirm whether human reviewers or annotators (employees or contractors of you or a sub-processor) may access customer data, and under what circumstances.

Human review for safety, evaluation, or annotation can be a hidden data-access surface, especially when contracted to third-party labeling firms. Buyers need explicit disclosure to evaluate confidentiality risk.

Describe your due-diligence process for onboarding a new sub-processor, including required certifications, security review steps, and approval authority.

Buyers inherit their vendor's sub-processor risk posture. A documented onboarding gate (e.g. SOC 2 review, DPIA, security questionnaire, executive sign-off) is a leading indicator of supply-chain hygiene.

Describe how you monitor sub-processors on an ongoing basis, including reassessment frequency and triggers for ad-hoc review.

One-time onboarding is insufficient. Buyers need evidence of continuous monitoring — annual reassessments, breach-triggered reviews, certification expiry tracking — proportional to the criticality of each sub-processor.

Edited on review: invented threshold.

Confirm whether you flow down equivalent data-protection, security, and breach-notification obligations to each sub-processor by written contract.

GDPR Article 28(4) requires that the same obligations imposed on the processor be imposed on sub-processors. Buyers need a positive confirmation, not a generic 'we have agreements.'

Describe how you handle international data transfers to sub-processors located outside the customer's region, including the transfer mechanism relied upon.

Schrems II and equivalent rulings make transfer mechanisms (SCCs, UK IDTA, adequacy decisions, BCRs) a material risk. Buyers need to know which mechanism applies per sub-processor and whether supplementary measures are in place.

Describe how you notify customers of a material security incident affecting a sub-processor, including the notification timeline.

A sub-processor breach starts the customer's own regulatory clock: GDPR Art. 33(1) gives a controller 72 hours to notify its supervisory authority, while Art. 33(2), which governs a processor telling its controller, sets no number and says only “without undue delay”. Buyers need a commitment specific enough to leave them time to meet their own deadline.

Edited on review: invented threshold, technical accuracy.

Describe your concentration risk posture: identify any sub-processor whose loss would materially impair your ability to deliver the service and any mitigations in place.

Heavy reliance on a single cloud, single model provider, or single data vendor concentrates risk that the buyer ultimately bears. The question is designed to surface that concentration even from a vendor inclined to deny it exists.

Edited on review: opinion as fact.

Confirm whether your contracts with sub-processors include audit rights letting you verify their controls, and state the cadence.

Regulated buyers (financial services, healthcare, public sector) often have statutory audit-rights obligations they must flow down. Without sub-processor audit rights, the vendor cannot satisfy these.

Edited on review: compound question.

Confirm whether those audit rights, or equivalent evidence such as SOC 2 reports, can be extended to your customers or their regulators where legally required, for example under DORA.

Regulated buyers (financial services, healthcare, public sector) often have statutory audit-rights obligations they must flow down. Without sub-processor audit rights, the vendor cannot satisfy these.

Describe any restrictions you can offer on which sub-processors process a given customer's data (e.g. region-locked sub-processor subsets, exclusion of specific sub-processors).

Some regulated buyers cannot accept certain sub-processors at all. The ability to constrain the sub-processor subset per customer — even when limited — is differentiating.

Confirm whether you can provide a Software Bill of Materials (SBOM) for the deployed product, and identify the format(s) supported (e.g. CycloneDX, SPDX).

SBOMs are increasingly required by government and enterprise buyers (e.g. US Executive Order 14028) to manage component-level risk. Format support (CycloneDX, SPDX) determines whether the SBOM integrates with the buyer's tooling.

Describe your process for identifying, prioritizing, and remediating vulnerabilities in open-source and third-party components.

Most of a modern stack is third-party code, so how a vendor finds and fixes a component vulnerability decides how long you are exposed to one. The answer reveals whether the vendor scans continuously or triages reactively.

Edited on review: invented threshold, opinion as fact.

Describe controls in place to verify the integrity and provenance of build artifacts (e.g. signed builds, reproducible builds, SLSA level).

Build-system compromise is a leading supply-chain attack vector. SLSA levels, signed builds, and provenance attestations indicate the vendor's maturity in defending against this class of attack.

Describe your approach to detecting and responding to malicious or typo-squatted packages introduced through dependency updates.

Dependency-confusion and package-squatting attacks have caused significant incidents in recent years. Buyers need evidence that the vendor's package ingestion pipeline has defenses beyond default registry trust.

Describe how you manage open-source license compliance for components included in your product, including any copyleft components.

License obligations (especially copyleft) can create downstream obligations for the buyer in some deployment models. Buyers need confidence that license risk is actively tracked.

Describe controls protecting your source-code repositories and CI/CD pipelines from unauthorized modification (e.g. branch protection, signed commits, secrets scanning).

Source and pipeline compromise enables supply-chain attacks at scale. Buyers need a quick read on basic hygiene before deeper diligence.

Edited on review: us english.

Describe how you secure and rotate secrets, API keys, and credentials used to authenticate to third-party services and sub-processors.

Compromise of vendor-to-sub-processor credentials is a common supply-chain attack pattern. Secrets management posture is a quick indicator of operational maturity.

Confirm whether you participate in a coordinated vulnerability disclosure program for issues found in your product or its dependencies, and describe how customers are notified.

A documented coordinated-disclosure program gives customers a path to receive advisories, and its absence is the question this is designed to catch: a vendor that patches quietly with no advisory.

Edited on review: opinion as fact.

Identify all third-party AI models (e.g., foundation, embedding) and related AI services (e.g., for annotation, evaluation, fine-tuning) used to deliver your product. For each, specify the provider, its function, and confirm if customer data is sent to it.

Material product behavior increasingly depends on third-party model providers whose terms, residency, and data practices vary. Buyers need explicit disclosure of all AI dependencies — including for training and evaluation — to evaluate model-tier risk separately from infrastructure risk.

For each third-party model used, confirm whether customer prompts, completions, or fine-tuning data may be used by the model provider to train or improve their models.

Buyers cannot accept training-on-customer-data by default in regulated workloads. The answer must be explicit per provider, since defaults differ across foundation-model vendors and across API tiers.

Disclose any third-party data sources (e.g. licensed datasets, web-scraped corpora, knowledge graphs) materially relied on to deliver service functionality.

Third-party data sources carry IP, copyright, and accuracy risk. Buyers need disclosure to assess whether their use of the product creates downstream legal exposure.

Describe how you handle deprecation or end-of-life of an underlying third-party model, including customer notice and migration support.

Foundation models are deprecated on the provider's schedule, not the buyer's. Deprecations can change product behavior and break customer prompt engineering or evaluations. Buyers need to know the notice window and continuity commitments.

Describe your technical failover plan if a critical third-party model provider suffers an outage, including tested recovery time.

Single-provider AI dependencies concentrate risk in one supplier's availability and commercial terms. Buyers need to see whether the vendor has tested failover or an alternative provider.

Edited on review: compound question, fabrication.

Describe your contingency if a critical third-party model provider becomes permanently unavailable, or changes commercial terms in a way that prevents continued use.

Single-provider AI dependencies concentrate risk in one supplier's availability and commercial terms. Buyers need to see whether the vendor has tested failover or an alternative provider.

Disclose any third-party tools or services invoked at runtime by AI features (e.g. retrieval services, code execution sandboxes, MCP servers, browser/automation tools) and the data they may receive.

Agentic and tool-using AI systems expand the data-flow boundary at runtime. Indirect dependencies — retrieval indexes, code interpreters, MCP servers, browser automation — each represent a new data egress point and need disclosure for buyer security review.

Confirm whether the disclosed third-party AI dependencies, models, and runtime tools are reflected in the customer-facing DPA and sub-processor list, or are documented separately.

AI-specific dependencies often live in marketing or technical documentation rather than the legal artifacts buyers rely on. Buyers need a single, contractually binding source of truth.