The triple regulatory framework: AI Act + NIS2 + DORA

Organizations that operate AI systems in regulated sectors face the convergence of three European regulatory frameworks that apply simultaneously:

• EU AI Act (Regulation 2024/1689): regulates AI systems according to their risk level. Focused on safety, fundamental rights and transparency.
• NIS2 (Directive 2022/2555): establishes cybersecurity obligations for essential and important entities in critical sectors. Transposed by Member States (in Spain, in progress).
• DORA (Regulation 2022/2554): establishes digital operational resilience requirements for financial entities. Applicable since January 2025.

These three frameworks do not exclude each other. A financial entity using AI for credit scoring may be subject to all three simultaneously: the AI Act because it is a high-risk system, DORA because it is a financial entity, and NIS2 if it is classified as an essential or important entity.

NIS2: fundamentals for AI professionals

Scope

NIS2 significantly expands the scope of the original NIS1. It affects essential and important entities in 18 sectors, including energy, transport, banking, financial market infrastructure, healthcare, drinking water, wastewater, digital infrastructure, ICT service management (B2B), public administration, space, postal services, waste management, chemicals manufacturing, food production and distribution, manufacturing (medical devices, IT products, electronics, optics, electrical equipment, vehicles, other transport equipment), digital service providers and research.

Key obligations relevant to AI

Risk management (Art. 21 NIS2)

Entities must adopt appropriate and proportionate technical, operational and organisational measures to manage the security risks of network and information systems. This expressly includes:

• Risk analysis and information system security policies.
• Incident handling.
• Business continuity and crisis management.
• Supply chain security.
• Security in network and information systems acquisition, development and maintenance (including vulnerability handling and disclosure).
• Policies and procedures to assess the effectiveness of cybersecurity risk management measures.
• Basic cyber hygiene practices and cybersecurity training.
• Cryptography and encryption.
• Human resources security, access control policies and asset management.
• Multi-factor authentication and secure communications.

Incident reporting (Art. 23 NIS2)

Obligation to notify significant incidents to the competent authority (CSIRT or NIS authority) with strict deadlines:

• Early warning: 24 hours from detection.
• Incident notification: 72 hours with initial assessment.
• Final report: 1 month after incident resolution.

Management body responsibility (Art. 20 NIS2)

Management bodies must approve cybersecurity risk management measures and supervise their implementation. They must also receive cybersecurity training. This obligation creates a direct line of senior management responsibility.

DORA: fundamentals for AI professionals

Scope

DORA applies to virtually all regulated financial entities: credit institutions, investment firms, payment institutions, electronic money institutions, insurance and reinsurance undertakings, pension funds, credit rating agencies, crypto-asset service providers, and critical third-party ICT service providers.

DORA pillars

Pillar 1: ICT risk management (Arts. 5-16)

A comprehensive ICT risk management framework that includes identification, protection, detection, response and recovery. The framework must cover all ICT assets, including AI systems. It requires a control function independent of business and ICT functions.

Pillar 2: ICT incident management and reporting (Arts. 17-23)

Incident management process with classification, registration, root cause analysis and reporting to authorities. Major incidents must be notified to the competent financial authority with deadlines similar to NIS2.

Pillar 3: Digital operational resilience testing (Arts. 24-27)

A testing programme that includes: vulnerability assessments, network security evaluations, gap analyses, performance testing, compatibility testing, penetration testing. Significant entities must conduct threat-led penetration testing (TLPT) at least every 3 years.

Pillar 4: ICT third-party risk management (Arts. 28-44)

Specific requirements for managing ICT service providers, including: pre-contractual due diligence, mandatory contractual clauses, continuous monitoring, exit strategies. Critical third-party providers are subject to a direct oversight framework by the European Supervisory Authorities (ESAs).

Pillar 5: Information sharing (Art. 45)

Financial entities may participate in information-sharing arrangements on cyber threats and intelligence, with appropriate data protection safeguards.

Critical intersections between the three frameworks

The three frameworks converge in several key areas. Understanding these intersections is essential for designing an efficient compliance programme.

