Third-party risk management is usually funded as a cost of doing business: a regulator expects it, an auditor tests it, a customer asks about it. That framing makes it easy to approve a small budget and hard to approve a better one. Yet a vendor programme touches money in at least four places a CFO already cares about: the hours skilled people spend reading documents and chasing vendors, the value the business loses while it waits for approvals, the spend on tools the organisation already owns, and the cost of the breach that starts at a supplier.
This post builds a business case on those four lines. It does not supply your numbers, because we do not have them and invented benchmarks would not survive a finance review. Instead it gives the model, the inputs to measure and where to find each one, so the case you take to the CFO is built from your own data. Examples use the demo organisation in our screenshots, Northwind Labs, whose vendors are fictional.
In short
- Four value lines. Reviewer hours, business cycle time, duplicate and auto-renewed spend, and third-party breach exposure.
- Two are hard savings, two are risk and opportunity. Hours and avoided spend can be counted; cycle time and breach exposure are estimated, and should be presented as ranges.
- Measure before you buy. Twenty recent requests and one year of renewals give you most of the inputs.
- Count the costs honestly. Licence (priced by vendors under management), set-up time, and the people time to review what agents prepare. Agents do not remove decisions.
- Present it as a range with a test. A ninety-day pilot on real vendors turns assumptions into your own figures.
Why the usual case is weak
Most TPRM business cases argue from fear: a supplier breach could cost millions, therefore buy a tool. Finance teams discount that argument, reasonably, because the probability is unknown and the tool does not obviously change it. The stronger case starts with costs the organisation is already paying every month and can measure, then adds risk reduction on top as a range rather than a headline. It is also more honest, which matters when the same CFO is asked to renew the budget a year later.
reading and chasing"] P --> C["Cycle time
value the business waits for"] P --> S["Spend
duplicates and missed notice dates"] P --> B["Breach exposure
third-party incidents"] H --> V1["Hard saving or capacity"] S --> V1 C --> V2["Estimated, as a range"] B --> V2
Four value lines. Two can be counted; two should be estimated and shown as ranges.
Line one: reviewer hours
Security, privacy, legal and procurement staff are among the most expensive people in the organisation, and a large share of their vendor-review time goes on work that is reading or chasing rather than judging: opening a SOC 2 report to find the audit period and exceptions, comparing a contract to the playbook, re-asking questions a document already answers, sending reminders. These are exactly the tasks agents can prepare.
In InsightVendors, the Document agent extracts the facts from SOC reports, certificates, penetration tests, insurance certificates, DPAs and contracts, citing the page for each finding. The Assessment agent pre-fills questionnaire answers already proven by documents on file and sends the vendor only the rest. The Contract agent checks clauses against the playbook and proposes redlines. Reviewers still check and decide, so the saving is the difference between reading everything and checking what was prepared.
| Input | How to measure it | Where to find it |
|---|---|---|
| Reviews per year, by tier | Count new vendors, new uses and renewals reviewed last year | Procurement records, ticket system, the vendor spreadsheet |
| Hours per review, by lane | Ask each lane owner to time five recent reviews honestly | Security, privacy, legal, procurement |
| Share of those hours spent reading and chasing | Split each timed review into reading, chasing, judging and writing | The same five reviews |
| Loaded hourly cost per lane | Salary plus overheads, from finance | Finance |
| Expected reduction in reading and chasing | Your assumption, tested in a pilot. Present a low and a high case. | Pilot results |
The formula is simple: reviews × hours per review × share spent reading and chasing × expected reduction × hourly cost. Two cautions. First, most organisations will not reduce headcount; the saving shows up as capacity to review vendors that are currently waved through, or to read the documents that are currently skimmed. Say so. Second, the reduction is an assumption until you have tested it, so present a range.
Line two: the business waiting
Every week a tool waits for approval is a week its value is not delivered. That cost is real and usually larger than reviewer hours, but it is harder to count. The honest approach is to take a handful of recent, material requests — a sales tool, a support tool, an AI pilot — and ask the business owner what a week's delay cost, in their own terms: deals not recorded, tickets not deflected, a pilot pushed into the next quarter.
Cycle time falls when requests arrive complete, reviews run in parallel lanes with service levels instead of in single file, and vendors are asked fewer questions. The demo's lane service levels are five business days for security and legal, four for privacy, three for finance and IT and two for the business owner; in parallel, the longest lane sets the pace. The insights page shows the average days requests actually spend in each lane, which is the number to baseline now and compare after.
There is a second, quieter benefit: fewer purchases made around the process. When the official route is fast, fewer teams sign up on a card and accept the vendor's standard terms. That is a risk benefit as much as a financial one, and it is hard to quantify; mention it, do not price it.
Line three: spend you did not need
This is often the easiest money in the case. Two sources are common.
Duplicate tools. Different teams buy tools that do the same job. When a request arrives, the Intake agent checks for an existing vendor, contract or approved alternative. In the demo, a request for Gong as a sales call recorder is met with “You may already have this — Callwave is an approved CRM & sales vendor.” Whether the answer is to extend Callwave or to move to Gong and retire it, the decision is made with both costs on the table.
Renewals that renew themselves. Many vendor contracts renew automatically unless notice is given by a date months before the end of the term. Miss the notice date and the organisation pays for another year, often at a higher price, whether or not it still wants the tool. InsightVendors sorts the renewal calendar by the date notice must be given, not the end date, and the Renewal agent recommends renew, renegotiate or offboard 90, 60 and 30 days before notice, with spend, risk trend and open findings attached. In the demo, Ledgerly's notice date of 4 November 2026 has already passed: the kind of miss this line is about.
To size this line, list last year's renewals and mark which ones renewed without a decision, which were for tools with low or falling use, and which overlapped with another tool. Finance can usually do this in an afternoon. Usage data from identity providers such as Okta, Google Workspace and Entra ID would sharpen it; that discovery is planned for 1.1, not available in 1.0.
Line four: breach exposure
Third-party breaches are expensive and becoming more common. This line belongs in the case, but as a range with clear assumptions, never as the headline.
data
IBM's Cost of a Data Breach Report 2024 put the global average cost of a data breach at about US$4.9 million, and found that breaches involving supply-chain or third-party compromise tend to cost more and take longer to identify and contain. Verizon's Data Breach Investigations Report has reported a sharp rise in the share of breaches involving a third party.
Sources: IBM Cost of a Data Breach Report 2024; Verizon Data Breach Investigations Report 2024 and 2025. Averages hide wide variation by sector, size and region; use them for direction, not as your expected loss.
What a TPRM programme changes is not whether a vendor is breached but how exposed you are when it happens and how fast you react. Exposure falls when vendors hold less of your data because the contract and DPA were checked before signature, when weak vendors are found and remediated or replaced, and when a breach signal triggers a re-assessment the same day. A defensible way to present it: the number of Tier 1 and Tier 2 vendors with open critical findings or expired evidence today, the plan to bring that to zero, and the industry figures above as context for why it matters.
The cost side, honestly
A case that only lists benefits will not be believed. Put the costs in the same table.
| Cost | What it is | How to size it |
|---|---|---|
| Licence | InsightVendors is priced by vendors under management | Ask us for a quote against your vendor count; pricing is not published |
| Set-up | Importing vendors and contracts, writing tiering and routing rules, uploading documents, the contract playbook | A few weeks of a vendor-risk lead's time, plus input from security, legal and privacy |
| Review time that remains | People still review what agents prepare and make every decision | Keep it in the hours model as the share that is judging and writing |
| Calibration | Starting agents at low autonomy and raising it as they earn trust | Part of the first ninety days; see the companion post |
| Hosting, if self-hosted | Your infrastructure, PostgreSQL and, optionally, your own AI model | Your platform team's estimate |
What we cannot tell you
We do not publish customer results or benchmark savings, and we would distrust any vendor who gave you a precise percentage without seeing your process. The hours and spend lines can be measured before and after; the cycle-time and breach lines are estimates. Agents make mistakes too: that is why every finding cites its page and every message to a vendor waits for a person. Build that review time into the case rather than assuming it away.
Turning the model into a decision
Put the four lines and the costs on one page, with a low and a high case for each. Finance teams respond better to a range they can challenge than to a single number they cannot. A simple layout works:
| Line | Low case | High case | Type |
|---|---|---|---|
| Reviewer hours | Your hours model with a cautious reduction in reading and chasing | The same model with the reduction you hope to see | Capacity, or hard saving if contractors are used |
| Cycle time | Value of one week saved on the three most material requests | The same across all Tier 1 and Tier 2 requests | Estimated |
| Spend | Renewals you would have stopped or renegotiated last year | Plus duplicate tools consolidated | Hard saving |
| Breach exposure | Not priced; exposure count shown instead | Industry averages as context only | Risk reduction |
| Costs | Licence, set-up and remaining review time | Plus calibration time and, if self-hosted, hosting | Cost |
Notice that the low case can stand on the hours and spend lines alone. If the investment pays back on those, cycle time and breach exposure become upside the CFO does not have to take on trust. If it does not, the case depends on the estimated lines, and you should say so plainly.
The strongest business case ends with a test, not a forecast. Propose a time-boxed pilot on real vendors with success measures agreed with finance in advance.
Elapsed days, days per lane and reviewer hours, split into reading, chasing and judging.
Which renewed without a decision, which overlapped, which missed a notice date.
Tier 1 and Tier 2 vendors with expired evidence or open critical findings.
Use the four lines. Count the costs in the same table.
Days per lane, reviewer hours, renewals decided before notice, exposure closed.
Report the measured result, not the forecast, and decide.
The best business case for third-party risk is built from money you are already spending and time you are already losing.
Count reviewer hours and avoidable spend, estimate cycle time and breach exposure as ranges, put the costs beside them, and let a ninety-day pilot replace the assumptions with your own numbers.