What DORA Means for EU Banks in 2026

The Digital Operational Resilience Act (DORA) became fully applicable across the European Union on January 17, 2025. For EU financial institutions — banks, insurance companies, investment firms, crypto-asset service providers, and their critical ICT third-party providers — DORA is no longer a future compliance concern. It is live, it is enforceable, and the first supervisory examinations are underway in 2026. Yet many security teams are still unclear on exactly what DORA requires of them technically and operationally.

This guide breaks down DORA's five pillars into concrete, actionable requirements for security and risk teams. It is not legal advice — it is a practical security engineering perspective on what DORA compliance actually looks like in production.

Pillar 1 — ICT Risk Management (Articles 5–16)

DORA requires financial entities to implement a comprehensive ICT risk management framework with a clear governance structure approved at board level. This is not optional: Article 5 explicitly makes the management body accountable for ICT risk. Security teams need to produce and maintain a formal ICT risk register, define risk tolerance levels in writing, and document their risk treatment decisions.

The framework must cover identification of all ICT assets, their classification by criticality, and continuous monitoring of ICT-related threats and vulnerabilities. In practice this means your asset inventory needs to be current, your vulnerability management programme needs documented SLAs for remediation by severity, and your threat intelligence feeds need to demonstrably inform your risk decisions. Periodic gap assessments against the DORA ICT risk framework are a key audit artefact supervisors will expect to see.

Pillar 2 — ICT-Related Incident Management (Articles 17–23)

DORA establishes a mandatory incident classification and reporting regime. Major ICT incidents must be reported to the relevant national competent authority — the ECB, BaFin, ACPR, or other national regulator — within four hours of classification, with an intermediate report within 72 hours and a final report within one month. Financial entities must also notify affected clients without undue delay.

The incident management implication is significant. You need a formally documented incident response plan, a defined classification methodology (DORA's RTS on incident classification provides the criteria), and tested communication protocols with your regulator. Most EU banks we work with are investing in dedicated incident response tooling and regulatory notification workflows. Those without these capabilities face real regulatory exposure if a major incident occurs.

Pillar 3 — Digital Operational Resilience Testing (Articles 24–27)

This is the pillar that most directly affects penetration testing and red team programmes. DORA Article 24 requires all financial entities to run a digital operational resilience testing programme, which must include both basic testing (vulnerability assessments, network security assessments) and, for significant entities, Threat-Led Penetration Testing (TLPT) under the TIBER-EU framework at least every three years.

TLPT under DORA is substantially more demanding than a standard penetration test. It requires a Threat Intelligence provider to produce a targeted threat landscape report, a Red Team provider to execute adversary simulation against live production systems — not a test environment — and a Blue Team to observe and document detection capabilities. Results must be shared with the NCA. For most significant EU financial institutions, the cost of a single TIBER-EU engagement ranges from €200,000 to €500,000+ depending on scope.

Continuous autonomous adversary simulation provides an operationally practical complement to periodic TIBER-EU exercises. Rather than waiting three years between expensive point-in-time tests, continuous simulation identifies exploitable attack paths on every scan cycle, enabling security teams to demonstrate ongoing resilience and arrive at TLPT exercises with a far more mature security posture.

Pillar 4 — ICT Third-Party Risk Management (Articles 28–44)

DORA introduces stringent requirements for managing ICT third-party providers — particularly Critical ICT Third-Party Providers (CTPPs) designated by the ESAs. Financial entities must conduct thorough due diligence on all ICT providers before contracting, maintain a detailed register of all ICT third-party arrangements, and ensure contractual provisions that guarantee audit rights, data access, and termination support.

From a security operations perspective, this means your vendor risk management programme needs to produce documented, risk-based assessments of every material ICT provider. Concentration risk — where a single provider underpins multiple critical functions — must be identified and managed explicitly.

Pillar 5 — Information and Intelligence Sharing (Article 45)

DORA encourages participation in threat intelligence sharing arrangements. Financial entities that participate in trusted communities for sharing information on cyber threats, tactics, and indicators of compromise can use this participation as a supporting factor in their ICT risk management programme documentation.

Practical Checklist for Security Teams in 2026