Two Compliance Horizons: What the EU’s 96% DORA Failure Rate Means for the Gulf

The statistic from the Span Cyber Security Arena conference deserves attention beyond Europe. Ninety-six percent of financial services firms in EMEA — including those headquartered in or operating from the Gulf — report that their data resilience does not yet meet DORA’s requirements. That is the near-consensus position of an industry that has invested heavily in compliance infrastructure. The failure rate is not about resources. It is about architecture.

For organisations across the GCC with European operations, EU client data, or EU data subjects, this statistic is not a European headline. It is an operational status report. DORA does not care where an ICT service provider is incorporated. If you provide critical or important ICT services to an EU-regulated financial entity, your compliance posture is subject to review under DORA’s framework.

The organisations I work with across the Gulf are navigating compliance pressure from two directions simultaneously. The EU’s three-framework wave — NIS2, DORA, and the EU AI Act — is pressing in from their European operations. And GCC data protection frameworks are maturing at significant pace from the domestic side.

The UAE Personal Data Protection Law, effective September 2023, establishes consent and data subject rights obligations that parallel GDPR in many respects. Saudi Arabia’s Personal Data Protection Law, with its 2024 implementing regulations, creates parallel obligations for organisations handling Saudi nationals’ data. Qatar’s Personal Data Privacy Protection Law adds a third GCC jurisdiction with formal data protection requirements. Organisations with operations across multiple GCC countries face a domestic multi-framework compliance environment that mirrors, in structure if not in detail, what their European counterparts face with NIS2, DORA, and the AI Act.

The compliance mathematics are not additive. EU frameworks, GCC frameworks, and sector-specific requirements from financial regulators such as SAMA, CBUAE, and the QCB produce a compliance workload that multiplies rather than sums — particularly when each framework demands its own documentation format, its own audit evidence, and its own incident notification procedures.

5 Key Takeaways

1. The 96% DORA failure rate is not a European headline — it is an operational status report for Gulf organisations.

Ninety-six percent of financial services firms in EMEA report that their data resilience does not yet meet DORA‘s requirements. If your organisation provides critical ICT services to EU-regulated financial entities — regardless of where you are incorporated — your compliance posture is subject to review under that framework. The failure rate is not about resources. It is about architecture.

2. Gulf organisations face compliance pressure from two directions simultaneously.

The EU’s three-framework wave — NIS2, DORA, and the EU AI Act — presses in from European operations. UAE, Saudi, and Qatari data protection laws are maturing from the domestic side. The compliance mathematics are not additive: EU frameworks, GCC frameworks, and sector-specific financial regulator requirements produce a workload that multiplies, not sums.

3. Fragmented audit infrastructure fails both horizons simultaneously.

61% of organisations have fragmented audit logs across multiple systems. In a dual-horizon environment, fragmented logs mean that every audit cycle requires the same evidence reconstruction effort — against two different sets of regulatory expectations, with two different evidence formats. A DORA supervisor and a Saudi PDPL auditor are asking for the same underlying records through different vocabularies.

4. An AI agent operating outside its intended scope is a multi-framework event.

Two-thirds of organisations suspect their AI agents have already accessed data outside their intended scope. For Gulf organisations spanning EU and GCC jurisdictions, that is simultaneously a DORA ICT incident, a GDPR data protection concern, a UAE PDPL notification obligation, and potentially a Saudi PDPL cross-border transfer violation. AI governance cannot be treated as a single-jurisdiction problem.

5. The architecture that satisfies both horizons is the same architecture.

The controls DORA, NIS2, the EU AI Act, and GCC data protection laws require in common are not substantively different: access controls, encrypted data handling, incident logging with attribution, and audit trails capable of satisfying regulatory review. Implement them once, across every channel through which sensitive data moves, and generate from that single implementation the evidence each framework requires.

Why the Current Evidence Generation Model Fails

The Cisco Privacy Benchmark Study found that organisations now operate an average of 3,891 SaaS and AI environments. Across those environments, access logs, incident records, and data transfer records are generated in dozens of different formats with dozens of different attribution standards. When a DORA supervisor asks for ICT incident classification evidence, or when a Saudi PDPL audit requires records of cross-border data transfers and consent documentation, the evidence reconstruction process — pulling records from email systems, file transfer platforms, cloud storage, MFT infrastructure, and AI interaction logs — routinely consumes weeks of compliance team time.

