DORA at the eighteen-month mark
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has been formally applicable since 17 January 2025. Eighteen months in, supervisory authorities — ECB, EBA, ESMA, EIOPA, and national competent authorities — have moved decisively from awareness to enforcement. The 2026 supervisory cycle is asking specific, evidence-based questions.
If you are a CISO in a financial entity covered by DORA — banks, investment firms, insurers, fund managers, payment institutions, e-money institutions, central counterparties, trading venues, credit rating agencies, crowdfunding service providers, or critical ICT third-party providers — your audit committee should be asking you for evidence against DORA's five pillars by Q4 2026 at the latest.
This article walks through each pillar with the practical question: what does an inspector actually want to see?
Pillar 1 — ICT risk management
Articles 5–14. The foundation. DORA requires a documented, board-approved ICT risk management framework covering identification, protection, detection, response, recovery, learning, and communication. In practice this is largely covered by ISO 27001 and NIST CSF programs, with three DORA-specific additions:
- Explicit board accountability. The management body must approve the framework, review it at least annually, and oversee its implementation. Board-meeting minutes need to show it.
- Digital operational resilience strategy. A specific document — distinct from the security policy — that articulates how the entity intends to remain operationally resilient. Many entities discover they have all the pieces (policies, BCP, IR plan) but no overarching strategy document.
- Information assets register and classification. An inventory of information and ICT assets with classification by criticality. Article 8 makes this explicit and supervisable.
What an inspector asks for: the framework document, the strategy, the assets register with last-updated date, and three sets of board minutes showing oversight discussions.
Pillar 2 — ICT-related incident management and reporting
Articles 15–23. This is where DORA imposes the tightest operational pressure. Major ICT-related incidents must be:
- Classified according to the criteria in the regulatory technical standards (transactions affected, geographic spread, duration, economic impact, reputational impact, criticality of services).
- Reported to the competent authority through a three-stage notification: initial within 4 hours of classification (and not later than 24 hours after detection), intermediate, and final.
- Followed by a root-cause analysis within one month.
Two practical realities:
- The classification thresholds are surprisingly low. A handful of affected payment transactions across multiple member states can constitute a "major" incident. Most institutions discover, when they actually run through the criteria with last year's incidents, that several were technically reportable.
- The 4-hour clock starts when classification completes. Build the classification step into your IR runbook so it happens quickly and is documented.
Voluntary notification of significant cyber threats is also encouraged. Several entities have adopted a policy of voluntary disclosure for anything that crosses an internal threshold below the mandatory line, on the theory that it builds supervisory goodwill.
Pillar 3 — Digital operational resilience testing
Articles 24–27. DORA requires entities to test their resilience, not just document it. The required testing includes:
- A comprehensive testing programme at least annually for normal operations.
- Threat-Led Penetration Testing (TLPT) at least every three years for entities classified as significant. TLPT must follow the TIBER-EU framework or an equivalent.
- Testing must be conducted by independent parties — internal or external — with no conflict of interest.
TLPT is the part most institutions underestimate. Unlike a standard penetration test, TLPT involves real-world threat-actor TTPs against production systems with limited internal awareness. Coordinating it requires a dedicated White Team, contractual relationships with red-team providers, and supervisory engagement before the engagement begins. Budget €300K–€800K and 6–9 months elapsed time per cycle.
Pillar 4 — ICT third-party risk
Articles 28–44. This is the most operationally consequential pillar for most institutions. DORA imposes detailed requirements on the management of ICT third-party providers:
- Comprehensive register of all contractual arrangements with ICT third-party providers, distinguishing those supporting critical or important functions.
- Pre-contractual due diligence with documented assessments.
- Standardized contractual provisions covering specified items: service level agreements, data location, security requirements, incident notification, audit rights, exit strategies.
- Concentration risk monitoring — entities cannot become overly dependent on a single ICT third party.
- Critical ICT Third-Party Providers (CTPPs) are designated by the European Supervisory Authorities and become directly supervised entities.
The register requirement alone is non-trivial. Most institutions have an inventory in their procurement system but not in the format DORA prescribes. Article 28(3) lists nineteen specific data fields per arrangement.
The contractual requirements ripple through legal, procurement, and security. Renegotiating existing contracts to add the DORA-mandated clauses is a multi-quarter project for most institutions, and one that Q4 2026 inspections are now actively reviewing.
Pillar 5 — Information and intelligence sharing
Article 45. The least prescriptive pillar but increasingly emphasized. DORA explicitly permits financial entities to exchange cyber threat information among themselves, including indicators of compromise, tactics, techniques, and procedures, within trusted communities. The permission is significant because it overrides certain confidentiality concerns that previously discouraged sharing.
What supervisors look for here is that you have considered participation in an information-sharing arrangement and either joined one (FS-ISAC, national ISACs, sector-specific groups) or documented why not. The expectation is rising that "we do not share threat intelligence" is no longer an acceptable answer for a significant institution.
The interplay with NIS2
Many financial entities are simultaneously in scope of NIS2 (essential entity, finance sector). DORA is lex specialis — it takes precedence where it covers the same ground. In practice this means:
- For ICT risk management and incident reporting, DORA applies and NIS2 yields.
- For aspects DORA does not cover (general cybersecurity hygiene, training, etc.), NIS2 still applies.
- Reporting incidents to a single authority under DORA usually satisfies both — but verify with your national competent authority because procedures differ.
What an inspector will ask in 2026
Based on early DORA examinations, the supervisory checklist looks roughly like this:
- ICT risk management framework document, board-approved, reviewed within the last 12 months.
- Digital operational resilience strategy.
- Information assets register, classified, last updated within the last 6 months.
- Major incident classification procedure.
- Last 12 months of incident notifications.
- Annual testing programme document and most recent test reports.
- TLPT schedule and last completed engagement (if applicable).
- Register of ICT third-party arrangements, in DORA Article 28(3) format.
- Three sample third-party contracts showing required clauses.
- Concentration risk analysis.
- Threat-intelligence sharing arrangements.
Coming in with that file ready saves enormous remediation work.
How a GRC platform helps
Almost every DORA evidence requirement is something a purpose-built GRC platform handles natively: registers, control-evidence linkage, incident logs, vendor inventories with risk tiers, audit trails, and board-ready reports. The institutions struggling most with DORA are those treating it as a series of one-off compliance projects in spreadsheets rather than as ongoing operations of a platform that produces the evidence as a side effect.
Closing thought
DORA is the most prescriptive operational-resilience regulation any major jurisdiction has produced. It is also one of the better-designed: the five pillars line up with how mature security and resilience programs actually operate. The institutions that will fare worst in the 2026 supervisory cycle are those that treated DORA as a documentation exercise rather than as a re-baselining of how the function operates day to day.