Financial institutions operating in the EU must comply with DORA requirements as of 17 January 2025. The regulation defines clear expectations across: ICT risk management, third-party oversight, incident reporting, and resilience testing that function together as a unified control framework.
But moving from regulatory text to operational reality is where many institutions encounter challenges. Translating DORA’s five pillars into defensible processes, contracts, registers, and governance structures requires practical clarity that policy papers alone can’t provide, especially as AI adoption expands the ICT surface area within scope.
This article breaks down each of DORA’s five pillars, identifies where the real compliance gaps tend to form, and lays out a practical action plan for meeting the requirements without stalling AI adoption or business momentum.
Key Takeaways
- DORA requires EU financial entities to demonstrate ICT risk management, incident response, resilience testing, and third-party oversight function together as an operational control system.
- The five pillars of compliance are ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing.
- AI complicates matters by introducing tools, vendors, and failure modes that may fall outside existing inventories, monitoring, and governance processes yet remain within DORA’s scope.
- The most practical path is to fix visibility first: identify AI usage, connect it to DORA controls, broaden detection and testing, and strengthen third-party records and contracts to ensure evidence remains defensible.
What Is DORA?
The Digital Operational Resilience Act (DORA) is an EU regulation that ensures banks, insurance companies, investment firms, and other financial entities can withstand and recover from ICT disruptions, such as cyberattacks or system failures. It establishes a unified, mandatory framework for ICT risk management across financial entities operating in the EU.
Before DORA, ICT risk rules were fragmented along sector-specific lines, with no EU-wide mechanism for pan-European oversight of critical ICT providers. DORA closes that gap.
Formally Regulation (EU) 2022/2554, the regulation applies to more than 20 types of financial entities spanning banks, insurers, investment firms, payment institutions, crypto-asset service providers, and other regulated firms. ICT third-party service providers also fall within scope, and a subset designated as Critical Third-Party Providers (CTPPs) is subject to direct oversight by the European Supervisory Authorities.
Competent authorities designated by each EU Member State enforce the regulation, with penalties including administrative fines and remedial measures.
The Five Pillars of DORA Compliance
DORA is structured around five interconnected pillars. Each addresses a distinct area of ICT governance, but weaknesses in one can quickly expose the others. The sections below break down what each pillar requires and where compliance gaps tend to form.
1. ICT Risk Management
ICT risk management is the structural foundation of DORA. The ICT risk management framework under Articles 5–16 assigns the management body ultimate responsibility for ICT risk. Boards can’t delegate accountability to IT or risk functions. Compliance requires maintaining a sound, comprehensive, and well-documented ICT risk management framework, which is reviewed and updated following significant ICT-related issues, testing, or audit outcomes.
The framework is organized around five functions: identify and classify ICT assets; protect and prevent; detect through monitoring and logging; respond and recover; and learn through post-incident reviews.
2. Incident Reporting
DORA’s incident reporting rules are strict, time-bound, and operationally demanding. Institutions need detection and classification processes that move quickly enough to support the reporting clock once a major incident is identified, creating accountability and enabling supervisory oversight when critical services are affected.
The requirements operate on a three-stage timeline, with the clock starting the moment a financial entity classifies an ICT-related incident as major.
- The initial notification must be filed within 4 hours of classification and no later than 24 hours of becoming aware of the incident.
- An intermediate report is issued within 72 hours of the initial notification, covering the cause of the incident, classification details, and economic impact.
- A final report is due within one month of the intermediate report and should include root cause analysis, lessons learned, and any other relevant information.
An incident qualifies as major when critical services are affected and either unauthorized access to network and information systems is identified, which automatically triggers reporting regardless of other factors, or the thresholds of two additional criteria are met. Those criteria include client impact, data losses, service downtime, and economic impact.
3. Digital Operational Resilience Testing
DORA requires institutions to conduct regular, risk-based resilience testing at least annually to validate that ICT systems and controls actually work under stress. All financial entities must establish a digital operational resilience testing program and ensure that annual tests are conducted on ICT systems and applications that support critical functions. Requirements are applied proportionately based on an entity’s size, significance, and risk profile.
Test types include vulnerability assessments, network security assessments, physical security reviews, source code reviews, and penetration testing. These tests may be done internally or externally.
The second tier, Threat-Led Penetration Testing (TLPT), applies to significant entities designated by competent authorities and must be conducted every three years. TLPT is an intelligence-led red-team test of critical live production systems that simulates the tactics, techniques, and procedures of real threat actors.
- TLPT scope must cover critical functions, including outsourced functions.
- The RTS introduces purple-team testing and provisions allowing internal testers under specific conditions, both of which depart from the original TIBER-EU framework.
4. Third-Party Risk Management
Financial entities must manage ICT third-party risk as an integral component of their overall ICT risk management framework, with the management body adopting a dedicated third-party risk strategy.
DORA requires full visibility into these relationships through contractual controls, a formal information register, and ongoing concentration risk assessments.
- Register of Information — The Register of Information requirement under Article 28(3) requires financial entities to maintain and update a complete register of all contractual arrangements with ICT third-party service providers, distinguishing between those covering critical or important functions and those that don’t.
- Concentration Risk — Concentration risk assessment under Article 29 requires evaluating whether a provider would be difficult to replace.
- Contractual Requirements — Article 30 adds another layer. From July 22, 2025, firms must document multi-tier subcontracting chains.
5. Information Sharing
Information sharing is DORA’s only voluntary pillar, but it still creates concrete compliance obligations. Under Article 45, financial entities may exchange cyber threat information and intelligence, including indicators of compromise, tactics, techniques, and procedures, cybersecurity alerts, and configuration tools within trusted communities while protecting business confidentiality.
The binding hook is Article 45(3). Any decision to participate in or leave an information-sharing arrangement triggers formal compliance obligations, making this voluntary pillar operationally binding in practice.
Can You Prove How Your Organization Governs AI? WitnessAI generates granular audit trails, enforces policies across every role and region, and redacts sensitive data before it ever leaves your network. Compliance-ready from day one. See How Control Works
Runtime AI Threats Need Runtime Defense.
WitnessAI’s enterprise AI firewall delivers bidirectional runtime defense, blocking prompt injections, jailbreaks, and data exfiltration before they reach your models or your customers.
Explore ProtectWhere AI Adoption Creates New DORA Compliance Challenges
DORA’s five pillars were designed to cover the full ICT environment, but AI adoption is expanding it faster than most compliance programs can keep up. AI tools, models, and agent-based systems introduce ICT dependencies and vendor relationships that span all pillars simultaneously, often without appearing in existing inventories or governance structures.
The challenge starts with visibility. AI adoption often occurs outside formal procurement channels: teams adopt third-party models, integrate with external APIs, or deploy AI-powered tools without undergoing security or compliance reviews. This shadow AI creates blind spots in the Article 8 asset inventory, the Article 28(3) Register of Information, and Article 29 concentration risk assessments. If a tool isn’t tracked, it becomes significantly harder to govern.
AI also introduces failure modes that traditional ICT monitoring wasn’t built to catch. Model hallucinations, data poisoning, prompt injection, and unauthorized AI-to-AI interactions may not be reliably detected by conventional incident detection workflows. If these disruptions affect critical functions, the 4-hour reporting clock still applies, but institutions may not detect the incident fast enough to report it.
On the third-party side, AI vendors often operate through layered subcontracting chains and shared infrastructure that concentrate risk in ways that aren’t immediately visible. A single foundation model provider may underpin multiple AI tools across different business units, creating exactly the kind of concentration exposure DORA requires institutions to assess.
The result is that institutions can have mature DORA compliance programs and still carry unmanaged risk simply because AI sits outside what those programs can see and control. Closing that gap typically requires structured action across all five pillars, starting with the steps outlined below.
Your Employees Use 5x More AI Tools Than You Think WitnessAI scans your entire network to catalog every AI app, agent, and conversation. No endpoint clients or browser extensions required. See How Observe Works
Can You Prove How Your Organization Governs AI?
WitnessAI generates granular audit trails, enforces policies across every role and region, and redacts sensitive data before it ever leaves your network. Compliance-ready from day one.
See How Control WorksHow to Meet DORA Compliance Requirements
Meeting DORA’s requirements in practice means solving the visibility problem first. Below are the steps to follow:
- Build a complete AI and ICT asset inventory. Identify every AI tool, model, and agent in use, including shadow AI adopted outside formal procurement. Untracked AI may fall outside the Article 8 ICT asset inventory and be missing from the Article 28(3) register and Article 29 concentration-risk assessments.
- Map AI systems to DORA’s five-function ICT risk management framework. Connect each AI tool, model, and vendor relationship to the identify, protect, detect, respond, and learn functions under Articles 5–16. This ensures AI-related risks are assessed and documented within the same governance structure as the rest of your ICT estate.
- Extend incident detection to cover AI-specific failure modes. Ensure monitoring and classification processes account for AI-driven disruptions, including model failures, data poisoning, and unauthorized AI access. Detection must be fast enough to meet the 4-hour initial notification window once a major incident is classified.
- Include AI systems in resilience testing programs. AI tools supporting critical functions should be included in your annual testing cycle, including vulnerability assessments and, where applicable, Threat-Led Penetration Testing. Don’t leave AI out of scope simply because it was adopted recently.
- Remediate contracts with AI providers. Update third-party agreements to include DORA-required provisions on audit rights, exit strategies, subcontracting chain transparency, and data location. Ensure every AI vendor relationship is captured in the Article 28(3) Register of Information.
- Establish ongoing monitoring and governance. DORA compliance is continuous. Maintain real-time visibility into AI usage, consistently enforce policies, and generate audit-ready evidence as your AI footprint evolves.
WitnessAI is a unified AI security and governance platform that supports financial institutions in operationalizing these requirements by providing visibility, policy enforcement, and runtime protection aligned to DORA control expectations. It provides network-level visibility to discover shadow AI and build a complete AI inventory; intent-based policy controls to enforce governance across employees and AI agents; and runtime defense to detect and help mitigate threats such as prompt injection and data exfiltration in real time.
With granular audit trails, real-time redaction of sensitive data, and a single-tenant architecture built for regulated industries, WitnessAI gives security and compliance teams the evidence and controls they need to meet DORA requirements without slowing AI adoption.
Compliance Deadline to Operational Discipline
DORA compliance isn’t a one-time project. It’s an ongoing operational discipline that must evolve alongside supervisory expectations and AI adoption. Institutions that treat AI risk management as inseparable from ICT risk management, not as a separate governance stream,
Learn more about how WitnessAI can help you become compliant with DORA requirements.