Navigating BaFin and DORA: How to Modernize Your IT Projects Without Regulatory Risk
- 3 days ago
- 18 min read
The Digital Operational Resilience Act (DORA) has set the stage for a harmonized digital resilience framework across the European Union’s financial sector. However, its implementation in Germany introduces some critical adjustments.
Notably, the Federal Financial Supervisory Authority (BaFin) plans to phase out existing supervisory requirements, such as BAIT, to avoid double regulation. This shift signals a streamlined compliance environment, but also necessitates a clear understanding of how DORA and these changes impact financial institutions and related industries.
In this article we will explore DORA’s implementation in Germany, its alignment with existing regulations, and what businesses need to know to ensure compliance.
The Regulatory Landscape Explained
The Digital Operational Resilience Act (DORA) protects financial entities against cyber risks and has been enforceable since January 17, 2025, to ensure market stability. The framework replaced fragmented national IT regulations with a single, standardized EU-wide standard. 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
DORA establishes a unified approach to digital operational resilience. Its provisions include:
information and communication technology (ICT) risk management frameworks.
Reporting of significant ICT-related incidents.
Resilience testing for digital systems.
Oversight of ICT third-party service providers.
Importantly, DORA establishes Level 1 requirements, supplemented by Level 2 regulatory and implementing technical standards (RTS/ITS). Together, these measures create a robust, tiered system for managing risks in the financial sector.
To meet supervisory requirements, aforementioned types of organizations must continuously upgrade and maintain their ICT systems. DORA establishes strict documentation rules and holds the management body directly accountable for ICT risk management. Non-compliance carries severe consequences - including fines of 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 until remediation is achieved. Beyond fines, regulators can suspend licences or revoke authorisation entirely under Article 50 of DORA - a risk no financial institution can afford.
In our experience working with financial leadership, this shift to direct executive liability is often the biggest wake-up call. At Plexteq, we have helped financial institutions translate these executive obligations into concrete IT modernization roadmaps that satisfy regulators from day one.
How does Germany adapt to DORA?
When it comes to navigating DORA in Germany, understanding how it integrates with existing regulations and elevates oversight is key. We've seen many organizations struggle to balance legacy frameworks with new EU-wide mandates, but DORA aims to simplify this process by streamlining compliance and raising resilience standards.
From National Circulars to EU Law: The End of BAIT, VAIT, KAIT, and ZAIT
BaFin has announced plans to repeal several existing supervisory requirements with DORA to prevent overlapping regulations. This includes:
BAIT (Supervisory Requirements for IT in Financial Institutions)
ZAIT (Payment and E-Money Institutions)
VAIT (Insurance Undertakings)
KAIT (Asset Managers)
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 xAIT clauses against DORA's article structure.
The challenge lies in managing overlapping but non-identical obligations without creating duplicative compliance processes. DORA requires explicit mapping of ICT systems to critical business functions, documented data flow diagrams showing how sensitive information moves across organizational boundaries, and board-approved risk appetite statements that quantify acceptable operational disruption levels. Many German institutions maintained less formal documentation under BAIT and VAIT.
German institutions must now implement centralized governance structures that provide single-source-of-truth visibility across all ICT risks, third-party dependencies, and incident response activities. This requires integrating data from vulnerability scanners, configuration management databases, contract management platforms, and incident ticketing systems into unified compliance dashboards. Institutions that maintained siloed risk management functions across business lines face significant integration challenges.
BaFin's New Strategic Focus
BaFin's strategic focus areas are the specific domains where its proactive doctrine is being actively enforced. These are high-priority areas examined during audits. The following five sections break down each of these high-priority domains in detail. Each one provides a practical analysis of how BaFin’s new expectations are being applied in the real world audits.
Domain | Focus |
|---|---|
Outsourcing and Third-Party Risk (DORA) | This focus marks a fundamental shift from merely documenting vendor relationships to proving operational resilience against third-party failure. Under the EU's Digital Operational Resilience Act (DORA), vendor management is no longer a simple contract-review (SLA) task; it is a C-suite issue of business continuity. Regulators are no longer just checking contracts. They are testing executable exit strategies and mapping concentration risk, for example, whether a bank is overly reliant on a single cloud provider for multiple critical functions. BaFin expects banks to maintain a dynamic, real-time outsourcing register (not a static PDF) and prove they can survive the sudden loss of a critical ICT provider without material disruption. |
AML/CTF and STR Timeliness | The primary lesson from recent enforcement is that timeliness is a non-negotiable outcome. BaFin's 'Risks in Focus 2025' identifies inadequate money-laundering prevention as a critical risk. The regulator is using hard metrics to measure the time taken from alert generation to filing the Suspicious TransactionReport (STR). Banks are being forced to move beyond static, rule-based systems, which often generate excessive false positives, and into behavioral models that efficiently isolate true risk. Critically, this process must retain human accountability. This means all automated systems must be transparent and support, not replace, the final judgment of a qualified analyst. |
Internal Governance and Reporting (Compliance Culture) | This focus area concerns the structural integrity and top-down commitment to compliance. Recent fines highlight that inadequate resourcing, incomplete board reports, or reporting gaps are treated as severe failures of governance, not mere administrative oversights. BaFin expects the management board to be proactively engaged, demanding clear, measurable KPIs (like compliance action closure rates) that signal the health of the control environment. This shifts board reporting from a retrospective explanation of what happened to a forward-looking risk management dashboard showing what is being done to prevent future breaches. |
ESG and Sustainability Risks | BaFin expects Environmental, Social, and Governance (ESG) risks to be fully integrated into the bank’s core risk management framework (e.g., MaRisk), not treated as a peripheral marketing topic. This means quantifying how climate change, transition risks, and social factors impact credit risk, operational resilience, and market positions. For the compliance function, the emphasis is on evidential truthfulness. Claims of "green" or "sustainable" products must be substantiated with auditable data, preventing the legal and reputational risk of greenwashing and ensuring full compliance with disclosure rules. |
Cybersecurity and Operational Resilience | Cyber incidents are now treated as immediate prudential concerns. Guided by BAIT (Bankaufsichtliche Anforderungen an die IT), BaFin expects banks to not only have detailed recovery plans (DR/BCP) but to rigorously test them and prove they can meet key metrics like Recovery Time Objective (RTO). The introduction of DORA formalizes the need for rapid incident classification and timely notification to the regulator, turning every major cyber event into a critical compliance checkpoint. Banks must demonstrate architectural resilience and incident readiness (e.g., playbooks, drills) to prove they are not a weak link in the financial system. |
A Blueprint for Modernization
Achieving the transformative benefits of advanced regulatory technology (RegTech) is a complex challenge extending beyond mere software adoption. Before financial institutions can fully leverage cutting-edge solutions, banks must proactively address the deep-seated foundational workflow and organizational gaps that repeatedly undermine compliance efforts. These include siloed processes, such as fragmented onboarding, legacy IT systems that hinder automation and integration, procurement bottlenecks, and data fragmentation, among other major hurdles.
This actionable blueprint for modernization provides the framework for transforming compliance from a check-the-box cost center into a proactive, strategic capability. More than simply a list of new technologies banks should implement, the approach centers around the critical human and process-oriented foundations that are the prerequisites for any successful technology implementation. The following steps outline the path to building a defensible, efficient, and data-driven compliance function that satisfies regulators and creates lasting business value.
Core Stakeholders
Institutions that succeed orient their compliance processes around three stakeholder groups:
Internal Teams: Relief from manual drudgery, structured workflows that create accountability, and free analysts to focus on genuine risk.
Customers: Simple, transparent onboarding, with data collected once and reused across products.
Auditors and Supervisors: Complete audit trails "from day one," with centralized, retrievable records that cut weeks of manual evidence-gathering.
Data Centralization
At the heart of modern compliance is data centralization. Without a single source of truth, controls collapse under the weight of duplications, inconsistencies, and delays in retrieval. A centralized case management system integrates KYC, alerts, investigations, and regulatory filings into a single platform, ensuring that the centralized, clean, and proprietary data becomes the bank’s most valuable asset. It is the Institutional IP, the “raw material” that, when fed into analytical models, creates the "Data Moat". It is the one asset competitors cannot replicate.
Human-Centric Workflows
Many banks benefit from lightweight workflows built on familiar platforms such as Jira, Azure Boards, BPM tools, and RPA. This approach increases transparency, accelerates adoption, and avoids multi-year procurement cycles.
By addressing these fundamental steps as part of a long-term, robust compliance strategy, banks lay the groundwork for transformational changes such as re-engineered governance and internal culture. Without these foundational changes, even the most sophisticated AI or monitoring system risks being undermined by silos, politics, and fragmented evidence.
Banks seeking to mitigate regulatory exposure and thrive in a fast-evolving financial services sector should take meaningful steps to modernize their approach to compliance. Doing so is more than a means to lower the risk of audits or potential penalties from regulators, but a newfound opportunity to turn compliance into a competitive advantage and long-term revenue driver.
Key Data and Requirements for BaFin DORA Compliance
Compliance Aspect | Key Details & Deadlines |
|---|---|
Enforcement & Scope |
|
Non-Compliance Penalties |
|
Legacy Framework Transition |
|
ICT Risk & Documentation |
|
Testing & Incident Reporting |
|
What to expect during BaFin examinations
German institutions should prepare for supervisory reviews focusing on:
Documentation Requests:
Complete third-party registers with criticality classifications and contractual provisions
Incident logs showing detection times, classification decisions, and notification timelines
Resilience testing results with remediation tracking
Data flow maps connecting critical business functions to supporting ICT systems
Technical Validation:
Demonstrations of control effectiveness (access controls, encryption, monitoring)
Evidence of automated incident detection and classification
Proof of immutable audit trail implementation
Validation of exit strategy viability for critical providers
Timeline Expectations:
Institutions must produce evidence within hours or days, not weeks
Real-time compliance dashboards preferred over manually assembled reports
Historical evidence showing continuous control operation over time
Common Examination Findings:
Incomplete third-party registers missing cloud providers or SaaS platforms
Incident classification methodologies lacking objective criteria
Resilience testing without documented remediation tracking
Data flow maps missing unstructured data exchanges (email, file sharing)
BaFin has signaled that it will enforce DORA through existing supervisory channels, incorporating DORA compliance assessments into regular examination cycles. German institutions should expect supervisory inquiries focused on third-party registers, incident classification methodologies, resilience testing results, and the completeness of ICT risk inventories. Demonstrating compliance requires producing evidence on demand through audit-ready documentation.
DORA as a Catalyst for IT Modernization in Financial Services
DORA is accelerating ICT modernization across the financial sector, compelling institutions to retire legacy systems and build resilient, future-proof infrastructures. For many organizations, this regulatory pressure has become the business case that finally justifies long-overdue infrastructure overhauls.
The practical result is a fundamental shift in how financial institutions design and build technology. Security and resilience are no longer retrofitted onto existing systems - they are embedded directly into the architecture of modern ICT platforms, including cloud-native applications and distributed databases. Development and engineering teams migrating critical infrastructure must now treat regulatory compliance not as a final checkpoint, but as a continuous design principle woven into every stage of the modernization process.
For CTOs and engineering leaders, this means ICT risk management protocols can no longer sit with compliance teams alone. They must be integrated into technical delivery frameworks, architectural decisions, and vendor selection criteria from day one.
Solvency II and IFRS 17: why your reporting infrastructure is a critical ICT function
Aligning Solvency II and IFRS 17 requirements with a digital resilience strategy means protecting the ICT infrastructure that underpins actuarial modeling, financial reporting, and regulatory disclosure workflows. System disruptions - including database outages, corrupted data feeds, degraded compute clusters, or failed ETL pipelines do not merely create operational inconvenience; they can compromise valuation accuracy, delay solvency calculations, interrupt closing cycles, and trigger supervisory scrutiny.
Modern insurance reporting environments depend on highly interconnected platforms that aggregate policy, claims, market, and actuarial data across core systems, cloud services, and third-party providers. Under DORA, institutions are expected to identify and secure ICT-supported critical or important functions, which frequently include solvency calculations, IFRS 17 subledger processing, actuarial projection engines, and regulatory reporting workflows. As a result, resilience engineering becomes directly linked to compliance readiness.
In practice, this requires insurers to implement resilient and observable architectures capable of maintaining data integrity, traceability, and operational continuity under stress conditions. Typical implementation measures include:
geographically distributed infrastructure and disaster recovery orchestration,
high-availability database clustering and automated failover,
immutable backup strategies and ransomware recovery controls,
end-to-end encryption for financial and actuarial datasets,
centralized logging and SIEM integration for auditability,
real-time monitoring of data pipelines and batch processing jobs,
role-based access controls integrated with IAM and PAM solutions,
infrastructure-as-code and controlled CI/CD pipelines for change governance,
and vendor risk monitoring across cloud and SaaS dependencies.
For insurers operating under BaFin supervision, technical implementation must also support strong governance and documentation standards. This includes maintaining auditable control evidence, preserving lineage of actuarial and accounting data transformations, validating model execution environments, and demonstrating recoverability of critical reporting functions during ICT disruption scenarios.
From an engineering perspective, DORA compliance therefore extends beyond cybersecurity hardening. It requires insurers to build operationally resilient financial platforms that can sustain solvency calculations, IFRS 17 reporting processes, and regulatory disclosures even during infrastructure failures or cyber incidents. This is driving increased adoption of cloud-native resilience patterns, zero-trust security models, automated compliance monitoring, and integrated observability frameworks across the insurance sector.
Core ICT Risk Management Requirements Under DORA
At its core, DORA requires financial institutions to implement a comprehensive ICT risk management framework that protects information assets, ensures operational resilience, and establishes clear governance accountability across critical systems and services. The framework must cover all digital assets and operational processes, including:
Data centers - physical and virtual infrastructure supporting critical financial workloads, requiring high availability, redundancy, backup integrity, and disaster recovery controls
Cloud environments - public, private, and hybrid deployments subject to documented risk assessments, third-party oversight, provider due diligence, data residency controls, and tested exit strategies
Internal networks - connectivity layers, identity and access management, segmentation architecture, endpoint security, and continuous monitoring capabilities supporting day-to-day operations
Under DORA, ICT risk oversight is no longer treated as a purely technical responsibility. Management bodies are expected to actively govern cyber and operational resilience risks, maintain visibility into critical dependencies, and ensure ICT risk management remains a board-level function aligned with business continuity and regulatory obligations.
As financial institutions integrate AI systems, automation platforms, and predictive analytics into operational workflows, these technologies must also fall within existing ICT governance, monitoring, and auditability requirements. This includes model oversight, access controls, logging, third-party dependency management, and documented change-management processes throughout the technology life cycle. In parallel, institutions must maintain robust ICT business continuity capabilities to preserve critical services during cyber incidents, infrastructure failures, or operational disruptions.
Financial institutions that embed ICT risk management into daily engineering, security, and governance processes are typically better prepared for supervisory reviews by regulators such as BaFin. At Plexteq, we work with engineering and compliance teams to design operational resilience frameworks that support audit readiness, traceability, and long-term regulatory alignment.
In our experience, financial institutions that treat ICT risk management as a continuous operational discipline - rather than a periodic compliance exercise - are significantly better positioned during BaFin audits. At Plexteq, we help engineering and compliance teams build ICT risk frameworks that are both technically sound and regulator-ready from the ground up.
How should financial entities develop a digital operational resilience strategy?
A DORA-aligned digital resilience strategy should establish clear governance, tested risk controls, and resilient technology foundations across critical ICT functions. To meet supervisory expectations, financial institutions should implement:
A documented ICT resilience roadmap - a board-approved plan defining resilience priorities, modernization objectives, and measurable implementation milestones aligned with DORA requirements
Formal ICT risk and incident response procedures - tested processes for identifying, assessing, escalating, and recovering from cyber and operational disruptions, including defined recovery objectives and accountability structures
Technology modernization and resilience initiatives - programs to reduce legacy system exposure, strengthen infrastructure resilience, and integrate security, compliance, and auditability requirements into new platforms and operational workflows
Under DORA, management bodies are expected to actively oversee implementation rather than approve resilience policies on a periodic basis. During supervisory reviews, regulators such as BaFin typically expect evidence of continuous governance, documented controls, and ongoing monitoring of ICT risks and resilience measures.
What are the documentation requirements for ICT asset management?
Financial institutions must maintain transparent, comprehensive documentation of all ICT assets to demonstrate effective security controls and withstand regulatory audit scrutiny. This requires the systematic identification, classification, and documentation of three primary asset categories:
Software - including licensed applications, custom-developed systems, third-party integrations, and all software dependencies that support critical financial functions
Hardware - covering physical servers, network devices, end-user equipment, and any infrastructure components involved in the processing or storage of regulated data
Physical infrastructure - encompassing data center facilities, power and cooling systems, and physical security controls that underpin ICT operations
To prevent undue administrative burden, DORA applies the proportionality principle - allowing institutions to calibrate documentation requirements to their specific size, complexity, and risk profile. Smaller institutions are not expected to maintain the same documentation depth as systemically important banks, but the obligation to document, classify, and actively manage ICT assets applies universally.
During external financial statement audits, auditors evaluate both the quality of asset mapping and the effectiveness of ICT risk management implementation verifying that institutions are not merely documenting their digital operational resilience strategy, but actively maintaining it.
In our experience, inadequate or outdated ICT asset documentation is one of the most common findings in BaFin audit cycles. At Plexteq, we help financial institutions build and maintain living asset registries that satisfy both BaFin's dynamic documentation expectations and DORA's broader ICT governance requirements.
ICT Third-Party Risk in Cloud-Native Migrations: What DORA Requires and BaFin Audits
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.
What are the rules for ICT incident reporting?
ICT incident reporting under DORA is a strict, multi-stage procedure that financial institutions must execute promptly to inform supervisory authorities. A reportable ICT incident is one that causes a high adverse impact on the network and information systems supporting critical functions - triggering mandatory communication obligations that cannot be deferred.
DORA structures these submissions in three mandatory stages: an initial notification within 24 hours of incident classification, an intermediate update, and a final report. Financial institutions must adhere to specific formats and strict timelines defined by implementing technical standards (ITS) to satisfy supervisory requirements. In Germany, BaFin receives incident reports exclusively through its dedicated reporting portal.
The reporting requirements under DORA are the most stringent the financial sector has ever faced. Delayed or incomplete reporting carries a dual consequence - regulatory fines and material erosion of client trust. Institutions that integrate these protocols directly into their broader ICT risk management frameworks are best positioned to respond accurately and on time, demonstrating effective cyber risk management and maintaining continuous regulatory compliance.
Operational Resilience Testing Under DORA
Operational resilience testing is a risk-based programme that financial institutions implement to continuously evaluate and strengthen their cyber defense capabilities. Compliant testing frameworks encompass a range of assessments - including regular vulnerability assessments, scenario-based testing, and advanced attack simulations which are designed to ensure that core operational processes and security architectures remain actively resistant to simulated cyber incidents such as ransomware attacks and data breaches.
Regular testing programmes allow financial institutions to identify structural weaknesses in their information and communication technology (ICT) systems before malicious actors - including hacking syndicates and unauthorized external users - have the opportunity to exploit them. This continuous validation is not a compliance checkbox exercise. It is an active, ongoing commitment to securing critical systems and strengthening overall cyber and ICT risk management throughout complex IT modernization initiatives.
In our experience, financial institutions that embed operational resilience testing into their IT modernization programmes - rather than treating it as a separate compliance workstream - consistently achieve stronger audit outcomes and faster remediation cycles. At Plexteq, we help engineering and security teams design testing frameworks that satisfy both DORA's technical requirements and BaFin's increasingly rigorous audit expectations.
What is threat-led penetration testing (TLPT)?
Threat-led penetration testing (TLPT) is an advanced, mandatory simulation of real-world cyber attacks required for high-risk financial entities under DORA. Regulators mandate that these organizations conduct intelligence-led red teaming exercises every three years, using established testing methodologies to safely simulate sophisticated attacks on critical live production systems - including payment gateways and core banking platforms.
Unlike standard vulnerability assessments that identify static flaws such as outdated software versions, TLPT actively tests dynamic cyber defenses under realistic attack conditions. Using ethical red teaming frameworks, it provides a rigorous, real-world evaluation of an organization's security posture across people, processes, and technology. With DORA enforcement now active, the first mandatory TLPT cycles must be completed by approximately 2028 - making early preparation essential for institutions that have not yet initiated their testing programmes.
In our experience observing live red teaming exercises firsthand, they are consistently eye-opening — even for the most seasoned ICT security professionals. The gap between documented security controls and their real-world effectiveness under simulated attack conditions is often the most valuable — and sobering - insight these exercises produce.
Integrating these standardized security evaluations directly into ICT environments strengthens overall cyber risk management while ensuring continuous compliance with financial services regulations. This intelligence-led approach ultimately protects critical and important functions to satisfy DORA mandates and BaFin supervisory requirements.
From Regulation to Practice: How RTS and ITS Translate DORA Into Actionable Requirements
Regulatory technical standards (RTS) and implementing technical standards (ITS) provide the detailed methodologies and uniform templates necessary to translate high-level regulatory requirements into concrete, executable practice. The European Supervisory Authorities (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 information and communication technology (ICT) risk management, covering encryption standards, network segmentation, identity management, and incident classification timelines
ITS provides practical tools for reporting and documentation, offering standardized templates, structured procedures, and the exact formats and timelines for mandatory ICT incident reporting
For CTOs and engineering leaders, RTS and ITS are not abstract regulatory documents - they are the precise technical specifications your ICT systems, processes, and reporting workflows must be built and measured against. Institutions that treat these standards as living implementation guides rather than one-time reference documents are significantly better positioned to maintain continuous compliance as supervisory expectations evolve.
In our experience, the gap between an institution's high-level DORA compliance strategy and its actual technical implementation is most often found in the details of RTS and ITS. At Plexteq, we help engineering teams translate these standards into concrete ICT architecture decisions, documentation workflows, and reporting pipelines that satisfy BaFin's audit expectations from day one.
What is the future scope of DORA?
DORA's regulatory perimeter may continue to expand beyond its current framework. Under Article 58, the European Commission was required to review by January 2026 whether statutory auditors and audit firms should be brought within DORA's scope. The ESAs published their joint report in December 2025, concluding that including auditors within DORA's framework is not warranted at this stage.
A broader legislative review under Article 58(1) is scheduled for January 2028, which may result in further proposals to adjust or expand the regulation. Financial institutions should monitor this review closely - particularly those with significant dependencies on audit firms or third-party assurance providers whose regulatory status may change as DORA's scope evolves.
