Vendor due diligence: what a company's own stack tells you

Every vendor you sign is a set of dependencies you inherit. The SaaS product you're buying runs on someone's cloud, sends mail through someone's API, processes payments through someone's rails, and hands your data to each of them in the process. Your security questionnaire asks about this. The answer arrives as a PDF, weeks later, written by someone whose job is to make it sound fine.

There is a faster and more neutral first pass: read what the vendor has already published about its own dependencies. This post is about how to do that systematically and what conclusions the data can and cannot support.

Scope: this is public information only

Be clear about the boundary before you build anything on it. What follows works entirely from a company's public web presence — trust centers, security pages, compliance documentation, and similar pages the company published itself. Nothing here involves private data, internal systems, or anything a company hasn't chosen to state publicly.

That boundary is a feature for diligence work. Every claim in your memo can be sourced to a URL on the vendor's own domain, which makes it verifiable by anyone reviewing your work, and defensible if challenged.

The first call

curl "https://api.vendorstacks.com/v1/check?url=candidate-vendor.com" \
  -H "Authorization: Bearer $VENDORSTACKS_KEY"

{
  "domain": "candidate-vendor.com",
  "found": true,
  "vendor_stack": {
    "cloud_infra": ["aws"],
    "email": ["sendgrid"],
    "payments": ["stripe"],
    "auth_identity": ["auth0"],
    "observability": ["datadog"],
    "support_cx": ["zendesk"],
    "ai_ml": ["openai"],
    "analytics_data": ["snowflake", "segment"]
  },
  "cloud_infra_evidence": [
    {
      "vendor": "aws",
      "source": "https://candidate-vendor.com/trust/subprocessors",
      "quote": "Amazon Web Services, Inc. — cloud hosting and storage (US-East)"
    }
  ],
  "subprocessor_urls": ["https://candidate-vendor.com/trust/subprocessors"],
  "vendor_confidence": "high",
  "scanned_at": "2026-07-19T16:33:12Z",
  "credits_used": 1
}

One credit, and if the domain isn't indexed yet it live-scans in 15–90 seconds. The *_evidence fields carry the verbatim source rows — that is the text you quote in a memo, and subprocessor_urls is where a reviewer goes to check it.

What to actually look at

Fourth-party exposure. Your vendor's vendors are your vendors, transitively. A candidate that names eight infrastructure providers is handing your data across eight boundaries, each with its own incident history. Not automatically disqualifying — it's how modern software is built — but it should be counted, not assumed away.

Concentration risk, in both directions. A vendor entirely dependent on one cloud region has a correlated failure mode with everything else in that region. A vendor spread across four providers has more operational surface but less correlated risk. If you are already heavily concentrated on one provider, a candidate hosted there adds nothing to your resilience — it just adds a company.

Data-path categories. Not all dependencies matter equally. The categories that touch customer data directly — cloud infrastructure, auth and identity, analytics, AI/ML, email — deserve more attention than productivity tooling. An AI/ML vendor appearing in the stack is a specific question worth asking: what data reaches it, and under what terms?

Coherence with what you were told. The most useful single check. Compare the published stack against the questionnaire response. Alignment is a small positive signal about process discipline. A significant gap is a question — often with a mundane answer, occasionally not.

Maturity signals. A stack including observability, identity management, and compliance tooling suggests an organization that has been through security review before. A stack with none of those, at a company selling to enterprises, is worth a question.

Portfolio and concentration analysis

If you're assessing more than one vendor — a procurement team reviewing a portfolio, or an investor looking across holdings — the aggregate view matters more than any individual stack. Enrich every vendor and count how many of them depend on the same underlying provider.

jq -r 'select(.found) | .vendor_stack.cloud_infra // [] | .[]' \
  portfolio.jsonl | sort | uniq -c | sort -rn

If eleven of your fourteen critical vendors publish a dependency on the same region of the same cloud provider, you have a concentration exposure that no individual vendor review would surface. That finding is worth the entire exercise on its own.

The reverse lookup helps size the question from the other end: /v1/prospect?vendor=AWS&category=cloud_infra&page=1 returns entities that publish that dependency, ten per page at 1 credit per result.

What this cannot tell you

A diligence memo is only as good as its stated limits. Four of them:

• Absence is not evidence. found: false means no public evidence was located for that domain. It does not mean the company has no vendors, and it is not a finding about their security posture. Private companies, smaller companies, and companies that simply don't maintain a public trust page all land here. Write it up as "no public disclosure located", and go ask them directly.
• Published lists lag reality. A company updates its published dependencies on whatever cadence its process runs. The scanned_at field tells you when the data was gathered; it cannot tell you when the vendor last updated the page.
• No terms, no volumes, no architecture. The data tells you a vendor relationship is stated to exist. It says nothing about contract terms, data residency beyond what the quote itself says, retention, or how the integration is actually built. Those remain questionnaire questions.
• A vendor list is not a risk assessment. It's an input. Use it to make your questions sharper and your review faster — not to replace the review.

Writing it up

The format that survives review: for each finding, state the claim, quote the source row verbatim, link the URL, and note the scan date. Then state the risk in terms of your own environment rather than in the abstract — "this vendor's stated hosting region matches our existing concentration" is a finding; "this vendor uses AWS" is a fact.

Because there is no model in the extraction path — matching is deterministic against a maintained taxonomy — the same source page always produces the same output, and every match carries the sentence it came from. For work that ends up in a memo someone will be held to, that reproducibility is the point.

Costs are trivial at diligence scale: a full portfolio review of 40 vendors is at most 40 credits, and misses are free. See pricing for the packs and the API reference for every field, including the per-category evidence structures.

Get a key — 25 free credits, no card required — and run it on the vendor whose questionnaire is currently sitting in your queue. It takes about a minute, and the published stack usually tells you which three questions to ask first.