Your customers, your regulators and your attackers no longer see a boundary at the contract

For most of the last twenty years, a vendor was something you bought, not something you were. A contract drew the line: their systems, their people, their problem. That line has stopped meaning much. Your customer data sits in a dozen software-as-a-service tools. Your payments run through a provider you have never visited. Your support team wants an AI tool that learns from ticket history. When one of those vendors is breached, goes down or quietly changes what it does with your data, your customers, your regulators and your board treat it as your incident, because it is.

This post is about what changed, what it costs, and what a third-party risk management (TPRM) programme now has to do. It is written for anyone who owns part of the answer: the CISO, the head of procurement, legal and privacy counsel, finance and the executive who signs off on all of them. Where it shows the product, it uses the demo organisation in our screenshots, Northwind Labs, and its vendors, all of which are fictional.

What changed: the boundary moved

Three shifts made third-party risk a first-party problem. None of them is new on its own; together they changed the scale.

The data left the building. A mid-sized company now runs its sales calls, support tickets, payroll, accounts payable, code and production hosting on other people's platforms. Each of those vendors holds some of the organisation's most sensitive data, often with standing access through an integration. The data map is no longer a diagram of your systems; it is a diagram of your contracts.

Operations concentrated. Many organisations depend on a small number of cloud, identity, security and payments providers, and so do their vendors. An outage at one shared provider can take down several of your suppliers at once. That is concentration risk, and it is invisible if you only look at your direct vendors one at a time.

AI vendors arrived. Tools that draft, summarise and answer are easy to buy and easy to like. They also raise a question older software rarely did: does the vendor, or one of its own suppliers, use your data to train a model? In the demo, the terms of service for a fictional AI support tool, Quill AI, contain a clause that lets the vendor train on customer data. The business case for the tool is real. So is the clause.

Recent history supplies the examples. The 2023 exploitation of the MOVEit Transfer file-transfer product reached a very large number of organisations, many of which had never heard of the tool because it was used by one of their suppliers. In July 2024 a faulty update to a widely used security product crashed Windows machines across airlines, hospitals and banks in a single morning. Neither was a failure of the affected organisations' own controls. Both were their problem.

Three ways a vendor becomes your incident

It helps to be specific about how vendor risk turns into business harm, because each path needs a different control. The demo vendors illustrate all three.

Path	What it looks like	Demo example (fictional)	The control that matters
Breach	The vendor's systems or accounts are compromised and your data goes with them	Callwave, a sales call recording vendor, confirms a credential-stuffing incident affecting a small number of accounts	Knowing what data and users the vendor has, and reacting the same day
Outage or failure	The vendor stops delivering, or a vendor it depends on does	Stackforge, the production hosting provider, reports a six-hour outage in one region	Tiering by business criticality, fourth-party visibility, exit plans
Terms and data use	The contract allows something you would not have agreed to if you had read it	Quill AI's terms let it use customer data to train models and set no deletion obligation on termination	Contract review against a playbook before signature, not after
Evidence going stale	The assurance you relied on quietly lapses	Ledgerly's SOC 1 Type II report expired in September 2026	Document validity tracked, with a signal and a finding on expiry

The fourth row is the least dramatic and the most common. A SOC 2 report (an independent auditor's report on a service organisation's controls) covers a fixed period. An insurance certificate has an expiry date. A penetration test is a snapshot. Programmes that review a vendor once and file the evidence end up relying, a year later, on documents that no longer say anything about today.

Accountability did not move with the data

Outsourcing a service does not outsource responsibility for it. That principle runs through almost every framework that touches vendors. In the EU, the Digital Operational Resilience Act (DORA), applying from 17 January 2025, makes financial entities manage ICT third-party risk and keep a register of information about their ICT providers. In the US, the federal banking agencies' interagency guidance on third-party relationships from June 2023 expects risk management across the whole lifecycle. GDPR Article 28 makes a controller responsible for choosing processors that give sufficient guarantees. Outside regulated sectors, SOC 2 and ISO/IEC 27001 audits ask how vendors are assessed and monitored. We read these side by side in a separate post on what regulators expect; the short version is that every one of them expects you to know your vendors, size your effort to the risk and keep records that prove it.

