MCP Server Compliance for EU Regulated Workloads: DSGVO, NIS2, DORA, AI Act, and the EU-Hosted Audit Trail Agents Need

Companion to the MCP Spotlight series · Last updated: 2026-07-31 Maintainer: Facio engineering · Status: Compliance-reference guide Audience: Compliance officers, security engineers, and operators deploying MCP in EU regulated industries (DACH, financial services, healthcare, public sector)

The MCP ecosystem in 2026 has crossed 500 published servers and handles billions of tool calls per day across thousands of production deployments. A growing share of those deployments are EU regulated — financial services under DORA, critical infrastructure under NIS2, AI systems under the AI Act, all data processing under DSGVO. MCP is not just a developer convenience anymore; it's a regulated data-processing surface. Every tool call potentially moves personal data, triggers compliance-relevant operations, or creates audit artifacts. Deploying MCP in the EU without a compliance-first mindset is the kind of decision that gets a compliance officer fired in 2026.

This post is the EU-compliance reference for MCP in 2026: what the regulations actually require, how MCP servers should be designed to meet those requirements, and the operational practices that make a deployment audit-ready.

The EU Regulatory Stack

Five regulations shape MCP deployments in the EU:

Regulation	Scope	Effective	What It Means for MCP
DSGVO (GDPR)	All personal data processing	2018	Personal data must stay in EU unless explicit basis for transfer; right to erasure, right to access, right to data portability
NIS2	Critical infrastructure, digital services	2024 (national implementations 2025-2026)	Cybersecurity requirements for incident response, supply chain risk, business continuity
DORA	Financial services	Jan 17, 2025	Operational resilience for ICT, third-party risk management, incident reporting
AI Act	AI systems (high-risk, general-purpose)	Phased 2025-2027	Transparency, risk management, human oversight, technical documentation
Data Act	Data generated by connected products	Sep 12, 2025	Portability, interoperability, FRAND terms for data sharing

Each regulation has implications for MCP. The aggregate is a compliance-first design floor that affects every layer of the deployment.

DSGVO Compliance for MCP Servers

The General Data Protection Regulation applies to any processing of EU residents' personal data. MCP tool calls frequently involve personal data — customer profiles, contact information, communication content, payment details. The compliance requirements:

Data Minimization (Article 5)

MCP servers should expose only the minimum data necessary for the operation. Concretely:

# Bad: returns full customer record
get_customer(id="cus_123")
  → Returns: {name, email, phone, ssn, address, billing_history, ...}

# Good: returns only what the agent asked for
get_customer_summary(id="cus_123", fields=["name", "email"])
  → Returns: {name, email}

The tool description should guide the agent toward field-level scoping. Don't expose raw database rows; expose structured, purpose-limited records.

Purpose Limitation (Article 5)

Each tool call should have a declared purpose. The agent's system prompt should specify which tools are authorized for which purposes. For multi-purpose agents, each tool call should include a purpose identifier:

create_issue(
  title="...",
  description="...",
  teamId="...",
  purpose="customer-feedback-processing",
  legal_basis="legitimate-interest"
)

The audit trail records the purpose + legal basis for every operation. Compliance officers can answer "why was this data accessed?"

Right to Erasure (Article 17)

For personal data the agent stores or processes, erasure must be possible. The Memory MCP's delete_entities and delete_observations tools enable this. For SaaS MCPs (Linear, Notion, GitHub), the upstream platform's data-deletion APIs must be wired into the erasure workflow:

// On erasure request
1. identify_data_sources()  → Returns the list of MCPs holding the user's data
2. For each source:
   a. Call the upstream's delete API
   b. Verify the deletion
3. delete_observations(entityName=user)  // Memory MCP
4. audit_log("user_X erasure completed, Y records deleted across Z sources")

The 30-day deadline (Article 12) means the erasure workflow must be automated, not manual.

Right to Access (Article 15)

The user can request all data held about them. The MCP layer must support data export:

// On access request
1. identify_data_sources()
2. For each source:
   a. Call the upstream's export API
   b. Aggregate the exports
3. Return the bundle to the user

The Memory MCP's read_graph + Notion's query-data-source + GitHub's search_issues compose into a unified data export. The audit trail shows what was exported, when, to whom.

Cross-Border Transfer (Articles 44-50)

The default rule: EU personal data stays in the EU. The MCP server's hosting matters:

Hosting	EU Compliance
EU-hosted (Frankfurt, Dublin, Stockholm)	Compliant by default
US-hosted (us-east-1, us-west-1)	Requires Standard Contractual Clauses (SCCs), Transfer Impact Assessment
Multi-region (EU + US)	Requires data-residency controls