The Kiteworks 2026 Data Security and Compliance Risk Forecast Report found that 61% of organisations have fragmented audit logs across multiple systems. In a single-framework compliance environment, fragmented logs are a manageable operational inconvenience. In a dual-horizon compliance environment — EU frameworks and GCC frameworks simultaneously — fragmented logs mean every audit cycle requires the same reconstruction effort, against two different sets of regulatory expectations, with two different evidence formats.

The Akeyless 2026 State of AI Agent Identity Security report, based on 400 IT and security leaders, found that two-thirds of organisations suspect their AI agents have already accessed data outside their intended scope. For Gulf organisations deploying AI across operations spanning EU and GCC jurisdictions — with different data classification requirements, different consent standards, and different cross-border transfer rules — an AI agent operating outside its intended scope is not just a security event. It is simultaneously a DORA ICT incident, a GDPR data protection concern, a UAE PDPL notification obligation, and potentially a Saudi PDPL cross-border transfer violation.

The EU AI Act Adds the Third Dimension

The EU AI Act’s high-risk obligations arrive in August 2026. For Gulf organisations providing AI-enabled services to EU clients — financial risk assessments, automated document processing, customer-facing AI systems that touch EU data subjects — the Act’s documentation, risk management, and human oversight requirements are not optional. The August deadline applies to the AI system’s impact on EU individuals, not to where the system is hosted or where its developer is incorporated.

Cybersecurity governance expert Antonija Vojnović, speaking at the Span conference, observed that awareness of AI data leakage risks from enterprise AI tools remains low. In my work with organisations across the Gulf and EMEA, this matches what I see: strong AI adoption intent, and a significant gap between that intent and the AI governance infrastructure needed to deploy AI safely across multi-jurisdictional regulatory environments.

What the Architecture Needs to Do

The controls that DORA, NIS2, the EU AI Act, UAE PDPL, Saudi PDPL, and QCB data governance guidance require in common are not substantively different from each other. Access controls, encrypted data handling, incident logging with attribution, audit trails capable of satisfying regulatory review, and third-party vendor oversight. The frameworks differ in vocabulary and enforcement mechanism. The underlying technical controls are the same.

The compliance architecture that makes dual-horizon compliance sustainable applies those controls once — across every channel through which sensitive data moves, across all jurisdictions — and generates from that single implementation the evidence each framework requires. Not a separate compliance program for DORA and a different one for UAE PDPL. One governed data environment that produces attributable, tamper-evident records for every data access event, formatted for whatever regulatory review requires it.

The Kiteworks Private Data Network consolidates email, file sharing, MFT, SFTP, web forms, APIs, and AI integrations under one policy engine and one consolidated audit log. Pre-built compliance dashboards for GDPR, DORA, and NIS2 generate framework-specific evidence from the same underlying data — one architecture, two compliance horizons, one evidence base.

The organisations building a compliance architecture now — regardless of which specific regulatory deadline is most immediate — are the ones that will close the DORA gap, satisfy the GCC audit cycle, and meet the AI Act’s August deadline from the same investment. The organisations building separate programs for each will find that the compliance workload compounds faster than the team capacity to address it.

The 96% DORA failure rate is not a warning aimed at European firms. It is a benchmark for any organisation with exposure to EU regulatory frameworks — and across the Gulf, that exposure is significant and growing.

To learn more about demonstrating DORA compliance, schedule a custom demo today.

Additional Resources

• Blog Post The Tug-of-War Over Your Data: How the CLOUD and SHIELD Acts Pit Security vs. Privacy
• Blog Post Secure Sensitive Data by Mapping DSPM to Your Compliance Goals
• Brief Top 3 FERPA Violations and How to Avoid Them
• Blog Post Executive Order 14117: Protecting Americans’ Bulk Sensitive Personal Data
• Blog Post Need NIS2 Compliance? Start With ISO 27001