Customers ask the same questions, in the form of security questionnaires and contract clauses about subprocessors. The board asks them too, usually after an incident at someone else's company makes the news. The same fact reads differently to each of them.

Why the traditional programme struggles

Most TPRM programmes were built around a questionnaire. A vendor is sent a few hundred questions, answers some of them, attaches a SOC 2 report, and a reviewer reads both. The result is filed and revisited a year or more later. That design has three weaknesses that the shifts above expose.

First, it is slow. The business waits weeks for an approval, so it routes around the process: teams buy on a credit card, or sign the vendor's standard terms because the review would take longer than the pilot. Second, it is shallow where it matters. A reviewer with forty open requests cannot read every SOC 2 report end to end, and the important facts — the audit period, the exceptions, the controls the customer must operate itself — are buried on page sixty. Third, it is static. A breach, an acquisition or an expired certificate between reviews goes unnoticed until the next cycle, if the next cycle happens.

What a modern programme has to do

A programme fit for this risk covers the whole vendor lifecycle, not just the first review. The stages are familiar; the difference is that each has to produce a record and hand off to the next without someone carrying it by hand.

The vendor lifecycle. Every stage writes to the activity trail; a serious signal sends the vendor back to triage.

Four principles make that lifecycle work in practice.

• Size the effort to the risk. Tier vendors from what they touch: data sensitivity, system access, business criticality, spend and regulatory flags. A Tier 4 design retainer and a Tier 1 hosting provider should not get the same review.
• Start from evidence, not from questions. If a current SOC 2 Type II report already answers a question, do not ask the vendor again. Ask only what the documents leave open, and record where each answer came from.
• Make the score explainable. Separate inherent risk (before controls, from what the vendor touches) from residual risk (after the evidence). Show every factor and its points, so a reviewer can argue with it.
• Keep watching. Breaches, sanctions, adverse media, financial distress, expired documents and silence on the vendor portal are all signals. Each needs a reaction sized to the tier: a note, a finding, a re-assessment or an escalation.

How InsightVendors approaches it

InsightVendors is agentic third-party risk management: a person asks for a tool in one sentence, and agents do the intake, research the vendor, pick the right assessment, read the SOC 2 report and the contract, score the risk, route the approvals, watch the vendor afterwards and come back before renewal with a recommendation. People decide. Agents hand them a prepared decision: findings with page citations, a risk score with its reasons, contract clauses that deviate from the playbook, and a recommendation to sign, change or send back.

Take the breach path from the table above. In the demo, a signal arrives: Callwave confirms a credential-stuffing incident. Callwave is a Tier 2 vendor that records sales calls for 31 users, under an MSA (master services agreement) and a DPA (data processing agreement) already on file. The Monitoring agent decides the reaction for its tier — here, a re-assessment. The Document agent has already found, in the DPA, that OpenAI is listed as a sub-processor, and in the MSA that there are no data privacy or data processing obligations. When renewal comes round, the Renewal agent, working at L1 (it drafts, a person decides), proposes offboarding because residual risk is 100 with eight high or critical findings open.

None of that requires the agent to be trusted blindly. Every agent action is an agent run with its input, output, autonomy level, what it cited and who approved it. Every message an agent writes to a vendor waits in an outbox until a person releases it. And every agent has a rule-based path that works without an AI model; the model makes the output better, it does not make it work.

Where to start

You do not need to rebuild the programme to make progress. The order that tends to pay off first is: know what you have, size it, and make sure nothing important is expiring or renewing without a decision.

The rest of this series goes deeper: a map of the tools on the market and what each is good at, why vendor reviews take weeks, what regulators expect, and how tiering and scoring work. If you want to see the lifecycle on your own vendor list, the demo walks through every stage shown here.

Keep reading