All posts

DORA: what the financial sector needs to know and how Zero Trust Segmentation helps

DORA: what the financial sector needs to know and how Zero Trust Segmentation helps (KAEMI)

DORA has been binding for the European financial sector since January 17, 2025. A year and a half later, the deadline has become everyday reality: supervisory authorities are requesting information registers, major IT incidents have to be reported within fixed deadlines, and the first threat-led penetration tests are underway. Anyone who has treated the regulation as a pure paperwork exercise is realizing by now: DORA demands technical substance.

This post explains what DORA regulates, who the regulation applies to, what lies behind the five pillars, and why Zero Trust Segmentation is one of the most effective tools for putting the requirements into practice.

What is DORA?

DORA stands for Digital Operational Resilience Act, formally Regulation (EU) 2022/2554 . It entered into force on January 16, 2023, and has applied directly in all EU member states since January 17, 2025. As a regulation, it needs no national transposition: the requirements apply directly, and in Germany, BaFin supervises compliance.

The goal is digital operational resilience: financial entities are not just supposed to fend off severe IT disruptions and cyberattacks; their business operations are supposed to withstand them. DORA assumes that incidents will happen. The regulation therefore asks less whether an attack is prevented, and more whether critical functions keep running in the meantime and how quickly normal operations return.

Who does DORA apply to?

The scope is broad: around 20 categories of financial entities fall under the regulation, including banks, insurers, payment and e-money institutions, investment firms, trading venues, fund managers, and crypto-asset service providers. Companies outside the EU are affected as well, as soon as they operate in EU markets.

What is new above all is the second circle: ICT third-party service providers. Anyone working for regulated financial entities as an IT service provider, cloud provider, or software house will feel DORA through their customers' contractual requirements and audit obligations. ICT third-party providers classified as critical are even placed under direct supervision by the European authorities, with periodic penalty payments of up to one percent of average worldwide daily turnover for violations.

The five pillars of DORA

1. ICT risk management

Financial entities need a documented framework that continuously identifies, assesses, and treats ICT risks. This includes resilient systems, detection of unusual activity, business continuity plans for critical functions, and a process for learning from their own incidents as well as those of others. Important: responsibility explicitly sits with the management body. The board cannot delegate ICT risk to the IT department.

The foundation of everything is visibility. If you don't know which systems exist, how they communicate, and which dependencies exist between applications, you can neither assess nor treat risks. This is exactly the inventory DORA explicitly demands.

2. ICT incident handling and reporting

Incidents have to be classified according to uniform criteria, and major incidents reported to the supervisor. The deadlines are tight: the initial notification is due within four hours of classification, and no later than 24 hours after becoming aware of the incident. An intermediate report follows after 72 hours, the final report within one month. Deadlines like these can only be met if detection, assessment, and reporting paths are in place beforehand.

3. Digital resilience testing

The risk framework has to be tested regularly, from vulnerability scans to scenario-based exercises. For significant institutions, a threat-led penetration test (TLPT) is added at least every three years, modeled on the TIBER-EU framework: a red team simulates real attackers against the production environment, including its critical functions.

4. ICT third-party risk management

Financial entities have to maintain a complete register of information on all ICT service providers, enforce minimum contractual clauses, and keep exit strategies ready for critical providers. The logic behind it: you can outsource the service, but not the responsibility. Concentration risks, for instance when many institutions depend on the same cloud provider, get separate attention from the supervisor.

5. Information sharing

DORA encourages financial entities to share threat intelligence within trusted circles. This pillar is voluntary but serves the same goal: the sector as a whole should detect attacks earlier and respond faster.

The core of DORA: keeping operations running instead of perimeter thinking

Pulling the five pillars together, one message remains: the supervisor expects financial entities to survive a successful attack. That is a break with the classic mindset that pours all its energy into defense at the perimeter. Resilience means limiting the spread of an attack, shielding critical functions, and working through the incident in a controlled way while the core business keeps running.

This is exactly where Zero Trust Segmentation becomes relevant. It does not prevent initial access, but it determines whether a compromised system turns into a local incident or a company-wide outage.

