DORA for Financials

Resilience in the finance sector

DORA regulates the EU financial sector with extensive cybersecurity obligations and oversight:

• Entities: DORA regulates financial entities such as credit institutions, traders and insurers, as well as ICT third-party service providers, in all EU member states.
• Resilience: Financial companies must fulfill extensive obligations such as Risk management, Incident management, Resilience testing, information sharing, provider management.
• IT providers: Have their own extensive obligations under EU supervision.
• Cooperation: DORA calls for cooperation between national authorities and EU authorities such as ESA, ECB and ENISA, plus cooperation between DORA and NIS2 authorities.
• Sanctions: Member states define sanctions that can be applied by authorities. Sanctions can be of an administrative, financial or criminal nature.
• Deadlines: DORA applies directly to affected companies as an EU regulation and must be applied from January 2025. No national transposition (like with EU NIS2) is necessary.
• Supervision: Financial entities are supervized by national authorities that cooperate with EU authorities; ICT third-party service providers are supervized by EU authorities.

DORA and NIS2

Entities

DORA and NIS2 overlap for regulated entities in the financial sector and companies that provide services for the financial sector. Financial entities are largely exempt from NIS2 (except for registration with the BSI), however some IT service providers might be subject to double NIS2 and DORA regulation.

Obligations

Obligations in DORA and NIS2 are similar – both require risk management of IT and services provided. DORA is more comprehensive and detailed than NIS2 – obligations are much more prescriptive and detailed.

Companies affected by DORA and NIS2 must translate between the obligations.

Oversight

In DORA, financial entities are subject to supervision by national supervisory authorities (e.g. Germany BaFin, Bundesbank and also ECB), which cooperate with EU authorities; ICT third-party service providers are subject to direct EU supervision.

In NIS2, institutions are primarily supervized by national authorities (in Germany BSI, BNetzA).

Entities

DORA regulates two types of companies in the EU: financial entities, which are directly affected, and ICT third-party service providers, which are indirectly affected.

Exclusions

There are exclusions for the financial entities affected by DORA: Art. 2 (3)

• Managers of alternative investment funds as referred to in Article 3(2) of Directive 2011/61/EU
• Insurance and reinsurance undertakings as referred to in Article 4 of Directive 2009/138/EC
• Institutions for occupational retirement provision with fewer than 15 members
• Natural or legal persons exempted pursuant to Articles 2 and 3 of Directive 2014/65/EU
• Insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries which are microenterprises or small or medium-sized enterprises
• Post office giro institutions as referred to in Article 2(5), point (3), of Directive 2013/36/EU

Difference to NIS2

When financial entities are regulated by DORA, they are excluded from NIS2. However, due to the exclusions in DORA, there are also financial companies that do not fall under the scope of DORA – these could be affected in turn by NIS2.

ICT third-party service providers regulated in DORA remain regulated in NIS2 if affected there.

Financial entities

DORA aims to achieve a high level of digital operational resilience within the EU and defines uniform requirements for the security of network and information systems that support the business processes of financial companies.

Financial entities regulated by DORA must implement resilience measures and provide evidence to supervisory authorities. Depending on their classification by the supervisory authority, critical ICT service providers are also regulated with separate DORA obligations.

Risk management

Governance

Financial institutions must implement many ICT risk management measures for DORA. The basis for ICT risk management is an internal governance and control framework for the effective and prudent management of ICT risks. The definition, approval, monitoring and responsibility for this lies with the management. Art. 5

The ICT risk management framework must be integrated into risk management and include strategies, policies, procedures and IT tools to properly and adequately protect information, IT and physical assets. Art. 6

A dedicated role must be filled in senior management for the monitoring of ICT third-party service providers. The management body should keep its knowledge and skills about ICT risks up to date and complete training courses. Art. 5 (3-4)

Requirements

The management must control and be responsible for the implementation of ICT risk management, which must include the following strategic guidelines and policies: Art. 5 (2)

