Digital operational resilience: what DORA requires and how to build it

Does DORA apply to your organisation?

DORA applies to almost every type of financial entity regulated in the EU: credit institutions, payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, central securities depositories and others. It also reaches critical ICT third-party service providers, meaning the cloud platforms, data centres and software vendors that financial entities depend on.

If you are a technology vendor whose customers include EU-regulated financial entities, DORA affects you indirectly. Your customers must manage ICT third-party risk. For you, that means contract requirements, audit rights and, for the largest providers, possible designation for supervisory oversight.

Financial entity

Any organisation listed in Article 2(1), such as banks, insurers, investment firms, payment institutions, crypto-asset providers and the other types of regulated entity it lists.

Critical ICT third-party service provider

An ICT provider designated by the European Supervisory Authorities as critical to the financial system. Subject to direct oversight under the Lead Overseer framework.

ICT services

Digital and data services provided through ICT systems on an ongoing basis, such as cloud computing, software, data analytics and data centres. Article 3(21) defines the term broadly.

ICT risk management framework

Chapter II of DORA requires every financial entity to establish an ICT risk management framework. The management body bears ultimate responsibility for it and must approve it at least annually. The management body cannot delegate this responsibility, and national law can attach penalties to its members.

The framework must cover the identification of ICT assets and dependencies, protection and prevention, detection of anomalous activity, response and recovery, and learning from incidents. DORA sets out in some detail what the framework must contain.

• Asset identification. Identify and document all ICT assets, their dependencies and the business functions they support. Include assets held by ICT third-party providers.
• Protection and prevention. Policies for ICT security, access control, encryption, network security and patch management, aligned with recognised standards.
• Detection. Mechanisms to detect anomalous activity, including ICT-related incidents, as promptly as possible, with more than one layer of control.
• Response and recovery. An ICT business continuity policy with response, recovery and communication plans, tested regularly.
• Learning and evolving. Post-incident reviews, threat intelligence gathering, and changes to the framework based on lessons learned.

ICT-related incident management and reporting

DORA requires financial entities to classify, manage and report major ICT-related incidents to their competent authority. The classification criteria and reporting timelines are the same across the EU and replace the national requirements that applied before.

A major ICT-related incident is reported in three stages: an initial notification within four hours of classification and no later than 24 hours after becoming aware of the incident, an intermediate report within 72 hours, and a final report within one month. The classification criteria include the number of clients affected, duration, geographical spread, data losses and the criticality of the services affected.

Financial entities must also inform affected clients without undue delay when the incident has or may have an impact on their financial interests. Significant cyber threats may be reported to the competent authority on a voluntary basis.

ICT third-party risk management and the Article 28 register

Chapter V of DORA sets detailed requirements for managing ICT third-party risk. Financial entities must keep a register of all ICT third-party arrangements, carry out due diligence before entering into them, include specific contract terms, and monitor providers on an ongoing basis.

The Article 28 register usually takes the longest to build. It must record every ICT service arrangement, including the provider, the services delivered, the functions supported, data locations and subcontracting chains. The register is filed with the competent authority in xBRL-CSV format.

• Article 28 register. A structured register of all information relating to ICT third-party arrangements, kept at entity, sub-consolidated and consolidated levels and filed with the competent authority.
• xBRL-CSV reporting. The register is reported in xBRL-CSV, the machine-readable format the European Supervisory Authorities specify for regulatory data.
• Pre-contractual assessment. Before entering into an ICT third-party arrangement, assess whether it supports a critical or important function, whether it would increase concentration risk, and whether the provider meets information security requirements.
• Contractual provisions. DORA sets minimum contract terms, including service levels, data location, audit rights, exit strategies and termination conditions. These apply wherever the provider is located.
• Concentration risk. Assess and manage concentration risk from ICT third-party dependencies. Map which critical functions depend on which providers, and whether alternatives exist.
• Exit strategies. Exit plans are mandatory for every ICT service arrangement that supports a critical or important function. They must be tested and kept current.

Digital operational resilience testing

DORA requires financial entities to test their digital operational resilience through a programme of ICT testing. All entities must carry out basic testing, such as vulnerability assessments, network security assessments, gap analysis and software reviews. Larger and more systemically important entities must also carry out advanced testing, including threat-led penetration testing (TLPT) at least every three years.

TLPT is carried out by qualified testers following a recognised framework such as TIBER-EU. Internal testers may be used under the conditions in Article 27, but external testers must run at least every third test, and significant credit institutions must always use external testers. The scope must cover critical or important functions and the ICT services that support them, including those provided by ICT third-party providers.

• Basic testing. Vulnerability assessments, open-source analysis, network security assessments, gap analysis, physical security reviews, software reviews, and source code reviews where feasible.
• Threat-led penetration testing. Advanced testing for significant entities, covering critical functions and their ICT infrastructure. It uses qualified testers, external or, under Article 27, internal, and a recognised threat intelligence framework.
• Testing of ICT third-party providers. Financial entities may require their ICT service providers to take part in testing, including pooled testing arrangements that share the cost.
• Remediation. All identified vulnerabilities must be prioritised, fixed and verified. Once a test is complete, the competent authority issues an attestation that it was performed.

Information sharing arrangements

Article 45 of DORA allows financial entities to exchange cyber threat information and intelligence among themselves. It is a permission, and the regulation encourages its use to strengthen resilience across the sector.

Sharing arrangements must respect data protection rules, competition law and the handling of non-public information. The regulation gives legal certainty that sharing threat intelligence within trusted communities does not breach confidentiality obligations.