Cybersecurity of AI systems

Article 15 of the AI Act requires high-risk systems to have an adequate level of cybersecurity. NIS2 requires security measures for network and information systems. DORA requires digital operational resilience for ICT assets. If your AI system is a "high-risk system" under the AI Act, an "information system" under NIS2 and an "ICT asset" under DORA, all three regulations apply to its cybersecurity. The good news: the security measures you implement for one serve the others, as long as they are documented correctly for each framework.

Risk management

AI Act (Art. 9): risk management system for high-risk systems. NIS2 (Art. 21): cybersecurity risk management measures. DORA (Arts. 5-16): ICT risk management framework. All three require identification, assessment, mitigation and monitoring of risks. A unified risk register covering all three perspectives (AI risk, cyber risk, digital operational risk) is more efficient than three separate registers.

Incident management

The same incident may require notification under all three frameworks with different deadlines and to different authorities. A cyberattack that compromises a high-risk AI system in a financial entity may require:

• Notification under NIS2: 24h (early warning), 72h (notification).
• Notification under DORA: per regulatory technical standards (similar to NIS2, with initial, intermediate and final notifications).
• Notification under the AI Act: 15 days (serious incident, Art. 73).
• Notification under the GDPR: 72h (if there is a personal data breach).

Supply chain

AI Act: provider and deployer obligations along the value chain. NIS2: supply chain security as a mandatory measure. DORA: comprehensive framework for managing third-party ICT providers with due diligence, contractual clauses and exit strategies. If your AI provider is also your ICT provider, all three regulations apply to the same contract.

ICT risk management for AI systems

AI systems introduce specific ICT risks that traditional technology risk management frameworks do not always adequately cover:

AI-specific risks in the ICT context

Adversarial attacks

Deliberate manipulation of input data to make the AI system produce incorrect results. Examples: imperceptible perturbations in images that fool classifiers, injection of poisoned data into training (data poisoning), prompt injection in language models. NIS2 and DORA require protection against cyberattacks. Adversarial attacks on AI are a specific category that must be included in the risk analysis.

Dependency on third-party models

Many organizations depend on proprietary third-party models (OpenAI, Anthropic, Google) for critical functions. If the provider suffers an outage, changes their API or modifies model behavior, the organization loses a critical capability. DORA explicitly requires exit strategies for critical ICT provider dependencies. This applies directly to AI model providers.

Model drift and degradation

AI models can degrade their performance over time when the production data distribution diverges from training. This is an operational risk that must be managed as part of the ICT risk framework. It requires continuous monitoring and retraining/update plans.

Provider concentration

The AI industry is dominated by few providers (OpenAI, Google, Anthropic, Meta). DORA pays special attention to the concentration risk in critical third-party providers. European supervisory authorities may designate AI providers as "critical third-party providers" if the financial sector's dependency is significant.

Integration into the ICT risk framework

For each AI system, the risk analysis must include:

• Availability risks: what happens if the system stops working? Is there a manual fallback?
• Integrity risks: what happens if the system produces incorrect results? How is it detected?
• Confidentiality risks: can the system leak sensitive data? Is input data sent to third parties?
• Traceability risks: can the system's decisions be reconstructed after an incident?
• Dependency risks: what level of dependency exists on the provider? Are there alternatives? Is there an exit strategy?

Incident reporting: coordinating deadlines and authorities

Coordinating incident reporting is one of the most complex aspects of joint compliance. Each framework has its own deadlines, definitions of "significant incident" and receiving authorities.

Notification deadline table

NIS2

• Significant incident: serious impact on service provision.
• Authority: CSIRT / national NIS authority.
• Deadlines: 24h early warning, 72h notification, 1 month final report.

DORA

• Major ICT incident: affects critical financial services.
• Authority: competent financial authority (BdE, CNMV, DGSFP in Spain).
• Deadlines: defined in regulatory technical standards (similar to NIS2, with initial, intermediate and final notifications).

AI Act

