DORA Article 28 + NIS 2: Third-Party Risk Management Playbook

DORA became applicable on 17 January 2025. Eighteen months later, supervisory examinations across the EU are producing a consistent finding: organisations understand their own resilience posture reasonably well, but they have poor visibility into the ICT providers that sit beneath it.

Article 28 — General principles on ICT third-party risk — is the provision most frequently cited in early inspection outcomes. The reasons are structural, not accidental. Most financial entities spent 2024 focused on policy and governance. Third-party inventories, contract remediation, and sub-outsourcing chains were treated as phase-two work. Phase two has arrived, and the gap is visible.

This article explains what Articles 28–31 require, how NIS 2 Article 21(2)(d) intersects for entities that also fall under that directive, and how to build a TPRM programme that will hold up under examination.

Why Article 28 Is the Hardest Part of DORA

DORA's governance, risk management, and ICT continuity requirements (Articles 5–15) map reasonably well onto existing frameworks — ISO 27001, NIST CSF, EBA Guidelines on ICT and Security Risk. Most organisations had something to work with.

Third-party risk is different for three reasons.

You do not control the other party. You can improve your own detection capability in months. Remediating a contract signed in 2019 with a tier-1 infrastructure provider takes legal negotiation, relationship management, and in some cases, migration to a different supplier.

Sub-outsourcing creates invisible exposure. Article 28(2) requires financial entities to assess not just direct ICT third-party service providers (ICT TPPs), but the sub-outsourcing arrangements those providers rely on. An entity may have ten direct ICT TPPs and two hundred sub-contractors it has never mapped.

The register of contracts is both an operational tool and a regulatory artefact. Article 28(3) requires a complete, up-to-date register of all contractual arrangements with ICT TPPs. Supervisors are requesting this register as one of the first documents in an examination. Entities that have maintained it only at a high level are finding the gaps immediately.

What Article 28 Requires: The Core Obligations

Article 28 of Regulation (EU) 2022/2554 establishes the overarching framework for ICT third-party risk. The key obligations are:

Article 28(1) — Financial entities must manage ICT third-party risk as an integral component of ICT risk within the broader ICT risk management framework defined in Article 6. The board retains responsibility; it cannot be fully delegated.

Article 28(2) — Proportionality applies, but the direction is consistent for all entities: identify, assess, and monitor ICT TPPs, including sub-outsourcing chains relevant to critical or important functions.

Article 28(3) — Maintain the register of contractual arrangements. The register must capture: provider name, type of service, criticality classification, commencement and end dates, and whether the service supports a critical or important function. The European Supervisory Authorities (ESAs) published a standardised template for this register in the regulatory technical standards adopted under Article 28(9) — entities using their own formats should verify alignment.

Article 28(4) — Pre-engagement, entities must conduct a risk assessment proportionate to the criticality of the function. This is not a checkbox; supervisors are asking to see the methodology and the documented output.

Article 28(5) — Due diligence must be performed before entering arrangements. Due diligence does not end at contracting — it is ongoing.

Article 28(8) — Entities must have exit strategies for all ICT TPPs supporting critical or important functions. Exit strategies must be documented, tested, and realistic. "We would use a different cloud provider" is not a strategy unless there is evidence the migration is feasible.

Articles 29, 30, and 31: The Supporting Architecture

Article 29 — Preliminary Assessment of ICT Concentration Risk

Before entering or significantly renewing an arrangement, entities must assess whether it would create concentration risk — at the level of the individual entity or across the financial sector.

In practice this means: if the same provider already supports critical functions at a significant share of EU financial entities, adding one more arrangement contributes to systemic exposure. Article 29(2) requires entities to document this assessment. The European Banking Authority (EBA) has flagged cloud infrastructure concentration as a sector-level concern in its 2024 and 2025 risk assessments.

The key question for your assessment is not just "is this provider important to us" but "is this provider important to the system."

Article 30 — Key Contractual Provisions

For arrangements supporting critical or important functions, contracts must include specific provisions. The RTS on contractual arrangements (adopted under Article 30(5)) specifies the minimum content:

• Full description of services, including SLAs

• Locations where data is processed and stored

• Provisions on data accessibility, availability, integrity, and confidentiality

• Audit rights — financial entity (or its auditors) and competent authority

• Business continuity and DR obligations of the ICT TPP

• Termination rights, including the conditions under which the financial entity can exit without penalty

• Sub-outsourcing provisions — the TPP must notify the entity of material sub-outsourcing changes

The audit rights clause is frequently the most contentious. Many major cloud providers offer pooled audit arrangements (third-party attestations, SOC reports) rather than direct examination. DORA's text does not prohibit this, but it requires that the arrangement give the entity sufficient assurance — and that the competent authority can exercise its own rights directly.

Article 31 — Designation of Critical ICT Third-Party Providers

Article 31 establishes the mechanism by which the ESAs can designate individual ICT TPPs as critical at EU level. Designated providers become subject to an oversight framework — examination, recommendations, and ultimately, compliance obligations administered by a Lead Overseer.

Designation is a regulatory process the ESAs control, not the financial entity. However, the practical implication for financial entities is real: if your primary cloud or SaaS provider is designated as critical, the scrutiny of that relationship increases, and your documentation of the arrangement must be materially complete.

The first list of critical ICT TPPs had not been finalised as of mid-2025; the ESA process was ongoing. Entities should monitor ESMA, EBA, and EIOPA publications on this point.

NIS 2: Supply Chain Provisions Under Article 21(2)(d)

