Vendor security review exists as a formal discipline — TPRM, Third-Party Risk Management — because a buyer's own security posture is only as strong as the weakest vendor with access to their data or systems. If you're a founder preparing for your first serious enterprise security review, the questions generally fall into two layers: general security hygiene, and — if your product involves AI — a second, newer layer most legacy vendor-risk processes weren't built to ask.
Layer one: general security hygiene
This is the layer every vendor gets evaluated on, AI or not. A CISO (or the tool/process standing in for one) is typically looking at:
- Certifications and audits — SOC 2 (Type I or Type II — Type II is the stronger signal, since it covers controls operating effectively over months rather than a single point in time), ISO 27001 for information security management, and industry-specific requirements like HIPAA if you handle health data.
- Responsible disclosure — whether you have a published process for how outside researchers report a vulnerability to you, typically via a security.txt file.
- Baseline technical hygiene — HSTS enforcement, security headers, and email authentication (SPF/DKIM/DMARC) are all lightweight, easily checked signals of whether an organization takes security seriously at an operational level.
- Vulnerability handling — whether you run a bug bounty program, and how you handle known CVEs in your own dependencies.
- Data handling terms — a DPA (Data Processing Agreement) governing how you handle a customer's data, particularly if GDPR applies.
- Subprocessors — the third parties you use to process customer data on your behalf. A buyer's security team wants to know who else has access to their data through you, not just what you do directly.
Layer two: what's specific to AI vendors
This is the layer generic vendor-risk tooling and older TPRM checklists weren't built to ask, because it isn't observable from a network scan or a certificate check — it's a disclosure question. See why "AI-native" isn't a security claim for more on why the label itself doesn't answer any of these:
- Does the vendor disclose which foundation model they're actually built on — or are they a thin interface layer over someone else's API without saying so?
- Training data provenance — what data trained or fine-tuned the model, and under what rights.
- Opt-in vs. opt-out — whether customer prompts or data are used to train the vendor's models by default (opt-out) or only with explicit permission (opt-in). This is one of the first questions a security-literate buyer will ask about an AI tool, since it determines whether their own data could end up influencing a model other customers interact with.
- Model cards — published documentation of a model's training data, intended use, limitations, and evaluation results.
- A subprocessor list that actually names the AI providers involved — the same subprocessor-transparency question from layer one, applied specifically to whichever foundation model or AI infrastructure provider sits underneath the product.
Disclosure vs. verification — the distinction that matters most
Most of what a due-diligence process actually produces splits into two very different kinds of confidence: disclosure (the vendor told us this) and verification (someone independently confirmed it's true). A SOC 2 report is verification — an accredited third party audited the controls. A subprocessor list or a training-data-use policy is usually disclosure — the vendor is stating it, not proving it via an external audit. Neither is worthless, but they aren't the same kind of evidence, and a careful buyer (or a careful vendor preparing for review) should be explicit about which is which rather than letting a confident-sounding answer imply more rigor than it actually has.
Why this takes weeks per vendor today
None of the above is a secret checklist — it's largely the same set of questions asked over and over, one procurement cycle at a time, by every buyer independently. That's the real cost: the work of assembling and verifying this evidence gets repeated dozens or hundreds of times for the same vendor, by different buyer security teams who each start from zero.