Third-Party Risk Management Without the Spreadsheet Nightmare

The questionnaire theater problem

Here is how third-party risk management works at most organizations. Procurement flags a new vendor. Security sends a 300-question spreadsheet. The vendor's sales engineer fills it in, optimistically. Someone skims the answers, files the spreadsheet, and approves the vendor. Three years later, the vendor is breached, and the spreadsheet is exhumed to prove that due diligence happened.

Every step of this is theater, and everyone involved knows it. Yet it persists, because it produces an audit artifact, and audit artifacts are what the process was actually designed to produce. Not risk reduction. Paper.

Meanwhile the actual risk grew: supply chain compromise is now a preferred initial access route, because breaching one managed service provider or file transfer product yields hundreds of victims at once. MOVEit alone compromised over 2,600 organizations, most of whom had never heard of the product because it belonged to a vendor of a vendor.

Why questionnaires fail

The failure is structural, not a matter of asking better questions.

Point-in-time. A questionnaire describes one moment. The vendor's security posture the day they answered says little about their posture eighteen months later, after two reorgs, a cloud migration, and the departure of the engineer who understood the firewall rules. Risk drifts continuously; annual assessment samples it annually.

Self-reported. Questionnaires are answered by people whose job is to close the deal. Not lying, exactly, but answering "do you encrypt data at rest" as aspiration rather than inventory. There is no verification step, and both sides know there will not be one.

Nobody reads them. A mid-size company has 300-800 vendors. At 300 questions each, honest review of every response is a full-time team nobody has. So responses get skimmed for red-flag keywords, scored by completeness rather than content, and filed.

Wrong granularity. The same questionnaire goes to the payroll processor holding all employee PII and to the vendor supplying office plants. Effort is spread evenly across vendors whose risk differs by four orders of magnitude.

What continuous TPRM actually looks like

Tier first, then spend effort

Tiering is the highest-leverage hour you will spend. Classify vendors by two axes: what they can touch (production access, sensitive data, none) and what breaks if they fail (critical business function, degraded operations, nothing). Three or four tiers is plenty.

The point of tiering is permission to do less: tier-3 vendors get a short attestation and contract boilerplate, freeing real assessment capacity for the twenty vendors that could take your business down. A TPRM program that treats every vendor equally is choosing to assess its critical vendors badly.

Verify from the outside

You cannot audit a vendor's internals continuously, but their external posture is observable the same way an attacker observes it: exposed services, certificate hygiene, leaked credentials, breached-data mentions, patch latency on internet-facing systems. External signals do not tell you everything, but they are verified rather than self-reported, and they update daily instead of annually. A vendor whose questionnaire claims mature vulnerability management while their perimeter shows six-month-old exploitable services has answered a question no questionnaire asks.

Pair monitoring with proportionate periodic review for top tiers: evidence-based deep dives (pentest reports, SOC 2 with actual exceptions read, architecture review) rather than another questionnaire round.

Put the risk in the contract

Monitoring without contractual teeth just means watching problems you cannot act on. The clauses that matter:

• Incident notification with a hard clock (24-72 hours), covering incidents at the vendor's own subcontractors.
• Audit and evidence rights, including the right to request current pentest results, not a three-year-old certificate.
• Security baselines stated as obligations (MFA, encryption, patching SLAs) so a gap is a breach of contract, not a disappointment.
• Subcontracting transparency, because your fourth parties are where surprises live.
• Termination and exit support: data return in usable formats, deletion attestation, transition assistance.

Plan the divorce before the wedding

Every critical vendor relationship needs a documented exit strategy: what data comes back, in what format, what replaces the service, how long migration takes, and what the degraded mode looks like meanwhile. Writing this before signing does two things. It surfaces lock-in while you still have negotiating leverage, and it converts "we could never leave" from an unexamined assumption into a priced risk. Concentration risk (three critical functions on one provider) only becomes visible when someone writes the exit plans and notices they all name the same vendor.

DORA turns good practice into obligation

For EU financial entities, this stopped being optional guidance in January 2025. DORA (Regulation (EU) 2022/2554) makes ICT third-party risk a supervised discipline, and its requirements map almost exactly onto the continuous model above:

• A register of information covering every ICT contractual arrangement, flagged by whether it supports critical or important functions, reportable to your regulator. This is a structured, current dataset, not a spreadsheet reconstructed on request.
• Pre-contract risk assessment proportionate to criticality, explicitly including concentration risk.
• Mandatory contract clauses (Article 30 of the regulation): security requirements, incident cooperation, audit rights, data location, exit support, with extended terms for critical functions.
• Documented exit strategies for critical providers.
• Ongoing monitoring for the life of the arrangement, not just at onboarding.

And the reach extends beyond banks: DORA arrives at ICT providers through their financial customers' contracts, so vendors selling into the sector are fielding these clauses whether or not they have ever read the regulation. If your customers are in scope, your TPRM answers just became part of their compliance surface.

The tooling gap is real here. The register alone, with its mandated structure and its need to stay synchronized with actual contracts, outgrows spreadsheets immediately. This is the problem mlab TPRM is built for: DORA-aligned third-party risk management with vendor tiering, the register of information, contract clause tracking, and continuous monitoring in one workflow. It is self-hosted, which matters for a system whose contents are effectively a map of your critical dependencies: that data should not itself become a third-party risk.

A realistic starting sequence

1. Inventory and tier every vendor. Expect to find 20-40% more vendors than anyone thought you had; expense reports and SSO logs are good discovery sources.
2. Deep-assess only the top tier with evidence, not questionnaires.
3. Stand up external monitoring for tiers 1 and 2, with alerts routed to a named owner.
4. Fix contracts at renewal, starting with critical vendors missing incident notification clauses.
5. Write exit strategies for the top ten, and read them side by side to find your concentration risk.

Retire the 300-question spreadsheet last, once the things that replace it actually run. It was never protecting you, but it was proving you tried, and you should not drop that proof until the better evidence exists.

Questionnaires measure a vendor's ability to answer questionnaires. Measure their exposure, their contracts, and your exit options instead.