DORA compliance: what financial entities need from their technology vendors

What is DORA?

DORA is the Digital Operational Resilience Act. It is an EU regulation, applied directly across all 27 member states, that sets binding rules on how financial entities manage their information and communication technology risk. It has been in force since 17 January 2025.

DORA does five things that previous national frameworks did not do uniformly:

• Sets an ICT risk management framework that financial entities must implement, with named board-level responsibility.
• Requires structured incident reporting on tight deadlines, including for cyber threats.
• Mandates digital operational resilience testing (including, for larger entities, threat-led penetration testing every three years).
• Defines a third-party risk management framework that brings ICT vendors into the regulatory perimeter, contractually.
• Creates a direct EU oversight regime for designated critical ICT third-party service providers.

Why your KYC vendor is now part of your regulatory perimeter

The change most compliance teams are still catching up with: every technology vendor providing services that support your business operations is an ICT third-party service provider (ICT TPP) under DORA. That includes KYC, AML monitoring, case management, identity verification, orchestration platforms, and pretty much every SaaS tool in your compliance stack.

You are now responsible for:

• Pre-contractual due diligence on every ICT TPP, with documented risk assessments.
• Contractual provisions that meet DORA's prescribed clauses (see below).
• Ongoing oversight with documented monitoring activities and periodic risk reviews.
• Concentration risk management, including assessment of provider substitutability.
• Exit strategies with documented transition plans, tested where critical.

For most firms, this is a substantial expansion of the vendor management function. The teams we work with are typically running 20-50 ICT TPP assessments in the first DORA cycle.

Standard ICT TPP vs Critical ICT TPP

DORA distinguishes two classes of vendors. Standard ICT TPPs are managed entirely through the financial entity's contractual oversight. Critical ICT TPPs (CTPPs) are designated by the European Supervisory Authorities based on systemic importance, substitutability, and the financial entity's reliance on the service. CTPPs are subject to direct EU oversight via a Lead Overseer, who can examine them, request information, and impose penalty payments for non-cooperation.

Most compliance vendors, including KYC and AML platforms, are standard ICT TPPs. Cloud hyperscalers, core banking platforms, and dominant market infrastructure providers are more likely to be designated critical. Your vendor management function needs to know the difference, and the contractual obligations differ.

What DORA requires in your vendor contracts

Most pre-DORA MSAs are now non-compliant. Specifically, DORA requires that ICT TPP contracts include, as a minimum:

• A clear description of the service, including locations where the service is provided and data is processed.
• Data protection and access provisions, including data ownership, return, and deletion on termination.
• Full access rights for the financial entity, its auditors, and competent authorities, with no contractual restrictions on the scope of the right of access, inspection, and audit.
• Service level agreements, with quantitative performance targets and reporting.
• Incident reporting and cooperation obligations, with timelines compatible with DORA's incident reporting deadlines.
• Subcontracting provisions, including notification of new subcontractors and the financial entity's right to object.
• Exit strategies and transition assistance, with documented procedures and tested recovery points.
• For services supporting critical or important functions, additional clauses on cooperation with the Lead Overseer, business continuity, and resolution.

The teams we work with are typically rewriting MSAs in two waves: first for critical-function vendors (where the regulator is going to look closely), then for the wider portfolio.

Incident reporting: the deadlines you cannot miss

DORA's incident reporting requirements force a structural change in how you and your vendors communicate. Financial entities must report major ICT-related incidents to their competent authority within these deadlines:

• Initial notification: within 4 hours of classifying the incident as major.
• Intermediate report: within 72 hours of classification, with structured technical detail.
• Final report: within one month, including root cause analysis and remediation.

That timeline only works if your vendors give you enough information, fast enough, to meet it. Most contracts pre-DORA gave vendors 48-72 hours to acknowledge an incident. That clock is now incompatible. Vendor incident notification SLAs need to land within a window that lets you classify, escalate, and report inside 4 hours. The compliance teams we see succeeding here have vendor incident notification clauses requiring confirmation within 1 hour of detection for major incidents.

The DORA vendor checklist: questions to ask before you sign