What Zero Trust Segmentation contributes to DORA in concrete terms

  • Visibility and mapping (pillar 1): A real-time map of all communication relationships between applications, workloads, and devices delivers exactly the inventory that ICT risk management demands. Unnecessary connections and risky dependencies become visible before an attacker finds them.
  • Containment as an architectural principle: Least-privilege rules between workloads limit the lateral spread of attacks and ransomware. A compromised system stays a compromised system instead of becoming a wildfire.
  • Ringfencing critical functions: Core banking applications, payment infrastructure, and backup environments can be shielded in a targeted way. Protected backups in particular are what makes recovery possible at all when it counts.
  • Faster detection: The segmentation's traffic data flows into the SIEM and makes unusual communication visible, a direct contribution to the anomaly detection in pillar 1 and the incident assessment in pillar 2.
  • Response during an incident: Affected systems or entire zones can be isolated in a few steps while the investigation is running. That shortens the duration of an incident and backs the reporting deadlines with solid facts.
  • Auditability: Documented policies and communication maps give auditors concrete evidence instead of declarations of intent. That helps with DORA audits as well as with ISO 27001, PCI DSS, or SWIFT requirements.

What this looks like in practice is shown in our case study Microsegmentation under DORA at a German insurance company : servers, terminal servers and Kubernetes in one segmentation model, from the first dependency map to the handover to the internal team.

Why banks and financial services providers in particular benefit

Illumio has compiled eight reasons why the financial sector benefits especially from Zero Trust Segmentation. Several of them hit the DORA context at its core:

  • Systemically important core systems: Trading, payment, and core banking environments are attractive targets with enormous damage potential. According to analyses by IBM X-Force, the banking sector was for years the most attacked target for cybercriminals.
  • Legacy and unpatched systems: There is often a long window between vulnerability and patch, and some legacy systems no longer receive updates at all. Segmentation drastically reduces the reachability of such systems and buys time.
  • Cloud migration without losing control: Policies are tied to the workload instead of the infrastructure. When an application moves to the cloud, the protection moves with it, a point that regularly comes up in DORA reviews of outsourcing arrangements.
  • Automated ransomware response: The fastest containment is cutting the communication paths. Known propagation ports such as RDP and SMB can be closed in advance and blocked organization-wide in an emergency.
  • Measurable benefit: Illumio puts the downtime costs avoided through Zero Trust Segmentation at just over 20 million US dollars per year for a typical large enterprise. For the board presentation, both things count in the end: less risk and verifiable numbers.

Practical steps toward DORA compliance

Across the projects of recent years, one sequence has proven itself:

  • 1. Identify critical functions: Which processes have to keep running in an emergency, and which systems support them? This list drives all further steps.
  • 2. Map communication: Without a real-time view of data flows, risk analysis and registers remain theory. The mapping regularly uncovers connections that no one can explain anymore.
  • 3. Capture third parties: Build the register of information, check contracts against the DORA minimum clauses, document exit scenarios for critical providers.
  • 4. Roll out segmentation based on risk: First protect the critical functions with ringfencing and close risky ports, then segment the environment further step by step, tested in monitoring mode before rules are enforced.
  • 5. Test and rehearse: Don't treat resilience testing and TLPT as a box-ticking exercise. If you know your own communication map, you can build test scenarios deliberately and translate findings directly into policies.

Implementing DORA with KAEMI

As a managed security service provider and Illumio EMEA Partner of the Year, we at KAEMI guide financial entities and their service providers along exactly this path: Zero Trust microsegmentation from visibility through policy design to the ongoing managed service. For the testing requirements in pillar 3, our assessments and penetration tests provide a clear picture of where you stand, from which a prioritized action plan emerges.

If you want to know where your environment stands on DORA today, talk to us . The first step is an honest inventory of the critical functions and their communication.

This post is based on two Illumio articles on DORA and on Zero Trust Segmentation in the financial sector, as well as the text of Regulation (EU) 2022/2554.

Want to stop lateral movement before an incident spreads?

KAEMI designs, implements and manages Zero Trust segmentation down to the workload — from the dependency map to the managed service.