Welcome offer: 50% off your first 3 months
New customers only. Applied automatically at checkout.
Data and AI SaaS
A trust center for B2B data and AI SaaS companies
If your product ingests, stores, enriches or models a customer’s data, the security review goes deeper than usual. Customers want to see which data categories you process and why, who your subprocessors are, where the data sits, how long you keep it, what your DPA says, and — increasingly — how models are involved. VendorLens gives you one branded trust center where those documents and statements live, with per-document access rules and a record of what was shared.
Built for the company being reviewed
This page is about security, privacy and AI-governance assurance for companies that sell data and AI products to other businesses — presenting your own evidence to the customers reviewing you.
Who this is for
- You sell a data, analytics, enrichment, ETL, warehouse-adjacent or AI product to other businesses, and you are the company being reviewed.
- Your customers’ privacy, security and procurement teams ask about processing purpose, subprocessors, residency and retention before they sign.
- You already hold the underlying evidence — audit report, certificates, DPA, subprocessor list, policies, pen-test summary — and want one controlled place to share it.
- Some of that evidence is sensitive enough that it should sit behind a request and an NDA rather than a public download.
What this page does not claim
- It is not a data marketplace, data catalogue or a place to buy, sell or list datasets.
- It is not a data-verification, data-enrichment or vendor-data subscription — VendorLens holds no data about other companies.
- It is not an assurance or certification body: VendorLens does not audit, verify, score or attest to anything you publish.
- It is not a continuous monitoring platform for your own suppliers — for that direction, see the vendor due-diligence page.
The eight topics a customer review keeps returning to
Each one is answered by a document or a written statement you already own — or by noticing that you do not yet have one.
Data categories and processing purpose
What customers askWhich categories of data does the product touch — account data, usage telemetry, customer content, personal data, special categories — and for what purpose is each one processed?
What you publishA plain processing summary per category and purpose, usually published openly, with the DPA schedule as the detailed version behind it.
Subprocessor transparency
What customers askWho else touches the data, for what, and from where? Reviewers also ask how they will hear about a change.
What you publishA versioned subprocessor list with entity, purpose and hosting region, plus a last-updated date. Update it in place so no one is reading a stale PDF.
Data residency
What customers askWhere is data stored and processed, which regions can be selected, and what happens on a cross-border transfer?
What you publishA residency statement per region you support and the transfer mechanism you rely on, kept alongside the DPA so the two never disagree.
Retention and deletion
What customers askHow long is data kept, what happens at the end of the contract, and how quickly can a deletion request be honoured?
What you publishA retention and deletion summary with the periods you actually commit to, including backups and any derived or aggregated data.
DPA and privacy documentation
What customers askIs there a signable DPA, does it cover the current transfer mechanism, and where is the privacy notice?
What you publishThe current DPA version, privacy notice, and any regional annexes — dated, so a reviewer can see which version they are reading.
SOC 2 and ISO evidence
What customers askIs there a SOC 2 report covering a current period, or an ISO 27001 certificate with a scope that includes this product?
What you publishThe audit report or certificate, the period or expiry date, and a bridge letter when the next period has not closed. Typically request-gated.
Penetration testing
What customers askWhen was the last test, who performed it, what was in scope, and what happened to the findings?
What you publishA shareable pen-test summary and a remediation note. Raw findings stay out of the portal.
AI model and data-use disclosures (where applicable)
What customers askIf models are involved: are customer inputs used for training, can that be turned off, which model providers are subprocessors, and how long do inputs persist in the pipeline?
What you publishYour own written statements on training use, opt-out, retention in the model pipeline and model providers — published as documents like any other evidence.
Sample document checklist
A typical evidence set for a data or AI vendor, and the access posture teams usually choose for each item. You decide what is open and what sits behind a request — VendorLens does not review or validate the contents.
| Document | What it covers | Usual access |
|---|---|---|
| Processing and data-categories summary | What data the product touches and the purpose for each category. | Usually open |
| Subprocessor list | Entity, purpose, hosting region and last-updated date. | Usually open |
| Data residency statement | Storage and processing regions, selectable options, transfer mechanism. | Usually open |
| Retention and deletion summary | Retention periods, end-of-contract deletion, backups and derived data. | Usually open |
| Data processing agreement (DPA) | Signable terms plus regional annexes, with a version date. | Usually open |
| Privacy notice | Roles, lawful basis and data-subject rights handling. | Usually open |
| SOC 2 report (and bridge letter) | Type, audit period and the trust criteria in scope. | Request and NDA |
| ISO 27001 certificate and scope statement | Certificate number, expiry and whether this product is in scope. | Open certificate, gated scope detail |
| Penetration-test summary | Test date, tester, scope and remediation status. | Request and NDA |
| Security overview or whitepaper | Encryption, access control, logging, tenancy and hosting. | Usually open |
| AI data-use and model statement (where applicable) | Training use, opt-out, input retention, model providers as subprocessors. | Usually open |
| Incident-response and continuity summaries | Notification commitments, RPO and RTO, last restore test. | Usually open |
Who reviews you, and what they open first
Privacy lead or DPO
Opens the DPA, the subprocessor list and the residency statement first, and checks that the three agree with each other. Their blocker is usually a missing transfer mechanism or a subprocessor with no stated region — not a missing audit report.
Security reviewer
Wants the SOC 2 report or ISO certificate with dates, the pen-test summary and the security overview. They care whether the report period is current and whether the certificate scope actually covers the product being bought.
Procurement or vendor management
Collects the pack, records which documents were received and when, and needs the same link to still work at the next reassessment. Access history matters more to them than any single file.
AI or model-risk reviewer
Appears when models are part of the purchase. Asks about training use of customer inputs, opt-out, retention inside the model pipeline, and which model providers sit in the subprocessor list. Your written statement is what they read.
Common review questions, answered from your own documents
The answer column names the evidence a reviewer reads. The wording of every claim inside it is yours.
| Question | Answered by |
|---|---|
| What personal data does the product process, and on what basis? | Processing and data-categories summary, plus the DPA schedule and privacy notice. |
| Who are your subprocessors, and how will we hear about changes? | Versioned subprocessor list with a last-updated date, and your change-notification statement. |
| Can our data stay in the EU? | Data residency statement for the regions you support, and the transfer mechanism in the DPA. |
| How long do you keep data after we terminate? | Retention and deletion summary, including backups and derived data. |
| Is there a current SOC 2 report we can review? | SOC 2 report with its audit period, released after a request and NDA, plus a bridge letter if the period has not closed. |
| Does your ISO 27001 scope include this product? | Certificate with number and expiry, alongside the scope statement. |
| When was your last penetration test, and were findings fixed? | Pen-test summary and remediation note. |
| Do you train models on our data, and can we opt out? | Your AI data-use and model statement, with the model providers listed as subprocessors. |
What a reviewer actually sees
If models are part of your product
Reviewers now ask a predictable set of questions about model and data use. VendorLens hosts the statements you write in response and controls who can read them. It does not assess your models, your training pipeline or the accuracy of your disclosures.
- Whether customer inputs, outputs or metadata are used to train or improve models, and whether that is on by default.
- How a customer turns training use off, and what changes for them when they do.
- How long inputs and outputs persist inside the inference pipeline, including any vendor-side logging.
- Which model or inference providers are involved, so they can be read as subprocessors with a purpose and a region.
- Whether human review of customer content happens, and under what controls.
Questions from data and AI teams
Put your processing, privacy and security evidence in one place
Publish what can be open, keep the audit report and pen-test summary behind a request, and keep the subprocessor and residency statements current in one edit.