The short answer
DORA is an EU financial-sector regulation. Start by establishing whether the entity and ICT arrangements are in scope, not by applying a generic checklist to every supplier.
Understand the scope before mapping controls
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies from 17 January 2025. It establishes obligations for financial entities within its scope, with distinctions and exemptions that require careful review. It is not a general law for every company that buys software. An ICT supplier may face customer contract requests without becoming subject to every obligation imposed on a financial entity.
This article is educational, not legal advice or a compliance determination. Read the current regulation, applicable technical standards and supervisory guidance with qualified advisers. A short article cannot determine your entity's status or contractual obligations.
Map the ICT service to the supported function
Begin with the entity, ICT supplier, service and business function supported. Determine whether a critical or important function is involved using the applicable criteria, rather than simply copying a supplier's marketing classification. Connect this map to the organization's ICT risk-management arrangements.
DORA's ICT third-party risk provisions include maintaining information about contractual arrangements. Build records that can be reconciled with procurement, legal and operational inventories. A spreadsheet of supplier names without service and entity context is unlikely to support reliable oversight.
Translate requirements into operating evidence
Chapter V of DORA addresses ICT third-party risk. Article 28 covers general principles, Article 29 addresses preliminary concentration-risk assessment and Article 30 sets out key contractual provisions. Requirements differ depending on whether services support critical or important functions. Delegated Regulation (EU) 2024/1773 further specifies policy content for those arrangements.
- Identify accountable owners for assessment, contracting and ongoing oversight.
- Record service scope, supported functions and material dependencies.
- Map applicable contractual requirements to reviewed clauses and gaps.
- Link monitoring, assurance evidence and findings to the arrangement.
Examine concentration and exit realistically
Multiple contracts do not necessarily mean diversified dependencies. Different providers can rely on the same infrastructure, subcontractor or location. Assess whether substituting or leaving a service is feasible and what disruption could follow.
Exit planning should consider data portability, transition support, operational continuity and the time needed to establish an alternative. A documented exit strategy is only useful if the organization understands its assumptions and maintains it as the service changes. Applicable testing and planning requirements should be checked against the actual arrangement and regulatory provisions.
Do not confuse buying a tool with compliance
A platform can help organize records and workflows, but it cannot decide scope, negotiate every contract or accept risk on behalf of accountable management. Evaluate tools against the operating records you need, not a general claim of being DORA-ready.
Keep legal requirements separate from your implementation choices. Record the provision, its applicability, the evidence and the reviewer. Revisit the map when standards, supervisory expectations or your ICT arrangements change. That is more defensible than a one-time completion badge.
Sources & further reading
Primary-source guidance informs these articles. Example workflows are illustrative, not regulatory requirements.