• Assume overall responsibility and establish roles (a, c, d)
• Strategies: Digital operational resilience (see below), risk tolerance for ICT (d)
• Policies and guidelines: Data security, business continuity, response/recovery plans (b, d)
• Internal audits and plans (f)
• Budgeting for security and resilience (g)
• Security awareness, training and awareness and ICT skills (g)
• Review and approval of agreements with third-party ICT service providers
• Reporting channels within the company

Strategy

ICT risk management must include a strategy for digital operational resilience with methods for translating risk management into action: Art. 6 (8)

• Anchoring ICT risk management in business strategy, determining risk tolerance, defining targets for IT security with KPIs and metrics (a, b, c)
• Description of detection mechanisms for ICT incidents and evaluations of incidents and preventive measures (d)
• Description of detection mechanisms for ICT incidents and analyses of incidents and preventive measures (e, f)
• Implementation of the resilience tests in Art. 24-27 (g)
• Communication strategy for incidents according to Art. 14 (h)

Information and IT assets must be protected with strategies, guidelines, protocols and tools, and ICT risks must be minimized by appropriate measures. Art. 6 (2)(3)

Audits and Review

ICT risk management must be documented and reviewed and regularly improved at least annually or on special request. An independent control function should monitor and manage ICT risks, and financial companies should adhere to the three lines of defence. Art. 6 (4)(5)

Internal auditors should regularly audit the ICT risk management framework as part of the financial organisation's risk-based audit plan. This requires the necessary skills and knowledge. Art. 6 (6)(7)

Protection of IT

Resilient IT

To manage ICT risks, financial organisations must use ICT systems, protocols and tools that are appropriate, reliable, sufficiently dimensioned and technologically resilient. They must always keep these up to date. Art. 7

As part of ICT risk management, solutions and processes must be designed to be resilient and ensure the availability, authenticity, integrity and confidentiality of data. This includes secure data transmission, management, protection against unauthorized access and errors. Art. 9 (3)

Identification

In ICT risk management, all ICT-supported company functions, roles and responsibilities as well as supporting assets with roles and dependencies must be identified, classified and documented. Configurations, connections and dependencies of assets must also be recorded.

All sources of ICT risks, cyber threats and vulnerabilities must be continuously identified and changes to the network, IT systems and processes must be assessed. Third-party ICT service providers must be identified and evaluated. The information collected must be documented in corresponding inventories. Art. 8

Measures

Security and functionality of ICT systems must be continuously monitored and the impact of risks minimized. Resilience, continuity and availability of ICT systems must be ensured to maintain high standards of availability, authenticity, integrity and confidentiality of data. Art. 9

As part of ICT risk management, the following requirements must be implemented: Art. 9 (4)

• Information security policy for data, information and ICT assets (a)
• Risk-based approach to network and infrastructure management and automated mechanisms for attack isolation (segmentation, zoning) (b)
• Access control through policies, procedures and mechanisms for IAM (c)
• Specifications for strong authentication, cryptography and encryption (d)
• Change management with policies, procedures and mechanisms for software, hardware, firmware(!), systems and security (e)
• Patch management policies and guidelines

Incidents and Reaction

Detection

Events like ICT security incidents and performance problems in networks must be recognized immediately and potential individual material vulnerabilities identified.

Incident management needs to define alarm thresholds and criteria, response processes and automated warning mechanisms with sufficient resources for monitoring user activities, anomalies and incidents. Art. 10

Communication

Financial organisations must have communication plans in place that enable appropriate disclosure of at least serious ICT incidents or vulnerabilities to clients and other financial organisations and the public.

Communication strategies must be in place for internal communication in the event of security incidents. With the implementation of the communication strategy, a role must be defined that fulfils tasks vis-à-vis the public and the media. Art. 14

Lessons Learned

There must be sufficient capacity to investigate vulnerabilities, threats, incidents and their impact on digital operational resilience. Training for IT security and digital operational resilience must be developed and made mandatory for all employees and management. Art. 13

