DORA (EU Regulation 2022/2554): a digital operational resilience guide for Brazilian companies that operate in or serve the EU

What DORA is and why it reaches companies outside the EU

The Digital Operational Resilience Act is Regulation (EU) 2022/2554 of the European Parliament and of the Council, complemented by Directive (EU) 2022/2556. As a regulation rather than a directive, it is directly applicable in all Member States, without depending on a national transposition law. It was published in December 2022, with an application date set for January 17, 2025. Its stated goal is to consolidate and harmonize, under a single regime, the digital operational resilience requirements that were previously scattered across European sector-specific rules.

DORA's logic starts from a simple observation: the stability of the European financial system increasingly depends on the continuity of ICT systems, many of them operated by third parties. Instead of treating information security as an appendix to governance, the regulation elevates digital operational resilience to a prudential requirement, with board-level obligations, metrics, testing and reporting. Resilience, in DORA's vocabulary, is the ability to prevent, withstand, contain and recover from ICT-related incidents, preserving the integrity and continuity of critical functions.

The extraterritorial reach does not stem from an explicit clause like that of the GDPR, but from the third-party risk architecture. European financial entities become legally responsible for ensuring that their ICT service providers, wherever they are, meet minimum contractual requirements, allow auditing and access, and support testing. For a Brazilian fintech, VASP or SaaS that sells to a bank, an insurer or a regulated CASP in the EU, this means that DORA arrives through contract, even without the company being physically or legally in the Union.

Who DORA applies to: financial entities and ICT providers

Article 2 of the regulation lists the universe of addressees. There are around twenty categories of financial entities, among them credit institutions, payment and electronic money institutions, investment firms, insurers and reinsurers, fund managers, credit rating agencies, market infrastructures and, by virtue of the MiCA Regulation (EU 2023/1114), crypto-asset service providers (CASPs) and issuers of asset-referenced tokens. Brazilian crypto companies that intend to act as an authorized CASP in the EU fall directly within this perimeter.

Alongside financial entities, DORA introduces its own category: ICT third-party service providers. The definition is broad and covers digital and data services provided on an ongoing basis, including cloud computing, software, data processing, data centers and managed security services. These providers do not receive direct obligations in the general case, but they become subject to the third-party risk management requirements imposed on financial entities, and must accept specific contractual clauses.

There is, however, a direct oversight regime for providers classified as critical (Critical ICT Third-Party Providers, CTPPs). The designation is made by the European Supervisory Authorities (ESAs: EBA, EIOPA and ESMA) based on criteria such as the number of financial entities served, substitutability and systemic importance. Once designated as critical, the provider answers to a Lead Overseer, who may conduct investigations, on-site inspections and issue recommendations, with the possibility of applying periodic penalties until it comes into compliance.

For most Brazilian ICT companies, the realistic scenario is not designation as a CTPP, but the indirect obligation: the European client will pass on, in the contract, the duties of subcontracting, auditing, data localization, exit plans and cooperation in testing. Refusing these clauses is, in practice, equivalent to being shut out of the European financial market.

The five pillars of DORA

The first pillar is ICT risk management (Chapter II, Articles 5 to 16). It requires a documented framework, under the ultimate responsibility of the management body, covering the identification of assets and critical functions, protection and prevention, detection, response and recovery, backup and restoration policies, and post-incident learning. The board cannot delegate the responsibility: it must approve the strategy, allocate the budget and keep its knowledge of ICT risks up to date.

The second pillar deals with the management, classification and reporting of incidents (Chapter III). Entities must have a process to detect, record and classify ICT-related incidents according to harmonized criteria (impact, duration, geographic spread, data loss, criticality of services). Major incidents must be reported to the competent authority within windows defined by the technical standards, with an initial notification, an intermediate report and a final report. There is also voluntary reporting of significant cyber threats.

The third pillar is digital operational resilience testing (Chapter IV). All entities must maintain a testing program proportionate to risk, with vulnerability assessments, code analyses, penetration tests and continuity exercises. Significant entities, identified by the authorities, must carry out Threat-Led Penetration Testing (TLPT) at least every three years, following the European TIBER-EU methodology, with tests based on real threat intelligence. TLPT also covers the ICT providers that support critical functions.

The fourth pillar covers ICT third-party risk management (Chapter V), with Article 28 establishing general principles and Article 30 setting the minimum contractual content: description of the services, location of data processing, access and audit rights, security requirements, subcontracting conditions, exit strategies and cooperation with authorities. The fifth pillar, the lightest, encourages the voluntary sharing of information and intelligence on cyber threats among financial entities, within trust arrangements and in compliance with data protection.

Deadlines, technical standards and the regulatory chain

DORA's application date is January 17, 2025, in accordance with Article 64. From that milestone, the obligations are enforceable and the competent national authorities begin to supervise compliance. There is no additional adaptation period provided for in the text; entities and providers should have had the controls implemented by that date.

