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.

flowchart LR P["Agentic TPRM programme"] --> H["Reviewer hours
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.

InputHow to measure itWhere to find it
Reviews per year, by tierCount new vendors, new uses and renewals reviewed last yearProcurement records, ticket system, the vendor spreadsheet
Hours per review, by laneAsk each lane owner to time five recent reviews honestlySecurity, privacy, legal, procurement
Share of those hours spent reading and chasingSplit each timed review into reading, chasing, judging and writingThe same five reviews
Loaded hourly cost per laneSalary plus overheads, from financeFinance
Expected reduction in reading and chasingYour 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.

Insights page: spend under management by tier, tier by residual risk heat map, average days per lane, requests by month
The baseline and the result on one page. Where requests wait, in average days per lane, beside spend by tier and the risk heat map.

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.

The Intake agent's proposal for the Gong request, warning that Callwave is already an approved vendor and listing the questions it could not answer
Savings start at intake. The duplicate warning appears before any reviewer has spent an hour on the request.

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.

Contracts and renewal calendar sorted by notice-by date, with contract values and Renewal review buttons
The calendar that matters is the notice calendar. Contracts sorted by the date notice must be given, with value and a renewal review for each.

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.

Industry
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.

CostWhat it isHow to size it
LicenceInsightVendors is priced by vendors under managementAsk us for a quote against your vendor count; pricing is not published
Set-upImporting vendors and contracts, writing tiering and routing rules, uploading documents, the contract playbookA few weeks of a vendor-risk lead's time, plus input from security, legal and privacy
Review time that remainsPeople still review what agents prepare and make every decisionKeep it in the hours model as the share that is judging and writing
CalibrationStarting agents at low autonomy and raising it as they earn trustPart of the first ninety days; see the companion post
Hosting, if self-hostedYour infrastructure, PostgreSQL and, optionally, your own AI modelYour 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:

LineLow caseHigh caseType
Reviewer hoursYour hours model with a cautious reduction in reading and chasingThe same model with the reduction you hope to seeCapacity, or hard saving if contractors are used
Cycle timeValue of one week saved on the three most material requestsThe same across all Tier 1 and Tier 2 requestsEstimated
SpendRenewals you would have stopped or renegotiated last yearPlus duplicate tools consolidatedHard saving
Breach exposureNot priced; exposure count shown insteadIndustry averages as context onlyRisk reduction
CostsLicence, set-up and remaining review timePlus calibration time and, if self-hosted, hostingCost

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.

A business case finance will acceptOwners are typical, not prescribed
1
Baseline twenty requestsVendor-risk lead

Elapsed days, days per lane and reviewer hours, split into reading, chasing and judging.

2
List last year's renewalsFinance + procurement

Which renewed without a decision, which overlapped, which missed a notice date.

3
Count today's exposureSecurity

Tier 1 and Tier 2 vendors with expired evidence or open critical findings.

4
Build low and high casesFinance

Use the four lines. Count the costs in the same table.

5
Agree pilot measuresCFO + sponsor

Days per lane, reviewer hours, renewals decided before notice, exposure closed.

6
Run ninety days and compareVendor-risk lead

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.

Keep reading