Following disruptions caused by ICT incidents, the cause must be investigated and improvements identified (lessons learned). Results must be incorporated into risk management. Changes following an ICT incident must be communicated to authorities on request.

Business Continuity Management

Continuity

A business continuity policy must be defined and implemented with BCM plans and methods to ensure the continuity of critical and important business functions and limit damage caused by ICT incidents through a rapid, appropriate and effective response. Art. 11

Business impact analyses (BIA) must be carried out.

Response and recovery plans must be implemented in ICT risk management and be subject to internal audits. The plans must be tested regularly, at least annually, including outsourcing and third-parties. Communication and crisis management measures must be defined.

Losses

Financial organisations must report to competent authorities, on request, the estimated aggregate annual costs and losses caused by serious ICT-related incidents. Art. 11 (10)

Recovery

ICT systems and data must be restored with minimum downtime and losses, data recovery must not risk its availability, integrity or confidentiality. Backup systems must be tested regularly.

Guidelines and procedures for data backup must be defined based on the criticality and confidentiality of the data. Data backup systems must be physically and logically separated.

Redundancies in resources, capabilities and functions must be maintained for business. Art. 12

Resilience testing

Financial entities must test their digital operational resilience in the ICT risk management framework and define a resilience testing programme for this purpose. Risk-based tests must be conducted by independent internal or external auditors. Findings must be addressed. Art. 24

ICT

Appropriate tests of digital operational resilience must be carried out at least annually to cover all IT systems and applications that support critical and important functions at the financial organisation. Art. 24 (6)

The test program must include vulnerability scans, open source analyses, network security, physical security checks, software scans, source code tests, scenario-based tests, compatibility tests, performance tests, end-to-end tests and penetration tests. Art. 25

Penetration testing (TLPT)

Certain financial organisations, such as significant financial institutions, need to perform extended Threat Led Penetration Tests (TLPT) at least every three years. These pentests have to cover critical and important functions and be carried out on live production systems. Art. 26

ICT third-party service providers in the scope of TLPTs have to be involved in testing. Tests must implement controls to mitigate the risk of impact of the tests on data, assets and critical and important functions. Art. 26 (2-5)

Once the tests have been completed, reports and corrective action plans must be drawn up and a summary of the results submitted to the competent supervisory authority. The authority then certifies that tests have been carried out. Art. 26 (6-7)

Testers

Financial companies are subject to guidelines as to which testers they should contract. Major financial organisations need to carry out the tests externally; for others, they must be conducted externally every third cycle. Art. 26 (8)

Auditors who carry out TLPTs are subject to special requirements such as professional suitability, technical and organisational skills, specialist knowledge, certifications, compliance with formal codes of conduct and insurance. Art. 27

Management of ICT third parties

Financial organisations must address risks of using ICT third parties (service providers) in their risk management. Responsibility for compliance with DORA requirements remains with the financial institution, even if they outsource business functions to ICT service providers with corresponding agreements. Art. 28 (1)

Strategy

ICT third-party risk strategy must include guidelines for ICT third-party service providers that support critical and important functions at the institution. Management must regularly review all risks arising from ICT services supporting critical and important functions. Art. 28 (2)

Provider audits

Financial entities must audit their service providers on a regular basis. To this end, they define the frequency of audits and inspections as well as the areas to be audited and the exercise of access, inspection and audit rights at the third-party ICT service provider.

Financial organisations must ensure that internal and external auditors have the skills to audit and assess the contractual services appropriately, especially if the services are highly technically complex. Art. 28 (6)

Concentration risk

When planning the conclusion of contracts for ICT services, financial organisations must take particular account of the risks that arise: Art. 29 (1)

• whether there will be contracts with a service provider that would be difficult to replace
• whether there will be several contracts with the same or closely related third-party ICT service providers to support critical or important functions.

Financial organisations must weigh up the benefits and costs of alternative solutions, such as using different service providers, and consider whether and how the planned solutions meet the business needs and objectives set out in the digital resilience strategy.

Provider register

