NIS2 Directive + AI: cybersecurity obligations for AI-enabled essential entities (EU 2022/2555)

The Network and Information Security Directive 2 (NIS2), formally Directive (EU) 2022/2555, is the European Union's cybersecurity baseline for essential and important entities. Adopted on December 14, 2022, NIS2 replaces the original NIS Directive (2016/1148) with a substantially expanded scope, more prescriptive risk-management measures, faster incident reporting, harder sanctions, and direct management liability. The transposition deadline was October 17, 2024, and Member States are now actively enforcing the transposed national laws, though several Member States slipped into 2025 with their transposition timetables.

NIS2 does not regulate AI directly. It regulates cybersecurity for entities operating in critical sectors. AI matters under NIS2 in three ways. First, AI-enabled essential and important entities (banks running AI fraud detection, healthcare providers using AI clinical decision support, transport operators using AI traffic systems) must apply NIS2 risk-management measures to the AI components of their critical operations. Second, AI vendors providing managed services to essential or important entities may themselves fall in scope as digital infrastructure or ICT service management providers, and supply-chain security obligations under Article 21(2)(d) flow through to them. Third, AI-specific threat vectors (prompt injection, model exfiltration, training-data poisoning, adversarial inputs) have been formally recognised by ENISA in the 2024 and 2025 AI Threat Landscape reports as cybersecurity risks that NIS2 risk management measures must address.

For AI governance leaders, the practical posture is to treat NIS2 as the cybersecurity baseline that operates alongside the EU AI Act's substantive AI obligations. NIS2 Article 21 risk management plus ISO/IEC 27001 information security management plus ISO/IEC 42001 AI management together provide an evidence pack that covers cybersecurity, information security management, and AI-specific risk in one unified governance programme. Areebi is designed for exactly this layered approach.

NIS2 itself is a directive: it sets the obligations and requires Member States to transpose them into national law. The operative legal stack for any given enterprise consists of NIS2, the Commission's implementing acts, the Member State transposition law, and the competent authority's enforcement guidance.

NIS2 expanded scope dramatically compared to NIS1, both in terms of sectors covered and in terms of the threshold for inclusion. The practical scope question for AI vendors is whether they themselves are in scope and whether their customers are in scope.

Essential entities (Annex I)

• Energy: Electricity, district heating and cooling, oil, gas, hydrogen.
• Transport: Air, rail, water, road.
• Banking: Credit institutions defined in Regulation (EU) No 575/2013.
• Financial market infrastructure: Trading venues, central counterparties, central securities depositories.
• Health: Healthcare providers, EU reference laboratories, R&D for medicinal products, basic pharmaceutical manufacturing, medical devices manufacturing.
• Drinking water: Suppliers and distributors of water intended for human consumption.
• Waste water: Operators of waste water collection or treatment.
• Digital infrastructure: Internet exchange point providers, DNS service providers, top-level domain name registries, cloud computing service providers, data centre service providers, content delivery network providers, trust service providers, public electronic communications networks and services.
• ICT service management (B2B): Managed service providers and managed security service providers. Many AI vendors providing managed AI services to essential entities fall here.
• Public administration: Central government entities, and (Member State discretion) regional government entities.
• Space: Operators of ground-based infrastructure supporting space-based services.

Important entities (Annex II)

• Postal and courier services.
• Waste management.
• Manufacture, production, and distribution of chemicals.
• Production, processing, and distribution of food.
• Manufacturing of medical devices, computers and electronic products, electrical equipment, machinery, motor vehicles, other transport equipment.
• Digital providers: Online marketplaces, online search engines, social networking platforms.
• Research: Research organisations carrying out activities relevant to the EU public interest.

Size thresholds (Article 2)

By default, NIS2 applies to medium-sized and large entities (above 50 employees or EUR 10 million annual turnover). The size threshold is waived for certain critical categories regardless of size: trust service providers, top-level domain name registries, DNS service providers, providers of public electronic communications networks or services, and entities qualifying as sole providers of essential services.

AI vendor scope assessment

• Pure SaaS AI vendor selling to essential entities: Likely in scope as an ICT service management entity if providing managed services, or as a digital service provider if running as a digital infrastructure service.
• AI model provider (API only) to essential entities: Likely a digital provider; status depends on the specific service model and whether the provider is considered to be providing a managed service or a self-service API.
• Bank deploying AI internally: The bank is an essential entity. NIS2 risk management measures apply to its AI systems alongside its other ICT assets. AI vendor obligations flow through under supply-chain security (Article 21(2)(d)).