1. Can you provide a current ICT risk assessment and the underlying control framework? No assessment = no deal.
2. What is your incident notification SLA, and what information do you commit to provide in the initial notification? 1 hour is the bar for critical functions.
3. How do you handle subprocessors and what is your notification process for adding new ones? DORA requires you have the right to object.
4. What is your data location, and can you guarantee processing within specified jurisdictions? Particularly for non-EU vendors.
5. What is your exit strategy, and how do you support transition to another provider? Vague answers indicate lock-in risk.
6. Can you support our right of access, audit, and inspection, including by competent authorities? This must be in writing.
7. What are your testing and resilience commitments, including business continuity and disaster recovery? Documented and tested, with recovery point and time objectives.

The firms that proactively work through this list with existing vendors, instead of waiting for the regulator to ask, are the ones that finish their DORA programmes calmly. The ones who treat DORA as someone else's problem will find out that it is very much theirs.

How Zenoo helps with DORA compliance

Zenoo is built to be a DORA-grade ICT TPP. The platform documents the controls, contractual provisions, and operational practices that financial entities need to satisfy DORA's third- party risk requirements. Specifically:

• Incident response: documented procedures, 1-hour critical incident notification, structured intermediate updates that map to DORA's reporting templates.
• Audit and access: every workflow generates an immutable trail. Compliance Hub exports a regulator-ready audit pack on demand.
• Exit and portability: orchestration architecture means you can swap underlying KYC, AML, or screening providers without changing your workflow. Zenoo Marketplace is 53 vendors deep.
• Subprocessor transparency: documented subprocessor list with notification commitments.
• Service location and data residency: configurable per jurisdiction.
• Implementation: 4 to 6 weeks, not 12-month integration projects.

Related reading

• DORA countdown: what compliance teams need from their vendors
• Why your KYC vendor is a single point of failure
• The vendor lock-in trap: signs you are stuck
• AMLA compliance: the EU's new AML rulebook

Frequently asked questions

What is DORA?

DORA is the Digital Operational Resilience Act, an EU regulation that sets binding rules on how financial entities manage ICT risk and oversee their technology vendors. It applies from 17 January 2025 across all 27 EU member states and replaces fragmented national approaches to operational resilience.

Who does DORA cover?

DORA applies to banks, investment firms, insurance and reinsurance undertakings, payment institutions, e-money issuers, crypto-asset service providers, trading venues, central counterparties, central securities depositories, and several other financial entity categories. It also applies, indirectly via contractual obligations, to ICT third-party service providers serving those entities.

Is my KYC vendor a DORA third-party service provider?

Yes. Any technology vendor that provides services supporting your business operations, including KYC, AML monitoring, identity verification, and case management, is an ICT third-party service provider under DORA. You are now responsible for assessing, contracting, and overseeing them according to DORA's requirements.

What is the difference between standard and critical ICT TPP?

Standard ICT TPPs are governed by your firm's contractual oversight under DORA. Critical ICT TPPs (CTPPs) are designated by the European Supervisory Authorities based on systemic importance and are subject to direct EU oversight via a Lead Overseer. Most KYC vendors are standard ICT TPPs; cloud hyperscalers and core banking platforms are more likely to be designated critical.

What does DORA require from my vendor contracts?

Contracts must include service descriptions and locations, data protection and access provisions, full access rights for the firm and its auditors and competent authorities, exit strategies and transition assistance, performance targets and incident reporting obligations, and for critical functions, additional clauses on subcontracting, audit cooperation, and resolution. Old MSAs almost always need updating.

What incident reporting does DORA require?

Financial entities must report major ICT-related incidents to their competent authority within tight deadlines: initial notification within 4 hours of classification, intermediate report within 72 hours, and final report within one month. Significant cyber threats must also be reported. Your vendors need to provide enough information, fast enough, that you can meet these deadlines.

What are the DORA penalties?

DORA gives competent authorities powers to impose administrative penalties and remedial measures, with member states setting specific amounts. Indicative ceilings reach 1% of average daily worldwide turnover for some breaches. For critical ICT TPPs, the Lead Overseer can impose periodic penalty payments up to 1% of average daily worldwide turnover until compliance is achieved.

How does Zenoo help with DORA compliance?

Zenoo is designed for DORA-grade resilience: documented incident-response procedures with within-deadline reporting, full audit trails on every workflow, contractual provisions aligned to DORA's requirements, exit strategies and data portability built in, and orchestration that lets you swap underlying providers without engineering work. Implementation in 4 to 6 weeks.