By Clarence Chio, CEO of Coverbase
Regulators and auditors are rewriting the standard for third-party risk management, and most programs aren’t built to meet it. The old benchmark was straightforward, asking simply whether you assessed a vendor. The emerging one is how fast you detected and responded once something changed about that vendor. Those are very different questions, and the gap between the two is where breaches are happening.
MOVEit, Snowflake, Change Healthcare all have something in common. Each held current, approved vendor status right up until the incident hit the news. These included:
- A questionnaire completed in Q1.
- A SOC 2 report dated January.
- A tiering decision made at onboarding.
Despite the fact that none of these tells you what a vendor’s exposure looks like today, most TPRM programs remain anchored to this kind of point-in-time evidence. But treating a completed assessment as a durable statement of risk instead of a snapshot that starts decaying the moment it’s filed is no longer sufficient.
A Different Audit Question
The shift shows up most clearly in what regulators and auditors are starting to ask. It used to be enough to show that a vendor was assessed before onboarding and re-assessed on some annual cadence. The question today is much sharper—when you found out something had changed, how fast did you act on it? A program built to answer the question, “did we assess this vendor,” cannot answer “how fast did you respond?” The latter requires a different infrastructure. One is a filing system. The other is a detection-and-response loop that most TPRM functions were not built for.
That’s the core problem with point-in-time evidence. Namely, it creates false assurance. A questionnaire captures a vendor’s posture as they described it, at a moment they chose to describe it. It says nothing about a credential leaked last week, a subprocessor added last month, or a breach disclosed by a fourth party the vendor depends on. Programs that rely on annual or even quarterly refresh cycles are, by construction, always looking backward.
Where Continuous Monitoring Breaks Down
Recognizing the problem is easy. Fixing it is where most security and procurement leaders get stuck, and the failures tend to compound.
The first is noise without context. External scanners are good at surfacing signals such as a CVE, an exposed port, or a leaked credential. Where they fall short is their inability to tell you whether any of it matters. A CVE against a vendor’s IP range means very little on its own. It means something entirely different if that vendor touches your production environment versus if they’re a marketing tool with no data access. Without that business context, every alert looks equally urgent, which in practice means none of them do.
The second is how risk scores get used. A single number is useful as an input to a decision, but too many programs treat the score as the decision itself: a liability shield to point to rather than a tool to reason with. “The vendor scored a B” answers an audit question, not a risk question. It tells you nothing about what changed, why, or what to do next.
The third is ownership. When a monitoring alert fires, it’s often unclear whose job it is to act on it. Procurement owns the contract, security owns the technical risk, legal owns the liability language, and an alert that touches all three often belongs to none of them in practice. Signals without a clear owner get acknowledged and shelved, which defeats the purpose of monitoring in the first place.
Moving From Filing Systems to a Detection-and-Response Loop
Adding a monitoring tool doesn’t fix this on its own. It usually just adds more unattributed alerts to a process that already can’t route the ones it has. The missing piece isn’t more external signal. It’s the internal context a program already holds. Think contract terms, tier definitions, data access scope, and prior assessment findings. These turn a raw signal into something you can actually prioritize and route to the right person. A leaked credential at a Tier 1 vendor with production access is a different problem, with a different owner and a different clock, than the same credential leaked at a Tier 3 vendor with no system access. Without the internal layer, a monitoring platform can’t tell the two apart.
The goal isn’t a bigger stream of alerts. It’s fewer, better-routed recommendations that land with the person who can act on them, backed by enough context to know what action is warranted. That’s what turns continuous monitoring from a dashboard nobody checks into an operating capability. It’s also the only way to build a program that can answer the question auditors are starting to ask—not just whether the vendor was assessed, but how quickly you knew, and how quickly you moved.
##
ABOUT THE AUTHOR
Clarence Chio, CEO and Co-founder, Coverbase
Clarence is the cofounder and CEO at Coverbase, the leading AI procurement and risk company that recently raised $20m from top investors to automate 90% of vendor management. Prior to this, he cofounded Unit21, a Google-backed company that raised $92m to help top financial institutions combat fraud and money laundering with AI. He has degrees in Computer Science and AI from Stanford, published the book “Machine Learning and Security” with O’Reilly Media, and teaches AI and security at UC Berkeley.
