DORA after 15 months: Security lessons from first 2026 audits

7 min read

Since 17 January 2025, DORA has been binding on financial institutions across the EU. After fifteen months of routine operation, the first audit cycles are complete. The lessons for security teams at banks, insurers and asset managers are both concrete and uncomfortable. The four-hour incident-reporting window, the new clauses in third-party contracts and the TLPT testing regime are pushing operations to the limit – limits that can no longer be met with standard processes.

RelatedNIS2 Reporting Channels: Shaping the First Incident Hour  /  Adaptive MFA in Entra, Okta & Duo: Rolling Out NIS2

What the first audits in 2026 have really revealed

The EU supervisors (BaFin, EBA, ESMA, EIOPA and the ECB for the largest institutions) conducted their first audit rounds in 2025 and the first quarter of 2026. The substantive questions were predictable; the answers from the institutions rarely were. The most frequent findings from these discussions in German banks’ compliance departments can be grouped into three key themes: incident classification within the tight deadline, contractual gaps with third-party providers, and under-dimensioned testing capacities for TLPT. None of these issues is new, but each now falls under DORA’s binding framework, which has shattered the former internal tolerances. On top of that, supervisors are sharpening their interpretations as more cases come in. What passed as pilot rule interpretation in 2025 is being applied more strictly in 2026.

The first hour after an incident is the decisive window. Regulation requires an initial report within four hours of classifying an ICT incident as major. The classification itself must be based on verifiable criteria. In practice, this means: if an alert arrives at 3 a.m. that might be a major incident, the SOC has just hours to decide whether the reporting threshold is met – while simultaneously preparing the report itself. Those without this process baked into their runbook automation are under immediate pressure. The early audits’ lesson is clear: institutions lacking unambiguous escalation chains and a defined classification matrix racked up more than one finding in this area during their first months.

Third-Party Registers and Exit Scenarios

The second major challenge lies in contracts with ICT third-party providers. DORA mandates explicit clauses on audit rights, exit strategies, service-level guarantees, security obligations, and incident reporting requirements. The reality: most cloud contracts, SaaS subscriptions, and outsourcing agreements from previous years do not fully meet these requirements. Renegotiation is not one-sided. Providers with market power (hyperscalers, leading SaaS platforms) have their own contract standards that do not always align with DORA requirements.

The lesson from the first fifteen months: institutions that proactively addressed the issue early received adjusted contract annexes from hyperscalers that cover a large portion of DORA requirements. Institutions that waited are now renegotiating under less favorable conditions, as providers know time is pressing. One often-overlooked detail: the register obligation is cumulative. Every contract update, every new subcontractor integration, and every criticality change must be promptly recorded in the DORA register. Without a workflow for continuous maintenance, the register becomes outdated within months.

The exit strategy is the area where many institutions have underestimated the demands. DORA does not merely require a termination clause; it demands a robust plan for how operations transition to an alternative within a reasonable timeframe in the event of provider failure or contract termination. For a critical SaaS core banking system, this is not a legal matter but a multi-year transition project. Supervisors have documented in early audits that a paper exit plan without realistic testing is insufficient.

In practice, this means: for the top five to ten critical third-party providers per institution, a detailed transition plan is required, including timelines, target architecture, data migration approach, and clear ownership. For cloud providers, this often involves a multi-cloud or multi-region setup; for SaaS core systems, a backup provider strategy or internal fallback. Documenting these plans is the first step; periodic updates and occasional simulation exercises are the second. Those who implement this rigorously will uncover weaknesses in their own processes that remain invisible during regular operations.

TLPT in practice: market, capacity and internal maturity

Threat-Led Penetration Testing under TIBER-EU represents the most stringent testing requirement under DORA and applies to institutions that fall under the TLPT thresholds (simplified: larger banks, payment service providers and market infrastructure operators). The test is conducted by accredited red-team providers, targeting the live production system without prior notice to the operational defence team. The challenge in 2026 is twofold.

