{"id":20698,"date":"2026-10-26T12:15:20","date_gmt":"2026-10-26T11:15:20","guid":{"rendered":"https:\/\/teamwire.eu\/en\/?post_type=lexicon&p=20698"},"modified":"2026-10-26T12:15:20","modified_gmt":"2026-10-26T11:15:20","slug":"dora-regulation-digital-operational-resilience-act","status":"publish","type":"lexicon","link":"https:\/\/teamwire.eu\/en\/lexicon\/dora-regulation-digital-operational-resilience-act\/","title":{"rendered":"DORA regulation (Digital Operational Resilience Act)"},"content":{"rendered":"

DORA (Digital Operational Resilience Act) is Regulation (EU) 2022\/2554 on digital operational resilience in the financial sector. DORA requires financial firms and their ICT service providers to systematically manage information and communication technology risks, report serious incidents within specified timeframes, regularly test their resilience and mitigate third-party risks through contractual arrangements. The Regulation has been directly applicable in all EU Member States since 17 January 2025.<\/p>\n

What is the DORA regulation?<\/h2>\n

For the first time, the DORA regulation establishes a uniform European legal framework to ensure that the financial sector remains capable of functioning even in the event of serious IT disruptions. The starting point of the Regulation is a shift in the logic of supervision: for decades, financial regulation focused primarily on capital adequacy, that is, on the ability to absorb financial losses. DORA supplements this perspective with the operational dimension \u2013 an institution may be extremely well capitalised and yet be unable to function if its core systems are down for days on end.<\/p>\n

The term \u2018digital operational resilience\u2019 is legally defined in Article 3(1) of DORA as the ability of a financial firm to establish, maintain and review its operational resilience against ICT-related disruptions. Noteworthy is the three-part structure of this definition: it requires not only the establishment and maintenance of resilience, but also, explicitly, its verification. A documented but never-tested resilience framework does not meet the requirement.<\/p>\n

DORA is an EU regulation and is therefore directly applicable, without the need for national implementing legislation. It is accompanied by Directive (EU) 2022\/2556, which aligns existing financial market directives with the DORA regulation, as well as by numerous regulatory and implementing technical standards (RTS and ITS) drawn up by the European supervisory authorities EBA, EIOPA and ESMA. A significant proportion of the detailed requirements relevant in practice \u2013 such as those concerning the content of reports, the information register or the classification of incidents \u2013 are not set out in the text of the Regulation itself, but in these downstream legal acts.<\/p>\n

Since when has DORA been in force?<\/h2>\n

The DORA regulation has been in force since 17 January 2025. The Regulation was adopted on 14 December 2022, came into force at the start of 2023 and provided for a 24-month transition period during which financial firms were required to adapt their processes, contracts and testing programmes.<\/p>\n

It is important to note that no further grace period was attached to the date on which the Regulation came into force: The requirements relating to ICT risk management, incident reporting and contract drafting have been fully applicable ever since. Only certain processes are subject to a phased supervisory approach, such as the submission deadlines for the information register and the designation of critical third-party ICT service providers by the European supervisory authorities. Check the current status of these deadlines before implementation, as the supervisory authorities continue to specify them in more detail.<\/p>\n

Who does the DORA regulation apply to?<\/h2>\n

DORA applies to around 20 categories of financial firms, as well as to third-party ICT service providers that serve these firms. These include, amongst others, credit institutions, payment and e-money institutions, investment firms, providers of crypto-asset services, central securities depositories, central counterparties, trading venues, management companies and managers of alternative investment funds, insurance and reinsurance undertakings (including intermediaries), occupational pension schemes, credit rating agencies and crowdfunding service providers.<\/p>\n

The scope of application thus extends well beyond banks \u2013 a point that is regularly underestimated in practical implementation. Also affected are medium-sized insurance intermediaries, smaller capital management companies and payment service providers that have hitherto had little contact with explicit IT supervision.<\/p>\n

However, DORA operates on the principle of proportionality. Article 4 requires that implementation takes into account the size, risk profile and the nature and complexity of the services. For certain smaller firms \u2013 such as small and non-interconnected investment firms, micro-enterprises amongst insurance intermediaries and small occupational pension schemes \u2013 Article 16 provides for a simplified ICT risk management framework. \u2018Simplified\u2019 does not mean \u2018exempt\u2019: governance, protective measures, incident handling and business continuity planning remain necessary; only the level of detail is reduced.<\/p>\n

What are the five pillars of the DORA regulation?<\/h2>\n

In terms of content, DORA is structured around five pillars that build on one another: those who manage risks must identify and report incidents; those who report must have carried out tests beforehand; and all of this also applies to outsourced services.<\/p>\n\n\n\n\n\n\n\n\n
Pillar<\/strong><\/td>\nSource<\/strong><\/td>\nMain content<\/strong><\/td>\n<\/tr>\n
ICT risk management<\/strong><\/td>\nArt. 5\u201316<\/span><\/td>\nGovernance by the governing body, ICT risk management framework, protection, detection, response, recovery, backup and learning processes<\/td>\n<\/tr>\n
Handling and reporting ICT-related incidents<\/strong><\/td>\nArt. 17\u201323<\/span><\/td>\nStandardised process for recording, classifying and reporting serious incidents within specified timeframes<\/td>\n<\/tr>\n
Testing digital operational resilience<\/strong><\/td>\nArt. 24\u201327<\/span><\/td>\nAnnual baseline testing programme and threat-led penetration tests (TLPT) for major organisations<\/td>\n<\/tr>\n
Management of third-party ICT risk<\/strong><\/td>\nArt. 28\u201344<\/span><\/td>\nInformation register, minimum contractual requirements, exit strategies, monitoring framework for critical suppliers<\/td>\n<\/tr>\n
Exchange of information<\/strong><\/td>\nArt. 45<\/span><\/td>\nVoluntary exchange of information on cyber threats between financial institutions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In practical terms, the fourth pillar involves the greatest implementation effort. ICT risk management and incident handling can largely be organised internally; by contrast, requirements relating to contracts, registers, and the ability to terminate contracts require negotiations with service providers, whose standard contracts are often not DORA-compliant.<\/p>\n

What does DORA require in terms of ICT risk management?<\/h2>\n

The DORA regulation requires a documented, regularly reviewed ICT risk management framework that encompasses strategies, guidelines, procedures and tools for the protection of all information and ICT assets. The framework must cover the entire cycle: identification of critical functions and dependencies, protection and prevention, detection of anomalous activity, response and recovery, as well as learning and improvement processes based on real-world incidents and tests.<\/p>\n

Continuity requirements are central to this. Under Articles 11 and 12, financial firms are required to have an ICT business continuity policy with response and recovery plans, redundant capacity, and backup and recovery procedures. Recovery time objectives (RTOs) and recovery point objectives (RPOs) must be defined for each function \u2013 the same metrics used in business continuity management<\/a> under ISO 22301. Backup systems must be physically and logically separated from the production system to ensure that an attack does not affect both primary and backup data simultaneously.<\/p>\n

Responsibility is clearly assigned. Article 5(2) stipulates that the management body bears ultimate responsibility for ICT risk management, approves the framework, monitors its implementation and provides sufficient resources. In addition, the Regulation requires members of the management body to keep their knowledge of ICT risks up to date through regular training. In practice, this is where DORA differs most clearly from purely technical regulatory frameworks: the regulation is addressed not to the IT department, but to senior management.<\/p>\n

How should ICT incidents be reported under DORA?<\/h2>\n

The DORA regulation requires a standardised process for recording and classifying ICT-related incidents and \u2013 where they are classified as serious \u2013 reporting them to the competent authority in three stages. Articles 17 to 19 and the supplementary technical standards are decisive in this regard.<\/p>\n

Classification is based on the criteria set out in Article 18: the number of customers and counterparties affected; duration and downtime; geographical spread; impact on the availability, authenticity, integrity and confidentiality of data; the criticality of the services affected; and the economic impact. Only when defined thresholds are exceeded is an incident deemed serious and does it trigger the reporting chain.<\/p>\n\n\n\n\n\n\n
Alert level<\/strong><\/td>\nDeadline<\/strong><\/td>\nContents<\/strong><\/td>\n<\/tr>\n
Initial report<\/strong><\/td>\nwithin 4 hours of being classified as serious, and no later than 24 hours after becoming aware of it<\/td>\nBasic information about the incident and the initial assessment<\/td>\n<\/tr>\n
Interim report<\/strong><\/td>\nwithin 72 hours of the initial report<\/td>\nUpdated status, implications, actions taken<\/td>\n<\/tr>\n
Completion notice<\/strong><\/td>\nno later than one month after the last interim report<\/td>\nRoot cause analysis, overall impact, permanent corrective measures<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

These deadlines have organisational implications that extend beyond IT. Four hours is not enough time to clarify responsibilities only after an incident occurs. Roles subject to reporting obligations, decision-making processes, templates and access to reporting portals must be prepared and practised \u2013 and they must function even if the incident affects the organisation\u2019s own IT infrastructure. To complicate matters further, additional reporting obligations may apply in parallel, such as those under Article 33 of the GDPR in the event of a personal data breach.<\/p>\n

Furthermore, the DORA regulation provides for significant cyber threats to be reported on a voluntary basis and obliges financial firms to inform affected customers if a serious incident impacts their financial interests.<\/p>\n

What tests of digital operational resilience does DORA require?<\/h2>\n

DORA requires two levels of testing. All financial firms covered by the regulation must maintain a programme for testing digital operational resilience and must test critical ICT systems at least once a year. According to Article 25, the scope includes, amongst other things, vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security checks, compatibility, performance and end-to-end tests, as well as penetration tests.<\/p>\n

The second stage consists of threat-led penetration tests, referred to in the text of the regulation as Threat-Led Penetration Testing (TLPT). These must be carried out at least every three years and apply only to those firms designated for this purpose by the competent authorities on the basis of risk and systemic importance criteria. TLPT is based on the European TIBER-EU framework: production systems are tested under realistic attack scenarios derived from current threat intelligence, with the institute\u2019s operational teams generally not being informed in advance.<\/p>\n

The methodological difference from traditional penetration tests is significant. A conventional test checks whether a vulnerability exists. TLPT checks whether the organisation detects, correctly assesses and manages a realistic attack \u2013 in other words, it tests detection and response capabilities, not just technical hardening. Critical third-party ICT service providers must participate in such tests if they operate systems that fall within the scope of the test.<\/p>\n

What does the DORA regulation require for managing third-party ICT risk?<\/h2>\n

DORA requires financial firms to fully document their relationships with ICT service providers, to secure these relationships through contracts, and to remain capable of operating in the event of a provider failure. This is based on a register of all contractual agreements relating to the use of ICT services, which must be kept up to date at all times and submitted to the supervisory authority. The register distinguishes between services that support critical or important functions and all other services.<\/p>\n

Article 30 sets out the minimum contractual requirements. For all ICT contracts, these include, amongst other things, a full description of services, details of the locations where data is processed and stored, provisions on the availability, integrity and confidentiality of data, support services in the event of ICT incidents, as well as termination rights and notice periods. In the case of critical or important functions, further requirements apply: quantitative performance targets, unrestricted rights of access, inspection and audit, conditions for subcontracting, participation in security training and tests, and documented exit strategies that enable a change of provider without interrupting business operations.<\/p>\n

A new development is the European oversight of the providers themselves. The European supervisory authorities designate particularly significant providers as critical third-party ICT service providers and subject them to a supervisory framework led by a lead supervisory authority. This authority may request information, conduct investigations and on-site inspections, and issue recommendations; in the event of persistent non-compliance, penalty payments of up to one per cent of average global daily turnover may be imposed, which can be levied daily over a period of up to six months.<\/p>\n

Experience shows that the biggest hurdle lies not in the register, but in the exit strategy. Concentration risks associated with a small number of large cloud and core banking providers cannot be resolved through contractual clauses, but only through architectural decisions \u2013 data portability, documented interfaces and tested migration paths.<\/p>\n

What requirements does DORA set for crisis communication?<\/h2>\n

DORA treats communication as a regulatory requirement in its own right, rather than as a secondary aspect of incident management. Article 14 requires financial firms to draw up crisis communication plans that enable the responsible disclosure of serious ICT incidents or significant vulnerabilities to customers, counterparties and the public. In addition, at least one person must be appointed to implement the communication strategy and act as the point of contact for the public and the media.<\/p>\n

Furthermore, the response and recovery plans required under Article 11 stipulate communication procedures for internal staff, external stakeholders and the supervisory authority. This creates a structure with three target groups that must be addressed simultaneously, each with different content, in the event of an incident: the internal crisis management team, the supervisory authorities within the reporting deadlines, and the affected customers.<\/p>\n

The practical difficulty lies in the fact that this communication depends on precisely the infrastructure affected by the incident. If a compromised network is isolated or the email system is shut down as a precautionary measure, the directory service, email and collaboration platform are no longer available as coordination channels \u2013 and with them the contact details and escalation lists stored there. Organisations therefore maintain pre-approved communication channels that function independently of the potentially affected ICT infrastructure, provide audit-proof documentation and are included in the tests in accordance with Article 24 et seq. Experience shows that, in the absence of such a channel, those involved resort to private consumer messaging apps \u2013 with consequences for confidentiality, GDPR compliance<\/a> and the ability to provide evidence to the supervisory authority.<\/p>\n

Teamwire demonstrates how a channel for alerting, crisis management and reporting processes \u2013 independent of the regular IT system \u2013 can be set up, either in a demo<\/a> or via a free trial<\/a>.<\/em><\/p>\n

What penalties apply for breaches of DORA?<\/h2>\n

DORA leaves the imposition of sanctions on financial firms to the Member States, but requires measures that are effective, proportionate and dissuasive. Under Article 50, the range of measures available to the competent authorities extends from orders to remedy a breach, through requests to cease certain practices, to public notices and financial penalties. In Germany, responsibility lies with BaFin.<\/p>\n

By contrast, daily penalty payments imposed on critical third-party ICT service providers that fail to follow the recommendations of the lead supervisory authority are regulated separately. These may be imposed on a daily basis for up to six months and amount to up to one per cent of the provider\u2019s average global daily turnover.<\/p>\n

In practice, however, the regulatory implications are more relevant than the fine framework. As DORA requires evidence of tests, registers and reporting processes, implementation becomes an integral part of ongoing supervision and audits \u2013 findings therefore have a direct impact on the relationship with the supervisory authority, regardless of whether a sanction is imposed.<\/p>\n

What are some common mistakes made when implementing the DORA regulation?<\/h2>\n

The most common mistake in implementing the DORA regulation is treating it as an IT project with an end date. DORA requires a continuous cycle comprising analysis, testing, reporting and verification; a framework set up once becomes obsolete with every contract amendment and every new application. Further weaknesses arising from implementation practice:<\/p>\n

    \n
  • An incomplete information register, because business units procure ICT services directly and these have never been recorded centrally<\/li>\n
  • Legacy contracts with service providers that do not include the minimum requirements of Article 30 and whose renegotiation takes months<\/li>\n
  • Exit strategies that exist on paper but have never been assessed for technical feasibility<\/li>\n
  • Reporting processes without designated roles and deputisation arrangements, which fail to meet the four-hour deadline in the event of an incident<\/li>\n
  • A narrow focus on the cloud, whilst core banking systems, data centre service providers and specialised business applications are overlooked<\/li>\n
  • Crisis communication that relies entirely on email and collaboration platforms and is itself affected in the event of an ICT incident<\/li>\n
  • A lack of integration with existing management systems, meaning that ISMS, BCM and the DORA regulation frameworks document the same issues three times over<\/li>\n<\/ul>\n

    Summary: Key points on the DORA regulation<\/h2>\n
      \n
    • DORA (Digital Operational Resilience Act) is Regulation (EU) 2022\/2554 on digital operational resilience in the financial sector and has been directly applicable in all EU Member States since 17 January 2025.<\/li>\n
    • The DORA regulation covers around 20 categories of financial firms \u2013 ranging from credit institutions to insurance companies and asset management firms, right through to crypto service providers \u2013 as well as their third-party ICT service providers.<\/li>\n
    • The Regulation is based on five pillars: ICT risk management, incident reporting, resilience testing, management of third-party ICT risk, and voluntary information exchange.<\/li>\n
    • Under Article 5, the management body bears ultimate responsibility for ICT risk management and must ensure that its members receive regular training on ICT risks.<\/li>\n
    • Serious ICT incidents must be reported in three stages: an initial report within four hours of classification, an interim report within 72 hours, and a final report within one month.<\/li>\n
    • Threat-led penetration tests (TLPTs) in accordance with the TIBER-EU framework must be carried out at least every three years, but apply only to organisations designated by the authorities.<\/li>\n
    • For ICT service providers, DORA requires an information register, minimum contractual provisions in accordance with Article 30, and documented, technically robust exit strategies.<\/li>\n
    • Critical third-party ICT service providers are subject to a European supervisory framework with penalty payments of up to one per cent of average global daily turnover.<\/li>\n
    • Compared with NIS-2, DORA is the more specific regulation; national IT requirements set by supervisory authorities, such as BAIT and VAIT, have largely been superseded for covered organisations.<\/li>\n
    • Crisis communication plans are mandatory under Article 14, including the appointment of a designated responsible person and regulated communication channels with staff, supervisory authorities and customers.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

      DORA (Digital Operational Resilience Act) is Regulation (EU) 2022\/2554 on digital operational resilience in the financial sector. DORA requires financial firms and their ICT service providers to systematically manage information and communication technology risks, report serious incidents within specified timeframes, regularly test their resilience and mitigate third-party risks through contractual arrangements. The Regulation has been […]<\/p>\n","protected":false},"featured_media":20699,"template":"","class_list":["post-20698","lexicon","type-lexicon","status-publish","has-post-thumbnail","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/lexicon\/20698","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/lexicon"}],"about":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/types\/lexicon"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/media\/20699"}],"wp:attachment":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/media?parent=20698"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}