DORA and KYC: Identity Vendors Are Now ICT Third Parties

When the Digital Operational Resilience Act (DORA) entered full application on January 17, 2025, most compliance teams were focused on the obvious: incident reporting timelines, penetration testing programmes, and ICT risk management frameworks. Identity verification vendors were barely mentioned in the implementation conversations.

That gap is closing fast. Eighteen months into DORA's application, regulators and internal audit teams are now scrutinising the third-party providers that financial firms depend on for continuous operations — and KYC platforms sit squarely in that category. For any CASP, bank, payment institution, or investment firm using an external identity verification provider, DORA has already changed what that relationship must look like contractually, operationally, and from a risk management standpoint.

What DORA Actually Requires

DORA (EU Regulation 2022/2554) establishes a harmonised framework for ICT risk across the EU financial sector. It applies to banks, insurers, investment firms, crypto-asset service providers (CASPs) under MiCA, payment institutions, and e-money institutions — plus the ICT providers that support them.

The regulation rests on five pillars:

1. ICT risk management — documented risk frameworks, asset registers, and recovery plans
2. ICT incident reporting — classification and notification to national competent authorities (NCAs) within defined timelines
3. Digital operational resilience testing — regular testing including Threat-Led Penetration Testing (TLPT)
4. ICT third-party risk management — structured assessment of all service providers
5. Information sharing — voluntary exchange of threat intelligence

For KYC, the fourth pillar is decisive. Article 28 of DORA requires financial entities to maintain a complete register of ICT third-party service providers. Article 30 sets out mandatory contractual elements for every agreement with those providers. And Articles 31–44 establish a designation process for providers deemed "critical" — those that, if they failed, would have systemic effects on the financial sector.

Why KYC Vendors Fall Under ICT Third-Party Rules

An identity verification platform is not a payment processor or a core banking vendor in the traditional sense. But it is an ICT third-party service provider under DORA's definition: any undertaking providing digital and data services on an ongoing basis to financial entities, including cloud platforms, data analytics, software as a service, and any service component that supports business processes.

That definition covers virtually every externally hosted KYC solution.

The operational test is straightforward: if your identity verification vendor went offline at 09:00 on a Monday morning, could you continue to onboard customers, complete re-verification checks, or process transactions requiring identity confirmation? For most financial firms, the answer is no — or not without significant operational disruption. That dependency makes the vendor ICT-critical to the firm's resilience posture.

Under Article 30, every contract with such a vendor must now include:

Contractual Requirement	Purpose Under DORA
Full description of services and data locations	Know where processing occurs and which jurisdictions apply
Service level agreements with defined performance metrics	Baseline for monitoring and incident escalation
Accessibility of data upon termination	Exit strategy support
Participation in DORA resilience testing (where applicable)	TLPT inclusion rights
Sub-processor disclosure	Third and fourth party risk visibility
Audit rights and right to inspect	Direct oversight by financial entity or designated third party
Incident notification timelines	Co-ordinated reporting to NCAs
Business continuity provisions	Vendor-side recovery obligations

If your current KYC vendor agreement was signed before January 2025 and has not been renegotiated, it almost certainly does not contain all of these elements. That is now a compliance gap.

The Critical ICTPSP Designation — And What It Means for Identity Vendors

Under Articles 31 to 44, the Joint Committee of the European Supervisory Authorities (ESAs — EBA, EIOPA, and ESMA) designates certain ICT providers as "critical ICT third-party service providers" (CICTPSPs). These providers are subject to direct oversight by a designated Lead Overseer from one of the ESAs.

The designation criteria include concentration risk (how many financial entities depend on the provider), cross-border systemic relevance, and criticality to regulated functions. Large identity verification platforms serving hundreds of banks and CASPs across the EU are plausible candidates for designation.

Designation has real operational consequences:

• Lead Overseer access: The designated ESA can request documents, conduct on-site inspections, and issue recommendations
• Remediation obligations: Financial entities must ensure their critical providers comply with ESA recommendations within defined timelines
• Exit strategy requirements: Financial entities must maintain credible plans to migrate away from a critical provider if required

For compliance teams, this means vendor due diligence is no longer a one-time procurement exercise. It is a continuous obligation. The same shift from periodic to continuous monitoring that defines perpetual KYC applies equally to vendor risk management under DORA.

CASPs Face Double Exposure

Crypto-asset service providers under MiCA already operate under a dense regulatory stack. MiCA's Travel Rule obligations require CASPs to transmit originator and beneficiary information for every crypto-asset transfer. Meeting those obligations depends on continuous access to identity data — which in most cases means an external KYC platform.

DORA adds a second layer. CASPs are in scope as financial entities under DORA. Their identity verification vendors are in scope as ICT third parties. The intersection creates compounded obligations: the CASP must comply with MiCA's KYC requirements, and it must also ensure that the KYC platform delivering that compliance meets DORA's resilience standards.

The post-MiCA enforcement environment has already raised the bar for crypto-KYC quality. DORA raises the bar for crypto-KYC resilience. CASPs that have ticked the MiCA box but haven't reviewed their KYC vendor contracts under DORA's Article 30 framework are sitting on a second compliance exposure.

What Financial Firms Must Do Before Year-End

The ESAs published their final guidance on the DORA third-party risk management framework in mid-2025. By August 2026, most large financial entities should have completed their initial ICT third-party risk assessments and renegotiated contracts. Smaller firms — particularly payment institutions and e-money institutions — have been slower, and the gaps are showing up in supervisory dialogue.

