By Stuart Watkins, CEO, Zenoo
The Digital Operational Resilience Act (DORA) applies from 17 January 2025. If you are a financial entity in the EU, or a technology vendor serving EU financial entities, the clock is now measured in weeks rather than months. And if the conversations we are having with compliance and operations teams are anything to go by, a significant number of firms are not where they need to be.
DORA is not an AML regulation. It is an ICT risk management regulation. But it has profound implications for compliance teams because the technology infrastructure that supports your KYC, screening, and monitoring operations is squarely in scope. Your KYC vendor is an ICT third-party service provider. Your screening tool is an ICT system. Your case management platform, your sanctions list feed, your identity verification API: all within DORA's perimeter.
This article is focused on one specific question: what should compliance teams be asking their technology vendors right now?
DORA in 60 seconds
DORA establishes a comprehensive ICT risk management framework for financial entities across the EU. It applies to banks, insurance companies, investment firms, payment institutions, e-money institutions, crypto-asset service providers, and a broad range of other financial entities.
The regulation has five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. For compliance teams, the most immediately relevant pillars are ICT risk management (because your compliance systems are ICT systems) and ICT third-party risk management (because your vendors are ICT third-party service providers).
The key distinction from previous regulations is that DORA creates specific, binding requirements for how financial entities manage their technology risk. Previous guidance was often principles-based and open to interpretation. DORA is prescriptive.
Your KYC vendor is now an ICT third-party service provider
Under DORA, any third party that provides ICT services to a financial entity is subject to the regulation's third-party risk management requirements. This includes cloud service providers, data analytics firms, software vendors, and, crucially, the companies that provide your KYC, screening, and monitoring technology.
For compliance teams, this means your vendor relationships need to be reassessed through DORA's lens. The regulation requires financial entities to maintain a register of all ICT third-party service providers, assess the risks associated with each, and ensure that contractual arrangements include specific provisions on security, data access, audit rights, and exit strategies.
"We mapped our ICT third-party service providers and found 14 vendors supporting our compliance operations alone. Screening, identity verification, document checking, case management, sanctions list feeds, adverse media, PEP databases, ongoing monitoring, risk scoring. Each one is an ICT third party under DORA, and each one needs a contractual review."
The contractual requirements are detailed. DORA Article 30 sets out specific provisions that must be included in contracts with ICT third-party service providers, including service level descriptions, data processing locations, provisions for termination, and audit and access rights. If your current vendor contracts do not include these provisions, they need to be renegotiated before January 2025.
Concentration risk: the compliance technology edition
DORA pays particular attention to ICT concentration risk. If multiple critical functions depend on the same vendor, that concentration presents a systemic risk. Sound familiar? This is the same single-point-of-failure problem we have been discussing in the context of KYC operations, now codified in regulation.
The regulation requires financial entities to assess ICT concentration risk at the entity level and to consider the substitutability of each critical ICT third-party service provider. In plain language: if your KYC provider goes down, can you keep operating? If your screening tool becomes unavailable, what is your fallback? If your case management system is compromised, can you continue processing and documenting compliance decisions?
For many compliance teams, the honest answer to these questions is uncomfortable. Most firms have a single KYC provider, a single screening tool, and a single case management platform. DORA does not prohibit this, but it requires you to have assessed the concentration risk and to have documented your risk mitigation measures, including exit strategies and substitution plans.
Incident reporting: the 72-hour window
DORA requires financial entities to report major ICT-related incidents to their competent authority. The timeline is tight: an initial notification within 4 hours of classifying the incident as major, an intermediate report within 72 hours, and a final report within one month.
For compliance teams, this matters because incidents affecting your compliance technology could constitute major ICT-related incidents. A sustained outage of your sanctions screening system. A data breach affecting customer due diligence records. A failure in your ongoing monitoring platform that creates a gap in surveillance. Each of these could trigger the incident reporting obligation.
The practical implication is that your incident management framework needs to include your compliance technology vendors. You need to know, quickly, when a vendor is experiencing an incident. You need to be able to assess whether that incident is major. And you need pre-agreed communication channels and escalation procedures that work within the 4-hour notification window.
"We asked our three main compliance technology vendors whether they could commit to notifying us within one hour of a service-affecting incident. One said yes. One said they would try. One said they would notify us 'in accordance with their standard SLA,' which turned out to be 24 hours. That was the conversation that triggered our vendor review."
The questions to ask your vendors now
Based on DORA's requirements and our experience helping compliance teams assess their vendor relationships, here are the questions you should be putting to your compliance technology vendors today.
1. Do you have a documented ICT risk management framework? DORA requires your vendors to manage their own ICT risks effectively. Ask to see their framework, not just a high-level summary, but the actual risk management documentation.
2. What are your incident notification procedures? Specifically, how quickly will you notify us of an incident that affects our services? What information will the notification include? How will ongoing updates be communicated?
3. Can you provide audit and access rights consistent with DORA Article 30? The regulation requires that contracts include provisions for the financial entity (or a third party appointed by them) to conduct audits and inspections of the vendor. Some vendors resist this. If yours does, that is a red flag.
4. What are your business continuity and disaster recovery arrangements? Ask for specifics: recovery time objectives, recovery point objectives, and testing frequency. A vendor that cannot articulate these has not done the work.
5. Where is our data processed and stored? DORA requires financial entities to know where their data is being processed. If your vendor uses sub-processors or cloud infrastructure in multiple locations, you need to understand the full chain.
6. What is your approach to exit management? DORA requires that contracts include exit provisions that ensure the financial entity can migrate to another provider without disruption. Ask your vendor how they support exit and data portability. If the answer is vague, plan accordingly.
7. How do you handle sub-outsourcing? If your vendor uses third parties to deliver parts of their service, DORA requires that you understand and have oversight of those arrangements. Ask for a list of material sub-contractors and the services they provide.
The orchestration advantage
One of the most practical ways to address DORA's ICT concentration risk requirements is to move from single-vendor dependency to an orchestrated, multi-provider approach. If your KYC, screening, or monitoring operations are spread across multiple providers through an orchestration layer, the failure of any single provider does not halt your operations.
This is not just good operational practice. It is directly responsive to DORA's requirements. An orchestrated approach with automatic failover between providers demonstrates that you have assessed concentration risk and implemented effective mitigation. It also simplifies exit management because migrating away from one provider within an orchestration stack is significantly less disruptive than migrating away from your only provider.
We built Zenoo's orchestration platform with exactly this kind of resilience in mind. Multiple providers behind a single integration point, with automatic routing and failover. When one provider experiences an incident, traffic routes to alternatives. When you need to exit a provider relationship, you switch routing without rebuilding integrations.
