Third-party risk management: what NIS2 and DORA ask

Third-party risk management (TPRM) is the process an organisation uses to identify, assess, contract and keep under review the risks that come from suppliers, service providers and other third parties. In the EU it is a legal requirement for entities in scope of NIS2 (Directive (EU) 2022/2555, Article 21(2)(d) and 21(3)) and, for financial entities, of DORA (Regulation (EU) 2022/2554, Articles 28 to 30).

Below: what TPRM covers in practice, what NIS2 and DORA actually ask, the supplier lifecycle in six stages, and what changes when the supplier is you.

What third-party risk management means in practice

A third party is anyone who touches your systems, your data or a process you depend on without being part of your organisation: the cloud provider, the vendor of your ERP, the contractor who connects remotely to production machines, the payroll bureau, the consultant with a VPN account. TPRM starts from one question: if one of them has an incident tomorrow, what happens to us?

Three terms travel together and are worth separating:

• Third-party risk management: the widest scope, every third party and every kind of risk it brings (security, continuity, compliance, data).
• Vendor risk management: the same work limited to suppliers you hold a contract with. In practice many people use the two terms interchangeably.
• Supply chain security: the wording NIS2 uses, focused on the cybersecurity risks that travel through suppliers and service providers. DORA speaks of ICT third-party risk, limited to ICT services.

What they share is simple: outsourcing moves the technology, not the accountability. DORA says it plainly. Financial entities that use ICT services from third parties shall, in the words of Article 28(1)(a), "at all times, remain fully responsible" for compliance with their obligations.

Why it is on the agenda now

The context comes from Verizon's Data Breach Investigations Report. In the 2026 edition, published on 19 May 2026, breaches involving a third party grew by 60% and now account for 48% of all breaches analysed, according to Verizon's press release.

The regulatory push runs alongside. DORA has applied since 17 January 2025 (Article 64), and NIS2 reaches entities through the national laws that transpose it, with supplier security listed among the minimum measures.

What NIS2 asks on supply chain security

Article 21 of Directive (EU) 2022/2555 asks Member States to ensure that essential and important entities take appropriate and proportionate cybersecurity risk-management measures. Paragraph 2 lists the minimum, and point (d) reads: "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers".

Paragraph 3 says how to judge which measures are appropriate. Entities take into account:

• the vulnerabilities specific to each direct supplier and service provider;
• the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures;
• the results of the coordinated security risk assessments of critical supply chains carried out at Union level under Article 22(1).

Because NIS2 is a directive, the obligation reaches you through your national law, and the national authority may add detail. Check the transposition in your country before you design the programme: for two examples, see our guides to NIS2 in Malta and NIS2 in Cyprus.

The detailed version for digital providers

For DNS providers, TLD registries, cloud computing, data centre and content delivery network providers, managed service providers, managed security service providers, online marketplaces, search engines, social networks and trust service providers, Commission Implementing Regulation (EU) 2024/2690 spells the measure out in section 5 of its Annex. It is binding only for those entities, but it is the most concrete EU text on what a supplier programme looks like, and it reads well as a checklist for anyone else:

• a supply chain security policy governing relations with direct suppliers and service providers, with criteria to select and contract them (points 5.1.1 and 5.1.2);
• contract terms, where appropriate, on cybersecurity requirements, staff skills and background checks, notification of incidents without undue delay, the right to audit or to receive audit reports, vulnerability handling, subcontracting and obligations at termination (point 5.1.4);
• review at planned intervals and after significant changes or incidents, including monitoring of service level reports (points 5.1.6 and 5.1.7);
• a registry of direct suppliers with a contact point for each and the list of ICT products, services and processes they provide (point 5.2).

What DORA asks of financial entities

For banks, insurers, investment firms, payment institutions and the other entities listed in Article 2 of Regulation (EU) 2022/2554, ICT third-party risk has its own chapter, Chapter V. The core is in three articles.

Article 28: general principles

• ICT third-party risk is managed as an integral part of the ICT risk management framework, in proportion to the nature, scale and importance of the dependency (paragraph 1).
• Entities other than microenterprises and those under the simplified framework of Article 16(1) adopt and regularly review a strategy on ICT third-party risk, with a policy on ICT services supporting critical or important functions (paragraph 2). Commission Delegated Regulation (EU) 2024/1773 sets out the content of that policy, including a yearly review by the management body.
• Entities keep a register of information on all contractual arrangements for ICT services, at entity level and at sub-consolidated and consolidated level, distinguishing those that support critical or important functions, and report to the competent authority at least yearly (paragraph 3). The templates are in Commission Implementing Regulation (EU) 2024/2956.
• Before signing, entities assess whether the service supports a critical or important function, identify the risks including concentration risk, carry out due diligence on the provider and assess conflicts of interest (paragraph 4).
• Contracts can be terminated in defined cases, and for services supporting critical or important functions there are documented, tested exit strategies (paragraphs 7 and 8).

Article 29: concentration risk

Before contracting a service that supports a critical or important function, the entity considers whether the provider is easily substitutable and whether it already depends on the same or closely connected providers. Where subcontracting is allowed, it weighs the risks of long or complex chains, especially with subcontractors established outside the EU.

Article 30: key contractual provisions