Determining scope is a regulator-specific exercise. Areebi customers operating across Member States typically maintain a scope matrix that records, for each Member State, the transposition law, the competent authority's published guidance on scope, and the entity's classification (essential/important/not-in-scope).

Article 21(1) requires in-scope entities to take "appropriate and proportionate technical, operational, and organisational measures" to manage cybersecurity risks. Article 21(2) sets a minimum list of ten measures. These are the operational core of NIS2 compliance.

The ten minimum measures (Article 21(2))

1. Policies on risk analysis and information system security.
2. Incident handling.
3. Business continuity, including backup management, disaster recovery, and crisis management.
4. Supply chain security, including security-related aspects of the relationships between entities and their direct suppliers or service providers.
5. Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure.
6. Policies and procedures to assess the effectiveness of cybersecurity risk management measures.
7. Basic cyber hygiene practices and cybersecurity training.
8. Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
9. Human resources security, access control policies, and asset management.
10. Use of multi-factor or continuous authentication solutions, secured voice/video/text communications, and secured emergency communication systems.

AI-specific risk overlay

For AI-enabled or AI-providing entities, each Article 21 measure has an AI-specific overlay. The mapping has been articulated in ENISA's 2025 AI Threat Landscape and is increasingly the expected baseline:

• Risk analysis (measure 1): AI risk assessment covering training-data integrity, model integrity, inference integrity, prompt injection, model exfiltration, membership inference, adversarial inputs, and AI-driven social engineering. Cross-mapped to NIST AI RMF MAP function and ISO/IEC 42001.
• Incident handling (measure 2): AI-specific incident types are formally recognised. Detection, triage, containment, eradication, recovery, and post-incident review must address AI-driven attacks (prompt-injection breach, model exfiltration, AI-driven phishing, model-inversion attack).
• Business continuity (measure 3): Continuity plans must address AI dependencies. Model failover, fallback to non-AI processes, and data-pipeline recovery are within scope.
• Supply chain security (measure 4): Most material AI overlay. AI model providers and AI service providers are direct suppliers and must be assessed under this measure. See dedicated section below.
• Acquisition, development, and maintenance (measure 5): AI development lifecycle controls including secure development, vulnerability management for AI components, model versioning, and rollback. AI dependencies (open-source models, training datasets, fine-tuning tools) must be inventoried and assessed.
• Effectiveness assessment (measure 6): AI control effectiveness is tested through adversarial red-teaming, model evaluation against bias and robustness benchmarks, and tabletop exercises simulating AI-specific incidents.
• Cyber hygiene and training (measure 7): Staff training on AI-specific risks (prompt injection, data exposure to third-party models, shadow AI). Shadow AI management is an explicit cyber hygiene concern.
• Cryptography (measure 8): Encryption of training data, model weights (where appropriate), inference traffic, and audit logs. Key management is explicit.
• Human resources, access control, asset management (measure 9): Identity and access management for AI systems including service accounts, API keys, and federation. AI assets (models, training datasets, prompts, evaluation harnesses) are managed in the asset inventory.
• Multi-factor authentication and secure communications (measure 10): MFA for AI admin and operator accounts; secure communications for sensitive AI workflows; emergency communications channels that do not rely on the AI being protected.

Implementing Regulation (EU) 2024/2690 specifications

For digital infrastructure, ICT service management, and digital providers in scope of Implementing Regulation (EU) 2024/2690, the ten measures are given detailed technical specification. Subjects covered in the implementing regulation include risk analysis methodology, incident handling SLAs, business continuity recovery objectives, supplier risk assessment process, vulnerability handling timelines, cryptographic standards, identity and access management controls, and asset management practices. AI vendors providing managed services should map their controls directly to this implementing regulation.

Supply chain security under Article 21(2)(d) is one of the most operationally consequential measures for AI. NIS2 explicitly requires that in-scope entities assess security-related aspects of relationships with direct suppliers and service providers. AI vendors providing services to essential or important entities are direct suppliers and must therefore be assessed.

What in-scope entities must do