Financial entities must keep a register of contractual agreements with ICT third-party service providers, including whether services support critical or important functions. New agreements, service provider categories and services provided must be reported to the competent authority at least once a year.

The complete register must be provided to the competent authority upon request. If service provider are planned to support critical or important functions, the competent authority must be informed Art. 28 (3)

Subcontractors

Financial entities must consider the risks of subcontracting in contracts with third-party ICT service providers. When subcontracting support for critical or important functions, financial organisations must consider the following: Art. 29 (2)

• Provisions of insolvency law in the event of insolvency of the ICT third-party service provider
• Restrictions arising for the urgent recovery of data
• Compliance and enforcement of EU data protection rules for ICT third-party providers
• Impact of complex subcontracting chains on their ability to fully monitor the contracts

Contract requirements

Evaluation of providers

Before concluding contracts with ICT service providers, financial companies must: Art. 28 (4)

• Check whether the service supports critical or important functions
• Evaluate and fulfil regulatory conditions for awarding contracts
• Assess the risks of the service provider relationship, including ICT concentration risks
• Ensure due diligence on the suitability of service providers continuously during procurement
• Evaluate conflicts of interest based on the contractual agreement

Contractual agreements with ICT third-party service providers may only be concluded if they comply with appropriate information security standards. If critical or important functions are supported, companies must ensure service providers apply the highes information security standards. Art. 28 (5)

Termination

Financial companies must be able to terminate service contracts in case of: Art. 28 (7)

• significant violation of applicable laws, regulations or contracts by the service provider,
• proven weaknesses of the service provider in ICT risk management,
• contract prevents effective supervision of the financial company by the authorities.

Exit strategies

Financial companies must have exit strategies for ICT services that support critical or important functions. These must ensure maintaining business activities, compliance with regulatory requirements and continuity and quality of the services provided to customers.

Exit strategies must include concrete exit plans, alternative solutions and workarounds, as well as appropriate contingency measures for the continuation of business operations if restrictions do occur in the course of an exit. Art. 28 (8)

Obligations

Contracts with ICT third-party service providers must clearly assign the rights and obligations of the financial company and the service provider and document them in writing. Art. 30 DORA prescribes specific aspects for service provider contracts, including:

• Clear and complete description of the functions and services provided
• Service locations/provision
• Provisions on availability, authenticity, integrity and confidentiality
• Agreed service levels
• Obligation to support the financial entity in ICT incident management
• Termination rights and associated minimum notice periods
• Training and awareness of ICT third-party service providers on digital operational resilience

Contracts for services supporting critical or important functions must fulfil higher requirements with more requirements, in particular monitoring and audit rights for financial companies and exit strategies that enable companies to change providers or switch to internal solutions.

ESA will develop technical standards (RTS) to specifyaspects that a financial organisation must evaluate when subcontracting ICT services that support critical or important functions.

Registration

DORA does not set out requirements for the registration of affected financial companies with competent authorities. Financial companies register with the competent supervisory authorities as part of (regular) national market entry procedures.

Incident reporting

Financial entities must report ICT incidents to relevant supervisory authorities and implement comprehensive internal and external processes. This includes detection, handling and reporting of incidents. All ICT-related incidents and significant cyber threats must be recorded.

Handling

Incident management processes must include indicators, procedures for detection, tracking, logging, categorisation and classification, and communication plans (employees, stakeholders, media and customers). Serious incidents must be reported to senior management. Art. 17

ICT incidents must be classified and their impact assessed. Criteria include number of affected customers, duration and geographical spread of the incident, loss of availability, authenticity, integrity or confidentiality of data, criticality of the affected services and economic impact.

Cyber threats must also be assessed using analogue criteria. Art. 18

Reporting

Financial entities must report serious ICT incidents to the competent authority. In the case of credit institutions classified as significant, this report is forwarded by the authority to the ECB.

If a serious ICT incident has an impact on the financial interests of customers, entities must inform customers of the incident. Cyber threats can be reported if the threat is relevant to the financial system, users of the service or customers. Art. 19