A practical checklist for compliance teams reviewing their KYC vendor arrangements:

Inventory and classification

• Is the identity verification vendor in your DORA third-party register?
• Has it been classified by criticality tier (critical, important, or standard)?
• Are all sub-processors and downstream data handlers documented?

Contractual review

• Does the contract include the Article 30 mandatory elements?
• Are audit rights explicit and exercisable (not just "reasonable notice")?
• Is there a documented exit strategy with defined data portability terms?

Ongoing monitoring

• Are KPIs and SLAs being tracked and reported against?
• Is there a process to escalate vendor performance degradation to the risk committee?
• Has the vendor provided evidence of its own ICT risk management framework?

Incident response

• Does the vendor have an obligation to notify you within DORA-compatible timelines?
• Is there a joint incident response protocol tested at least annually?

The Argument for Agentic Monitoring

Manual vendor risk management does not scale. A compliance team managing ten ICT third-party providers with quarterly review cycles will find it impossible to maintain real-time visibility into each provider's operational status, security posture, and SLA performance. This is precisely where AI agents in compliance offer a structural advantage.

Agentic systems can monitor vendor SLA performance continuously, flag anomalies in processing times or failure rates, track public disclosures and regulatory filings by third-party providers, and trigger escalation workflows when pre-defined thresholds are breached. The same AI logic that makes agentic KYC effective at continuous customer monitoring applies directly to continuous vendor monitoring.

DORA does not mandate specific tools. But it does mandate continuous processes — and continuous processes, at scale, require automation.

Enforcement Is Coming

The first DORA supervisory cycle by NCAs across the EU is now underway. The ESAs are consolidating third-party registers to identify concentration risk patterns. Firms that have not renegotiated their KYC vendor contracts, maintained their third-party registers, or established ongoing monitoring programmes are increasingly visible to supervisors.

The enforcement consequences are not trivial. DORA gives NCAs the power to impose:

• Periodic penalty payments of up to 1% of average daily worldwide turnover for non-compliance by financial entities
• Temporary bans on the use of ICT services from non-compliant critical providers
• Public disclosure of infringements

For smaller fintechs and CASPs, the reputational damage of public disclosure may exceed the financial penalty. The EU AI Act's KYC compliance requirements have already focused board attention on technology governance in identity systems. DORA adds operational resilience to that governance agenda.

What to Ask Your KYC Vendor Now

The most direct action financial firms can take is to engage their identity verification vendors with a structured set of DORA-related questions. Vendor responses reveal both the vendor's own compliance posture and the gaps in your existing contractual framework:

• Do you have a documented ICT risk management framework aligned with DORA?
• What is your major ICT incident classification and notification timeline?
• Have you been subject to, or do you anticipate being subject to, ICTPSP designation review?
• Can you provide a register of your material sub-processors and their geographic locations?
• What audit rights can you offer — documentary, remote, or on-site?
• What business continuity commitments can you make for identity verification availability?
• Do you have a published penetration testing programme?

Vendors that cannot answer these questions clearly are not DORA-ready. And if your vendor is not DORA-ready, your firm's reliance on them is a documented risk that supervisors will find.

---

FAQ

Does DORA apply to non-EU KYC vendors serving EU financial firms?

Yes. DORA's third-party risk rules apply based on where the financial entity is regulated, not where the vendor is based. An EU bank using a US-based identity verification platform must still ensure that platform meets DORA's Article 30 contractual requirements and participates in applicable testing regimes.

When does DORA's critical ICTPSP designation affect my firm?

Once a provider is designated critical, the financial entities using it must ensure compliance with the Lead Overseer's recommendations. The initial designation list was published by the ESAs in 2025. Financial firms should check whether any of their ICT providers appear on that list.

Is a KYC platform always an "ICT third-party service provider" under DORA?

DORA's definition is broad: any undertaking providing ICT services to a financial entity on a continuous basis. An identity verification platform delivering services via API or SaaS model falls within this definition. On-premises solutions where the financial entity controls all infrastructure may be treated differently, but cloud-hosted or hybrid deployments are generally in scope.

What are the consequences for a financial entity if its KYC vendor has a major outage?

Under DORA, a major outage by a critical ICT third-party provider that causes operational disruption to a financial entity's regulated activities triggers incident reporting obligations. The financial entity must notify its NCA within the defined timeline (initial notification within 4 hours of classification, intermediate report within 72 hours, final report within one month). Failure to report is itself a DORA violation.

Can an AI agent help with DORA vendor monitoring?

Yes. Agentic systems can monitor SLA performance, flag degradation in vendor response times, track public incident disclosures by third-party providers, and trigger automated escalations. This does not replace the human governance obligations under DORA — risk committee oversight and audit rights remain human-driven — but it significantly enhances the continuous monitoring posture that DORA requires.

Does DORA interact with GDPR for KYC data processed by third parties?

Yes, and the interaction creates dual obligations. Under GDPR, identity data processed by a KYC vendor is subject to data processing agreement requirements and data transfer rules. Under DORA, the same vendor relationship is subject to ICT third-party risk management obligations. Both frameworks must be satisfied simultaneously, which typically means a combined vendor agreement covering GDPR Article 28 DPA terms and DORA Article 30 contractual elements.