• Supplier inventory: Maintain an up-to-date inventory of ICT suppliers and service providers, including AI model providers, AI platform providers, and AI managed service providers.
• Risk-based assessment: Assess each supplier's cybersecurity posture using a risk-based methodology that considers the criticality of the service, the sensitivity of data shared with the supplier, and the supplier's own cybersecurity maturity.
• Contractual obligations: Reflect cybersecurity expectations in contracts with suppliers. Common contract terms include incident notification timelines, audit rights, certification requirements, sub-processor management, data-handling obligations, and exit and transition support.
• Ongoing monitoring: Reassess suppliers regularly (typically annually for critical suppliers) and on triggering events (incidents, ownership changes, certification lapses).
• Concentration risk: Identify and manage supplier concentration risk where a single supplier or a small number of suppliers becomes a single point of failure.

What AI vendors must provide

AI vendors selling to essential or important entities should expect to provide:

• Cybersecurity attestation pack: Documentation of the AI vendor's own cybersecurity controls aligned with NIS2 Article 21 measures, ISO/IEC 27001 certification (or evidence of an equivalent ISMS), SOC 2 Type II reports, and any AI-specific certifications.
• Incident notification SLAs: Commitment to notify the customer of incidents within timelines that allow the customer to meet its own Article 23 reporting obligations (typically within 24 hours of discovery).
• Sub-processor disclosure: Identification of sub-processors and lower-tier suppliers, with comparable cybersecurity expectations flowed down.
• Right-to-audit provisions: Reasonable audit rights or independent third-party audit reports that the customer can use to verify the vendor's cybersecurity posture.
• Exit and transition support: Plans for orderly exit including data return or deletion, transition assistance, and continued cybersecurity support during the transition window.
• AI-specific overlays: Disclosure of training-data sources, model evaluation results, AI-specific incident history (prompt-injection incidents, model exfiltration attempts), and model robustness evidence.

Concentration risk and the GPAI question

NIS2 explicitly directs attention to concentration risk. Many AI deployments depend on a small number of foundation model providers, which creates supplier concentration risk by design. The EU AI Act's general-purpose AI (GPAI) obligations on systemic-risk models intersect here: a GPAI provider designated under the AI Act is highly likely also to be a critical supplier under NIS2. Multinational enterprises are increasingly building multi-model and multi-vendor strategies to mitigate this concentration risk.

The Areebi supplier-attestation pack

Areebi publishes a NIS2 supplier-attestation pack covering the Article 21 measures, sub-processor disclosures, incident notification SLAs, audit rights, and AI-specific overlays. Customers can adopt this pack as evidence of supplier assessment under Article 21(2)(d) and can flow the contractual terms into their downstream agreements.

NIS2 Article 23 sets a four-stage reporting cascade for significant incidents. AI-specific incident types (prompt injection breach, model exfiltration, AI-driven misinformation, AI-enabled phishing) trigger the cascade in the same way as traditional cybersecurity incidents, provided they meet the significance threshold.

The reporting cascade

1. Early warning (24 hours): Within 24 hours of becoming aware of a significant incident, the entity must submit an early warning to the CSIRT (Computer Security Incident Response Team) or the competent authority. The early warning indicates whether the incident is suspected to be caused by malicious actors and whether it could have cross-border impact.
2. Incident notification (72 hours): Within 72 hours of becoming aware, a more detailed notification updating the initial assessment, indicating severity, impact, and indicators of compromise.
3. Intermediate report (on request): A status update may be requested by the competent authority during the incident.
4. Final report (one month): Within one month of the incident notification, a final report with detailed description, type of threat, root cause, mitigation measures applied, and (where applicable) cross-border impact.

For ongoing incidents that remain unresolved at the one-month mark, a progress report is required, with the final report submitted within one month of incident handling completion.

Significance threshold

Article 23(3) defines a significant incident as one that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, OR has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The Commission's Implementing Regulation (EU) 2024/2691 sets out detailed significance criteria for digital infrastructure, ICT service management, and digital providers.

AI-specific incident types

The ENISA 2025 AI Threat Landscape catalogue, combined with sector regulator guidance, identifies the AI-specific incident types most likely to trigger NIS2 reporting:

• Prompt injection breach: An attacker uses prompt injection to bypass policy controls, exfiltrate data, or cause unintended AI actions. Significant where it leads to data exposure, financial loss, or service disruption.
• Model exfiltration: A copy of a model is taken without authorisation, including via API querying or insider exfiltration. Significant where the model embodies trade secrets, training data with personal data, or safety constraints that downstream attackers could circumvent.
• Training-data poisoning: An attacker introduces malicious data into a training pipeline to compromise model behaviour. Significant where the affected model is in production for critical functions.
• Adversarial input attack: Carefully crafted inputs cause the model to misclassify or misbehave. Significant where the misbehaviour causes harm (autonomous-system failure, fraud detection bypass, healthcare misdiagnosis).
• AI-enabled phishing or social engineering: Attackers use AI to craft convincing phishing, deepfakes, or other social engineering. Significant where the attack succeeds and leads to data exposure or financial loss.
• Model inversion or membership inference: Attackers reconstruct training data or determine whether specific records were used in training. Significant where the model was trained on sensitive personal or business data.
• AI-driven misinformation in critical systems: AI generates or amplifies misinformation in a way that causes operational disruption or public harm. Significant for digital providers and social networks.
• Hallucination causing direct harm: An AI hallucination causes operational harm (incorrect financial advice, wrong medical guidance, false legal claim). Significant where the harm meets the Article 23(3) threshold.

Areebi incident response support

Areebi's incident response workflow includes pre-built templates for the four-stage NIS2 cascade and for AI-specific incident types. The audit trail captures the indicators required for the early warning (24h), the notification (72h), and the final report (one month), including the timestamps that prove the cascade was met. Templates are pre-mapped to each Member State's CSIRT and competent authority.

Article 32 is one of the most consequential policy shifts from NIS1 to NIS2. It places personal accountability on senior management for cybersecurity risk management, with explicit liability for breach of duty.

What Article 32 requires

• Management approval of risk management measures (Article 20(1)): The management body of an essential or important entity must approve the cybersecurity risk management measures and oversee their implementation. This is not delegated to operational management; it is an obligation of the management body itself.
• Management training (Article 20(2)): Members of the management body must follow training to gain sufficient knowledge and skills to identify risks and assess cybersecurity risk management practices and their impact on the services. Member State competent authorities increasingly require evidence of completed management training.
• Personal liability (Article 32(6)): Where the management body fails to comply with its Article 20 obligations, Member States must ensure that natural persons holding senior management positions can be held liable. Member States may temporarily prohibit such persons from exercising managerial functions at an essential entity.
• Sanctions accompanied by other penalties (Article 34): Administrative fines are not the only enforcement tool. Competent authorities can issue warnings, binding instructions, suspension orders, and the temporary prohibition of managerial functions.

Practical implications

• AI governance committee at the board level: Many essential entities have established board-level cybersecurity committees with AI governance as a standing item. The committee reviews and approves the Article 21 risk management measures, the AI risk assessment, and the incident reporting performance.
• Director D&O cover and personal indemnity: The personal liability dimension has changed director risk profiles. Many essential entities have updated D&O cover and personal indemnity arrangements. Some Member State transposition laws explicitly provide for personal financial penalties on directors.
• Cybersecurity literacy across the management body: Article 20(2) training requirements have prompted significant investment in board-level cybersecurity and AI literacy programmes. Annual training and tabletop exercises are now standard practice for essential entity boards.
• Documented decisions and minutes: The management body's approval of risk management measures must be documented. Minutes evidencing the approval, the considerations, and the dissents are routinely requested by competent authorities during inspections.

AI-specific governance overlays

The combination of NIS2 Article 32 (cybersecurity governance) and the EU AI Act Article 17 (quality management for high-risk AI providers) creates a unified board-level governance expectation. Essential entities deploying high-risk AI typically operate a single integrated governance structure that covers both regulatory regimes, with documented evidence of management body approval, training, and oversight for the combined cyber-plus-AI risk envelope.

NIS2 is enforced by Member State competent authorities, not by EU institutions. Each Member State designates one or more competent authorities and one or more CSIRTs. Enforcement practice already varies materially across Member States.

Key competent authorities (selected)