Entities that fall under both DORA and NIS 2 — which includes some energy, financial market infrastructure, and digital infrastructure operators — face overlapping but not identical requirements.

NIS 2 Directive (EU) 2022/2555, Article 21(2)(d) requires that essential and important entities implement:

"supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers"

The scope is broader than DORA's ICT-focused definition. NIS 2 supply chain provisions apply to physical and software supply chains, not only ICT service arrangements. An energy operator subject to both regimes must satisfy DORA's contract register and assessment requirements and NIS 2's broader supply chain security obligations.

Where the two frameworks overlap, the more specific provision generally governs for financial entities (DORA is lex specialis). However, entities should confirm this interpretation with their competent authority, as NIS 2 transposition varies across member states following the October 2024 deadline.

Building a TPRM Programme: 8 Steps

The following sequence reflects what a functional TPRM programme looks like for a mid-size regulated entity. Adjust scope to your classification and the criticality profile of your ICT TPP portfolio.

Step 1: Build the inventory. Start with contracts. Pull every active agreement with an ICT component — software, infrastructure, managed services, data processing. This is rarely done in one place; finance, procurement, and IT operations each hold pieces. Reconcile them.

Step 2: Classify by function. For each provider: does this service support a critical or important function? DORA's definitions (Article 3(22)) and EBA Guidelines provide the criteria. Where the answer is uncertain, treat the function as important until assessment resolves it. Supervisors penalise under-classification more than over-classification.

Step 3: Populate the register. Use the ESA template fields. Do not build a bespoke format without confirming it captures everything the RTS requires. This register is a living document — assign an owner and a review cadence.

Step 4: Conduct due diligence on critical and important providers. Risk assessment methodology should be documented before you start. Assessment outputs — findings, risk ratings, escalation decisions — must be retained. An EU mid-market fintech we worked with had conducted assessments verbally for years; when asked to produce evidence, they had none. Supervisors treat this as a gap equivalent to not having assessed at all.

Step 5: Remediate contracts. Compare existing contracts against Article 30 requirements. Identify which lack the mandatory provisions — audit rights, exit, sub-outsourcing notification, SLAs aligned to your RTO/RPO. Prioritise critical and important providers. Negotiate amendments. For providers unwilling to accommodate DORA-required clauses, document the risk and escalate to the board.

Step 6: Map sub-outsourcing. Request sub-outsourcing disclosures from each critical and important provider. Many will have a standard process for this; some will resist. Where sub-outsourcing is material to service delivery and you have no visibility into it, that is a concentration and continuity risk requiring assessment.

Step 7: Develop exit strategies. For each critical and important provider, document a realistic exit scenario. Include estimated migration timelines, data portability requirements, operational dependencies, and cost estimates. Test the assumptions — a cloud migration "feasibility" that has never been validated is not a strategy.

Step 8: Embed ongoing monitoring. Questionnaire-based annual reviews are insufficient for critical providers. Define monitoring triggers: material sub-outsourcing changes, significant incidents at the provider, changes in ownership or financial stability, contractual renewals. Assign responsibility for acting on each trigger.

Common Pitfalls: What We See in Practice

The register exists but is not maintained. A register built in Q4 2024 and not updated through 2025 will show providers that have been offboarded and miss providers added since. Supervisors compare the register against active contracts; discrepancies are the first finding.

Criticality classification was done once and never revisited. A provider supporting a non-critical function in 2023 may now support a critical one following internal reorganisation or a new product launch. Classification must follow the function, not the contract.

Due diligence questionnaires sent but responses never analysed. Sending the questionnaire satisfies the "we assessed them" narrative. Not acting on the responses — or not reviewing them at all — does not. If a provider's questionnaire discloses a significant control gap and the file shows no follow-up, that is the examiner's finding, not the provider's.

Exit strategies that assume capabilities the organisation does not have. Stating that you would migrate to an alternative provider in 90 days is only meaningful if you have the technical capacity, licensing agreements, and data migration plan to support it. Document the assumptions and the evidence.

Concentration risk assessed only at the entity level. Article 29 requires considering sector-level concentration. An entity that uses the same major cloud provider as 70% of its peer group has a different concentration profile than one using a regional provider. The assessment must reflect this.

Documentation: What Auditors and Supervisors Look For

Beyond the register of contracts, a DORA-compliant TPRM programme produces and retains the following:

• Criticality classification decisions — documented rationale, not just the conclusion

• Due diligence outputs — completed questionnaires, risk ratings, escalation records, and evidence that gaps were followed up

• Contract gap analyses — comparison of existing contracts against Article 30 requirements, remediation actions and timelines

• Sub-outsourcing disclosures — provider communications and your assessment of material sub-contracting chains

• Exit strategies — one document per critical/important provider, including tested assumptions

• Board reporting — evidence that TPRM findings and concentration risk were reported to the management body at least annually

• Incident records from ICT TPPs — incidents at providers that affected your operations, your assessment, and your response

The audit trail is not a formality. DORA's enforcement mechanism runs through supervisory examination. The documentation is the evidence; without it, the programme did not happen.

Preparing for Examination

If you are expecting a supervisory examination in 2026, the register of contracts is the document to prepare first. It signals to examiners whether the programme is real or nominal within the first hour of an engagement.

The second document is your criticality classification methodology. Examiners will select three to five providers from your register and ask why each was classified as it was. The answer must come from a documented methodology, not from institutional memory.

If either of these is not ready, that is where to start.

If your organisation is preparing for a DORA examination or remediating gaps in your third-party risk programme, we work with financial entities across both requirements. Get in touch to discuss where your programme stands.