NIS2, DORA, and the EU AI Act: Why European Organizations Are Struggling to Keep Up
European organizations are not failing at regulatory compliance because they lack commitment. They are failing because three major regulatory frameworks arrived at nearly the same time, with overlapping but distinct requirements, inconsistent implementation timelines across member states, and compliance obligations that each demand their own documentation, audits, and evidence chains. The result is a compliance environment that is not merely demanding — it is architecturally misaligned with how most organizations have built their security and governance programs.
At the Span Cyber Security Arena conference, cybersecurity governance expert Antonija Vojnović put a number on the problem: 96% of financial services firms in EMEA report that their data resilience does not yet meet DORA’s expectations. That is not a statistic about the most unprepared organizations. It is a near-consensus finding across a sector that has dedicated substantial resources to compliance for decades.
NIS2, DORA, and the EU AI Act share a common objective — protecting organizations and the individuals whose data they handle from systemic cyber and AI-related risks — but they operationalize that objective through different scope definitions, different evidence requirements, and different enforcement bodies. For organizations subject to all three, the compliance workload does not add up. It multiplies.
5 Key Takeaways
1. Three major EU regulatory frameworks are in simultaneous enforcement with only partial guidance available for each.
NIS2 enforcement varies by member state. DORA’s RTS technical standards are still being finalized. The EU AI Act’s August 2026 high-risk deadline is being extended for some categories. Organizations cannot wait for clarity — they must build compliance infrastructure now, against requirements that are still evolving.
2. 96% of EMEA financial services firms say their data resilience does not meet DORA’s expectations.
DORA is not an aspirational standard. It is an operational one, with prescriptive requirements for ICT risk management, incident classification and reporting, third-party vendor oversight, and digital operational resilience testing. A 96% failure rate means the industry is starting from a significant deficit — and the controls most organizations are missing are the same controls NIS2 and the EU AI Act also require.
3. NIS2 implementation varies significantly across EU member states.
Multinationals operating across borders face different audit timelines, different national competent authority processes, and potentially different interpretations of the same directive text. The 24-hour preliminary notification requirement does not flex for member-state variation — the audit record must exist before the incident occurs, not assembled during one.
4. The EU AI Act’s August 2026 high-risk processing deadline is approaching, with low awareness of AI data leakage risks.
EU spending on AI is forecast to reach $290 billion by 2029. Organizations that have not inventoried where AI is touching regulated data are already behind on an obligation with fines reaching 7% of global annual turnover. Shadow AI — tools operating outside the governance framework — is directly relevant because the Act requires documented AI inventories as a foundational step.
5. The architectural answer is a single platform generating compliance evidence across all three frameworks simultaneously.
NIS2, DORA, and the EU AI Act each require access controls, encrypted data handling, incident logging, and audit trails. Organizations that implement these controls once, in a unified platform, satisfy requirements for all three — without maintaining three separate evidence chains that multiply cost and audit risk.
What Data Compliance Standards Matter?
What NIS2 Actually Requires from European Organizations
NIS2 expands the original Network and Information Systems Directive to cover energy, transport, financial infrastructure, health, and digital infrastructure — and introduces direct executive accountability for compliance failures. Directors and senior managers at in-scope organizations can be held personally liable for systematic NIS2 violations, a shift that has moved cybersecurity governance from the IT department to the board table.
The directive’s substantive requirements include technical and organizational measures appropriate to the risk, with specific attention to supply chain security, access control, and encrypted communications. Organizations must notify national competent authorities within 24 hours of becoming aware of a significant incident, with a more detailed report due within 72 hours.
The 24 and 72-hour notification windows are the operational pressure point. Meeting them requires having the audit logs and attribution records in place before an incident occurs, not assembled during one. Organizations that rely on scattered system logs across multiple platforms — email, file transfer, cloud storage, MFT — to reconstruct a breach sequence will find that 24 hours goes very quickly when spent on log aggregation rather than incident analysis.
NIS2 compliance is also a supply chain obligation. In-scope organizations must verify that their critical ICT service providers meet equivalent security standards — vendor assessments, contractual security requirements, and the ability to demonstrate that the compliance posture extends to third-party dependencies.
What DORA Demands That Most Financial Firms Do Not Yet Have
DORA applies to financial entities regulated at the EU level — banks, investment firms, insurance undertakings, payment institutions, and their critical ICT service providers — and establishes a unified framework for digital operational resilience across the EU financial sector. Unlike NIS2, which sets baseline requirements and allows member states to add more, DORA is a regulation, not a directive. Its requirements are directly applicable and uniform across all EU member states.
The 96% EMEA failure rate reflects the gap between DORA’s operational expectations and how most financial institutions have historically structured their ICT risk management. DORA requires a comprehensive ICT risk management framework covering identification, protection, detection, response, and recovery. Organizations must classify ICT incidents according to DORA’s prescribed criteria and report major incidents within specific timeframes.
DORA’s ICT risk mitigation requirements extend to how financial institutions handle data in transit and at rest across their operational channels. The encrypted managed file transfer systems through which financial institutions exchange sensitive data with counterparties, regulators, and service providers must meet DORA’s security standards. Many organizations are discovering that their legacy MFT infrastructure, built for performance rather than compliance, lacks the audit trail depth DORA requires.
DORA’s third-party risk provisions require financial entities to maintain a register of all ICT service providers supporting critical or important functions, conduct due diligence, include specific contractual provisions addressing security and incident notification, and demonstrate ongoing monitoring of provider performance. For organizations that have relied on informal vendor relationships, building this register and the required contractual infrastructure is a multi-month effort.
Why the EU AI Act Is Arriving Into an Already Strained Environment
The EU AI Act adds a third compliance dimension to an environment already stretched by NIS2 and DORA. Its high-risk AI system requirements — covering AI used in employment, credit decisions, education, law enforcement, and critical infrastructure management — carry obligations for risk management systems, data governance, transparency, and human oversight administered through a different legal framework with different enforcement mechanisms.
Vojnović’s observation — that awareness of AI data leakage risks from enterprise AI tools remains low — is significant. Organizations subject to the EU AI Act must not only govern the AI systems they deploy intentionally; they must also account for AI that enters their environment through embedded features in enterprise software, third-party integrations, and employee-adopted tools. The shadow AI problem is directly relevant because the Act requires documented AI inventories as a foundational step before any other obligation can be met.
The Overlapping Evidence Problem
What makes the NIS2-DORA-EU AI Act environment particularly challenging is not that the requirements are individually unreasonable. The problem is operational: satisfying all three simultaneously requires generating evidence across three regulatory vocabularies, from three sets of technical systems, for three separate audit processes.
NIS2 wants incident detection and notification records. DORA wants ICT risk management documentation and incident classification logs. The EU AI Act wants AI system risk assessments and data governance documentation. The underlying controls that generate this evidence — access logging, encrypted data handling, audit trails, incident response procedures — are largely the same. The problem is that most organizations have implemented these controls in silos: one set of logs for email, another for file transfer, a third for cloud storage, with no unified record satisfying all three frameworks from a single authoritative source.
Zero-trust architecture addresses this by treating every data access and exchange event as a policy decision that must be authenticated, authorized, attributed, and logged. In a zero-trust environment, the audit record is continuous and comprehensive by design, not assembled after the fact — generating the evidence NIS2 needs for incident notification, DORA needs for ICT risk management, and the EU AI Act needs for data governance documentation from a single record with consistent attribution.
What the Unified Platform Approach Changes
The Kiteworks platform provides NIS2 compliance, DORA compliance, and GDPR compliance capabilities from a single architecture. FIPS 140-3 validated encryption, ABAC-enforced access controls, and tamper-evident audit logging apply to every content exchange — secure email, SFTP, managed file transfer, and secure file sharing — through the same policy engine and the same audit record.
For DORA, ICT incident classification evidence, third-party communication logs, and access control documentation that supervisory authorities will request during a DORA audit are already present in the Kiteworks audit trail. For NIS2, the 24-hour preliminary notification and 72-hour detailed report timelines become manageable when the audit record already exists. For the EU AI Act, the Kiteworks Secure MCP Server and AI Data Gateway govern what AI agents can access and log every interaction in the same tamper-evident record as every human interaction.
The goal is not to treat each regulation as a separate implementation project. The goal is to build the security and governance infrastructure that all three frameworks require in common, once, and generate the evidence each framework needs from that single foundation. The Kiteworks Private Data Network is that foundation.
To learn more about demonstrating compliance with these and other data privacy regulations, schedule a custom demo today.
Frequently Asked Questions
NIS2 is a directive — EU member states must transpose it into national law, producing variation in implementation timelines. It applies across energy, transport, financial infrastructure, and digital services. DORA is a regulation, directly applicable and uniform across all EU member states, covering financial entities specifically. The two overlap for financial institutions subject to both. Building controls satisfying the highest common denominator — tamper-evident audit logging, encrypted data handling, third-party vendor oversight — reduces duplication across both programs.
Financial entities must maintain a register of all ICT service providers supporting critical functions, with contracts covering security standards, incident notification, audit rights, and data location. Organizations must also demonstrate ongoing monitoring to supervisory authorities. The most significant gap for most organizations is not contract language but evidence generation — the logs proving ongoing oversight, not just the text requiring it. Third-party risk management programs built around contractual compliance without operational monitoring are structurally vulnerable to a DORA examination.
August 2, 2026 is the enforcement date for high-risk AI system obligations, with staggered extensions — 16 months for new or substantially modified Annex III systems, 12 months for AI embedded in EU product safety regulations. Despite these extensions, the foundational requirement — maintaining an inventory of AI systems and risk classifications — applies from August 2. Fines for non-compliance reach 7% of global annual turnover. Organizations that have not begun their AI system audit are already behind.
Identify controls common to all three frameworks and implement them once through a unified architecture. Access controls, encrypted data handling, incident logging, and audit trails are required by all three in different vocabularies but through similar technical measures. A platform implementing these controls once — with ABAC enforcement, FIPS-validated encryption, and tamper-evident logging — generates the evidence each framework requires from a single authoritative source. The data governance posture built for DORA’s ICT risk management also satisfies NIS2’s notification requirements and the EU AI Act’s data governance obligations.
Start with controls generating the widest evidence coverage: access logging capturing every content exchange with identity attribution and timestamps, encrypted communications across all data exchange channels, and a documented incident response plan with tested notification procedures. These three measures produce compliance-relevant evidence for NIS2’s notification requirements, DORA’s ICT incident classification, and the EU AI Act’s operational monitoring obligations simultaneously. AI system inventory discovery should run in parallel — knowing what AI is in your environment is the prerequisite for every other AI Act obligation.
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