The Eight Records to Demand From a Data Vendor Before You Sign
This article is for informational purposes only and does not constitute legal advice. Consult a qualified attorney for legal guidance specific to your situation. Every clause line in this article is illustrative wording drawn from published templates; have counsel review any clause before you use it.
Send a data vendor your due diligence questionnaire (DDQ) and you get answers. What an examiner, an investor's operational due diligence (ODD) team, your model-risk function or your own exit later asks you to produce is something else: documents and clauses.
Data vendor due diligence means checking, before you license a dataset, that the vendor had the right to collect and sell it and that you may use it the way you plan to.
In an April 2022 risk alert, SEC examination staff described advisers that "could not demonstrate, such as by producing documentation, that their policies and procedures had been consistently implemented", and others with no system for deciding when diligence "needed to be re-performed". The alert is a staff view, "not a rule, regulation, or statement of the Securities and Exchange Commission".
These records sit behind the sign-off stage of the alternative data diligence loop. Below are eight of them, five sent with the DDQ and three written into the contract, each with a good and an evasive answer, plus what to keep on file after you sign.
- Security is not provenance: SOC 2, ISO 27001 and penetration tests do not show where the rows came from or under what rights.
- Five plus three: five records go out with the DDQ as documents; three go into the data licensing agreement as clauses.
- The file outlives the signature: someone will ask after signing, so keep every dated version the vendor sends.
What should you request from a data vendor before signing?
Request eight records: five for the file, three for the contract.
| # | Record | Contract or file | The later question it answers |
|---|---|---|---|
| 1 | Dataset documentation pack | File | Model risk: what did we test, and is the history as it was on the day? |
| 2 | Upstream rights chain and provenance warranty | Both | Examiner: what terms govern collection? Exit: when does the upstream licence expire? |
| 3 | Collection-method statement | File | ODD and examiner: how was this collected, and does the vendor stand behind it? |
| 4 | Consent evidence, or a signed no-personal-data statement | File, plus a contract right to receive | An upstream deletion order: can you show the consumer consented? |
| 5 | Signed, dated DDQ response | File | ODD and examiner: can you demonstrate it "by producing documentation"? |
| 6 | Permitted-use schedule | Contract | Model risk: may this data touch a model? Exit: does what we built survive? |
| 7 | Change-notification clause | Contract | Examiner: what triggers re-diligence? |
| 8 | Deletion and exit terms | Contract | Exit: what do we delete, what may we keep, and how do we prove it? |
Keep all of it as long as your books-and-records obligation requires.
SOC 2, ISO 27001 and penetration tests answer whether the vendor protects data and stays solvent. They do not show where the rows came from, under what rights, how they were collected, or what changed since you last looked. Even FISD's January 2025 GenAI paper treats SOC 2 as information-security assurance, separate from use rights.
Five records to request with the due diligence questionnaire
The first five are documents that travel with the DDQ and stay in your file. The FISD Alternative Data Council DDQ (February 2024, the latest general compliance version on fisd.net as of October 2026) already names most of them. A vendor-completed form records a claim, not a verified fact; its value is being signed, dated and checkable.
1. The dataset documentation pack
Request line: "Please send the tear sheet, data dictionary, a sample of under 100 rows from more than three months ago, a point-in-time or backfill statement with backfill dates, and the revision history since launch."
What it is: the data, field by field, plus how its history was built and changed. FISD's Data Description Guidelines put revision tracking inside the same documentation standard as the field description, so the pack carries the change log rather than being a separate record. Template source: DDQ Document Request List items 1 to 3; FISD Tear Sheet (June 2021).
The later question it answers: model risk asks whether the history you tested is as it was on the day. Point in time, per Mark Fleming-Williams, Head of Data Sourcing at CFM (2025): "the data has not been changed from the way it would have been on the day it was created."
A good answer contains: - A data dictionary giving "the types of values that may be contained within each field", and a sample of "less than 100 rows" taken "from more than 3 months ago". - Originator or aggregator status, with breaks in history explained. - Which fields are true point-in-time and which were backfilled, with dates. - A revision record; the Guidelines name it but publish no format, so ask by name.
An evasive answer sounds like (our reading): a marketing deck offered as the tear sheet; "PIT compliant" with no backfill dates. Method detail can be confidential; whether history was backfilled cannot.
Contract or file: File. On point-in-time data, see financial datasets.
2. The upstream rights chain and provenance warranty
Request line: "Please send the relevant terms of your upstream data contracts, redacted as needed, showing your right to license the data and derived products to us, and a list of third-party dependencies with upstream licence expiry dates."
What it is: proof the vendor may sell you the data, plus the clause behind it. Template source: DDQ Document Request List item 4; FISD Trial License Agreement §9 (2021).
The later question it answers: the examiner asks what terms govern "the collection or provision of the data"; your exit plan asks when the upstream licence expires.
A good answer contains: - Upstream terms showing a "legal right to resell or license the Data to us"; a redacted chain is still a chain. - Warranty wording on FISD's model (illustrative): the vendor complied with applicable law "in creating, gathering or providing the Data" and "has made reasonable inquiry into third party provider practices". - An indemnity for missing rights, as one large cloud marketplace's standard data licence (2022-07-14 version) gives for "any actual or alleged failure by Provider to obtain and hold sufficient legal right and any consents".
A warranty moves the liability, it does not establish the fact, so the documents ride with the clause. None of the six published standard licences and model terms we read gives the buyer an audit right; DORA, the EU's Digital Operational Resilience Act, requires one in Art 30(3)(e) only for EU financial entities' information and communication technology (ICT) services supporting critical or important functions.
An evasive answer sounds like (our reading): "a proprietary network of sources"; "we warrant compliance" with nothing behind it; no redacted copies.
Contract or file: Both: documents in the file, warranty and indemnity in the redline.
3. The collection-method statement
Request line: "Please send a written statement of how the data is collected, your completed web-collection answers naming any proxy, CAPTCHA or scraping providers, and whether you keep a collection log and what it records."
What it is: the vendor's written account of how data reaches it, naming every collection provider. Template source: DDQ Appendix 2 (Web Scraping and APIs); FISD Web Data Collection Considerations: Cease and Desist (c.2021).
The later question it answers: does the vendor stand behind its description of the collection? The SEC's first securities fraud action against an alternative data provider, App Annie (2021, $10 million penalty), described a firm that "used non-aggregated and non-anonymized data to alter its model-generated estimates".
A good answer contains: - The method: scraped, licensed from the originator, or other. - Named "proxies, CAPTCHA solutions, third-party scraping providers", whose practices the answers must cover too. - A yes or no on paths "specified as disallowed in robots.txt", on gated pages, and on whether websites can "identify and contact the Company", plus five years of cease-and-desist history. - Whether a collection log exists (an ask from FISD's cease-and-desist guidance, not the DDQ); see what a collector's audit trail should contain.
A clean answer is a diligence record, not proof the collection is lawful; that is a question for US web scraping laws. Respecting robots.txt is a floor, not a ceiling, and proxies are not misconduct: "yes, we use proxies, and here is how a site can reach us" beats a vague "no".
An evasive answer sounds like (our reading): "we only collect publicly available data", full stop; unnamed subcontractors; an aggregator answering only for itself.
Contract or file: File.
4. Consent evidence, or a signed no-personal-data statement
Request line: "Please send copies of the notice and consent terms behind any data from individuals or their devices, including upstream sources, or a signed statement that neither you nor your sources collect personal or device-level data."
What it is: consent evidence for data from people or devices, or a signed statement that none is involved. The statement is our construction, mirroring the DDQ's yes/no question on "Covered Personal Information". Template source: DDQ Document Request List item 5 and Appendix 1.
The later question it answers: an upstream deletion order. The FTC's January 2025 Mobilewalla order made the broker tell customers its historic location data must be deleted "unless such customer has obtained records in accordance with Provision VI.B showing that the relevant consumer consented". It binds Mobilewalla, not its customers, and covers geolocation data only.
A good answer contains: - A record of "the specific notice that individual consumers viewed and consented to, and the time and date of consent" (FTC InMarket order, 2024). - Supplier-assessment records, which Mobilewalla must make "within 30 days of a Supplier entering into data-sharing agreements" and "thereafter annually".
An EU controller must tell data subjects the source under GDPR Art 14(2)(f); Art 28 terms apply only where the vendor is your processor. For the CCPA side, see our enterprise guide to external data.
An evasive answer sounds like (our reading): "users consent via our partners' privacy policies"; "we are GDPR compliant" with no notice text; a "no" covering the vendor but not its sources.
Contract or file: File, plus a contract right to receive updated consent evidence.
5. The signed, dated DDQ response
Request line: "Please return the DDQ signed and dated, reviewed by two named people (one from legal or compliance), with your written data policies and five years of legal history, including your upstream providers."
What it is: the questionnaire itself, signed, dated and backed by the documents it cites. Template source: DDQ cover, legal and policies sections.
The later question it answers: can you show your process "such as by producing documentation"? A dated response can be superseded, which makes re-diligence and retention possible.
A good answer contains: - Two named reviewers, one from legal or compliance where the vendor has that function, and a completed "Effective date of this questionnaire". - Written policies on material nonpublic information (MNPI), Covered Personal Information, confidential information and data supplier due diligence, sent as documents. - Five years of legal history, providers included, and the MNPI answers.
Policies are records, not assurances, so ask for the document rather than a yes.
An evasive answer sounds like (our reading): "None of the above" with the upstream question blank; no signature or date; last year's DDQ re-sent unchanged.
Contract or file: File. Our vendor shortlisting guide lists what to check; this article names the documents and clauses behind it, plus the documentation pack, change-notice clause, exit terms and keep-on-file rule.
Three terms to put in the data licensing agreement
The last three are clauses for the redline; they decide what happens after signature.
Published standard terms mostly protect the licensor, so you draft these in. In October 2026 we read six in full, clause by clause: FISD's model trial licence (2021), one large cloud marketplace's standard data licence, Community Data License Agreement (CDLA) Permissive 2.0, CDLA Sharing 1.0, the Montreal Data License (2019) and the European Commission's draft model terms (November 2025).
6. The permitted-use schedule
Request line: "We will ask for a permitted-use schedule covering derived data, redistribution and model training, stating whether training and fine-tuning are permitted or prohibited, and whether models built during the term survive expiry."
What it is: what you may do with the data and what you build from it. A licence, ownership of what you derive, and permission to train are three separate rights. Template source: grant and derived-data clauses of published licences; DDQ Appendix 4 (the gap).
The later question it answers: may this data touch a model, and does what you built survive exit?
A good answer contains: - Derived data owned by you, definition read. The cloud marketplace licence gives the subscriber "all right, title and interest in and to the Derived Data" and counts "models" inside it, never saying "train". - Redistribution stated. - One sentence on training, permitted or prohibited, and one on fine-tuning; FISD's March 2026 buy-side paper calls model training "distinct from fine-tuning". - What survives expiry for models trained during the term.
Of the same six, one names training in its grant, the Montreal Data License (2019). Two reach models only through a definition of 'derived data' or 'results', and three do not mention models at all. The FISD DDQ's GenAI appendix asks about the vendor's own GenAI use, which is the vendor's permission, not yours.
Silent is not permission. Silence is not prohibition either; it leaves the question open until an audit, an exit or a dispute answers it.
An evasive answer sounds like (our reading): "fully licensed"; "standard commercial use"; "derived data is yours" with no word on models.
Contract or file: Contract (grant clause and permitted-use schedule).
7. The change-notification clause
Request line: "We will ask for written notice at least 90 days before any change to sources, collection method, upstream providers or methodology takes effect, your cooperation in re-confirming compliance, and prompt notice of any cease-and-desist letter."
What it is: a duty to warn you before the data changes underneath you and help you re-check it. Template source: FISD Trial License Agreement §9; FISD service-level best practice (v1.0, June 2021).
The later question it answers: what triggers re-diligence? SEC staff found advisers with no system for re-running it after "changes in data collection practices". This clause makes the trigger a contractual duty; a dataset can stop being usable without any outage.
"The evolution of these legal aspects has to be monitored even once the data have been bought. In doing so, we would consider a number of things, including if the provider adds a new field a few months later that breaks the anonymity of the data set or if the regulation evolves." Charles-Albert Lehalle, Head of Data Analytics, CFM, in AIMA and Simmons & Simmons, Casting the Net (2020).
A good answer contains: - Trial-licence wording (illustrative): "not less than thirty (30) days' prior notice of any planned change to the information sources or methodologies", plus cooperation to confirm compliance. - A definition of change. FISD's best practice (a recommendation, not a term) counts a new upstream provider, changed exposure to "MNPI or PII", or changed "processing methodologies", with notice "at least 90 days prior to implementation". - Notice of any cease-and-desist letter.
Of the six published standard data licences and model terms we read in full, only FISD's model trial licence sets a notice period for changes to sources or methodology (30 days). The European Commission's draft model terms leave the period blank, and the other four say nothing. Two data-marketplace provider policies we read ask for notice of changes but set no period. In short, most published standard terms we read do not include one.
For EU financial entities, DORA Art 30(2)(b) requires notice of processing and storage location changes in all ICT contracts; Art 30(3)(b) adds material developments, for critical or important functions only.
An evasive answer sounds like (our reading): "we will notify you of changes" with no period or definition, the shape both marketplace policies use; a location notice offered as if it covered methodology.
Contract or file: Contract (change-notification and re-diligence clause).
8. The deletion and exit terms
Request line: "We will ask for exit terms setting the removal period, what survives (derived data and models), an archive right for history if we need it, and the form of the deletion certificate."
What it is: what you delete, keep and prove when the licence ends. Template source: termination clauses of published licences; FISD buy-side paper (March 2026); EU draft model terms 5.1.5.
The later question it answers: what must go at exit, including models? The FTC's Mobilewalla order defines "Data Product" as "any model, algorithm, derived data, or other tool" (geolocation; it binds the broker).
A good answer contains: - A removal period, such as the cloud marketplace licence's "within ninety (90) calendar days following such termination or expiration". That template leaves derived data with you. - An archive right for history; UK market-data users told the Financial Conduct Authority in 2024 that contracts "generally require users to purge historical data from their systems". - The certificate form, agreed now; the non-binding EU draft asks for "written certification of such deletion" where the parties agreed a time limit on use. - For models, the FISD buy-side paper's advocacy position: certified deletion of raw data and retrieval-augmented generation (RAG) embeddings, not retraining. - The vendor's retention schedule. A regulator has ordered location-data brokers to publish one "in no instance providing for the indefinite retention of any Covered Information".
Exit clauses default to the licensor's protection, so ask now for what you will want then. EU financial entities can add DORA Art 30(3)(f) exit strategies, for critical or important functions.
An evasive answer sounds like (our reading): "delete all copies and derivatives" with "derivatives" undefined; "we keep everything"; no certificate form.
Contract or file: Contract (term, termination and exit clause; deletion certificate schedule).
A data vendor due diligence request you can send today
The eight records become one email or DDQ addendum; each line repeats its card's request line.
Subject: [Dataset name] due diligence request, response requested by [date]
Part 1. Please provide with your DDQ response
1. Please send the tear sheet, data dictionary, a sample of under 100 rows from more than three months ago, a point-in-time or backfill statement with backfill dates, and the revision history since launch.
2. Please send the relevant terms of your upstream data contracts, redacted as needed, showing your right to license the data and derived products to us, and a list of third-party dependencies with upstream licence expiry dates.
3. Please send a written statement of how the data is collected, your completed web-collection answers naming any proxy, CAPTCHA or scraping providers, and whether you keep a collection log and what it records.
4. Please send copies of the notice and consent terms behind any data from individuals or their devices, including upstream sources, or a signed statement that neither you nor your sources collect personal or device-level data.
5. Please return the DDQ signed and dated, reviewed by two named people (one from legal or compliance), with your written data policies and five years of legal history, including your upstream providers.
Part 2. We will ask for these terms in the agreement
2. We will ask for a warranty that the data was created, gathered and provided in compliance with applicable law, and an indemnity if you lack the rights or consents to provide it.
6. We will ask for a permitted-use schedule covering derived data, redistribution and model training, stating whether training and fine-tuning are permitted or prohibited, and whether models built during the term survive expiry.
7. We will ask for written notice at least 90 days before any change to sources, collection method, upstream providers or methodology takes effect, your cooperation in re-confirming compliance, and prompt notice of any cease-and-desist letter.
8. We will ask for exit terms setting the removal period, what survives (derived data and models), an archive right for history if we need it, and the form of the deletion certificate.
Please name the two people who reviewed your answers and give an effective date for them.
Clause wording is illustrative and subject to review by our counsel.
The 90 days in line 7 is a FISD best-practice value, not a legal requirement.
A few of these records are cheaper to specify before collection than to demand afterwards. When data is built to your own fields under contract, the field definitions, ownership and handling rules are set up front. That is how Forage AI works: the client owns the data, Forage AI never resells it, and contractual controls and client-specific handling rules are agreed up front.
Provenance for training data is recorded at collection or not at all. Ask whether the supplier can fill a datasheet-style record per source: collection dates and method, licence at source, where consent documentation is held. Two published shapes: Gebru et al.'s Datasheets for Datasets (2021), and the Data & Trust Alliance's Data Provenance Standards (v1.0.0, July 2024), with fields such as "Range of dates for data generation" and "Consent documentation location". More in our guide to AI training data providers.
What should you keep on file after signing?
Keep the eight records as received, plus your own dated record of the review.
- Contract: the executed agreement and every schedule.
- DDQ versions: every dated version, superseded and never overwritten.
- Change notices: each one under record 7.
- Reviews: each annual review.
- Exit: the deletion certificate.
Keep it as long as your books-and-records obligation requires; for many SEC-registered advisers that starts at five years. Ask counsel how your own policies bring these documents into scope.
As of October 2026, Rule 204-2 never names vendors or diligence. It reaches the file through (a)(10), "All written agreements (or copies thereof)", and (a)(17), your policies and "Any records documenting the investment adviser's annual review". Under (e)(1), five years run "from the end of the fiscal year during which the last entry was made on such record"; copies of your policies carry their own look-back, covering any that "at any time within the past five years were in effect". So for an adviser with a calendar fiscal year, a licence signed in 2026 and last amended in 2028 stays on file to the end of 2033. Rule 206(4)-7(b) requires that review "no less frequently than annually", which makes it the natural re-diligence date.
Under DORA, EU financial entities need the full contract "documented in one written document", but DORA sets no retention period. We hold no evidence for other jurisdictions; do not borrow a period from tax rules, the EU AI Act or FTC broker orders. A corporate AI team that is not an SEC-registered adviser has no Rule 204-2 clock; its own policies and contracts set the period.
Frequently asked questions
Is a SOC 2 report enough for data vendor due diligence?
No. SOC 2 and ISO 27001 cover how a vendor protects data, not where the rows came from, under what rights, or what changed since you last looked. Ask for both.
Does a data licence let you train an AI model on the data?
Only if it says so. A licence, ownership of derived data and permission to train are three separate rights; of six published standard licences we read, one names training in its grant. Silent is not permission.
How often should you re-run due diligence on a data vendor?
On every material change notice, at each annual compliance review (Rule 206(4)-7 for SEC-registered advisers) and at renewal. SEC staff found advisers with no system for re-running it.
How long should you keep data vendor due diligence records?
As long as your books-and-records obligation requires; for many SEC-registered advisers that starts at five years under Rule 204-2. DORA sets no period; do not borrow a clock from another regime.
Send the request before you sign
A DDQ gets you the vendor's answers; the eight records give you something to produce when the examiner, ODD, model risk or your counsel at exit asks. Fleming-Williams put the stakes plainly in 2025: "the risk of taking on the wrong data set is much bigger than the cost of the data set." Send the request while the vendor still wants the deal, keep what comes back as it arrived, and reopen the file at every change notice, annual review and renewal.
If you would rather specify the data than chase it, Forage AI builds managed data pipelines to the client's own fields, client-owned, with handling rules agreed up front. Talk to us about your next dataset.
Related articles
- Alternative Data for Hedge Funds: the full diligence loop, from signal test to sign-off.
- Top Alternative Data Vendors: how to shortlist vendors and what to check on each.
- Web Scraping Legal Compliance: what a collector's provenance log should record.
Sai is a data infrastructure enthusiast who has spent the past two to three years following the AI space closely, from the infrastructure layer to the fast-growing world of data for AI. He is genuinely curious about how modern data pipelines get built and where the data industry is heading, and he writes insightful pieces on the core topics that shape this niche.