For DSGVO-critical workloads, EU-hosted MCP servers are non-negotiable. The Docker MCP Catalog lets you filter by region; the Facio ecosystem defaults to EU hosting.

For mixed-region setups (some data in EU, some in US), the transfer is restricted to the data the agent actually needs. Don't transfer personal data across regions when EU-equivalent processing is available.

Lawful Basis

Each tool call must have a lawful basis. The most common:

Basis	Use Case
Consent	User explicitly authorized the processing
Contract	Processing is necessary to fulfill a contract with the user
Legal obligation	Processing is required by law (e.g., tax records, anti-money-laundering)
Legitimate interest	Processing is necessary for legitimate business interest, balanced against user rights

The agent's system prompt should declare the lawful basis per tool. The audit trail records it. Compliance officers can answer "what was the legal basis for this processing?"

NIS2 Compliance for MCP

The NIS2 Directive applies to essential and important entities — energy, transport, banking, health, digital infrastructure, public administration. For MCP deployments in these sectors:

Risk Management (Article 21)

NIS2 requires proportionate technical and organizational measures. For MCP:

• Supply-chain risk management — verify MCP server publishers, image provenance, signing
• Vulnerability handling — patch cadence for MCP servers, dependency updates
• Cryptography — encryption at rest, in transit, end-to-end for sensitive tool calls
• Access control — principle-of-least-privilege for MCP tool permissions, audit logging

The Docker MCP Catalog's signature + provenance model is the supply-chain primitive NIS2 expects. The Facio HITL gating + audit trail is the access-control primitive.

Incident Handling (Article 21)

NIS2 requires incident detection, response, and reporting. For MCP:

• Detection — anomalous tool calls, unexpected data flows, credential anomalies
• Response — kill switch for compromised MCP servers, credential rotation, isolation
• Reporting — within 24h early warning, 72h notification, 30-day final report for significant incidents

Facio's audit trail captures every tool call; the anomaly detection layer flags suspicious patterns. The kill switch is the Facio runtime's ability to stop the agent + revoke MCP server access.

Business Continuity (Article 21)

NIS2 requires backup, disaster recovery, crisis management. For MCP:

• Backup — Memory MCP's local JSON file is git-versioned; PostgreSQL backups are regular
• Disaster recovery — MCP servers can be redeployed via Docker in minutes; audit trail survives
• Crisis management — escalation paths, on-call, incident command

The MCP ecosystem's docker-based distribution makes disaster recovery straightforward. The audit trail is append-only and replicated.

Supply-Chain Security (Article 21)

NIS2 specifically calls out supply-chain risk management for direct suppliers and service providers. For MCP:

• Publisher verification — only Docker MCP Catalog verified publishers
• Image signing — cosign verification before deployment
• Provenance attestation — SLSA L3, build-from-commit, CI attestations
• Vulnerability scanning — daily CVE scans, patch SLAs
• Concentration risk — diversify MCP server publishers, avoid single-vendor dependency

For MCP servers touching critical systems, only Docker MCP Catalog with signature verification is acceptable. npm-distributed servers are too risky.

DORA Compliance for MCP

DORA applies to financial entities — banks, insurance, investment firms, crypto-asset service providers, ICT third-party service providers. For MCP deployments:

ICT Risk Management (Article 6-16)

DORA requires comprehensive ICT risk management including:

• Identification — catalog all ICT systems, dependencies, MCP servers
• Protection — encryption, access control, HITL gating for destructive operations
• Detection — anomaly detection, audit trail monitoring
• Response — incident response procedures, MCP server kill switches
• Recovery — backup, restore, BCP testing

The Facio audit trail + HITL gating is the protection primitive. The kill switch + anomaly detection is the response primitive. The Memory MCP git-versioned backup is the recovery primitive.

ICT Third-Party Risk (Article 28-30)

DORA specifically regulates third-party ICT service providers. For MCP:

• Register of contracts — every MCP server in use, its publisher, its scope, its SLAs
• Risk assessment — per MCP server: data processed, jurisdictions involved, failure modes
• Concentration risk — avoid dependency on single MCP publishers; diversify
• Exit strategies — ability to replace any MCP server, no vendor lock-in

The MCP registry metadata (Docker MCP Catalog, Glama) provides the publisher + provenance data. The Facio runtime's portability (any MCP server can be replaced without code changes) is the exit strategy.

Incident Reporting (Article 17-23)

