DORA (Digital Operational Resilience Act) is an EU-wide regulation focused on managing ICT and cybersecurity risks in the financial sector. Its core aim is to strengthen digital operational resilience. The regulation entered into force in 2023 and has applied since 17 January 2025, so affected organisations must now meet its cybersecurity and resilient-infrastructure standards. The following sections explain what DORA regulates, what it covers, which organisations it applies to and how it differs from NIS-2.
The LamaPoll survey tool is DORA-compliant, so organisations can use it with confidence as an ICT service provider to the financial sector.
Table of Contents
DORA - Digital Operational Resilience Act
DORA, formally Regulation (EU) 2022/2554, aims to close existing regulatory gaps in the European financial sector. Like NIS-2, DORA also covers the supply chain, in particular ICT service providers. DORA has applied since 17 January 2025. Unlike NIS, however, DORA is not a directive but a regulation, and is therefore directly binding.
DORA harmonises security requirements, promotes cooperation and EU-wide recognition of test results, and makes negotiating and concluding contracts in the financial sector easier. For ICT service providers to the financial sector in particular, DORA is an opportunity.
What does DORA regulate?
DORA sets requirements in six key areas:
1.) ICT risk management (Chapter II)
- Uniform requirements across all financial sectors, covering the following elements of risk management: identification, protection and prevention, detection, response and recovery, learning and evolving, and communication.
2.) ICT-related incident management, classification and reporting (Chapter III)
- DORA brings together the previously scattered reporting obligations for ICT incidents (including those under the Payment Services Directive PSD2 and the NIS Directive), harmonises them for the entire financial sector and designates the competent national authority as the recipient (in Germany, for example, BaFin).
3.) Digital operational resilience testing (Chapter IV)
- Technical standards define what the tests must look like. They are closely based on the European TIBER-EU framework, which until now had been applied on a voluntary basis, in Germany for example. Tests carried out within the EU are to be mutually recognised.
4.) Managing ICT third-party risk (Chapter V, Section I: key principles for sound management of ICT third-party risk)
- DORA requires ICT third-party risks to be assessed and monitored.
5.) Oversight framework for critical ICT third-party service providers (Chapter V, Section II)
- An EU oversight framework is established with a lead overseer (EBA, ESMA or EIOPA, depending on the sector). The lead overseer has audit, inspection and information rights over the critical service provider, backed by periodic penalty payments. Among other things, it monitors compliance with the ICT risk management requirements.
6.) Information-sharing arrangements (Chapter VI)
- DORA encourages organisations to share information on threats, techniques, procedures and the like, both within and across sectors.
Why is DORA necessary?
The regulation sets out the reasons for it in detail in its recitals. Some of the most important are:
- Information and communication technology (ICT) is generally vulnerable to cyber threats, so an inherent ICT risk is assumed.
- ICT has become central to financial services.
At the same time:
- Digital resilience requirements had been developed for some parts of the financial sector, but not for others.
- Existing requirements were independent of one another rather than aligned, and resilience tests were not mutually recognised. This led to duplicate costs and a lack of clarity.
- Contractual arrangements were individual, complex and difficult to negotiate.
- Certain rights (access, audit) could not be enforced.
- To align business strategy and ICT security, management has to be held accountable.
In short: security must not be sacrificed for business goals. To avoid competitive disadvantages and prevent a patchwork of measures and contract terms, the financial sector has to meet uniform, recognised requirements. Strict rules that apply to all organisations raise the overall level of resilience. Financial entities are also expected to share information on the topic with each other and with the authorities.
Scope of DORA: who is affected
DORA applies to financial entities and to ICT third-party service providers that have been designated as critical.
What are financial entities?
Under DORA (Article 2), the following 20 types of organisation are “financial entities”:
- Credit institutions
- Payment institutions
- Account information service providers
- Electronic money institutions
- Investment firms
- Crypto-asset service providers
- Central securities depositories
- Central counterparties
- Trading venues
- Trade repositories
- Managers of alternative investment funds
- Management companies
- Data reporting service providers
- Insurance and reinsurance undertakings
- Insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries
- Institutions for occupational retirement provision
- Credit rating agencies
- Administrators of critical benchmarks
- Crowdfunding service providers
- Securitisation repositories
What are critical ICT service providers?
Under Article 31(1)(a) of DORA, ICT service providers that are critical to financial entities are designated on the basis of the following criteria (Article 31(2)):
- Systemic impact on the stability, continuity or quality of financial services if the ICT service provider suffered an operational failure (would these be significantly impaired?)
- Systemic character of the financial entities that rely on the ICT service provider (number of global and other systemically important institutions, G-SIIs and O-SIIs, using the provider, and the degree of interdependence between them and other financial entities)
- Degree of reliance of financial entities on the provider’s services in relation to critical or important functions
- Substitutability of the provider: number of alternatives, or lack of them, and the complexity of a potential migration
In other words, under DORA an ICT service provider is critical if a disruption would have a significant impact on financial services, if it has many or particularly systemically important customers in the financial sector, if the financial sector depends heavily on it, or if it would be impossible or difficult to replace.
Who does DORA not apply to?
DORA explicitly excludes six types of organisation:
- 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 that operate pension schemes with fewer than 15 members in total
- Natural or legal persons exempted under Articles 2 and 3 of Directive 2014/65/EU (for example, persons who provide investment services exclusively to their parent company, their subsidiaries or other subsidiaries of their parent company)
- Insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries that are micro, small or medium-sized enterprises
- Post office giro institutions as referred to in Article 2(5), point (3), of Directive 2013/36/EU
Member states may also exempt certain bodies from the regulation, but must notify the Commission if they do so.
What are the differences between NIS-2 and DORA?
Objectives
The main objective of NIS-2 is to harmonise and raise the overall level of cybersecurity in the EU. NIS-2 also explicitly covers banking. DORA, by contrast, is aimed exclusively at the financial sector and regulates its security in greater depth and with a longer-term focus.
Audits and evidence
NIS-2 does not prescribe a uniform audit cycle; the details are set by national law. In Germany, for example, operators of critical facilities must provide evidence of implementation to the Federal Office for Information Security (BSI) every three years (Section 39 BSIG), and the BSI can order essential entities to provide evidence where the risk warrants it (Section 61 BSIG). DORA is stricter: it requires at least annual reviews of security-relevant aspects and, for selected financial entities, threat-led penetration testing at least every three years.
Legal form
NIS-2 is a directive. EU directives do not apply directly in the member states; they first have to be transposed into national law. DORA, on the other hand, is a regulation and as such has general application and is binding in its entirety.
Organisations affected
NIS-2 covers 18 sectors, including banking. DORA focuses specifically on the financial sector and defines 20 types of financial entity as well as the ICT service providers that serve them.
Supervisory authorities
Under NIS-2, each member state designates its own competent authorities. In Germany, for example, supervision lies almost entirely with the BSI, with the main exceptions being the energy sector (Federal Network Agency) and banking (Federal Financial Supervisory Authority, BaFin).
DORA, by contrast, specifies the competent authority for each type of financial entity (Article 46).
Next steps: a DORA checklist
Chapter II - ICT risk management
- Identify critical assets and business processes and rate them by criticality
- Carry out a gap analysis and document the results
- Plan risk treatment (define risk acceptance, tolerance thresholds, etc.)
- Build resilience into business-critical systems: security, availability, integrity, backup and recovery of ICT systems and data
- PDCA: establish continuous learning and improvement, with regular review and optimisation of your ICT risk management framework
Chapter III - ICT-related incident management, classification and reporting
- Set up a comprehensive incident management and response strategy
- Establish a process to detect, log and classify all ICT-related incidents
- Classify incidents: define thresholds for minor and major incidents and critical breaches based on impact, duration, critical services affected, geographical spread and economic impact
- Categorise cyber threats by likelihood and business impact, based on their expected effect on critical systems and business processes
- Keep improving your ICT management processes: regularly review and optimise ICT-related incident management and reporting
Chapter IV - Digital operational resilience testing
- Define the scope of DORA reviews and audits, including systems, tools, protocols, processes and attack surfaces
- Initiate DORA reviews and audits of ICT risks: regular, comprehensive testing of all ICT exposure across every attack surface
- Initiate DORA testing of security defences: regular, comprehensive testing of all security controls and threat detection solutions
- Set a DORA testing cadence for incident management: regularly test ICT-related incident management processes, systems and response measures
- Penetration testing: choose suitable partners and tools and define an appropriate scope
Chapter V - Managing ICT third-party risk
- Service provider management: create a register of ICT third-party service providers
- Assess the criticality of each service provider
- Define roles and responsibilities
Chapter VI - Information-sharing arrangements
- Set up a GRC project team for DORA: extend governance, risk and compliance teams and processes to integrate and manage the DORA programme and framework
- Foster a culture of information sharing with industry peers, partners and ICT third-party service providers
- Training, education and knowledge transfer: make sure every team member knows all DORA-related requirements, processes and operational resilience measures, and how they evolve
LamaPoll: a DORA-compliant survey tool
LamaPoll complies with the Digital Operational Resilience Act (DORA) and can be used with confidence as an ICT service provider to the financial sector.
ICT risk management (Chapter II)
Our comprehensive, externally audited risk management covers:
- Identification: proactive detection of risks and threats
- Protection and prevention: safeguards that prevent incidents
- Detection: real-time monitoring to identify security incidents immediately
- Response and recovery: fast, effective response and recovery after incidents
- Learning and evolving: continuous improvement and adaptation to new threats
- Communication: transparent reporting and communication on risks and measures
ICT-related incident management, classification and reporting (Chapter III)
As part of our incident management, LamaPoll has tightened and formalised its reporting processes:
- Uniform classification: consistent categorisation of incidents
- Efficient reporting: timely notification of the competent supervisory authorities
Digital operational resilience testing (Chapter IV)
LamaPoll regularly tests its operational resilience:
- External tests: recognised specialist firms carry out regular penetration tests covering our infrastructure and back end
- Internal tests ensure that our tool can be restored and remains resilient
Managing ICT third-party risk (Chapter V, Section I)
We have put comprehensive measures in place to assess and monitor risks arising from third-party providers:
- Continuous assessment: ongoing monitoring of third-party providers’ security standards
- Regular supplier assessments and document control
- Strict requirements: we make sure third-party providers meet our high standards
Information-sharing arrangements (Chapter VI)
LamaPoll promotes the sharing of information on threats, techniques and experience:
- Networking: we support cross-sector dialogue to improve security; among other things, LamaPoll is a participant in the German Alliance for Cyber Security
With LamaPoll, you choose a solution that helps you meet legal requirements (DORA compliance) while providing a robust and secure digital environment. Our voluntary ISO 27001 certification underlines our commitment to the highest security standards and robust risk management.
Together with the Federal Office for Information Security (BSI), we conducted a security survey for the first time. The participating companies had high requirements for data protection, cybersecurity and anonymity. LamaPoll met them very well, both technically and organisationally. A contact person was also available whenever needed. We are extremely satisfied with the cooperation.
Any questions for our team?
We’re happy to answer all your questions about security at LamaPoll.
Feel free to get in touch.
