HOW TO ENSURE IT MODERNIZATION PROJECTS COMPLY WITH BAFIN AND DORA REGULATIONS?

What is BaFin DORA compliance?

The Digital Operational Resilience Act (DORA) protects financial entities against cyber risks, having been enforceable since January 17, 2025, to ensure market stability. The framework shifted financial services compliance from fragmented national IT circulars to a standardized EU-wide regulation. With over a year of enforcement behind us, regulators have moved from reviewing frameworks to demanding real-time evidence of resilience and active compliance. This regulation impacts a broad spectrum of the financial sector, specifically:

• Banks
• Insurers
• Payment institutions
• Investment firms

To meet supervisory requirements, these organizations have upgraded and must continuously maintain their information and communication technology (ICT) systems. DORA establishes strict documentation rules and holds the management body directly accountable for ICT risk management. Failing to meet these cyber standards exposes organizations to significant administrative fines from regulators, including up to 2% of global annual turnover for financial entities and up to EUR 5 million for critical ICT providers, with daily recurring penalties of up to 1% of average daily worldwide turnover to force immediate remediation. Regulators can also suspend licences or revoke authorisation entirely under Article 50 of DORA. In my experience working with financial leadership, this shift to direct executive liability is often the biggest wake-up call.

How does DORA replace BAIT, VAIT, KAIT, and ZAIT?

DORA substitutes sector-specific German supervisory requirements with a unified European framework, entirely replacing BAIT, VAIT, KAIT, and ZAIT. BaFin has already repealed VAIT, ZAIT, and KAIT as of January 17, 2025. BAIT remains in force only for a limited group of institutions not yet subject to DORA, but will be fully repealed on December 31, 2026. A final group of institutions, such as certain financial service institutions under the German Banking Act (KWG), must apply DORA in full by January 1, 2027, as specified by the German Financial Market Digitalisation Act (FinmadiG). To navigate this transition, financial entities have conducted gap analyses mapping former BAIT, VAIT, KAIT, and ZAIT clauses against DORA’s article structure.

Organizations that have fully implemented the former BaFin circulars are well positioned for DORA compliance, since BaFin has confirmed large overlaps between the legacy frameworks and the new European standard. Through legacy modernization, institutions achieve regulatory compliance. Particularly when upgrading critical systems, they implement methods such as automated compliance mapping or continuous control monitoring.

Key Data and Requirements for BaFin DORA Compliance

Compliance Aspect	Key Details & Deadlines
Enforcement & Scope	Enforceable since January 17, 2025 Impacts banks, insurers, payment institutions, and investment firms
Non-Compliance Penalties	Up to 2% of global annual turnover for financial entities Up to EUR 5 million for critical ICT providers Daily recurring penalties of up to 1% of the average daily worldwide turnover Regulators can suspend licences or revoke authorisation
Legacy Framework Transition	Replaces German supervisory requirements: BAIT, VAIT, KAIT, and ZAIT BAIT fully repealed on December 31, 2026 Full DORA application for remaining institutions by January 1, 2027
ICT Risk & Documentation	Management body is directly accountable for ICT risk management Mandatory annual register of information submitted to ESAs in xBRL-CSV format
Testing & Incident Reporting	Initial incident notifications required within 24 hours Threat-led penetration testing (TLPT) mandated every 3 years First mandatory TLPT cycles must be completed by approximately 2028

How does DORA affect IT modernization in financial services?

By forcing the acceleration of IT modernization, the Digital Operational Resilience Act pushes financial entities to upgrade legacy systems and adopt resilient infrastructures. Organizations use this regulatory transition as a chance to finally overhaul outdated infrastructure. As a result, institutions integrate security directly into the architecture of modern ICT systems, such as cloud-native applications and distributed databases.

To ensure resilience against cyber incidents, financial companies are updating their core processes and security architectures. Rather than just a technical upgrade, this structural shift requires leaders to embed strict ICT risk management protocols directly into new digital frameworks. As development teams migrate critical infrastructure, they must adopt a compliance-safe approach that strengthens cyber risk management across the organization.

How do Solvency II and IFRS 17 align with digital operational resilience?

When you align Solvency II and IFRS 17 with your digital resilience strategy, you’re directly protecting the IT infrastructure that handles your financial reporting. System disruptions, such as database outages and severed data pipelines, materially impair financial performance. Regulators classify this reporting mechanism as a critical function requiring strict ICT risk management.

Resilient infrastructure supports the stringent data demands of insurance and broader regulatory compliance. This structural alignment guarantees accurate financial services compliance, and it also satisfies strict record-keeping rules when financial entities maintain secure IT architectures.

What are the core ICT risk management requirements?

At its core, the European regulation requires a framework to protect information assets, ensure system resilience, and maintain management accountability. Financial entities must establish an ICT risk management framework covering all digital assets and operational processes. These assets include:

• Data centers
• Cloud environments
• Internal networks

Management is now legally on the hook for cyber risk, meaning they must stay actively informed about threats. This executive accountability ensures strict regulatory compliance across the organization.

