DORA: ICT risk, TLPT, and critical third parties in EU financial services

DORA is not a generic information-security framework. It is a financial-sector resilience regime that expects senior management accountability, ICT risk controls, registers of third-party arrangements, contractual rights, incident classification, and digital operational resilience testing. It applies to many regulated financial entities, and it indirectly affects providers that serve them.

The register of information is a supervisory artifact, not a vendor spreadsheet. It must reflect services, functions supported, subcontracting chains, locations, criticality, and exit considerations. The same practical lens applies to testing: basic vulnerability management, scenario exercises, and, for designated firms, threat-led penetration testing all serve different purposes.

DORA also makes resilience evidence more connected than many firms are used to. The outsourcing register should match contracts, the incident taxonomy should match playbooks, the testing plan should reflect critical functions, and board reporting should show whether open findings threaten those functions. When those artifacts disagree, supervisors will see a governance issue rather than a formatting issue, especially if senior management cannot explain which version is authoritative.

The checklist cannot decide whether an ICT service supports a critical or important function. That judgment requires business owners, risk teams, outsourcing owners, and technology leaders to agree what would happen if the service failed, degraded, or became unavailable during market stress.

It also cannot negotiate your contracts. DORA expects audit rights, access rights, termination support, incident cooperation, and subcontracting visibility where relevant. Procurement must decide when a provider risk is acceptable, when remediation is required, and when a service cannot be used for the intended function.

Finally, the checklist will not tell you whether a particular test is proportionate. A tabletop, vulnerability scan, red-team exercise, and TLPT are not interchangeable. The organization has to choose testing that matches its risk profile and supervisory expectations.

The first failure is treating DORA as ISO with a financial-services label. ISO controls may support the evidence base, but DORA asks for specific outsourcing governance, operational resilience testing, incident reporting, and registers that can be inspected by supervisors. A polished ISMS does not prove those operating routines exist.

The second failure is weak ICT provider governance. Financial entities sign cloud and SaaS contracts without usable audit rights, incident cooperation language, exit provisions, or subcontractor visibility. The gap is manageable during onboarding and painful during an outage, investigation, or regulator request.

Teams also underestimate incident clocks and shadow IT. A major ICT incident can intersect with NIS2, GDPR, customer commitments, and market obligations. If business units buy tools outside the register, risk owners may not know the provider exists until the incident has already become reportable.

Another practical failure is outsourcing concentration that hides inside business language. Three different teams may describe a provider as minor because each uses only one module, while the combined dependency supports payments, reporting, authentication, or customer communications. DORA readiness needs a view of aggregate dependency, not only contract-by-contract diligence.

Start by identifying critical and important functions, then map ICT services to those functions. The checklist should be used after that map exists; otherwise teams will produce generic controls without knowing which providers, systems, and tests matter most.

Bring outsourcing, legal, ICT, security, resilience, and business owners into the same review. For each checklist item, ask for the evidence that a supervisor or internal audit would expect: register fields, contract clauses, test results, incident decision logs, risk acceptances, and remediation plans.

Use the final pass to find contradictions. If the register says a provider is critical, the contract should support that importance. If the incident plan promises notification on a tight clock, the playbook should name who classifies, who drafts, who approves, and who sends.