• Serious incident: death, serious harm to health/property/environment, serious breach of fundamental rights.
• Authority: market surveillance authority (AESIA in Spain).
• Deadline: 15 days (without undue delay).

GDPR

• Personal data security breach.
• Authority: data protection authority (AEPD in Spain).
• Deadline: 72 hours.

Coordination protocol

Upon an incident that may affect multiple frameworks:

1. Hour 0-4: detection, initial classification, response team activation, immediate containment.
2. Hour 4-24: impact assessment, determination of which frameworks apply, preparation of NIS2 early warning (if applicable).
3. Hour 24-72: NIS2 notification (if applicable), GDPR notification (if data breach), DORA notification (if applicable to financial entity), investigation in progress.
4. Day 3-15: AI Act notification (serious incident), investigation deepening, corrective actions.
5. Day 15-30: NIS2 final report, investigation closure, lessons learned.

Supply chain and AI providers

AI provider management is a critical convergence point between the three frameworks. Organizations increasingly depend on external providers for AI capabilities, and each framework imposes specific requirements on this relationship.

Pre-contractual due diligence

Before contracting an AI provider, the organization must assess:

• AI Act: does the provider comply with Title III obligations (if it is a high-risk system)? Does it provide technical documentation, instructions for use, human oversight mechanisms?
• NIS2: does the provider implement adequate cybersecurity measures? Do they have an incident history? What is their supply chain?
• DORA: full provider risk assessment, including concentration risk, substitutability, data localisation, subcontracting.
• GDPR: data processor agreement (Art. 28), international transfer safeguards, technical and organisational measures.

Contractual clauses

The contract with the AI provider must include clauses covering all three frameworks' requirements:

• Transparency and technical documentation obligations (AI Act).
• Service level agreements (SLAs) with availability, performance and accuracy metrics.
• Cybersecurity and incident notification obligations (NIS2/DORA).
• Audit rights and access to information (DORA Art. 30).
• Exit strategy: transition plan if the provider relationship ends (DORA).
• Data protection clauses (GDPR Art. 28).
• Obligations regarding material changes to the service (model change, data policy change, localisation change).

Continuous monitoring

Provider management does not end with contract signing. DORA requires continuous monitoring that includes: periodic review of provider performance, assessment of changes in their risk profile, SLA compliance verification, incident tracking, periodic testing of the exit strategy.

Joint compliance framework

Instead of managing three separate compliance programmes, the efficient approach is an integrated framework.

Integrated framework principles

A unified risk register

A single risk register that captures for each risk: the AI perspective (impact on fundamental rights, bias, opacity), the cybersecurity perspective (confidentiality, integrity, availability), and the operational resilience perspective (continuity, recovery, dependencies). Each risk is mapped to the articles of the three frameworks that cover it.

A single incident management process

A single incident management process with a decision tree that determines, for each incident, which frameworks apply and which notifications are required. A response team with competencies in AI, cyber and financial regulation (if applicable).

A coordinated audit programme

Plan AI, cybersecurity and operational resilience audits in a coordinated manner. Where possible, a single audit covering the requirements of all three frameworks. Reduce audit fatigue for operational teams.

An integrated policy

A security and AI governance policy that integrates the requirements of all three frameworks. Specific sections for each framework where necessary, but a unified structure, one owner, one review cycle.

Cross-control map

Controls can be grouped into 5 cross-cutting domains:

• Governance: policies, roles, committees, training (AI Act Art. 4 + NIS2 Art. 20 + DORA Art. 5).
• Risk management: identification, assessment, mitigation, monitoring (AI Act Art. 9 + NIS2 Art. 21 + DORA Arts. 6-16).
• Technical security: encryption, access control, resilience, testing (AI Act Art. 15 + NIS2 Art. 21 + DORA Arts. 24-27).
• Incident management: detection, response, notification, lessons learned (AI Act Art. 73 + NIS2 Art. 23 + DORA Arts. 17-23).
• Supply chain: due diligence, contracts, monitoring, exit (AI Act Arts. 6/26 + NIS2 Art. 21 + DORA Arts. 28-44).

Ejercicio practico

Puntos clave