For reporting serious ICT incidents and cyber threats and reporting deadlines, ESA will develop technical standards (RTS) with ENISA and the ECB and explore the establishment of an EU platform for reporting serious ICT incidents. Art. 20 Art. 21

Feedback by authorities

Supervisory authorities shall acknowledge reports of serious ICT incidents and provide guidance as appropriate. This may include the provision of relevant anonymized information and intelligence on similar threats and remedial actions. Art. 22

The requirements also apply to payment-related operational or security incidents, including those of a serious nature, if they concern credit institutions, payment institutions, account information service providers and e-money institutions. Art. 23

Information exchange

Financial organisations can share information and intelligence about threats, such as indicators, tactics, techniques and procedures, warnings and tools. Participation in such information exchange is voluntary. Recital 34

The exchange of information and insights is intended to strengthen the digital operational resilience of financial organisations, with agreements to protect sensitive information. Art. 45

If financial undertakings enter into or terminate such an exchange, they must notify the competent supervisory authority accordingly.

National supervision

In DORA, financial companies are supervized nationally by competent authorities, which are defined in various other EU regulations to which DORA refers. Art. 46

Critical third-party ICT service providers are monitored separately by EU.

EU supervision

In addition to the national supervision of financial entities, there is cooperation between EU supervisory authorities and mechanisms: ESA, JON and cooperation with national authorities.

European Supervisory Authorities (ESA)

ESA are the three European Supervisory Authorities which, together with the European Systemic Risk Board (ESRB), form part of the European System of Financial Supervision (ESFS):

• European Banking Authority (EBA): EBA develops European supervisory standards for financial market supervision, which form the framework for the primarily responsible national supervisory authorities.
• European Insurance and Occupational Pensions Authority (EIOPA): EIOPA is responsible for the harmonized supervision of insurance and occupational pensions and for maintaining financial market stability in these areas.
• European Securities and Markets Authority (ESMA): ESMA monitors compliance with legal regulations in the financial sector focused on rating agencies, traders and central counterparties. ESMA also coordinates the activities of the securities supervisory authorities.

Joint Oversight Network (JON)

The supervisory authorities EIOPA, ESMA and EBA are setting up a Joint Oversight Network (JON) to coordinate the supervisory activities of ICT third-party service providers. The ECB and ENISA may be asked for ad hoc technical advice or to participate in meetings. Art. 34

Cooperation with NIS2 authorities

ESA and competent authorities may participate in the NIS2 Cooperation Group as part of their supervision of financial entities. They may request participation in topics concerning ICT service providers that are NIS2 entities and critical ICT service providers under DORA. The authorities for DORA and NIS2 should coordinate their activities. Art. 47

Cooperation is also planned in the reporting system so that financial supervisory authorities can also pass on details of serious ICT incidents to non-financial authorities, e.g. competent authorities under NIS2. Recital 52

Interdependencies

Competent authorities under DORA (ESA, ENISA, national authorities, etc.) should establish information exchange in financial sectors. They should develop crisis and contingency plans for cyber-attacks to analyse the interdependencies of the financial sector with other sectors and develop a coordinated response at EU level. Art. 49

Harmonisation

ESA is developing technical standards (RTS) together with ENISA and the ECB. Art. 15

Audits

ICT risk management framework of financial entities must be regularly reviewed:

• at least annually
• after ICT incidents
• according to supervisory instructions
• in case of findings from tests or audit procedures

Reports must be submitted at the request of the competent supervisory authority. Art. 6 (5) The national supervisory authorities use these reports to check the consistency of the ICT risk management framework. Art. 4 (3)

If a simplified ICT risk management framework is applied, it must be documented and reviewed in accordance with regulatory instructions on a regular basis and when serious ICT-related incidents occur. Art. 16 (2)

Critical ICT third party service providers

Some IT providers that serve financial entities in the EU are categorized critical by ESA and monitored by an EU lead overseer. These critical third-party ICT service providers that provide high-risk services for financial entities must implement provider-specific DORA obligations.

