Third-Party Risk Management: One Inventory, Four Regimes

Third-party risk management is the only compliance discipline where four different regimes ask about the same suppliers, in four different formats, on four different timetables — and most organisations answer each one from scratch.

The obligations genuinely differ. The supplier population does not. That gap is where the wasted effort lives.

What each regime asks of third-party risk management

DORA is the most prescriptive. Article 28(3) requires financial entities to maintain a register of information covering all contractual arrangements for ICT services — at entity, sub-consolidated and consolidated level — distinguishing those that support critical or important functions, on templates fixed by implementing technical standards, reported at least yearly.

NIS2 is narrower in one respect and broader in another. Article 21(2)(d) requires supply chain security “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”.

Direct. NIS2 does not push you down the chain indefinitely — but Article 21(3) then tells you what to weigh for each of those direct relationships: the vulnerabilities specific to each supplier, the overall quality of their products and cybersecurity practices, and their secure development procedures. That is a substantive assessment, not a questionnaire score.

ISO 27001 supplies the management system the other two assume — supplier relationship controls, governance, audit and review — without prescribing any register format.

Sector schemes approach it from the other end. TISAX and SWIFT CSP assess you as a party in somebody else’s supply chain, which means your own assurance work and your suppliers’ are the same activity viewed from opposite directions.

Three definitions that decide third-party risk management scope

Most third-party risk management programmes are the wrong size because one of these was never settled.

What counts as a third party. DORA is explicit about ICT service providers under contractual arrangements. NIS2 speaks of direct suppliers and service providers. Neither definition matches a typical procurement vendor master, which contains cleaners and stationery suppliers alongside the cloud platform running your core system.

What counts as critical. DORA’s “critical or important functions” test drives contract content, exit planning and supervisory notification. It is a determination about your functions, not about the supplier’s size — a small provider inside a critical process outranks a large one at the periphery.

How far down the chain you go. NIS2 says direct. DORA reaches subcontracting through its contractual requirements. Deciding your own depth, and writing the reasoning down, is better than discovering the question during an assessment.

Where third-party risk management programmes fail

Third-party risk management does not fail at the assessment. It fails at the joins.

• The inventory does not reconcile. Procurement holds vendors, legal holds contracts, IT holds systems, and nothing links a supplier to the function it supports. Every regime above needs exactly that link, and it is usually the longest task in the programme.
• Criticality is asserted, not assessed. A recorded determination survives challenge; a colour on a spreadsheet does not.
• Assessment is a point in time. Suppliers change ownership, jurisdiction, subprocessors and security posture after onboarding, and almost no programme watches for it.
• Nobody owns the transition. The moment a routine service becomes critical has no procurement event to trigger it — under DORA that moment carries a notification obligation.
• Exit exists on paper. An exit plan that has never been costed or tested is a document, not a control.

Build the inventory once, report many times

The practical answer to third-party risk management is a single supplier inventory carrying the union of what the regimes need, with reporting drawn from it rather than assembled per deadline.

At minimum, per supplier: legal entity and identifiers that resolve across the group; the contract and its key terms; the services provided; the business functions those services support; the criticality determination and its reasoning; data categories and locations; subprocessors; the assurance evidence held and its expiry; and the exit position.

That last set is where this meets your other obligations. The same supplier record answers a DORA register field, a NIS2 supply chain measure, an ISO 27001 supplier control, a records of processing recipient entry and an international transfer question — if it was designed to.

How third-party risk management connects

Where to start with third-party risk management

1. Define “third party” for your regimes, not from the vendor master. Most of it is out of scope.
2. Link supplier to function. Without that link no regime above can be answered, and it is the hardest data to assemble.
3. Assess criticality and record the reasoning, because it drives contract terms, exit and notification.
4. Set your depth deliberately — NIS2 says direct suppliers; decide and document how far you go beyond that.
5. Ask suppliers for assurance they already hold — a CSA STAR entry, an ISO 27001 certificate, a TISAX result — before sending a questionnaire.
6. Build the “became critical” monitoring control, since nothing else will trigger it.

This guide reflects Regulation (EU) 2022/2554 and Directive (EU) 2022/2555 as published on EUR-Lex, read at 16 August 2026. NIS2 is transposed nationally — check your Member State’s implementation.

The DORA Toolkit covers the ICT third-party framework and register, the NIS2 Toolkit covers the supply chain measures, and the ISO 27001 Toolkit provides the supplier relationship controls and assessment records underneath both.