Around 160,000 organisations across the EU now fall inside the scope of the NIS2 Directive (Directive (EU) 2022/2555), up from roughly 15,000 under the original 2016 NIS Directive. Every one of them that wires an AI agent into an operational system has just added a piece of ICT supply-chain risk that Article 21 turns into a board-level legal obligation. NIS2 is the fifth regulatory pillar in the EU quintet, after GDPR, the EU AI Act, Peppol, and DORA, and it is the one that converts a Model Context Protocol (MCP) server from a convenience into an audited control.
Who NIS2 applies to: essential vs important entities, 18 sectors, ~160,000 organisations
NIS2 (Directive (EU) 2022/2555) replaced the original NIS Directive. Member States had to transpose it into national law by 17 October 2024, and it applied from 18 October 2024. The European Commission estimates that over 160,000 entities now fall under the expanded scope. The Directive covers 18 sectors split across two annexes: 11 high-criticality sectors in Annex I and 7 other critical sectors in Annex II.
Classification turns on two filters, the sector (Annex I or II) and the size of the organisation under Recommendation 2003/361/EC. The split determines your supervision regime and your maximum fine, and it is not optional.
- Essential entities are large organisations (250+ employees or over EUR 50M turnover) in Annex I sectors. They face proactive, ex-ante supervision and the higher fine ceiling. Under Article 34, fines reach a maximum of at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher, a floor for Member States rather than a cap.
- Important entities are medium organisations (50+ employees or EUR 10M+ turnover) in Annex I or II sectors, plus large Annex II entities. They face reactive, ex-post supervision and fines up to EUR 7 million or 1.4% of global turnover.
- In scope regardless of size: DNS service providers, top-level domain name registries, qualified trust service providers, and providers of public electronic communications networks.
A critical point for technical buyers: Article 20 makes the management body personally accountable. It requires boards and senior management to approve and oversee the Article 21 measures, undergo training, and allows them to be held liable for infringements. The deeper procurement framing for technical leaders sits in our MCP guide for the EU CTO and CIO.
Article 21 in plain English: the 10 risk-management measures
Article 21(2) lists ten minimum cybersecurity risk-management measures that both essential and important entities must implement. The measures are technology-neutral and outcome-based, the Directive tells you what to achieve, not how, and they are bounded by the proportionality principle in Article 21(1), which weighs the entity’s risk exposure, size, and the likelihood and severity of incidents. Article 21 also mandates an all-hazards approach covering physical and environmental threats, not just cyberattacks.
- Risk analysis and information system security policies, with a documented methodology, asset inventory, and treatment plans.
- Incident handling, covering prevention, detection, analysis, containment, response, and recovery, read alongside the Article 23 reporting cascade.
- Business continuity, including backup management, disaster recovery, and crisis management.
- Supply chain security (Article 21(2)(d)), covering the relationships between the entity and its direct suppliers and service providers.
- Security in acquisition, development and maintenance, including vulnerability handling and disclosure.
- Policies to assess the effectiveness of the risk-management measures, the audit loop.
- Basic cyber hygiene practices and cybersecurity training, including specific training for the management body.
- Cryptography and, where appropriate, encryption.
- Human resources security, access control policies, and asset management.
- Multi-factor or continuous authentication, secured communications, and secured emergency communications where appropriate.
Article 21(3) extends the supply-chain measure explicitly: entities must take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of their products and cybersecurity practices, including their secure development procedures. That sentence is precisely where an AI agent platform lands.
Where AI agents intersect NIS2: data access, writeback, supply chain risk
An AI agent that reads from and writes back to operational systems does not sit at the edge of NIS2, it sits inside several Article 21 measures at once. Reading data engages access control and asset management (measure 9); writing back engages incident handling and secure development (measures 2 and 5); and the agent’s identity controls engage multi-factor authentication (measure 10).
The MCP vendor itself is an ICT third-party service provider, which means it is assessed under the Article 21(2)(d) supply chain obligation. A regulator does not ask what you intended, it asks what you can prove: which prompt triggered which mutation, on whose authority, against which dataset. Writeback without a defensible log is the single most common gap, which is why writeback governance has to be designed in rather than bolted on. Our walkthrough on how to build and publish an MCP server with audited writeback shows the pattern in practice.
Finally, the agent’s actions must be reconstructable for the Article 23 incident-reporting cascade. If you cannot answer “which records, which fields, which time window” within hours, you cannot meet the 24-hour and 72-hour deadlines. The role-based controls that gate agent access are documented in the Peliqan permission layer for AI agents.
Why most MCP servers fail NIS2 readiness
Most MCP platforms shipped in 2025 and 2026 were built for the agentic-tooling problem first and the European-regulation problem second. Four structural gaps recur, and each maps to a specific Article 21 or Article 23 obligation.
- US hosting and no EU data residency. Several popular servers are US-headquartered and US-hosted by default. A US legal entity stays reachable under the CLOUD Act regardless of which region the data physically sits in, a point we develop in the GDPR-compliant MCP servers reference.
- No audit trail. Many servers proxy prompts against live data without logging the originating user, source dataset, mutation payload, and response, so there is no artefact to hand a supervisory authority.
- No incident logging. Without a unified, searchable log, scope reconstruction takes days, and the Article 23 early-warning clock runs out in 24 hours.
- No writeback governance. Action-based wrappers execute mutations but do not capture enough context to defend a single write in an audit, and rarely enforce human-in-the-loop approval.
The architectural fix is to put a warehouse beneath the MCP server so the audit log is a by-product of normal operation, not a separate workstream, the pattern set out in our cross-source MCP guide.
The Peliqan NIS2 architecture: warehouse-first audit trail, EU hosting, governed writeback
Peliqan was built EU-hosted and warehouse-first from day one, so the NIS2 procurement questions have prebuilt answers rather than retrofitted ones. The platform is a Belgian entity headquartered in Ghent, hosted EU-only on AWS Frankfurt, with no US parent and no CLOUD Act inheritance.
How Peliqan maps to the NIS2 control surface
- Audit trail by default: a built-in Postgres and Trino warehouse means every prompt-to-SQL translation, row read, and reverse-ETL writeback is logged with the session identifier, supporting Article 21 measures 1, 5, and 6 and the Article 23 reconstruction.
- Governed writeback: reverse ETL routes every mutation through one audited path with explicit approval, satisfying the human-oversight and incident-handling expectations.
- Data minimisation and access control: column-level masking and a role-based permission layer address measures 9 and 10.
- Certification evidence: SOC 2 Type II, ISO 27001:2022, GDPR, HIPAA, and CCPA are all achieved, and ENISA guidance treats an ISO 27001 ISMS as primary evidence for much of Article 21.
- Data sovereignty option: a Private Sovereign Cloud single-tenant deployment with region-locked storage for the strictest operators.
The warehouse-first design is what produces the lineage a regulator asks for; the mechanics are documented in the Peliqan data lineage guide.
The platform ships 300+ connectors with a two-week custom-connector SLA, and the warehouse, federated query engine, and MCP server are covered on the platform overview. The full certification set and sub-processor list live in the Peliqan security and compliance center.
Customer proof: CIC Hospitality
CIC Hospitality runs Peliqan as an EU-hosted data plane across 50+ data sources, including guest records, POS transactions, and HR data. Column-level masking redacts sensitive fields before any AI agent reads them, and the unified audit log is the same artefact that would support an Article 23 breach reconstruction, while the team saves 40+ hours per month on board reporting. Read the case studies.
NIS2 + DORA + EU AI Act stacking: the regulatory quintet
NIS2 rarely arrives alone. For a regulated EU operator it stacks with up to four other regimes, and the interactions matter for how you build.
- NIS2 vs DORA. DORA (Regulation (EU) 2022/2554) is lex specialis for financial entities. Under NIS2 Article 4, where a sector-specific act imposes requirements at least equivalent in effect, the relevant NIS2 provisions do not apply to those entities. In practice a bank meeting DORA’s tighter initial-report clock satisfies the NIS2 24-hour requirement. Our DORA + MCP playbook covers the financial-entity case in depth.
- EU AI Act. Article 26 deployer obligations for high-risk systems add human oversight, log retention, and incident-cooperation duties, detailed in our EU AI Act and MCP reference.
- GDPR and Peppol. GDPR governs personal data in the systems the agent touches, while Peppol mandates structured e-invoicing across an expanding set of EU countries, the subject of our pan-EU Peppol MCP pillar.
The common thread is that one EU-hosted, audit-logged architecture answers all five at once. No US-hosted vendor satisfies the quintet without re-architecting jurisdiction.
Incident reporting workflow with MCP: the Article 23 cascade
Article 23 imposes the most prescriptive incident-reporting regime in EU cybersecurity law. It is triggered by a significant incident, one that has caused or can cause severe operational outages or financial loss, or considerable damage to others. The clock starts when the entity becomes aware of the incident, not when the investigation finishes.
The three mandatory deadlines (Article 23)
- 24-hour early warning: flagging whether the incident is suspected to be malicious and whether it could have cross-border impact.
- 72-hour incident notification: an initial severity and impact assessment plus indicators of compromise where available.
- 1-month final report: a detailed description, root-cause analysis, and remediation measures, with a progress report instead if the incident is still live.
A warehouse-first MCP server makes the cascade mechanical rather than heroic. Because every agent read and writeback is logged in one ledger, the security team can answer “which subjects, which fields, which time window” in hours, not days, and the same log feeds any parallel GDPR Article 33 notification, which also runs on a 72-hour clock. The writeback path that produces those records is documented in the Peliqan reverse ETL guide.
Sector-specific examples: energy, transport, banking, health, digital infrastructure
NIS2 reaches deep into operational technology, and the sector you operate in shapes both your obligations and your realistic threat model.
- Energy (electricity, oil, gas, hydrogen, district heating): essential entities running ICS and SCADA, where an AI agent writing back to operational systems needs the strictest human-in-the-loop gates.
- Transport (air, rail, water, road): ENISA recorded transport as one of the most-targeted EU sectors in 2025.
- Banking and financial market infrastructure: in Annex I, but governed primarily by DORA under the Article 4 lex-specialis rule.
- Health (hospitals, reference laboratories, device and pharmaceutical manufacturers): masked access to patient data is non-negotiable.
- Digital infrastructure (cloud providers, data centres, IXPs, DNS, TLD registries): several of these are in scope regardless of size.
- Public administration: central and regional government, the most-targeted EU sector in 2025.
Public administration absorbed 38.2% of all sector-attributed incidents in the ENISA Threat Landscape 2025, which analysed 4,875 incidents from 1 July 2024 to 30 June 2025, primarily due to hacktivist-led DDoS attacks. Essential entities accounted for more than half of recorded incidents in the same period, confirmation that the sectors NIS2 prioritises are precisely the ones under pressure.
NIS2 readiness compared: Peliqan vs Composio vs Workato vs Pipedream
Ratings reflect each vendor’s public posture as of mid-2026 and should be reverified during procurement. The issue with the US-parented vendors is structural jurisdiction, not security maturity.
For a broader catalogue of MCP options for European businesses, see our roundup of the best MCP servers for European businesses.
Implementation checklist for NIS2-bound EU operators
- Classify your entity. Run the sector (Annex I/II) and size (Recommendation 2003/361/EC) filters and document the rationale as a scoping memo.
- Map Article 21 gaps. Compare current controls against the ten measures and map them to ISO 27001 and ENISA technical guidance, which national regulators accept as evidence.
- Fix the supply-chain assessment. Treat every MCP and ICT vendor as an Article 21(2)(d) supplier and capture jurisdiction, certifications, and secure-development practices.
- Pre-build the reporting templates. Have the 24-hour, 72-hour, and one-month formats ready, keyed to your CSIRT or competent authority, with a named owner.
- Demand audit-grade logging from the agent layer. Insist on a unified log of every read and writeback with user, dataset, payload, and response attribution.
- Verify EU jurisdiction, not just an EU region. Confirm the legal entity is inside the EU, not a US parent operating an EU data centre.
- Document board oversight. Record management-body approval and training to satisfy Article 20. The agent build pattern is covered in the guide to building AI agents in Peliqan.
A practical note on timing: as of mid-2026 there are no public, named NIS2 fines, national authorities are at the registration and remediation stage, mirroring early GDPR enforcement. The window to get the architecture right before the first wave of audits is open, but narrowing.
Getting started
If you are an essential or important entity preparing to put AI agents into production, the cheapest defensible decision is to choose the data layer for jurisdiction, audit trail, masking, and writeback governance before the first agent ships, because the same artefacts satisfy NIS2 Article 21, the Article 23 cascade, your SOC 2 renewal, and the EU AI Act in one evidence pack.
Browse the full connector library to see the 300+ sources and targets available, and explore the governed MCP layer on the Peliqan MCP page.
