Are Your Vendors Lying to You?

Your Vendors Probably Aren't Lying. That's the Worse News.

Lying would be easier to fix. A liar knows the truth and chooses to hide it. Most vendors filling out your questionnaire have no idea what the truth is.

In the latest episode of the Third Party podcast, Jeffrey Wheatman, Bob Maley, and Ferhat Dikbiyik take apart the uncomfortable space between what a vendor attests to and what a vendor actually does.

The pattern repeats constantly. A customer flags a vulnerable IP address to a vendor. The vendor says it isn't theirs. The customer pushes back. The vendor checks again and finds a backup server nobody ever added to the digital inventory.

That isn't dishonesty. That's an asset list that quietly stopped being true. Questionnaire answers are aspirational and point in time. They describe policy, not practice.

A Yes or No Answer Measures Compliance, Not Control Efficiency

"Do you require MFA?" is a compliance question. "What percentage of your systems enforce it, and which ones?" is a security question. Almost nobody asks the second one.

Policy says multi-factor everywhere. Reality is a number somewhere below 100%, and the person completing your questionnaire usually cannot tell you what that number is. Ask about the policy and you get a checkbox. Ask about the efficiency of the control and you get an actual risk signal.

The data backs this up hard. Among the 50 most-relied-on vendors across the Forbes Global 2000, the companies carrying the most certifications, the most completed questionnaires, and more scrutiny than any other suppliers on earth, the 2026 Third-Party Breach Report found:

• 70% carrying KEV-listed vulnerabilities
• 62% with corporate credentials sitting in infostealer logs
• 80% missing SPF or DMARC email protections

These are the honor students. The questionnaire and the observed data are not telling the same story about them, which should tell you something about the rest of your portfolio.

Verification Has Three Modes. Most Programs Use One.

"Trust but verify" gets quoted far more than it gets practiced. Part of the problem is that "verify" sounds like a single activity. It's three.

• Signals. Externally observable evidence: exposed services, known vulnerabilities, missing email authentication records, leaked credentials.
• Behavior analysis. Not whether a vendor has vulnerabilities, because every vendor does, but how fast they remediate them. Patching cadence is a personality trait.
• Testimony. What the vendor tells you: questionnaires, SOC 2 reports, ISO certifications.

Testimony is the weakest of the three, and it's the one most TPCRM programs lean on hardest. That doesn't make third-party audits worthless. A SOC 2 is genuinely useful if you read it and know which domains it covers.

But every company that got breached while holding a valid PCI certification is a reminder that a certificate documents a moment, not a condition. It's the difference between reading the changelog and running the code.

The fix isn't abandoning attestation. It's inverting the order. Start the vendor review with observed evidence, then use the questionnaire to fill the gaps. Most programs still do exactly the reverse.

Every Signal Needs a Confidence Level

You cannot fight every battle, so stop trying. Choosing which findings to push on is the actual skill, and confidence is how you choose.

A missing DMARC record is observable from the outside with near-total certainty. No vendor is going to talk you out of it. A possible vulnerability on an IP address you aren't certain belongs to them is a conversation, not an accusation. Same program, completely different posture.

Attaching a confidence level to every signal is what turns monitoring data into a decision, and it's what keeps the vendor relationship intact while you do it. High confidence earns a direct ask. Lower confidence earns a question. That logic is the whole point of FocusTags® and of treating cyber risk intelligence as something more useful than a finding count.

Effort should also scale with the vendor. You are not sending an auditor to 20,000 vendors. You might send one to 20. Good luck telling a hyperscaler you're stopping by Thursday. The mistake most programs make is looking at the entire vendor population through one set of lenses.

And the gap is bigger than the vendors. Only 33% of organizations fully map their third-party ecosystem, and just 27% simulate cyber incidents with their supply chain, according to the WEF Global Cybersecurity Outlook 2026. "Verify" isn't mostly failing at the vendor. It's missing from the program.

AI Is Turning Trust But Verify Into Trust But No Verify

Verification has a new problem, and it isn't the vendor. It is genuinely hard to verify the output of an AI, and AI now sits on both ends of the questionnaire.

When you ask what percentage of a vendor's systems enforce multi-factor, nobody walks the estate and counts anymore. An AI is monitoring the environment and answers 80%.

So you ask the obvious follow-up: how did you get to 80%? The vendor may not be able to tell you either, because the reasoning also came from AI. Trust but verify quietly becomes trust but no verify.

Push one step further back and it gets worse. That AI ingested data about MFA from somewhere. Where does that data come from, and how reliable are those systems? A confident number built on unreliable telemetry is more dangerous than no number at all.

The risk isn't that the model is wrong. It's the false sense of security that arrives with a fast, clean answer, plus the cognitive decline studies keep finding in heavy LLM use. Nobody checked, and nobody feels the need to.

Verification survives only if it stays anchored to something observable from outside the vendor's environment. That's the case for threat actor monitoring and observed susceptibility over static self-assessment, and for using The Bridge™ to take a finding straight to a vendor's security team instead of their account manager. Security teams answer differently than sales teams do.

Four things worth changing before your next review cycle:

1. Track fewer vendor claims. Observe more vendor behaviors.
2. Give every signal a confidence level before you take it to a vendor. (The Black Kite platform does this for you.)
3. Match verification depth to vendor criticality, and be honest about which vendors are actually critical.
4. When monitoring data and a questionnaire disagree, open a conversation instead of running another scan.

Most programs are built to discover and to ask. Very few are built to follow up. That gap, not vendor honesty, is where the real risk lives.

Don't Miss an Episode!

Subscribe to Third Party on YouTube, the podcast for people who don't need to ask ChatGPT what TPCRM means. New episodes every other week.

Next time on Third Party:

Next time we tackle a question we’ve been circling for months — when is a TPRM program too broken to fix, and when do you just need to restart. We’re going to be direct about what restarting actually means.

Subscribe below.