Every ICT contract includes, among other things, a full description of the services and whether subcontracting is permitted, the locations where services are provided and data processed, provisions on access to and return of data, assistance when an ICT incident occurs, cooperation with the competent authorities and termination rights. For services supporting critical or important functions the list grows: precise service levels, notice and reporting obligations, business contingency plans, participation in threat-led penetration testing, unrestricted rights of access, inspection and audit, and an exit transition period.

One point holds even for the largest providers: when a provider is designated critical and overseen at EU level (Article 31 onwards), Article 28(1)(a) still leaves full responsibility with the financial entity. How we approach the whole regulation is on our DORA page. Country-specific supervisory practice is covered in our guides to DORA for MFSA-licensed firms and DORA for CySEC-regulated firms.

The supplier lifecycle in six stages

NIS2 and DORA use different words, but they ask for the same cycle. Delegated Regulation (EU) 2024/1773 lists the phases for DORA (planning with risk assessment and due diligence, implementation and monitoring, documentation, exit). A programme that holds up under review looks like this.

1. Inventory and classification

You cannot assess what you have not listed. Start from accounts payable, active contracts, external accounts on your systems and remote access, then cross-check the sources: suppliers nobody had flagged as relevant to security usually appear. Then classify by criticality: what access the supplier has, what data it touches, what stops if it stops.

2. Due diligence before the contract

The depth of the assessment follows criticality. A short questionnaire is enough for a marginal supplier. For a critical one, ask for evidence: an ISO/IEC 27001 certificate with its scope, a SOC 2 report (see what SOC 2 is and how to get it), penetration test results, continuity plans. A certificate is worth what its scope covers, so read the scope before filing it.

3. Requirements in the contract

Under DORA, Article 30 sets the minimum contract content; under NIS2, the contract is where supply chain requirements become enforceable. In practice four clauses matter most: how quickly the supplier tells you about an incident, compatible with your own reporting obligations; audit rights; subcontracting rules; return and deletion of data at the end of the relationship.

4. Monitoring during the relationship

An assessment done at onboarding and never reopened does not meet either text. For the digital providers in its scope, Implementing Regulation (EU) 2024/2690 asks for review at planned intervals (point 5.1.6), DORA Article 30(3)(e) gives the right to monitor, on an ongoing basis, the performance of providers of services supporting critical or important functions, and Delegated Regulation (EU) 2024/1773 has an article of its own on monitoring (Article 9). In practice: a yearly review for critical suppliers, tracking certificate expiry dates, reviewing supplier accounts on your systems.

5. Incidents that start at the supplier

When an incident starts at a supplier, your reporting obligations remain yours. Agree in advance who alerts you, how fast, and who watches supplier access to your systems: legitimate remote access used in an unusual way is one of the signals a security operations team needs to read. Your business continuity plan should name the suppliers whose outage you cannot absorb.

6. Exit

The end of a relationship is a risk stage, not a formality. Accounts to revoke, data to recover and have deleted, a plan to replace the service without stopping. Under DORA, exit strategies are an explicit requirement for services supporting critical or important functions (Article 28(8)).

The mistakes we see most often

• One questionnaire for everyone. The same two hundred questions to the stationery supplier and the cloud provider. Classification exists to size the effort.
• TPRM as a one-off project. An inventory built for an audit ages within months, because suppliers and access change all the time.
• Nobody looks past the first link. Your supplier has suppliers. Subcontracting appears in Articles 29 and 30 of DORA and in point 5.1.4 of the Annex to Implementing Regulation (EU) 2024/2690.
• The contract says one thing, the systems another. Permanent remote access, accounts of former suppliers still active: checking access on the systems is TPRM as much as the paperwork.

If the supplier is you

Many mid-market companies meet TPRM from the other side: a customer in scope of NIS2 or DORA sends a security questionnaire or new contract clauses. That is the direct effect of Article 21 of NIS2 and Article 30 of DORA. The customer's obligations travel down the chain as contract requirements, even when the supplier is not in scope of either law.

If you answer several questionnaires a year, it pays to answer once with solid evidence rather than from scratch each time. An ISO/IEC 27001 certification covers many of the usual questions: Annex A controls 5.19 (information security in supplier relationships), 5.20 (addressing information security within supplier agreements), 5.21 (managing information security in the ICT supply chain), 5.22 (monitoring, review and change management of supplier services) and 5.23 (information security for use of cloud services) deal directly with suppliers. Independent penetration testing adds technical evidence that a questionnaire cannot give.

Where to start

A sensible order: list the suppliers with an impact on your systems, classify them by access, data and dependency, start with the critical ones (documented assessment, reviewed contract, verified access), then put the review in the calendar. If you are a financial entity, align the inventory with the DORA register of information from the start, so you maintain one list instead of two.

How AmagisTech works on third-party risk

We work on both halves of TPRM with mid-market organisations: the governance half, meaning inventory, classification, contract requirements and evidence for the supervisor or the auditor, and the operational half, meaning monitoring of supplier access and handling of incidents that start in the supply chain, run by our SOC. If you want to understand where to begin in your case, talk to us.

In short: third-party risk management is the management of risk that comes in through suppliers, from selection to exit. NIS2 requires it through Article 21(2)(d) and 21(3), DORA through Articles 28 to 30 for the financial sector. According to Verizon's DBIR 2026, almost one breach in two involves a third party: inventory, classification, contracts and continuous monitoring are how you learn who you depend on before an incident tells you.