Updated:
August 12, 2026
August 12, 2026
There's a moment I've noticed in a lot of calls with TPRM managers. Someone asks a question that should have a one-line answer: "How many third parties do you have?" And the answer isn't a number. It's a pause, a caveat, then a promise to follow up.
The real vendor list doesn't live in one place. Part of it is in the procurement system. Part of it is a spreadsheet one person maintains and everyone else copies from. Part of it is contracts that were signed years before anyone thought to track them centrally. At a company with subsidiaries, acquisitions folded in over the years, multiple business units, and a handful of jurisdictions, "part of it" turns into four or five different places that don't fully agree with each other.
One security lead at an AI infrastructure company put the consequence plainly: "It's very hard to easily see what are all my Tier 1 vendors. It's a very hard view to get."
Reassessments cluster because vendors were onboarded in the same busy quarter and the backlog isn't a sign the team is behind, it's arithmetic. This many vendors, this much depth required per tier, this many hours in a quarter.
And underneath this equation is the manual work that is all too familiar in GRC. A GRC lead at a sports franchise built her vendor intake as an Excel form she emails to business owners, and everything lands back in Excel to be consolidated by hand. At a fast-growing AI company, the same job runs through direct messages: "I can't wait to have a TPRM tool and not have this incredibly manual DM talks I'm getting right now." One person there told us she was facing roughly 100 vendors to risk-adjust by hand.
Different companies, different sizes, same shape. A team doing document logistics, and calling it risk management because there's no time left over to do the other thing.
The industry is answering the wrong question
The industry's answer to this has been to make the questionnaire faster: autofill the answers, summarize the responses, auto-score what comes back. That's true whether the questionnaire is a PDF you email around or a compliance tool that uses AI to fill it out faster. Same workflow, just quicker. All of it treats speed as the constraint.
But that's not what we heard from teams. A questionnaire asks a vendor to describe its own controls, and you grade the description. Whatever comes back is the vendor's account of itself. Every decision downstream, the tier you assign, the residual score, the exception you grant, rests on that one unverified document. Making it arrive faster doesn't fix that. It just gets you to an unverified conclusion sooner.
So why has the whole category converged on the same broken instrument? The clearest answer I've heard came from a customer: "The most challenging part is probably getting the material. The fact that nobody in the industry has found a uniform way for us to be able to go in and get access to things."
That's the root of the problem. There has never been a standard way for a vendor to hand you their security posture, so every program fell back on the one method that always works: ask them to type it out. The questionnaire is the workaround everyone adopted for a missing interface, and then thirty years of tooling got built on top of the workaround.
The evidence that actually answers the question was sitting there the whole time. ISO 27001 certificates with real expiry dates. Pen test reports. Subprocessor lists. DPAs. Trust center documentation. Audit reports. A vendor can produce these, and you can verify them against what's claimed. That's a different relationship than asking someone to characterize themselves and hoping they're accurate.
We're not the only ones who got here. A security leader at a large enterprise described the end state to us before we ever showed him anything: stop reaching out to vendors for their security posture at all, and instead use their existing certifications and audit reports and public information to make the determination.
So here's where we come in: we kept the questions and verified the input. Anecdotes TPRM is question-driven, not questionnaire-driven. Your question sets stay exactly as they are. What goes away is the manual, self-attested questionnaire as the default way you collect answers.
The questions stay. The questionnaire goes.
{{ banner-image }}
The five decisions
None of this works as one feature. It's five key features we built into the product, each one a choice against an alternative option we didn't take.
Agents that do the work, not agents that fill in the form. The easy version of "AI in TPRM" is an assistant that drafts the vendor's questionnaire responses, or drafts your review notes a little faster. We didn't build that. Our agents collect, read, and verify the actual evidence documents. That's the work of TPRM, not the paperwork around it.
Scores calculated against your specific program, not a universal benchmark. The easier path here is a fixed formula and a vendor rating feed: a portable score, the same for every customer. It demos well. It doesn't hold up as a decision. Your risk tiers, your thresholds, and your tolerance for a given control gap aren't the same as anyone else's. We calculate risk against your program, so the score is relevant to the person who has to defend it later. This is also the one that gets pushback in demos: people ask how they compare to a "universal" benchmark. The honest answer is that a benchmark built on someone else's methodology tells you very little about whether a vendor clears your bar. A score tied to your program is harder to compare to a peer's, but it's the one you can actually stand behind.
Your methodology converted, not replaced. The standard version is a generic best-practice template you adopt, and you adjust your program to fit it. We went the other way. We convert your existing methodology into the system, so the tool bends to how you already assess risk instead of asking you to bend to it.
Human-in-the-loop by design, not by default. Of the five, this one is critical. It would have been easier to pick one fixed setting, full autonomy or a human checking every step, and ship that. We didn't do that. It's not a hedge. It's a choice we handed to you. You decide how much oversight you want, by tier. Require your approval as a gate on classification or assessment results for your critical vendors, and the agents stop and wait for you. Or let them run all the way through. Either way, whatever needs you shows up in one place, an action-required queue sorted by the type of decision it is. If it's empty, your program is running itself. If it's not, you know exactly what's waiting and why. And every action still carries the reasoning behind it, so nothing happens that you couldn't explain later if someone asked.
Discovery that reads your environment. Every other version asks the customer to upload their vendor list, the same list that was already incomplete in four or five places. We built discovery that reads your actual environment instead of asking you to hand us the same fragmented picture you started with.
What the agents actually own
"Agentic" is doing a lot of unexamined work in this market right now, so here is the literal version.
A vendor enters your program one of two ways. Discovery finds it by reading the systems you already have connected, or someone adds it by name. From there it moves through a pipeline where each stage is a different agent with a different job, and each one hands off to the next.
Enrichment builds the vendor's profile and pulls in what the later stages will need.
Classification runs the vendor against your tier logic, answers your classification questions, and assigns the tier.
Document collection works out which documents are actually in scope for that tier, fetches the public ones, requests the private ones, and validates each one as it arrives.
Assessment answers your question set for that tier. Every question comes back pass, fail, or incomplete, with the source document, the section it came from, and a confidence level attached.
Risk score produces a residual score with a written explanation of what pushed it up and what pushed it down.
What matters here is there's no human queue between the stages. A vendor goes from discovered to scored without anyone assembling it by hand, and the trail from the score back to the sentence in the PDF that produced it stays intact the whole way.
Two things the agents don't own. They don't own the setup: you pick the starting preset, then review the tiers, the classification rules, and the question sets before anything runs. And they don't own the decisions you want to make.
What happens after the assessment
An assessment is a photograph. Programs don't usually fail because the photograph was bad. They fail in month fourteen, when nobody remembers to take another one.
This is the part every customer raised and none of them believed was solved. One of them described the thing he wanted as a button that would come back in a year or two, go to the vendor, and run it again, and then said he had never met a tool that does it.
So we built the agents that run in the background and don't stop. They track reassessment against the cadence you set for each tier. They watch for documents that have gone stale, which for most vendors is the first real signal that something has changed. And when a document is replaced or a gap closes, the vendor's score is recalculated rather than left sitting at whatever it was the day you last looked.
Cadence is per tier because real policies aren't uniform. One customer walked us through theirs: some vendors annually, some every two years, some every three, and any of them pulled forward immediately on a confirmed breach in the market. A tool that only understands "annual" can't hold a policy like that, so ours holds multiple tiers, each on its own clock, and you can always trigger a reassessment by hand.
One vendor is never the question
Assessing a single vendor well is table stakes. Nobody's board asks about a single vendor.
Go back to the security lead at the top of this piece, the one who couldn't easily see all his Tier 1 vendors. That's the actual question, and almost every program answers it by exporting to CSV and building the view by hand, which means the view is only accurate on the morning somebody built it.
So the portfolio is the primary surface, not a report you generate. Filter it by tier, by score, by status, by what's due next and what's already overdue. Two vendors with the same score aren't the same problem if one is Tier 1 and the other isn't, so inherent risk and residual risk stay visible as separate things rather than collapsed into a single number. Findings carry a severity, an owner, and a status, so "we have a gap" and "someone is fixing the gap" aren't the same row. And you can ask the portfolio a question directly instead of building a query.
The part that matters most is where all of it lives. Vendor risk sits on the same data foundation and the same risk register as your compliance program, which means third-party risk stops being a parallel universe with its own definitions and its own spreadsheet. When someone asks how exposed you are, the answer comes from one system, and it's the same system the rest of your GRC program already runs on.
What actually changes for you
Here's the honest before-and-after, because "AI does the work" is a sentence that should make a GRC professional nervous.
What goes away is the logistics. Chasing a vendor for eight weeks for a document. Reading a hundred-page report to locate one control. Re-keying findings into a spreadsheet so the spreadsheet stays current. Holding the reassessment calendar in your head. One customer described this as administrative work that adds burden without adding value, which is a fair description of most of a TPRM manager's week.
What doesn't go away is your program. You set the tiers and what puts a vendor in each one. You set the questions, the thresholds, what evidence you'll accept and what you won't. You approve or you override, and when you override, the reason is recorded next to it. Every judgment call in the process is still yours, because the agents are extremely good at collection and verification and have no opinion whatsoever about your organization's risk appetite.
The change isn't that the job gets smaller. It's that the ratio inverts. Most third-party risk roles today are roughly ninety percent administration and ten percent analysis, and the ten percent is the part you were actually hired for. A customer told us they were trying to work out whether their vendor volume meant hiring someone whose entire job would be TPRM administration. That's the trade this is meant to remove: not the analyst, it's the manual work that floods your bandwidth and makes it difficult to focus on what you need to.
You stop being the courier for your own program and go back to being the person who decides.
Go count
If you want a version of this exercise before you talk to us: count your third parties. Then count how many were actually assessed in the last twelve months, at the depth their tier requires. Look at the difference between those two numbers.
That difference isn't a reflection on your team. It's a function of the model you're running.
With Agentic TPRM, you set the rules. The agents do the work.
