A few TPRM vendors have started marketing a simple pitch: skip the questionnaires, we'll assess your third parties automatically using only public data. No forms, no back-and-forth, no waiting on vendors to respond. It sounds efficient, but it also sounds like something you could just do yourself with a few well-written prompts to Claude or ChatGPT.

I know that we can say that about a lot of tools these days, and so it’s actually worth sitting with for a second, because it points to the real problem: in this case, if the entire “assessment” is built on regurgitating information that anyone can already pull from a search engine or a language model, what exactly is the product? And if you take that one step further, does it actually help you manage third-party risk?

What public data actually shows about a vendor (and what it misses)

Most of what's publicly available about a company was put there on purpose. Press releases, marketing pages, SOC 2 badges on a website footer, a security page written by the same team that writes the pricing page. Even the information that isn't outright promotional, like vulnerability scans of public pages, security weaknesses discussed on Reddit, or a Glassdoor review, only shows you the parts of the business that happen to be visible from outside.

If the vendor isn't publicly traded, there's even less to work with. Private companies aren't required to disclose much of anything, and the little that leaks out tends to be incomplete or years old. A public-data-only assessment of a private vendor is mostly an assessment of what that vendor's marketing team decided to publish.

Which vendor security controls are never in public data

Access control policies. Incident response procedures. How often backups are tested. Who has admin rights to the production database and how that access gets revoked when someone leaves. None of this shows up in a Google search, and none of it shows up in an LLM's training data, because it was never posted anywhere in the first place (or if it was, it was gated behind an NDA).

Vulnerability scans and similar external signals are useful, but they're low-hanging fruit. They tell you what's visible from the outside of the building. They say nothing about what happens once you're inside.

It's a bit like judging a retail chain by touring its flagship store. The flagship is polished because it's meant to be seen. But it tells you nothing about the warehouse three states away, the training given to seasonal staff, or what happens to customer data after checkout. A vendor's public footprint is the flagship store. Everything you're actually trying to manage risk around happens somewhere else behind the scenes.

Why TPRM questionnaires stuck around (and where they fall short)

Security questionnaires have a bad reputation. They're long, repetitive, and often answered by someone who's only guessing, but nonetheless filling out the same form for the fortieth time that quarter. But they've stuck around for a reason: they're still the only mechanism most companies have for getting a vendor to state, in writing, what their actual security practices are and where the risk sits.

The problem with questionnaires isn't that they ask for too much information. It's that a self-reported answer is only as good as the honesty and attention of whoever filled it out. "Yes, we encrypt data at rest" is an answer. A copy of the actual encryption policy, or a config screenshot showing the setting enabled, is evidence.

Evidence-based TPRM: How to verify what vendors actually do

The real gap isn't between public data and questionnaires. It's between asking a vendor to describe their controls and actually checking whether the artifacts back up the description. Policy documents, system configurations, audit reports: these are the things that either confirm a vendor's claims or reveal a gap between what they say and what they do.

That's the specific thing a 200-question form isn't built to do, and it's the specific thing public data can't do at all. It requires someone, or something, to actually read the document and compare it against a defined requirement.

This is the problem Trust Chain is built to solve. Using Verify AI, it reviews the actual documentation a vendor provides and checks it against the requirements set by the company managing the risk. In practice, that turns a 200-plus question form into a request for the 10 to 15 documents that answer those questions with evidence attached, not a self-reported checkbox. The result is a vendor assessment grounded in what the vendor does, not just what they say.

Effective vendor risk assessment requires:

• Vendor-provided documentation, not just publicly visible data
• A mechanism to compare that documentation against defined requirements
• Evidence that confirms stated controls, not just self-reported checkboxes

Public data can tell you a vendor exists and looks fine from the outside. It can't tell you whether the store is locked at night.