MCP and EU regulation: GDPR, DORA, NIS2 and the AI Act

Anyone hooking an AI agent up to a CRM, ERP or policy administration system via MCP is, legally speaking, doing nothing new: there is no "MCP law". But the combination of four existing frameworks — GDPR, DORA, NIS2 and the AI Act — does touch MCP use at points where most organisations have no answer yet. That this is no theoretical debate is clear from the adoption figures: according to the 2026 Stacklok survey, 41% of enterprises already have MCP in production, and Anthropic reported over 10,000 active public MCP servers at the end of 2025. At the same time, according to Integrate.io, 65% of financial institutions cite data security as the biggest barrier to agentic AI. This article walks through the four regulations, with a practical checklist for each. New to MCP? Start with what MCP is and how it works.

Does an MCP server fall under the GDPR?

The core question under the GDPR is: who processes the personal data flowing through the MCP connection? If the MCP server runs locally on your own infrastructure, you remain the controller and no additional party is involved. But if you use a hosted (remote) MCP server from a third party, or send customer data through the connection to an AI model provider, those parties are processors — and a data processing agreement is mandatory. In practice that question is rarely asked: MCP servers are installed by developers, not reviewed by privacy officers. The Dutch DPA (Autoriteit Persoonsgegevens) points out in its guidance on the security of personal data the duty to take appropriate technical and organisational measures; for violations, data protection authorities can impose fines of up to €20 million or 4% of worldwide annual turnover.

Two GDPR topics deserve extra attention with MCP. First, the DPIA: for processing operations with a high privacy risk, a data protection impact assessment is mandatory. An AI agent that independently searches customer files, reads emails or combines data from multiple systems is exactly such an operation — especially where special categories of personal data are involved, such as health data in a policy administration or absence-management file. Second, the breach notification duty: a compromised MCP server easily amounts to a data breach that must be reported to your data protection authority. That is no hypothetical scenario. In September 2025, the malicious npm package postmark-mcp was caught silently forwarding every outgoing email — password resets, invoices, internal memos — to an attacker. Anyone running that server with customer email had a breach to report.

What does DORA mean for financial institutions using MCP?

For banks, insurers, pension funds and investment firms, DORA comes on top of this. DORA requires financial institutions to manage their ICT third-party risk: every external ICT service provider must be mapped, included in the register of information and continuously monitored. An external MCP server, a vendor's MCP gateway and the AI model provider itself are each such ICT third parties — even if a developer connected them "just quickly" without a procurement process. There is also a recognised blind spot here: security researcher Bitsight points out that DORA contains no provisions that specifically address AI model providers or orchestration layers such as MCP. The obligation to manage the risk still exists, but the translation to this new category of suppliers is something every institution has to make itself — and be able to explain to its supervisor.

That supervisor is watching closely in 2026. DNB, the Dutch central bank, has announced it will tighten supervision of AI and cyber resilience at banks and insurers this year, and according to Integrate.io an expected 44% of finance teams will use agentic AI in 2026 — a 600% increase on a year earlier. The combination of rapid adoption and a regulatory gap makes MCP use at financial institutions a classic case of "permitted, but prove you are in control". For what this looks like per subsector, see our guides for banking and fintech and insurance.

Why does NIS2 touch every MCP connector?

NIS2 — implemented in the Netherlands through the Cyberbeveiligingswet (Cybersecurity Act) — obliges essential and important entities to manage risk across the entire supply chain. And that is exactly where MCP changes the playing field: every MCP connector an employee adds is a new supplier dependency and a new attack surface. Where a traditional SaaS vendor enters through a procurement process, an MCP server is often added with a single install command — inheriting the user's permissions and access to real business data. The risk is concrete: the UpGuard study of the MCP ecosystem (2026) found that 10 to 16% of servers in the registries examined are typosquats or lookalikes, with three to fifteen unverified imitations per official brand server. One mistyped server name installs an attacker's code.

Things also go wrong further upstream in the chain. In October 2025, a path traversal flaw at hosting platform Smithery leaked a token that gave control over more than 3,000 hosted MCP servers, and the postmark-mcp incident showed that a trusted package can turn malicious in a single point release. For NIS2 this means treating your MCP connectors like any other critical supplier: inventoried, assessed, monitored — and covered by your incident reporting process towards the regulator. The technical measures that go with this (allowlists, sandboxing, version pinning, egress control) are covered in detail on our security page.

What does the AI Act require from companies using MCP?

The AI Act is the only one of the four written specifically for AI, and the clock is ticking: the remaining obligations take effect in August 2026 and August 2027. For most MCP applications — an assistant that summarises meeting notes or looks up data — the obligations remain limited. But the AI Act designates credit scoring and insurance pricing, among others, as high-risk applications, and that is exactly where MCP gets interesting: the protocol makes it easy to connect an AI model directly to underwriting, pricing or scoring systems. Do that, and you pull in the high-risk requirements: risk management, data quality, technical documentation, logging, human oversight. The Dutch financial markets authority AFM is being given new supervisory tasks here; in June 2026 it published an implementation assessment of its role under the AI Act.

The Dutch supervisory agenda gives a sense of what is expected. The AFM named digital resilience and responsible AI as priorities for 2026, wants rules for the deployment of AI agents in capital markets, and is already calling on institutions to do three things: inventory AI applications, document decision logic and report incidents. For MCP use, that means concretely: record which agent can access which systems, which tools it may invoke, and on what basis it prepares or takes decisions. That documentation is harder with agentic AI than with a classic model — an agent combines tools and data differently in every session — which is exactly why you want to set it up from day one rather than reconstruct it afterwards.

How do you approach this in practice?

The four regulations impose different requirements, but the foundation is always the same: know what is running, know where your data goes, and be able to demonstrate that you are in control. Lay that foundation, and you cover most of all four frameworks at once.

1. Inventory all MCP servers and AI connections in the organisation, including anything installed outside IT.
2. Classify each connection: which personal data (GDPR), which supplier (DORA/NIS2), which risk category (AI Act).
3. Sort out the paperwork: data processing agreements, inclusion in the register of information, DPIAs where needed.
4. Restrict technically: allowlist, minimal scopes, EU data location, logging — see the security page for the full approach.
5. Document and monitor: record decision logic, pin versions, test your incident process, and reassess periodically.

Last updated: 2026-07-06