Institutions integrate modern tools, such as AI systems and predictive analytics engines, into their existing ICT structure to guarantee security and regulatory alignment throughout their life cycle. This step is non-negotiable. A complete digital operational resilience strategy also requires ICT business continuity management to protect critical functions during disruptions. Supporting this, organizations must maintain extensive documentation whenever modifying core operational systems to satisfy supervisory mandates.

How should financial entities develop a digital operational resilience strategy?

Financial entities establish a digital operational resilience strategy that surpasses traditional IT approaches to stay ahead of ICT risks. This framework features critical components to satisfy supervisory requirements:

• A strategic roadmap for digital resilience
• Mitigation protocols for technology-related risks
• IT modernization initiatives

Senior management approves, drives, and monitors the strategy implementation to guarantee effective cyber risk management. During regulatory audits, clear and transparent documentation is essential to prove your cyber defenses meet supervisory standards.

What are the documentation requirements for ICT asset management?

Financial entities maintain transparent documentation of all ICT assets to ensure security controls and make regulatory audits easier. This means identifying, classifying, and documenting primary asset categories: software, hardware, and physical infrastructure. To prevent undue administrative burden, institutions apply the proportionality principle, aligning documentation requirements with their specific size and operational complexity.

Auditors evaluate this asset mapping and ICT risk management implementation during external financial statement audits to ensure the firm actively maintains its digital operational resilience strategy.

How should you manage ICT third-party risk during cloud-native migrations?

Managing ICT third-party risk during cloud-native migrations requires strict oversight, contractual compliance, and specific strategies to reduce reliance on external service providers. Organizations integrate ICT third-party risk management directly into the entire lifecycle of cloud-native adoption and outsourcing management while enforcing stringent security standards.

Firms ensure external cloud providers adhere to strict contractual obligations, implementing standard contractual clauses to guarantee their agreements meet European supervisory requirements. This legal alignment protects critical or important functions during IT modernization initiatives. By establishing clear exit strategies and continuous monitoring protocols for external vendors, organizations achieve effective cyber risk management.

What is the register of information?

The register of information is a mandatory log of every contractual arrangement with an external ICT service provider required for regulatory submission. This record contains specific data categories regarding a third-party ICT contract: service descriptions, vendor locations, and supported critical or important functions. This register provides the necessary oversight to manage and mitigate third-party risks effectively. If you’ve ever had to scramble to track down a forgotten vendor contract right before an audit, you know exactly why this centralized record is so crucial. Financial entities maintain this register to provide transparency into third-party dependencies, including cloud hosting and data processing, during an external audit.

The register of information is now an annual reporting obligation. National competent authorities collect the registers and forward them to the European Supervisory Authorities (ESAs) by the end of March each year. In Germany, BaFin required the first submission in April 2025, and the second annual submission cycle is underway in Q1 2026. The ESAs now require submissions in xBRL-CSV format and strongly discourage the use of spreadsheets for official reporting. Nearly half of financial institutions have identified the register of information as their single most challenging DORA requirement, making automation and continuous register maintenance a top priority.

Supervisory authorities, such as national regulators and central banks, use this data to identify systemically critical service providers across the financial sector when evaluating market stability. In November 2025, the ESAs published their first list of 19 designated critical ICT third-party providers (CTPPs), including cloud hyperscalers (AWS, Google Cloud, Microsoft), data center operators (Deutsche Telekom), and financial technology specialists (Oracle, SAP). These designated providers are now subject to direct ESA oversight through Joint Examination Teams (JETs), with the list updated annually. Organizations meet DORA’s strict standards for their ICT architecture by updating this log continuously.

How can you prevent vendor lock-in with critical cloud providers?

Preventing vendor lock-in requires adopting a multi-vendor strategy to reduce the risks of relying on critical cloud service providers. Financial entities implement this approach to ensure flexibility, business continuity, and easier provider substitution during IT modernization. Relying on a single provider for critical or important functions creates severe technical complexity and a lack of alternatives during service disruptions.

Regulators classify vendor lock-in as a significant dependency risk that the ICT third-party risk management framework directly addresses. Since the ESAs designated the first critical ICT providers in late 2025, supervisory focus on concentration risk has intensified. National competent authorities now probe reliance on any single designated CTPP for critical functions, regional availability zone strategies, and failover realism. To avoid vendor lock-in, organizations typically rely on cloud-native architectures for platform independence while distributing workloads across diverse ICT environments.

Which legacy modernization strategies ensure a compliance-safe approach?

Phased modernization techniques allow financial entities to safely upgrade outdated systems to modern architectures. This incremental approach minimizes operational disruption while securing continuous regulatory compliance. Consequently, organizations use this compliance-safe approach to maintain system resilience and security throughout the transition.

Financial companies used the regulatory transition phase to execute modernization projects without compromising their mandatory risk management frameworks.

How can the strangler fig pattern reduce regulatory compliance risk?