Critical how?

The ESA (European Supervisory Authorities) categorise critical ICT third-party service providers based on several criteria: Art. 31

• Systemic effects: Operational disruptions of the ICT service provider that would have an impact on the stability, continuity or quality of financial services
• Systemic nature: Importance of the ICT service provider or financial entities that consume the services. Number of global systemically important institutions or other systemically important institutions that rely on the ICT service provider, or interdependencies between the aforementioned institutions
• Dependence of financial entities on the services: Critical or important functions in which the same ICT service provider is involved (directly or indirectly)
• Degree of substitutability of the ICT service provider: Potential lack of alternatives due to the limited number of third-party ICT service providers, or difficulties in migrating from one service provider to another

If a ICT third-party service provider is part of a larger group, the above criteria must be applied to the ICT services provided in the overall group structure, regardless of the company structure. This should ensure an accurate assessment of service providers. Recital 77

The ESA publish a list of service providers categorized as critical on an annual basis.

Exclusions

The following entities cannot be categorized as critical: Art. 31 (8)

• Financial entities that provide ICT services to other financial entities
• ICT third-party service providers subject to other EU monitoring frameworks
• Group-internal ICT service providers
• ICT third-party service providers that provide their services exclusively in a Member State to financial entities operating only in that Member State

Overlap with NIS2

For critical ICT service providers under DORA, there are overlaps and duplications with NIS2. Companies are potentially subject to multiple regulation with DORA obligations as a critical ICT service provider and NIS2 obligations as an organisation under NIS2. DORA identifies cloud computing service providers as infrastructure that also falls under NIS2.w Recital 20

Critical service providers

Critical ICT third-party service providers are monitored by an EU authority and assessed in ICT risk management. To this end, critical ICT service providers must fulfil many obligations: Art. 33

Scope

ICT risk management in DORA must include all ICT services and processes that support critical or important functions of financial organisations. To this end, service providers must assess which services they use to pose ICT risks to financial entities, and implement DORA measures within this scope. Art. 33 (2)

Cybersecurity

Governance: Organisational structures and governance rules with clear responsibility and accountability for effective ICT risk management. Art. 33 (3) d

Risk management: Processes and policies for ICT risk management, business continuity (BCM) and IT emergency plans (ICT response and recovery plans). Art. 33 (3) c

Standards: Utilisation of relevant national and international standards in services to financial entities. Art. 33 (3) i

Interoperability: Mechanisms for data and application portability and interoperability, for effective termination rights of financial entities. Art. 33 (3) f

Technical security

IT protection: Measures for IT and TC to protect the services provided by ICT service providers for financial entities - in particular the security, availability, continuity, scalability and quality of services. This also includes data security. Art. 33 (3) a

Physical security: Protection of buildings, properties and data centres, and physical security that supports IT security. Art. 33 (3) b

Detection and incidents: Identification, monitoring and reporting of IT incidents to financial organisations and handling and remediation of these incidents and cyber attacks. Art. 33 (3) e

Tests and Audits: Testing of systems, infrastructure and controls, IT audits. Art. 33 (3) g/h

Contractual

In addition to their own DORA obligations, ICT third-party service providers must also implement contractual obligations of their financial clients that arise from the DORA-prescribed provider management in contracts; they must actively participate in some obligations of financial entities.

• Possible integration into the annual testing programme of ICT systems for critical and important functions at financial entities Art. 24
• Integration into Threat Led Penetration Tests (TLPT) at financial entities Art. 26, 30 (3) d
• Service provider audits by the financial entities Art. 28 (6)
• Compliance with appropriate standards for information security and highest standards when supporting important and critical functions Art. 28 (5)
• Various information obligations and information on services and infrastructure Art. 30 (2)
• Supporting financial entities in ICT incident management and cooperation, including with authorities Art. 30 (2) f-g
• Participation in security awareness programmes of financial entities Art. 30 (3) i
• Reporting obligations for developments in critical and important functions that have an impact on financial entities (and SLAs) Art. 30 (3) b
• Implementation and testing of BCM plans and IT measures for critical and important functions Art. 30 (3) c
• Extensive audit rights for critical and important functions: Access, inspections and audits by financial entities and authorities, access to documents, co-operation Art. 30 (3) e