First, the market of accredited providers is tight. In Germany and across Europe, there are double-digit – not triple-digit – numbers of accredited red-team providers for TLPT. Calendars are booked six to nine months in advance. Anyone aiming to test in the second half of 2026 needs to start negotiations now. Second, internal maturity is decisive. A TLPT only yields insights if the blue team, detection pipeline and incident-response processes are mature enough to process the simulation. Institutions that choose the TLPT timing too early waste valuable red-team capacity on findings already visible from an asset inventory.

The pragmatic sequence crystallising in 2026 looks like this: first, an internal maturity assessment; then targeted purple-team exercises over six months; finally, TLPT with an external accredited provider. Institutions that jump straight to TLPT risk an expensive audit yielding mostly generic findings. Those who build the preparatory stages receive specific vulnerability reports that justify the investment.

An additional point emerging in the second DORA cycle is the integration of TLPT findings into ongoing risk management. Many institutions treat TLPT reports like standard penetration-test reports: findings are prioritised, fixed and closed. That falls short. Supervisors expect TLPT insights to feed into strategic risk analysis, trends across multiple tests to be documented and the effectiveness of mitigations verified in follow-up tests. The difference between simple pentest tracking and genuine resilience management becomes a key audit field in the second round.

The interface with business-continuity planning is also under scrutiny. TLPT simulates attacker scenarios; BCP plans for outage scenarios. In many institutions, these disciplines operate separately. DORA demands their integration. Coordinating both exercises creates evidence for resilience assessments that is far more robust than isolated proofs.

The Operational Roadmap for Security Teams in DORA’s Second Phase

For security teams that have survived the first DORA year and are now preparing for the second audit cycle, a four-phase rhythm has proven effective.

The rhythm offers two key advantages. First, it decouples TLPT execution from audit preparation, giving both topics the focused attention they require. Second, it gives the incident-management team breathing room to fold runbook changes into operations after each phase without creating a last-minute pile-up. Institutions that cram everything into Q4 may produce paperwork that looks pristine on audit day but fails in real-world operations.

A recurring theme in supervisory conversations: regulators don’t just check whether processes exist; they verify that they are actually used. A six-month-old incident-classification workflow that hasn’t been touched because no major incidents occurred will still be scrutinised. Supervisors then demand evidence of readiness – exercises or tabletop drills that prove the process works. Banks that run quarterly tabletop exercises sail through these questions, while those that schedule them annually face extra scrutiny.

Another recurring issue in the second wave is the role of senior management. DORA is neither a pure compliance matter nor a pure IT project; responsibility sits with the board, not the second tier. Supervisors examine whether the board actively steers DORA measures, receives regular reports, and has co-signed the remediation roadmap. Delegating oversight to the IT leadership team invites findings at board level. Institutions with a standing ICT-risk review in the board agenda – typically quarterly and with its own agenda – produce far more credible evidence than those treating DORA as a technical project.

Finally, DORA reshapes collaboration between information security, IT operations, and operational compliance. The three functions must operate in shared workflows, not siloed handoffs. Banks that relied on Excel-based handovers between CISO, CIO, and compliance in round one are now rolling out unified GRC platforms where findings, actions, and evidence are centrally tracked. This cuts search time during audits and presents supervisors with a coordinated organisation instead of a stack of separate documents.

One last point that separates compliance from resilience payoff: in practice, DORA is a framework that elevates incident-response maturity and third-party risk management to levels many institutions already need. Treating the requirements as mere checkboxes yields costly documentation with no added value. Viewing them as an opportunity to harden resilience against ICT disruptions delivers, within twelve months, not only a clean audit report but also fewer sleepless nights. Investments in SIEM automation, clear runbooks, and robust exit plans pay off regardless of regulation; DORA simply sets the timeline for building them.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.

More from the MBF Media Network