The strangler fig pattern reduces regulatory compliance risk by enabling the step-by-step replacement of outdated architecture rather than executing a high-risk complete migration. This incremental IT modernization prevents system downtime and ensures the continuous availability of critical or important functions. Replacing legacy systems piece by piece allows financial entities to continuously test and validate regulatory compliance at each modernization stage. I routinely recommend this specific pattern to engineering teams who are understandably wary of high-stakes ‘big bang’ migrations.

This step-by-step method shields you from massive regulatory missteps while you upgrade. Teams embed strict ICT and cyber risk management into new ICT components as they systematically retire old operational systems.

How does API wrapping protect critical or important functions?

API wrapping protects critical or important functions by creating a secure interface around legacy systems. By encapsulating vulnerable systems, this technique not only extends their lifespan but also meets current security standards by shielding them from direct exposure to modern cyber threats. Ultimately, the primary benefits of this method are secure data exchange and continuous system interoperability without immediately rewriting underlying business logic.

API wrapping provides a secure interim step for modernization. This isolation layer allows firms to maintain operational continuity and meet DORA’s strict data-in-transit security requirements while gradually migrating to cloud-native microservices.

What are the rules for ICT incident reporting?

ICT incident reporting is a strict, multi-stage procedure that financial entities execute to inform supervisory authorities promptly. An ICT incident triggers mandatory communication to authorities if it causes a high adverse impact on network and information systems supporting critical functions. Regulators require you to structure these submissions in mandatory stages: initial notifications within 24 hours of classification, intermediate updates, and final reports.

Organizations adhere to specific formats and strict timelines that implementing technical standards (ITS) define to satisfy supervisory requirements. In Germany, BaFin receives incident reports through its dedicated reporting portal. The reporting requirements under DORA are the strictest the financial sector has ever seen. Delayed or incomplete reporting not only brings regulatory fines but can erode client trust. By integrating these exact protocols into their broader ICT risk management frameworks, institutions demonstrate effective cyber risk management and maintain continuous regulatory compliance.

How do you conduct operational resilience testing?

Operational resilience testing is a risk-based program that financial entities implement to continuously evaluate and improve their cyber defense capabilities. Compliant testing frameworks include various assessments, such as regular vulnerability assessments, scenario-based testing, and advanced attack simulations. Organizations establish this testing regimen to ensure that core operational processes and security architectures remain actively resistant to simulated cyber incidents, such as ransomware attacks and data breaches.

Financial institutions conduct these regular testing programs to identify structural weaknesses in their ICT systems before malicious actors, such as hacking syndicates and unauthorized external users, exploit them. By building these evaluations into your broader strategy, you don’t just check a compliance box. You actively secure your systems. This continuous validation strengthens overall cyber and ICT risk management during complex IT modernization initiatives.

What is threat-led penetration testing (TLPT)?

Threat-led penetration testing (TLPT) is an advanced, mandatory simulation of real-world cyber-attacks that test the defense capabilities of high-risk financial entities. Regulators mandate a specific requirement for these organizations: performing intelligence-led red teaming exercises every 3 years. These exercises use established testing methodologies to safely simulate sophisticated attacks on critical live production systems, such as payment gateways and core banking platforms. Unlike standard vulnerability assessments that simply flag static flaws like outdated software, TLPT actively tests dynamic cyber defenses. It uses ethical red-teaming frameworks to provide a rigorous, real-world evaluation of an organization’s security. With DORA enforcement now active, the first mandatory TLPT cycles must be completed by approximately 2028, making early preparation essential. Having observed a few of these live red-teaming exercises firsthand, I can tell you they are consistently eye-opening for even the most seasoned IT security professionals.

Integrating these standardized security evaluations directly into ICT environments strengthens overall cyber risk management. More importantly, it ensures continuous compliance with strict financial services regulations. Ultimately, this intelligence-led approach protects critical or important functions to satisfy strict supervisory requirements, such as DORA mandates and BaFin regulations.

How do regulatory technical standards (RTS) and implementing technical standards (ITS) guide implementation?

Regulatory technical standards (RTS) and implementing technical standards (ITS) provide the detailed methodologies and uniform templates necessary to put high-level regulatory requirements into practice. The ESAs released these standards in two batches, the first in January 2024 and the second in July 2024, and they are now fully in force.

• RTS supplements the primary legislation by specifying detailed technical requirements for ICT risk management, covering encryption, network segmentation, identity management, and incident classification timelines.
• ITS provides practical tools for reporting and documentation, offering standardized templates, structured procedures, and the exact format and timelines for mandatory ICT incident reporting.

Organizations satisfy strict supervisory and extensive documentation requirements by applying these precise standards to their ICT systems.

What is the future scope of DORA?

DORA’s scope may continue to expand. Under Article 58, the European Commission was required to review by January 2026 whether statutory auditors and audit firms should be brought under DORA’s framework. The ESAs published their joint report in December 2025, concluding that including auditors within DORA’s scope is not warranted at this stage. A broader review under Article 58(1) is scheduled for January 2028, which may lead to further legislative proposals adjusting or expanding the regulation.

Sources

• https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora
• https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers
• https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-regulatory-technical-standards-specifying-elements-related-threat-led-penetration-tests