• Germany - BSI (Bundesamt fuer Sicherheit in der Informationstechnik): Federal Office for Information Security. The German NIS2 transposition (2025) gives BSI broad supervisory powers including ex ante inspections of essential entities. BSI has indicated its enforcement priorities include supply chain security and incident reporting compliance.
• France - ANSSI (Agence nationale de la securite des systemes d'information): National Cybersecurity Agency. The French transposition law (May 2025) establishes ANSSI as the principal supervisory authority for essential entities, with sectoral cooperation for finance, energy, and telecom.
• Spain - INCIBE plus sectoral authorities: The Spanish transposition (2025) coordinates supervision across INCIBE (general), the Banco de Espana (banking), the CNMV (financial markets), and other sectoral regulators.
• Italy - ACN (Agenzia per la Cybersicurezza Nazionale): National Cybersecurity Agency. The Italian transposition (Decreto Legislativo 138/2024) places ACN as the lead authority with strong cross-sector coordination.
• Belgium - CCB (Centre for Cybersecurity Belgium): The Belgian transposition (October 2024) places CCB as the national competent authority with sectoral cooperation.
• Netherlands - NCSC + RDI: The National Cyber Security Centre (operational) and the Rijksinspectie Digitale Infrastructuur (supervisory) jointly administer the Dutch Cyberbeveiligingswet 2024.
• Ireland - NCSC and sectoral regulators: The Irish transposition designates the National Cyber Security Centre alongside sectoral regulators for the in-scope entities. Important for many AI vendors with EU headquarters in Ireland.

Penalty calculations

Article 34 sets the maximum penalties:

• Essential entities: Up to EUR 10 million or 2% of global annual turnover of the preceding financial year, whichever is higher.
• Important entities: Up to EUR 7 million or 1.4% of global annual turnover of the preceding financial year, whichever is higher.

Member State transposition laws have generally adopted these caps. Some Member States have added further sanctions (for example, criminal liability for serious or repeated breaches in some transpositions).

Early enforcement actions (2025)

First substantial enforcement actions began in 2025 as competent authorities completed their initial supervisory inspections. Areas of early focus across multiple Member States include:

• Late or absent incident reports: Several Member States have issued enforcement notices for failure to meet the 24-hour and 72-hour reporting cascade.
• Supply chain assessment quality: Inspections have flagged insufficient supplier risk assessments, particularly for cloud and AI service providers.
• Management body training evidence: Member States have begun requiring documented evidence of management body training under Article 20(2).
• Asset inventory completeness: Several inspections found incomplete asset inventories, particularly for AI assets and shadow IT.

Areebi tracks Member State enforcement decisions and publishes regular updates to the NIS2 evidence pack to reflect emerging enforcement priorities.

NIS2 (cybersecurity risk) and the EU AI Act (AI-specific substantive risk) are the two main EU regimes that touch AI in critical sectors. They overlap significantly, and a unified governance approach is more efficient than running two separate programmes.

Where the regimes intersect

• Risk management: NIS2 Article 21(2)(a) requires cybersecurity risk analysis; EU AI Act Article 9 requires a comprehensive AI risk management system. For an essential entity deploying high-risk AI, both apply. A unified risk register covering cyber and AI risk is the efficient design.
• Data governance: NIS2 measures address protection of data; EU AI Act Article 10 sets training-data quality and bias-management requirements. The data inventory and data lineage controls satisfy both, but the EU AI Act adds quality and bias overlays.
• Incident handling: NIS2 Article 23 sets cybersecurity incident reporting; EU AI Act Article 73 requires serious AI incident reporting (notably for high-risk AI). Some incidents will need to be reported under both regimes to different competent authorities.
• Supply chain: NIS2 Article 21(2)(d) requires supplier security assessment; EU AI Act Article 25 requires high-risk AI providers to identify and assess their suppliers and partners.
• Governance: NIS2 Article 32 imposes management liability for cybersecurity risk management; EU AI Act Article 17 (high-risk AI providers) and Article 26 (deployers of high-risk AI) impose comparable governance expectations for AI.
• Documentation and audit: Both regimes require extensive documentation and audit-grade evidence. A unified evidence pack reduces duplicate work.

The ISO 27001 + ISO 42001 unified approach

The practical pattern for essential entities deploying AI is to operate a unified management system combining:

• ISO/IEC 27001 ISMS: Provides the information security management baseline that maps directly to NIS2 Article 21 measures.
• ISO/IEC 27002 controls: Detailed control catalogue mappable to NIS2 Article 21(2) and to EU AI Act Article 15 (cybersecurity, accuracy, robustness for high-risk AI).
• ISO/IEC 22301 BCMS: Business continuity management, mapping to NIS2 Article 21(2)(c).
• ISO/IEC 42001 AIMS: AI management system, providing AI-specific governance, risk, and assurance that maps to EU AI Act obligations and to the AI-specific overlay of NIS2 Article 21.
• NIST AI RMF: Used as the practical AI risk management methodology for the MAP, MEASURE, MANAGE functions, cross-referenced to ISO/IEC 42001.

An entity that holds ISO/IEC 27001 and ISO/IEC 42001 certification, has implemented ISO/IEC 22301 BCMS, and has an active NIST AI RMF programme is well-positioned to demonstrate NIS2 Article 21 plus EU AI Act compliance with a single evidence pack.

Areebi unified evidence pack

Areebi's Compliance Hub publishes a cross-mapped evidence pack covering NIS2 Article 21, EU AI Act high-risk AI obligations, ISO/IEC 27001, ISO/IEC 42001, and NIST AI RMF. Customers can produce a NIS2-only pack, an EU AI Act-only pack, or a unified pack covering both regimes from the same underlying audit trail.

Areebi's AI control plane is built to support NIS2 Article 21 risk management measures for AI-enabled organisations and to provide the supplier-attestation pack that AI vendors selling to essential and important entities need to provide.

Article 21(2)(a) - risk analysis and information system security

Areebi's risk register supports comprehensive AI risk assessment cross-mapped to ENISA's 2025 AI Threat Landscape and to NIST AI RMF MAP function. Risks covered include prompt injection, model exfiltration, training-data poisoning, adversarial inputs, model inversion, AI-enabled phishing, and AI-driven misinformation. Risk treatments are tracked through to closure.

Article 21(2)(b) - incident handling

The runtime policy engine detects AI-specific incidents (prompt injection attempts, anomalous output, exfiltration patterns) and triggers the incident response workflow with pre-built templates for the four-stage Article 23 cascade.

Article 21(2)(c) - business continuity

Model failover, fallback-to-non-AI processes, and data-pipeline recovery are configurable through the platform. Recovery objectives align with the sectoral expectations published by competent authorities.

Article 21(2)(d) - supply chain security

Areebi publishes a comprehensive NIS2 supplier-attestation pack covering Article 21 measures, sub-processor disclosures, incident notification SLAs, audit rights, and AI-specific overlays. Customers can use this pack as supplier-assessment evidence under Article 21(2)(d) and can flow comparable terms into their downstream agreements with AI model providers and AI tool providers.

Article 21(2)(e) - acquisition, development, maintenance, vulnerability handling

AI development lifecycle controls including secure development, vulnerability management for AI components, model versioning, and rollback are built into the platform. AI dependency inventory (foundation models, training datasets, fine-tuning tools, open-source libraries) is maintained automatically.

Article 21(2)(f) - effectiveness assessment

AI control effectiveness is tested through configurable red-team campaigns, model evaluation against bias and robustness benchmarks, and pre-built tabletop exercise scenarios for AI-specific incidents.

Article 21(2)(g) - cyber hygiene and training

Shadow AI detection identifies unauthorised AI tool use across the organisation. Staff training modules on prompt-injection awareness, data-exposure prevention, and shadow-AI risk are available through the platform.

Article 21(2)(h) - cryptography

Encryption of training data, model weights (where appropriate), inference traffic, and audit logs is enforced by policy. Key management is integrated with enterprise KMS.

Article 21(2)(i) - human resources, access control, asset management

Identity and access management for AI systems, including service accounts, API keys, and federation, is unified through the platform's policy engine. AI assets (models, training datasets, prompts, evaluation harnesses) are recorded in the asset inventory.

Article 21(2)(j) - MFA and secure communications

MFA for AI admin and operator accounts is enforced by default. Secure communications for sensitive AI workflows are supported through encrypted channels. Emergency communications channels that do not rely on the AI being protected are documented in the BCMS.

Article 23 - incident reporting

The incident response workflow includes pre-built templates for the 24-hour early warning, 72-hour notification, and one-month final report. Templates are pre-mapped to each Member State's CSIRT and competent authority. The audit trail captures all timestamps required to demonstrate compliance with the reporting cascade.

Article 32 - governance and management liability

Board-level dashboards provide the management body with the evidence required under Article 20(1) for approval of risk management measures. Documented training records support Article 20(2) management training requirements.

Organisations seeking to accelerate NIS2 compliance can request a demo to see how Areebi operationalises Article 21 measures alongside the broader AI control plane.

Authoritative external sources:

• Directive (EU) 2022/2555 (NIS2) consolidated text on EUR-Lex
• ENISA NIS Directive topic page
• ENISA publications including AI Threat Landscape 2025
• BSI - Bundesamt fuer Sicherheit in der Informationstechnik (Germany)
• ANSSI - Agence nationale de la securite des systemes d'information (France)