Procurement, samples and ongoing supply
Security review of a data vendor: what to require from a training data supplier
Quick answer
A security review of a data vendor tests whether a training data supplier can protect the licensed records on their way from its source systems to your environment, and protect what you send it. Scope the review to every system that will hold a copy, not to the company in general. Ask for a SOC 2 Type 2 report or ISO/IEC 27001 certificate that covers export, preparation and delivery, then verify encryption and key exchange, staff and subcontractor access, integrity manifests, file screening and deletion of staging copies.
By SourceX Editorial · Updated
What a data supplier security review has to cover
A data supplier review differs from a software-vendor review because the data flows toward you: the main risks are exposed copies along the supplier's export path, tampering before delivery, unsafe files, and the access you grant the supplier to your cloud account. What you send matters too. Specifications and gold labels can reveal model plans, and an evaluation set shared for scoring loses its value if it leaks.
NIST's Generative AI Profile (AI 600-1, July 2024) lists value chain and component integration among the 12 generative AI risks it identifies [1], and purchased training data is one of those upstream components. NIST SP 800-218A adds secure-development practices addressing the integrity of training, testing, fine-tuning and alignment data [2].
Keep the security review separate from two neighbors in your AI training data procurement process. The data provider due diligence questionnaire covers the company, its sourcing and its resale rights; the privacy review of a training data vendor covers lawful basis, consent and de-identification. The security review covers the confidentiality, integrity and availability of the records and of the channels that move them.
Match review depth to the delivery model and the data
Review depth should follow where copies of the records will exist and how sensitive they are, not the contract value. The delivery model decides which systems are in scope; the data decides how much evidence each one needs.
| Delivery model | Where copies exist | Review focus | Depth |
|---|---|---|---|
| Zero-copy share (Snowflake Secure Data Sharing, Delta Sharing) | Supplier's platform; you query it | Provider account, share scope, your roles and query logs | Light on transfer |
| You pull from the supplier's bucket | Supplier staging, then your storage | Bucket policy scope, credential lifetime, staging retention | Standard |
| Supplier pushes into your prefix | Supplier staging, your landing bucket | Write-only grant, keys, removing the grant afterwards | Standard |
| SFTP or managed file transfer | Supplier, transfer server, your landing zone | File-level encryption, key exchange, server retention | Standard to full |
| Encrypted drive shipment | Media in transit and at both ends | Drive encryption, separately sent keys, chain of custody, destruction | Full |
| Clean room or remote access | Supplier or neutral environment | Isolation, export and output controls | Review the environment |
With Snowflake Secure Data Sharing no data is copied between accounts and shared objects are read-only for the consumer [3]; in Delta Sharing the provider's sharing server manages recipient access [4]. Either way, the supplier's platform account becomes the main control point. For physical transfers, as of October 2026 AWS Snowball Edge has been closed to new customers since 7 November 2025, and AWS points them to DataSync, Data Transfer Terminal or partner solutions [5]; see shipping datasets on encrypted drives for custody design.
Raise the review one tier for personal data with residual re-identification risk; health, nonpublic financial or children's data; evaluation sets whose leak would contaminate future benchmark results; and bulk US sensitive personal data that anyone outside the US could reach. The supplier risk-tiering guide applies these tiers across a vendor portfolio.
Reading a supplier's SOC 2 report or ISO/IEC 27001 certificate
An attestation answers the security question only if its scope includes the systems that will hold your records and its period is recent, so check both first. Industry commentary reports that buyers of AI data services ask which suppliers hold ISO 27001 and SOC 2 Type II, alongside HIPAA workflow controls [6], and one published AI-vendor RFP template gives data privacy and security their own section [7].
SOC 2. A SOC 2 examination reports on controls relevant to security, availability, processing integrity, confidentiality or privacy; the AICPA's SOC 2 guide distinguishes type 1 reports, on control design at a point in time, from type 2 reports, on operating effectiveness over a period [8]. The criteria are the 2017 Trust Services Criteria with revised points of focus (2022) [9]. Read a data supplier's report in this order:
- System description, prepared against the AICPA description criteria [10]. Does it name the export jobs, preparation environment and delivery storage, or only the customer-facing product?
- Categories in scope. Security is the baseline; confidentiality and processing integrity speak most directly to delivered data.
- Subservice organizations. A carved-out cloud host or labeling subcontractor needs its own report or other evidence.
- Complementary user entity controls, which the supplier expects you to operate, such as protecting delivery credentials. Give each one an owner.
- Exceptions and opinion. Read every exception on access, change management or logging, and note any qualified opinion.
- Period end. If the period ended months ago, ask the supplier's management for a bridge letter.
A SOC 3 report is a general-use report [11] that leaves out tests and exceptions, so request the SOC 2 under NDA.
ISO/IEC 27001. ISO/IEC 27001:2022, the third edition (October 2022), specifies requirements for an information security management system (ISMS) built on risk management, and certification against it is optional [12]; ISO/IEC 27002:2022 supplies the control guidance [13]. Ask for the certificate, its scope statement and the Statement of Applicability, and check that the certificate names the 2022 edition, is current and comes from an accredited certification body. A scope of "software development and support" says nothing about a data export team. The AICPA's mapping between the Trust Services Criteria and ISO 27001 helps compare one supplier's SOC 2 with another's certificate [14].
ISO/IEC 42001:2023 covers AI management systems for organizations that develop, provide or use AI [15]. It is useful context when a supplier also builds models, but it is not evidence about how records are stored and moved.
When the supplier holds no attestation
Operating companies that hold valuable records, such as a regional distributor or a freight brokerage, may have no SOC 2 report or ISO certificate because they never sold a hosted service, so the review shifts to direct evidence about a narrow data path. The fewer supplier systems the records touch, and the shorter they stay there, the less you have to verify.
- A written data-flow description naming each system, account and person in the export.
- Evidence of the controls that matter: MFA on the staging account, the key policy, the access list.
- Export straight into a prefix you control through a write-only grant.
- A zero-copy share or a data clean room, so records never leave a controlled environment.
- Deletion of every staging copy after acceptance, evidenced by a dated certificate.
Security questionnaire for data suppliers: questions and evidence
Each question below names the evidence that answers it and the answer that should stop approval. Send it once the supplier has described its delivery path, and skip questions that an in-scope attestation already tested.
| # | Question | Evidence that answers it | Answer that should stop approval |
|---|---|---|---|
| 1 | Which systems, cloud accounts and regions will hold any copy, from export to deletion? | Data-flow description naming each system and account | "Our standard environment," nothing named |
| 2 | Does a current SOC 2 Type 2 report or ISO/IEC 27001 certificate cover those systems? | System description, or certificate scope and Statement of Applicability | Scope limited to an unrelated product |
| 3 | How is the export produced, by whom, with what permissions? | Job definition, service-account permissions, run log | An analyst exports to a laptop |
| 4 | Which tools, including third-party AI APIs, process records during redaction or labeling? | Tool list with each provider's retention and training terms | Unnamed tools or personal accounts |
| 5 | Who can access raw records, and how is access granted, logged and revoked? | Named roles, MFA, access logs, last access review | Shared logins; no logging on staging |
| 6 | Which subcontractors or offshore staff can see records, and from where? | Subprocessor list with locations and terms | "Contractors as needed" |
| 7 | How are staging copies encrypted, and who controls the keys? | Key policy listing permitted principals; named custodians | Any console administrator can use the keys |
| 8 | Which channel delivers the data, and how are keys or credentials exchanged? | Delivery spec: channel, TLS, file-level encryption, out-of-band fingerprint check | Email attachments or unauthenticated links |
| 9 | How will we confirm that what arrives matches what was approved? | SHA-256 manifest sent separately; record counts per file | MD5 only, or no manifest |
| 10 | How are files screened for malware and executable content? | Scan results; agreed formats such as Parquet or JSON Lines | Pickled Python objects or macro-enabled documents |
| 11 | How and when will we hear about an incident affecting our records? | Incident procedure; notice period in the contract | "As required by law" only |
| 12 | When are staging copies deleted, and what proves it? | Deletion certificate naming systems, method and date | Indefinite retention "for support" |
Rows 8 and 9 are covered in depth in encrypting dataset deliveries and exchanging keys and verifying a delivery with manifests and checksums.
For row 4, obtain each model provider's terms on training and retention; FTC technology staff warned in a January 2024 blog post that model-as-a-service companies may be liable under laws it enforces if they break promises not to use customer data for training [16]. For row 6, involve counsel when records include bulk US sensitive personal data. The Justice Department's rule implementing Executive Order 14117 prohibits and restricts certain transactions involving countries of concern and covered persons; according to White & Case, its data transaction rules took effect on 8 April 2025 and further compliance provisions on 6 October 2025 [17]. See the DOJ bulk sensitive data rule and licensed training data and subcontractor and workforce disclosure.
Worked example: a SOC 2 report that misses the export path
Illustrative example: invented to show structure; it does not describe an available dataset.
A buyer plans to license three years of claim notes from a regional claims administrator, pushed into the buyer's S3 bucket. The supplier provides a SOC 2 Type 2 report on security and confidentiality for calendar year 2025.
| Finding | Where it appears | Resolution |
|---|---|---|
| Only the claims platform is described; the export runs from a separate analytics account | System description | Supplier evidences that account's controls, or preparation moves into scope |
| Cloud host carved out | Subservice organizations | Buyer reviews the host's own SOC 2 report |
| "User entities restrict access to delivered credentials" | Complementary user entity controls | Buyer's platform team owns rotation and revocation of the delivery role |
| Period ended nine months before signature | Report cover | Bridge letter and a commitment to deliver the next report |
The buyer owns the landing bucket, so it writes the grant. In Amazon S3 a bucket owner grants another account access in a bucket policy, that account delegates the access to its own users, and an explicit deny in either policy overrides any allow [18]. The buyer allows writes to one delivery prefix, denies reads and lists elsewhere, and removes the grant after acceptance. The outcome is conditional approval, with each condition in the security schedule.
Findings that block approval and findings you can contract around
Block approval when a gap leaves records exposed with no workable fix, and contract around a gap that has a dated remedy and an owner. That line keeps reviews from stalling on paperwork while still stopping real exposure.
| Finding | Decision | Typical remedy |
|---|---|---|
| Delivery by email attachment or public link | Block | Change the channel before any data moves |
| Raw records on personal devices, consumer accounts or unnamed systems | Block | Managed, named environment only |
| Undisclosed subcontractors with raw-record access | Block until disclosed | Named subprocessors, locations and terms |
| No integrity manifest or record-count reconciliation | Block until fixed | SHA-256 manifest with counts per file |
| Type 1 report only | Contract around | Type 2 by a named date; interim evidence of key controls |
| Attestation scope excludes the export path | Contract around if compensating evidence is strong | Direct evidence, or move preparation into scope |
| No commitment to delete staging copies | Contract around | Deletion clause with a dated certificate |
Write the conditions into a security schedule attached to the license: delivery channel, encryption and key exchange, an incident notice period you choose, annual attestation delivery, subprocessor change notice and deletion evidence. See deletion and return clauses for drafting and ongoing due diligence after signature for yearly re-checks, and record the result as the security gate in your data vendor evaluation scorecard.
How SourceX fits into your supplier security review
When SourceX manages a purchase, the supplier is a US business that approves every release, and your review still needs to establish which party holds each copy at each stage. SourceX describes these parts of its process:
- Delivery happens through private, access-controlled workflows, never email attachments, and nothing is delivered until an agreement is executed and the supplier approves the terms.
- Personal details such as names, emails, phone numbers and account numbers are removed or replaced before delivery; the method is recorded per dataset and a sample is checked after processing. No de-identification method is perfect.
- Diligence materials covering source, rights, preparation and allowed use are prepared per dataset for your review.
- SourceX does not train AI models.
SourceX explains its own approach in how SourceX handles data security, its trust center and its answer on whether licensed data is encrypted in transit. If you are scoping a purchase now, you can describe the dataset and the controls your security team requires.
Planning the security review for a data purchase?
At the SourceX buyer page you can submit a data request that states the records you need and the transfer, storage and deletion controls your reviewers expect, talk to SourceX, or browse the dataset catalog. SourceX looks for US companies that hold the data, checks their licensing permissions, and manages the license and delivery. Share your security and delivery requirements.
Sources
- National Institute of Standards and Technology (NIST), "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)" (2024). https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- National Institute of Standards and Technology (NIST), "Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile (NIST SP 800-218A)" (2024). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218A.pdf
- Snowflake Inc., "About Secure Data Sharing" (Snowflake Documentation). https://docs.snowflake.com/en/user-guide/data-sharing-intro.html
- Databricks, "Introducing Delta Sharing: An Open Protocol for Secure Data Sharing" (2021). https://www.databricks.com/blog/2021/05/26/introducing-delta-sharing-an-open-protocol-for-secure-data-sharing.html
- Amazon Web Services, "AWS Snowball Edge availability change" (2025). https://docs.amazonaws.cn/en_us/snowball/latest/developer-guide/snowball-edge-availability-change.html
- Syndicated industry article, "What enterprise procurement teams actually find when they evaluate AI data partners". https://agtechdata.uga.edu/what-enterprise-procurement-teams-actually-find-when-they-evaluate-ai-data-partners/
- Dan Cumberland Labs, "AI Vendor RFP Template". https://dancumberlandlabs.com/blog/ai-vendor-rfp-template/
- AICPA & CIMA, "SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy" (2022). https://www.aicpa-cima.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy
- AICPA & CIMA, "2017 Trust Services Criteria (With Revised Points of Focus - 2022)" (2022). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
- AICPA & CIMA, "2018 SOC 2 Description Criteria (With Revised Implementation Guidance - 2022)" (2022). https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report
- AICPA & CIMA, "SOC 3 - SOC for Service Organizations: Trust Services Criteria for General Use Report". https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-3
- ISO/IEC, "ISO/IEC 27001:2022 - Information security management systems" (2022). https://www.iso.org/standard/27001
- ISO/IEC, "ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls" (2022). https://www.iso.org/standard/75652.html
- AICPA & CIMA, "Mapping: 2017 Trust Services Criteria to ISO 27001". https://www.aicpa-cima.com/resources/download/mapping-2017-trust-services-criteria-to-iso-27001
- ISO/IEC, "ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management system" (2023). https://www.iso.org/standard/42001
- Federal Trade Commission, Office of Technology, "AI Companies: Uphold Your Privacy and Confidentiality Commitments" (2024). https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2024/01/ai-companies-uphold-your-privacy-confidentiality-commitments
- White & Case LLP, "DOJ issues final rule prohibiting and restricting transfers of bulk sensitive personal data". https://www.whitecase.com/insight-alert/doj-issues-final-rule-prohibiting-and-restricting-transfers-bulk-sensitive-personal
- Amazon Web Services, "Example 2: Bucket owner granting cross-account bucket permissions" (Amazon S3 User Guide). https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html
Tell us what your models need
Share scope, volume, language, format, timing and licensing requirements.