Listen To Our Podcast🎧
DORA compliance became a binding legal requirement for European financial institutions on January 17, 2025, and the clock is already running on supervisory reviews. If your bank or payment institution has not yet mapped its ICT systems against the regulation's five pillars, you are behind schedule. This post breaks down the seven most pressing ICT risk requirements under DORA, what each demands in practice, and how real-time payment fraud controls, AI model governance, and third-party oversight connect to your compliance program. Whether you are a CISO building a remediation roadmap or a compliance officer preparing for your first supervisory review cycle, these are the requirements that matter most right now.
What DORA Compliance Requires from Financial Institutions
The Digital Operational Resilience Act (Regulation EU 2022/2554) applies to roughly 22,000 financial entities across the EU: banks, investment firms, payment institutions, crypto-asset service providers, and critical ICT third-party service providers. Its core obligation is that financial entities must be able to withstand, respond to, and recover from ICT-related disruptions and threats.
What sets DORA compliance apart from frameworks like NIS2 or ISO 27001 is scope and enforceability. Supervisory authorities can now directly oversee Critical Third-Party Providers (CTPPs), not just the financial entities using them. Fines can reach 2% of total annual worldwide turnover for entities and up to €5 million for individuals in management positions.
The regulation organizes its requirements into five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing. The seven requirements below represent the areas where most banks are currently falling short.
ICT Risk Management Framework
DORA compliance begins with a documented, board-approved ICT risk management framework. Under Articles 5 through 16, financial entities must maintain a framework that covers identification, protection, detection, response, recovery, and learning. This is not a one-time document; it requires continuous review and testing.
The practical gap most banks face is governance. The regulation requires the management body to approve the framework and take direct responsibility for its implementation. Your board cannot delegate ICT risk entirely to the CISO. Banks that operate with siloed risk and technology functions are finding this difficult to satisfy.
Key requirements under this pillar:
- A complete ICT asset inventory covering all systems that support critical or important functions
- Documented ICT risk tolerance levels aligned to the bank's overall risk appetite
- Procedures for detecting anomalous activities, including network traffic and ICT-related incidents
- Recovery time and recovery point objectives (RTOs and RPOs) for all critical systems
The asset inventory is often where work stalls. Banks with hybrid infrastructure across on-premise, private cloud, and public cloud frequently discover undocumented dependencies when they start mapping critical function support chains. That discovery process itself is a major undertaking before any gap remediation begins.
ICT Incident Reporting Under DORA Compliance Rules
DORA's incident reporting framework in Articles 17 through 23 is more prescriptive than most banks have dealt with before. Financial entities must classify ICT incidents and report major incidents to their competent authority within strict timeframes: an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month.
The classification criteria are where complexity builds. An incident qualifies as "major" if it crosses thresholds across five criteria: clients affected, geographic spread, duration, economic impact, and reputational impact. The European Banking Authority has published implementing technical standards for incident reporting that specify exactly how these thresholds work, including numeric floors for each criterion.
Banks with mature security operations centers will still need to retrofit their incident management workflows to capture DORA-specific classification data. The 4-hour initial notification window is tight. Many organizations find that manual classification processes cannot reliably meet it across all incident types. The integration of automated detection and classification tooling is where most institutions are investing right now.
One thing worth noting: the regulation distinguishes between ICT incidents and cyber threats. Both require monitoring processes, but only major incidents trigger formal reporting. Your SOC runbooks need to reflect that distinction clearly.
Third-Party ICT Provider Oversight
This pillar is the most operationally complex for most banks. Articles 28 through 44 require financial entities to manage ICT third-party risk through a formal program that goes well beyond standard vendor management.
For each ICT third-party provider supporting a critical or important function, banks must:
- Conduct pre-engagement due diligence on the provider's security and resilience capabilities
- Negotiate contractual provisions covering data access rights, audit rights, exit strategies, and service level agreements
- Maintain a register of all third-party arrangements, accessible to supervisors on request
- Perform ongoing monitoring of third-party performance and risk exposure
The most significant new obligation is the direct supervision of CTPPs by the European Supervisory Authorities. Major cloud providers serving EU financial entities will be designated as CTPPs and subject to annual fees and oversight examinations. If your bank relies on AWS, Azure, or Google Cloud for critical functions, those relationships now carry regulatory weight on both sides.
If your bank relies on a CTPP, your contracts must include the mandatory provisions under DORA's Annex. Many existing cloud agreements do not meet this standard, and renegotiation takes time, often six to nine months when the provider is a large hyperscaler with standardized contract terms.
For open banking and API-driven architectures, third-party risk extends to API gateway providers, identity verification vendors, and payment orchestration platforms. The API security strategies for CISOs in banking your institution already applies need to be formally documented as part of this third-party register. Credential stuffing attacks against open banking APIs are a specific threat vector that DORA's detection requirements must address at the gateway layer.
Digital Operational Resilience Testing Requirements
DORA requires financial entities to run a structured testing program under Articles 24 through 27. At minimum, all entities must conduct basic resilience tests annually: vulnerability assessments, network security reviews, and scenario-based testing. Significant financial institutions must additionally conduct Threat-Led Penetration Testing (TLPT) at least every three years.
TLPT uses the TIBER-EU framework: a red team methodology that simulates sophisticated threat actors targeting the bank's live production environment. This is not a standard penetration test. It requires coordination between your ICT team, a threat intelligence provider, and the competent authority, and it typically takes 6 to 12 months from scoping to final report.
The honest position on TLPT readiness: most mid-tier banks are not there yet. The TIBER-EU methodology requires a level of threat intelligence maturity and red team coordination that is genuinely new for most institutions. If TLPT applies to your entity tier, start scoping now. The three-year cycle sounds long until you account for the preparation time.
Basic testing requirements are more achievable but still require formalization. If your vulnerability management program lacks documented scope, frequency, and remediation tracking tied to ICT risk, it does not satisfy DORA compliance requirements as written. Informal or ad hoc testing does not count.
How DORA Compliance Applies to Real-Time Payment Fraud
DORA compliance intersects with real-time payment fraud in two distinct ways. First, the regulation requires ICT continuity for payment processing systems, which means fraud detection infrastructure cannot be a single point of failure. Second, the fraud vectors specific to instant payment rails require detection capabilities that traditional rules engines structurally cannot provide, creating a direct ICT risk exposure.
FedNow, SEPA Instant, and UPI operate on sub-second settlement windows. Legacy fraud rules engines built for card processing can evaluate a transaction in 200 to 400 milliseconds, but they were designed with a buffer period for manual review after authorization. On instant rails, there is no callback window after settlement. The fraud loss is immediate and, in most cases, irrecoverable.
The failure mode is rule brittleness, not rule speed. A rules engine tuned for card-not-present fraud patterns will generate high false positive rates on push payment transactions, and low true positive rates on authorized push payment (APP) fraud, which dominates FedNow and SEPA Instant volumes. AI-based behavioral models trained on payment graph features have achieved 35 to 50% improvement in APP fraud detection rates over rules baselines without increasing false positives.
For DORA compliance specifically, your ICT business continuity plan must address payment system availability and define recovery procedures for fraud-related incidents. If your fraud detection system is a single point of failure in your payment authorization chain, a DORA gap assessment will surface it. Our analysis of AI-powered fraud detection strategy for risk heads covers the underlying model architecture that addresses these instant payment fraud challenges in detail.
AI Model Risk Management Under DORA
DORA does not mention AI explicitly, but it requires that all ICT systems supporting critical functions are subject to change management, testing, and ongoing monitoring. When those systems include machine learning models, this intersects with the Federal Reserve's SR 11-7 guidance on model risk management, which applies to US-supervised banks and which EU supervisors reference as a global benchmark for what good looks like.
SR 11-7 requires three things from AI models used in critical financial functions: conceptual soundness (the model is theoretically valid for its intended use), ongoing monitoring (performance is tracked against defined thresholds), and outcome analysis (predictions are checked against actual outcomes over time).
Explainability is where banks are getting stuck. A gradient boosting model or neural network that classifies a loan application or flags a transaction cannot simply output a score. Regulators expect the bank to explain why a specific decision was made for a specific customer. This is not only a GDPR Article 22 obligation covering automated decision-making for consumers. It aligns with SR 11-7 model validation standards, and DORA extends the same testing and change management logic to ICT systems supporting any critical function.
Practical approaches that satisfy both SR 11-7 and DORA's ICT change management requirements:
- SHAP (SHapley Additive exPlanations) values for feature-level attribution on individual model decisions
- Model cards documenting training data, intended use, known limitations, and performance benchmarks
- Challenger model programs that run shadow models alongside production models for continuous validation
- Formal model retirement and replacement procedures with supervisory documentation
Financial institutions that have adopted zero trust security architecture for banking operations are finding that the same governance discipline applies directly to AI model governance: document everything, verify continuously, and never assume inherited trust from a prior validation cycle.
DORA Compliance Checklist: 7 ICT Requirements to Meet Now
The table below consolidates the seven requirements with the highest remediation urgency in 2025. These are not the only DORA obligations, but they are the ones where most banks have documented gaps and where supervisory attention is focused in the first review cycle.
| Requirement | DORA Articles | Key Action Required |
|---|---|---|
| Board-approved ICT risk framework | 5-16 | Obtain board approval; document risk tolerance levels |
| ICT asset inventory | 8 | Map all assets supporting critical or important functions |
| Incident classification and reporting | 17-23 | Automate 4-hour initial notification workflow per EBA ITS |
| Third-party provider register | 28 | Build and maintain live register accessible to supervisors |
| CTPP contract compliance | 30 | Audit cloud agreements against mandatory DORA Annex provisions |
| Resilience testing program | 24-27 | Annual vulnerability assessments; TLPT scoping if applicable |
| ICT business continuity plan | 11-12 | Document RTOs and RPOs; test recovery procedures annually |
Banks that have already invested in DORA compliance automation for compliance officers have a head start on reporting workflows and third-party tracking. The gap for most institutions is testing maturity and AI model governance, both of which require time to build from the ground up.
For institutions handling cross-border transactions and trade finance, DORA's third-party oversight requirements align with the supply chain risk obligations covered in our cross-border trade compliance automation strategy. The underlying principle is identical: document the dependency, assess the risk, and maintain ongoing monitoring with evidence that survives supervisory review.
Onboard Customers in Seconds
Conclusion
DORA compliance is a substantial undertaking, but its seven ICT risk requirements are specific enough to be actionable. Start with the ICT risk management framework and asset inventory; without those foundations, a credible gap assessment is not possible. Move to third-party contracts next because renegotiation with hyperscalers takes months. Then build out the testing program, distinguishing between basic requirements that apply to all entities and TLPT obligations that apply to significant institutions.
The institutions that will struggle most are those treating DORA compliance as a documentation exercise rather than an operational shift. The regulation was designed to make financial infrastructure genuinely resilient. Fraud controls that cannot handle instant payment fraud patterns, AI models that cannot explain their decisions, and third-party contracts that do not meet DORA's Annex requirements will not satisfy a supervisory review regardless of how well the policies are written on paper.
Start with a structured gap analysis against the seven requirements above, tie your remediation priorities to the next supervisory calendar, and address the areas of highest exposure first. The preparation window is shorter than it looks.
Share this article