The regulation is a text of principles, detailed by binding technical standards drawn up by the ESAs: regulatory technical standards (RTS) and implementing technical standards (ITS), adopted by the European Commission as delegated and implementing acts. These standards specify, for example, the content of the ICT risk management policy, the incident classification criteria, the reporting templates, the content of the Register of Information and the TLPT methodology. Keeping up with this layer is essential, because it is where the concrete and auditable requirements are found.

A relevant operational element is the Register of Information: each financial entity must maintain and report to the authorities a structured record of all contractual arrangements with ICT providers, distinguishing those that support critical or important functions. This register feeds the designation of critical providers and systemic supervision. In practice, a Brazilian supplier will be inventoried in the European client's register, with an assigned criticality level.

How a Brazilian company positions itself: regulated entity, provider or subcontractor

Before achieving compliance, the company needs to understand which role it occupies. If it is a fintech or a VASP seeking authorization to operate as a financial entity in the EU, it will be a direct addressee of DORA and will be accountable for all five pillars in full. If it is a SaaS, cloud provider, managed security or processing company that only sells to European financial entities, it will be an ICT third-party provider, reached by the contractual and audit obligations that the client passes on to it.

The most sensitive point is the critical or important function. If your service underpins a function that, in the event of failure, would compromise the continuity or compliance of the financial entity, the contract will include the complete set of Article 30 requirements, and the client is likely to require participation in TLPT and continuity tests. Non-critical services face a reduced contractual set, but one that is still formalized. Identifying this classification early avoids commercial surprises.

For most Brazilian providers, the effective strategy is to get ahead of it: structure the security posture and documentation so that the DORA clauses already have operational backing. This turns compliance from a commercial obstacle into a competitive differentiator, shortening the due diligence and onboarding cycle with European clients. It is precisely at this point that Decripte's Regulatory Security approach applies: translating regulatory requirements into verifiable controls and auditable evidence.

Where Decripte works on DORA compliance

Decripte supports Brazilian companies across the four most demanding pillars of DORA with direct technical services. In ICT risk management, we conduct the identification of assets and critical functions, risk assessment and the design of controls aligned with Chapter II and the applicable RTS, with the documentation the board needs to assume the responsibility set out in the regulation.

In resilience testing, we perform vulnerability assessments and conventional pentesting and, for cases subject to Threat-Led Penetration Testing, we conduct exercises based on threat intelligence aligned with the logic of TIBER-EU, in the position of a testing provider that the European financial entity can contract. In incident response, we help build the detection, classification and reporting process required by Chapter III, with playbooks compatible with the notification windows and the ESAs' report templates.

In third-party risk management, we work on the side of the Brazilian provider: we review the alignment of the security posture with the clauses of Article 30, prepare the company for the client's audits and access rights, and organize the documentation that feeds the European contracting party's Register of Information. The goal is for your company to arrive at the negotiating table with compliance ready, rather than reactive.

How to comply

1. 1

   Determine your role and scope

   Define whether the company is a financial entity subject to DORA, an ICT third-party provider or a subcontractor of a provider. Map which European clients are financial entities and which of your services underpin critical or important functions for them. This framing determines the depth of the entire compliance effort.

2. 2

   Map assets, critical functions and dependencies

   Build an inventory of ICT assets, data flows, subcontractors and dependencies that support the services sold to European clients. Identify single points of failure and the location of data processing and storage, information the client will need for its Register of Information.

3. 3

   Structure the ICT risk management framework

   Implement policies and controls covering identification, protection, detection, response, recovery and backup, with the approval and oversight of the management body. Align with Chapter II of DORA and the RTS, and produce auditable evidence: versioned policies, risk registers and metrics.

4. 4

   Build the incident management and reporting process

   Define the detection, recording and classification of incidents according to the harmonized criteria (impact, duration, spread, data loss). Create playbooks that enable you to support the European client with the initial, intermediate and final notifications, within the windows of the technical standards, and establish contractually agreed communication channels.

5. 5

   Prepare for testing and TLPT

   Establish a continuous vulnerability assessment and pentesting program. For services that underpin critical functions, prepare the company to participate in Threat-Led Penetration Testing conducted under the TIBER-EU methodology, ensuring the environments, scope and clauses that authorize the test without violating other commitments.

6. 6

   Adjust contracts to Article 30

   Review contracts with European financial clients to accommodate access and audit rights, security requirements, subcontracting rules, data localization, exit strategies and cooperation with authorities. Negotiate viable terms before the client imposes a unilateral model.

7. 7

   Consolidate governance and continuous evidence

   Centralize the compliance documentation, keep the register of subcontractors up to date and establish periodic and post-incident reviews. Treat compliance as a commercial differentiator: a ready package of evidence shortens the European client's due diligence and supports renewals.

Frequently asked questions