7 min read<\/p>\n
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 \u2013 limits that can no longer be met with standard processes.<\/strong><\/p>\n Key Takeaways<\/p>\n Related<\/span>NIS2 Reporting Channels: Shaping the First Incident Hour<\/a> \/<\/span> Adaptive MFA in Entra, Okta & Duo: Rolling Out NIS2<\/a><\/p>\n 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\u2019 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\u2019s 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.<\/p>\n 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 \u2013 while simultaneously preparing the report itself. Those without this process baked into their runbook automation are under immediate pressure. The early audits\u2019 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Where DORA implementations may fail by 2026<\/p>\n What supports DORA readiness<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n First, the market of accredited providers is tight. In Germany and across Europe, there are double-digit \u2013 not triple-digit \u2013 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n A recurring theme in supervisory conversations: regulators don\u2019t just check whether processes exist; they verify that they are actually used. A six-month-old incident-classification workflow that hasn\u2019t been touched because no major incidents occurred will still be scrutinised. Supervisors then demand evidence of readiness \u2013 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.<\/p>\n 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 \u2013 typically quarterly and with its own agenda \u2013 produce far more credible evidence than those treating DORA as a technical project.<\/p>\n 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.<\/p>\n 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.<\/p>\n Every question is locked. A tap unlocks the answer.<\/p>\n The regulation applies to all supervised financial institutions in the EU: banks, insurance companies, securities firms, payment service providers, e-money institutions, investment funds, trading infrastructures, and critical ICT third-party providers. There are relief measures for small institutions below certain thresholds, but no complete exemption. If you provide services to financial institutions without being regulated yourself, you will still face DORA-relevant requirements through the backdoor via your customers\u2019 third-party provider clauses.<\/p>\n<\/details>\n DORA is sector-specific for financial institutions and imposes more detailed requirements for incident reporting, testing, and third-party provider management. NIS2 applies across sectors and is in some respects more general. Where both regulations overlap, DORA takes precedence within its scope.<\/p>\n<\/details>\n EU supervisors designate providers that are critical to multiple financial institutions as CTPP and subject them to a dedicated supervisory regime. This typically includes large cloud providers, central payment service providers, and specialized core banking system vendors. The CTPP list is updated annually.<\/p>\n<\/details>\n Institutions subject to TLPT obligations must perform a test at least every three years. The supervisory authority may require an early test following significant changes to the IT landscape or after major incidents. Planning lead times range from six to nine months.<\/p>\n<\/details>\n The internal audit function plays a central role. It continuously reviews whether ICT risk management processes comply with DORA requirements and reports to the executive board and supervisory board. Without adequate internal audit capacity, the external supervisory review becomes a stress test for which you are unprepared.<\/p>\n<\/details>\n More from the MBF Media Network<\/p>\n\n
What the first audits in 2026 have really revealed<\/h2>\n
Third-Party Registers and Exit Scenarios<\/h2>\n
\n
\n
TLPT in practice: market, capacity and internal maturity<\/h2>\n
The Operational Roadmap for Security Teams in DORA\u2019s Second Phase<\/h2>\n
Frequently Asked Questions<\/h2>\n
Which institutions fall under DORA?<\/strong><\/summary>\n
How does DORA differ from NIS2?<\/strong><\/summary>\n
What is the role of critical ICT third-party providers (CTPP)?<\/strong><\/summary>\n
How often must a TLPT be conducted?<\/strong><\/summary>\n
What role do internal audits play in DORA implementation?<\/strong><\/summary>\n