Auditing

Critical ICT third-party service providers are monitored annually by their supervisory authority for compliance with the above-mentioned obligations under Art. 33 (3). Competent authority carries out the assessment with a clear, detailed monitoring plan containing annual monitoring objectives and measures. Art. 33 (4)

The monitoring plan is sent as a draft to the critical ICT service providers, who can then propose solutions within 15 days if the monitoring activities lead to risks and negative effects for their customers outside DORA.

Supervision of service providers

ESA, European Supervisory Authorities, appoint EIOPA, ESMA or EBA as the lead supervisory authority for each critical third-party ICT service provider. Art. 33 (1b) Critical ICT third-party service providers are therefore under the direct supervision of an EU financial authority.

Monitoring forum

A monitoring forum will support the competent EU supervisory authorities on risks from ICT third parties. The forum develops common positions, discusses risks and vulnerabilities and promotes an approach to monitoring. Art. 32

Powers of the supervisory authorities

In order to assess whether critical third-party ICT service providers fulfil their DORA obligations, EU supervisory authorities have far-reaching powers over service providers:

• Information requests: Supervisory authorities may request that all information necessary for monitoring be made available. Art. 37
• General investigations: Supervisory authorities may conduct investigations at the ICT service provider and examine records, data and procedures, summon representatives, request statements to be made, question persons and request recordings of telephone conversations and data transmissions.
  It may authorise third parties for these investigations. Art. 38
• Inspections: Supervisory authorities are authorized to carry out inspections in the business premises, properties and buildings of the ICT third-party service provider. They may enter and seal premises. Art. 39
• Follow-up measures: Supervisory authorities may share information on the implementation of recommendations with the authorities responsible for financial entities. In certain cases, the public may also be informed, naming the ICT service provider and the nature of the non-compliance. In case of doubt, authorities can require financial entities to suspend the use of the ICT service provider concerned. Art. 42
• Sanctioning: Supervisory authorities can impose fines to force critical third-party ICT service providers to comply with measures. Art. 35 (6-11)

ESA are developing technical standards (RTS) to specify the requirements for ICT third-party service providers for duties and monitoring activities. Art. 41

Reports

After monitoring activities, authorities can request reports on measures from the service providers and make recommendations for improvement. Authorities will coordinate with each other, including with NIS2 authorities, in order to avoid overlapping technical and organisational measures. Art. 35 (2)

Audit team

Authorities are supported in their activities, such as investigations and inspections, by a monitoring team that is set up for each critical ICT service provider. Art. 40

• Employess of ESA (European Supervisory Authorities)
• Employees of competent authority for financial entities
• (optional) Employees of competent NIS2 authority
• (optional) Employees of the national authority for the ICT service provider

Register of providers

ESA will publish a list of ICT service providers categorized as critical on an annual basis. Art. 31

Legislation

Timeline

EU Parliament and Council adopted the DORA Regulation (2022/2554) on 14 December 2022. DORA entered into force on 17 January 2023 and will be applied from 17 January 2025.

DORA framework

European Supervisory Authorities EBA, EIPOA and ESMA must publish supplementary regulatory technical standards (RTS) and technical implementing standards (ITS) by 17 July 2024 to specify individual requirements from DORA.

Review

DORA is to be reviewed periodically by the Commission after consultation with the ESA and the ESRB, with the first report in January 2028.

Literature

1. European System of Financial Supervision, European Central Bank, 2024.
2. ESAs publish first set of rules under DORA for ICT and third-party risk management and incident classification, European Securities and Markets Authority, 17.01.2024.

Sources

1. REGULATION (EU) 2022/2554 (DORA), on digital operational resilience for the financial sector, 14 December 2022