From a spreadsheet of vendors to a programme that runs itself

Most third-party risk programmes start life as a spreadsheet. One row per vendor, columns for owner, spend, contract end date and “last reviewed”, a folder of PDFs somewhere and an inbox of questionnaires in various states of completion. It works until it does not: a SOC report expires unnoticed, a contract renews itself, a new AI tool is bought on a card. Moving off the spreadsheet is less about software than about deciding, once, how the organisation wants to treat its vendors, and then letting the system do it every day.

This post is a ninety-day plan for that move, written for the procurement and vendor-risk leads who will run it. It uses InsightVendors as the example, and the demo organisation in our screenshots, Northwind Labs, whose eight vendors are fictional. The plan works in three phases: get the facts in, set the rules and let the agents read, then turn on the parts that run continuously and raise the autonomy dial as the agents earn it.

Before day one: decide who owns what

The most common reason vendor programmes stall is not tooling. It is that nobody agreed who decides. Before importing anything, settle three things with the people who will be approvers: who owns the programme overall (usually procurement or a vendor-risk lead), who owns each review lane (security, privacy, legal, finance, IT and the business owner), and who owns each vendor relationship. In the demo, procurement owns most vendors and the finance lane, security owns the security and IT lanes, and legal owns privacy and legal.

Agree also what “done” looks like at day ninety. A reasonable target is: every vendor tiered with an owner, every Tier 1 and Tier 2 vendor's evidence read, every renewal inside ninety days carrying a recommendation, and every new request going through the new front door.

Illustrative dates. The phases overlap; the order matters more than the exact days.

Days 1–30: get the facts in

Load the vendor list and the contracts. Start with the spreadsheet you have. For each vendor you need, at minimum, a name, an internal owner, what it does, what data it touches, which systems it connects to, annual spend and the contract's end date and notice period. Missing data is fine at this stage; record it as missing. The notice date matters most, because it is the one that costs money if missed. In 1.0 the import is done through the API or with us during onboarding; supplier sync from NetSuite and Coupa is planned for 1.2.

Set the tiering rules. Tiers in InsightVendors run from Tier 1 Critical to Tier 4 Low, and they are calculated from rules you own: data sensitivity, system access, business criticality, spend and regulatory flags. Write the rules with security, privacy and legal in the room. The test of a good rule set is that, applied to your current vendors, the result looks right to the people who know them. If your production hosting provider comes out Tier 3, the rules are wrong, not the provider.

Set lanes, service levels and routing. Each lane needs an owner and a service level in business days. The demo uses five for security and legal, four for privacy, three for finance and IT, and two for the business owner. Routing rules decide which lanes each request needs and record why: personal data adds a privacy lane, an integration adds IT, an AI vendor requires the AI questionnaire. Set the reassessment cadence by tier (the demo reviews Tiers 1 and 2 every twelve months, Tier 3 every twenty-four and Tier 4 every thirty-six) and the insurance minimums each tier must meet.

Upload the documents you already hold. Gather the SOC reports, ISO certificates, penetration test summaries, insurance certificates, DPAs and contracts that are sitting in shared drives and email. Do not chase vendors for new ones yet; first find out what you have and how current it is.

Days 31–60: let the agents read

This is the phase where the programme changes character. The Document agent reads each document and extracts what a reviewer needs — for a SOC 2 report, its type, period, auditor, opinion, exceptions, complementary user entity controls (CUECs) and subservice organisations; for an insurance certificate, the limits against the tier's minimums and the expiry; for a DPA, the subprocessors, breach-notification window, data location and deletion terms. Every finding cites the page and quotes the text. The Contract agent checks agreements against your playbook. The Risk agent turns the evidence into an inherent and a residual score, listing every factor.

Expect a findings spike. Reading every document properly finds problems that were always there. In the demo, eight vendors produce 88 open findings, five of them critical and 21 high: a SOC 2 Type I report with a future-dated audit period, an insurance certificate showing the cyber limit only in aggregate, a contract that lets an AI vendor train on customer data. Your numbers will differ, but the shape is common. Plan for it.

Open the new front door. From around day thirty, new requests should go through one-sentence intake rather than email. Tell the organisation once, clearly, and make it the only route to a purchase order. The Intake agent will catch duplicates and approved alternatives, which is often the first saving people notice.

Days 61–90: make it continuous

Turn on monitoring. Signals — breach, sanctions, adverse media, financial, certificate, domain, document expiry, portal silence and news — reach the system from InsightPulse company intelligence and the API. For each tier, decide the reaction: a note, a finding, a re-assessment or an escalation. A breach at a Tier 2 sales vendor, like the credential-stuffing incident at Callwave in the demo, might warrant a re-assessment; adverse news about a Tier 4 design agency, a note.

Run renewals through the agent. The renewal calendar sorts contracts by the date notice must be given. The Renewal agent assembles spend, risk trend, open findings and the notice date, and recommends renew, renegotiate or offboard at 90, 60 and 30 days before notice. Keep it at L1 at first: it drafts the recommendation and a person decides.

Report upward. By day ninety you can give leadership a short, honest picture: vendors by tier, spend under management, critical and high findings open on Tier 1 and Tier 2 vendors, expired evidence, renewals decided before notice, and where requests wait. The insights page carries most of it; dedicated board reporting is planned for 2.0.

Avoid the common traps. Three mistakes recur in the first quarter. The first is importing everything at full depth: a Tier 4 design retainer such as BrightPixel in the demo, with a residual score of 7, does not need its documents chased in month one. Let the tier set the order. The second is treating every finding as a vendor problem. Some are yours: a CUEC such as PeopleLoop's “user entities are responsible for enabling single sign-on/MFA” is a control Northwind must operate itself, and the finding belongs to an internal owner. The third is leaving the old route open. If email requests still reach procurement and still get approved, the new front door will be used only by the people who were already following the process.

Raising the autonomy dial

Every agent works at an autonomy level: L1 Draft (it prepares, a person does it), L2 Ask first, L3 Act and tell (it acts, and the action can be pulled back), and L4 Act. The level is set per agent for the organisation, capped by a tenant ceiling that defaults to L3. Every outgoing message waits in the outbox at L2. Start low and raise each agent only when its record justifies it.

Keep reading