DORA requires major ICT-related incident reporting to the competent authority:

• Initial notification — within 4 hours of classification
• Intermediate report — within 72 hours
• Final report — within 1 month

For MCP, the audit trail + kill switch provide the inputs:

1. Major incident detected (e.g., compromised MCP server)
2. Kill switch activated (server disabled, credentials rotated)
3. Audit trail extracted (full record of the incident)
4. Initial notification generated (within 4h)
5. Intermediate report (within 72h)
6. Final report (within 1 month)

The 4-hour window is tight — the Facio kill switch + audit extraction must be automated, not manual.

Resilience Testing (Article 24-27)

DORA requires periodic resilience testing including:

• Vulnerability assessments — quarterly, including MCP dependencies
• Penetration testing — annual, with MCP servers in scope
• Red team exercises — for significant entities

For MCP, the penetration test specifically includes:

• Prompt injection via tool output
• Agentjacking via attacker events
• Tool squatting via name collisions
• Supply-chain via malicious servers
• Credential leakage via misconfigured transports

The MCP security threat model (covered in a companion post) is the test plan.

AI Act Compliance for MCP

The EU AI Act is the world's first comprehensive AI regulation. For MCP:

Provider Obligations (Article 16-22)

If your MCP-powered agent is a "provider" of an AI system, you must:

• Risk management system (Article 9) — identify, evaluate, mitigate risks across the lifecycle
• Data quality (Article 10) — training/validation data quality, bias testing
• Technical documentation (Article 11) — system architecture, design choices, compliance evidence
• Record-keeping (Article 12) — automatic logging of operations
• Transparency (Article 13) — user-facing instructions, system capabilities, limitations
• Human oversight (Article 14) — designed for effective human supervision
• Accuracy, robustness, cybersecurity (Article 15) — appropriate levels across all dimensions

For MCP, the relevant obligations:

Article	MCP Implication
9 (Risk management)	Threat model + defense-in-depth (covered in companion post)
11 (Documentation)	MCP server docs, Facio audit trail exports
12 (Logging)	Facio's tamper-evident audit log
13 (Transparency)	MCP server tool descriptions, agent's system prompt
14 (Human oversight)	Facio HITL gating on destructive operations
15 (Cybersecurity)	Defense-in-depth stack (signature + isolation + RBAC + HITL + audit)

High-Risk AI Systems (Annex III)

MCP-powered agents that fall under high-risk categories:

• Biometric identification — agents accessing biometric data
• Critical infrastructure — agents managing power, water, transport
• Education / vocational training — agents making educational decisions
• Employment / worker management — agents making hiring / performance decisions
• Access to essential services — agents determining access to public services, credit
• Law enforcement — agents supporting law enforcement operations
• Migration / border control — agents in migration contexts
• Justice / democratic processes — agents in judicial or electoral contexts

For high-risk agents, the compliance burden is substantial: conformity assessment, CE marking, registration in EU database, ongoing post-market monitoring. MCP deployments in these categories need legal review.

General-Purpose AI Models (Article 51-55)

If the underlying LLM (e.g., GPT-4, Claude, Gemini) is a general-purpose AI model, the model provider (OpenAI, Anthropic, Google) handles GPAI compliance. The MCP server authors and agent operators are downstream — they use the model but don't redistribute it.

For MCP servers, the obligations are lighter: provide documentation about the model's capabilities, support the operator's compliance work, avoid misuse-enabling design.

Data Act Compliance for MCP

The Data Act (effective Sept 12, 2025) applies to data generated by connected products (IoT, industrial machines, vehicles). For MCP deployments:

• Portability — users can move their data to other providers
• Interoperability — data formats must be standard, not proprietary
• FRAND terms — data sharing with third parties must be fair, reasonable, non-discriminatory

For MCP servers that handle IoT-generated data (e.g., a Cloudflare MCP server managing connected-device telemetry), the compliance pattern is:

• Standard data formats — JSON, CSV, Parquet, not proprietary blobs
• Export APIs — users can export their data
• Portability documentation — clear migration paths

For most MCP deployments, the Data Act's primary impact is avoiding proprietary lock-in. Use standard formats; provide export APIs.

The EU Compliance Stack for MCP

The aggregate design floor for EU regulated workloads:

┌──────────────────────────────────────────────────────────────┐
│ Layer 7: Tamper-evident audit trail (Article 12, NIS2 21)    │
├──────────────────────────────────────────────────────────────┤
│ Layer 6: HITL gating (Article 14)                            │
├──────────────────────────────────────────────────────────────┤
│ Layer 5: Per-tool RBAC + purpose + legal basis               │
├──────────────────────────────────────────────────────────────┤
│ Layer 4: Output sanitization (Article 5, Article 15)         │
├──────────────────────────────────────────────────────────────┤
│ Layer 3: Container isolation + EU hosting (Articles 44-50)   │
├──────────────────────────────────────────────────────────────┤
│ Layer 2: Signature + provenance (NIS2 21, DORA 28)           │
├──────────────────────────────────────────────────────────────┤
│ Layer 1: EU-hosted registry, verified publishers             │
└──────────────────────────────────────────────────────────────┘

Each layer addresses a specific regulatory requirement. Skipping any layer creates a compliance gap.

The EU-Hosted Server Checklist

Before deploying any MCP server in an EU regulated workload:

□ Publisher identity verified (Docker MCP Catalog, official org)
□ Image signature verified (cosign)
□ Provenance attested (SLSA L3, build-from-commit)
□ No high/critical CVEs (Docker Scout, Trivy)
□ Hosting is EU-resident (Frankfurt, Dublin, Stockholm — never us-east-1 for personal data)
□ Data residency is configurable (per-tenant EU region)
□ Tool surface is minimal (data minimization)
□ Output sanitization is in place (length bounds, structured format, encoding normalization)
□ Secrets are brokered, not exported (per-tenant scoping)
□ Transport is stdio local-only OR authenticated HTTP (mTLS, OAuth)
□ HITL gating is configured per tool severity
□ Audit trail is append-only, tamper-evident, EU-resident
□ Right-to-erasure workflow is tested (per Article 17)
□ Right-to-access workflow is tested (per Article 15)
□ Cross-border transfer is restricted (no US fallbacks for EU personal data)
□ Incident response runbook includes MCP-specific scenarios
□ BCP tested (MCP servers can be redeployed in target EU region)
□ Penetration test includes MCP threat model
□ Documentation includes AI Act Article 11/13/14 evidence

A server that passes all 20+ checkboxes is EU compliant by design. Anything less is a gap.

The Operational Discipline

Beyond the design, MCP compliance requires operational discipline:

• Quarterly compliance reviews — verify all MCP servers still meet the regulatory bar
• Annual penetration tests — include the MCP threat model
• Incident response drills — practice the 4-hour DORA notification window
• Data Protection Impact Assessments (DPIAs) — for high-risk processing changes
• Records of Processing Activities (RoPA) — maintained per Article 30
• Audit trail retention — minimum 1 year, often 5+ for regulated industries
• Vendor risk reviews — for each MCP publisher, the EU equivalent of SOC2

For most teams, this is a substantial compliance burden. The good news: the patterns are well-understood, the tooling exists (Facio + Docker MCP Catalog + signed images + audit trail), and the design floor is achievable.

The Facio EU Compliance Posture

For Facio as a HITL agent runtime, the compliance posture:

• EU-hosted by default — Facio's infrastructure is Frankfurt-based
• DSGVO-compliant — Article 28 processor terms, Article 32 security measures, Article 30 RoPA-ready
• NIS2-aligned — risk management, incident handling, business continuity, supply chain
• DORA-aligned — ICT risk management, third-party risk, incident reporting, resilience testing
• AI Act-aligned — transparency, human oversight, documentation, logging
• Audit trail — tamper-evident, EU-resident, append-only, Article 12 evidence

For customers deploying Facio + MCP in EU regulated workloads, the compliance transfer is straightforward: Facio provides the runtime + audit; MCP servers provide the data + actions; the operator is the data controller. The compliance artifacts are composable.

Bottom Line

EU regulated workloads in 2026 require compliance-first MCP design. The five regulations (DSGVO, NIS2, DORA, AI Act, Data Act) each impose specific obligations; the aggregate is a substantial compliance floor.

The good news: the design patterns are known. EU hosting, data minimization, purpose limitation, right-to-erasure, right-to-access, audit trail, HITL gating, supply-chain security, incident response, BCP — all are achievable with Facio + Docker MCP Catalog + signed images + standard tooling.

For regulated industries in DACH, EU compliance is non-negotiable. The MCP ecosystem that operationalizes compliance (EU-hosted servers, signed images, audit trails, HITL gating) is the ecosystem that wins. Facio + the verified MCP servers are that ecosystem.

---

MCP Compliance for EU Regulated Workloads is part of the Facio engineering documentation. Companion to the MCP Spotlight series covering individual MCP servers. Last updated: 2026-07-31.