Third-party risk management: from questionnaires to continuous evidence

Most third-party risk programmes are questionnaire programmes. A spreadsheet goes out, the answers come back, someone files them, and the vendor counts as assessed for another year. The process is real. The assurance it produces is mostly on paper.

Why the questionnaire stopped being enough

Four structural limits, and a better questionnaire fixes none of them.

• Self-reported. The vendor writes the answers, nobody verifies them, and the incentive runs one way. No supplier describes its own patching as slow.
• Point-in-time. An answer given in March describes March. The vendor's estate changes every week; the assessment changes once a year.
• Unverifiable at scale. Checking one vendor's claims properly takes days. Across several hundred vendors the checking stops, and the questionnaire becomes a record that a question was asked.
• Blind past the first tier. Your vendors' own suppliers are where a large share of incidents start, and a questionnaire almost never reaches them.

The result is a programme that produces documentation rather than warning. When a supplier is compromised, most organisations hear about it from the supplier, a customer or the news — not from their own oversight.

What regulators now ask for

The major regimes in the US and the EU point the same way: overseeing a supplier is the buyer's job, and it continues after the contract is signed.

One clause in DORA shows where this is heading. Article 28(7) requires that a contract can be terminated for “circumstances identified throughout the monitoring of ICT third-party risk”. That only works if monitoring exists and can find something. An annual questionnaire does not produce that kind of evidence between cycles.

If you are the supplier rather than the buyer, the same instruments reach you through your customers' contracts. That side of the question is covered in what NIS2, DORA and SEC Reg S-P demand of your vendors.

Tier by impact before assessing anything

The most common design error is treating every vendor alike. The office-supplies vendor and the provider hosting your core platform do not deserve the same scrutiny, and pretending they do guarantees the scrutiny is shallow everywhere.

Tier on impact, not spend. The question is not what you pay a vendor. It is what happens if they go down, are breached, or lose your data.

Tier A should include every vendor supporting what DORA calls a critical or important function, because those carry the exit-strategy duty. Tiering once to that standard saves re-drawing the line for each regulator.

Continuous evidence, and where questionnaires still belong

External monitoring observes each vendor's internet-facing posture every day, independently, without asking the vendor for anything. What it adds:

• Evidence rather than assertion. An expired certificate or an exposed service is observed, not claimed.
• Change detection. The useful signal is usually decline. A vendor whose posture slips over six weeks is telling you something no questionnaire will.
• Coverage at scale. Monitoring four hundred vendors costs about what monitoring forty does. Verifying four hundred questionnaires does not.
• A dated record. Each vendor's rating over time is the kind of evidence a supervisor, an auditor or an Item 106 disclosure can rest on.

A rollout sequence

1. Build the real vendor list. Procurement, accounts payable and the asset inventory will disagree. Reconciling them usually turns up third parties no single system knew about. For a DORA entity, it is also the starting point for the register of information.
2. Tier hard. If a third of your vendors come out as critical, the tiering is wrong.
3. Baseline Tier A and B externally before telling vendors anything, so the first picture is unmanaged.
4. Put thresholds in contracts at renewal. A minimum rating, a remediation window, a right to monitor and a notification duty. Most programmes skip this step, and most need it.
5. Give every alert an owner. An alert with no owner and no deadline is noise that teaches people to ignore the console.
6. Report the portfolio, not the incidents. Boards need distribution and trend by tier, not last month's findings.

Fourth parties and concentration

A vendor list that looks diversified often is not. Map the dependencies behind your Tier A and B vendors and many of them converge on the same few cloud hosts, payment processors or managed service providers. An incident at one of those is a correlated failure across your portfolio, not an isolated vendor problem.

DORA makes this explicit: before contracting, a financial entity has to assess whether an arrangement adds to ICT concentration risk. Outside DORA the duty is less explicit, but the exposure is the same, and it is invisible to a programme that stops at the first tier.

What to report to the board

• Share of Tier A and B vendors under continuous monitoring — the target is all of them
• Distribution of vendor ratings by tier, quarter on quarter
• Vendors below their contractual threshold, and for how long
• Median time from alert to vendor acknowledgement
• Fourth-party concentration: dependencies shared by more than five Tier A vendors

Note what is missing: the number of questionnaires sent. It measures activity, not risk, and reporting it upward rewards the wrong programme.

Related reading

• Security questionnaires vs security ratings
• What is a cyber security rating?
• Third-party risk management for Indian BFSI — the same method under the RBI outsourcing Directions.

Read from the published text: Regulation (EU) 2022/2554, Article 28, and Directive (EU) 2022/2555, Article 21, on EUR-Lex; 23 NYCRR 500.11 on dfs.ny.gov; 17 CFR 229.106 on the eCFR; and OCC Bulletin 2023-17 on occ.gov.