MCP server GDPR compliance security: lawful basis, data subject rights, and DPA obligations

GDPR and the MCP server data processor role

Under GDPR Article 4, a data processor processes personal data on behalf of a controller. An MCP server that provides tool access to a database of EU personal data is acting as a data processor — even if it's deployed internally. This has three immediate implications:

• A Data Processing Agreement (DPA) must exist between the data controller (your company) and any external MCP server provider
• The MCP server must implement appropriate technical measures per Article 32 (encryption in transit, access controls, audit logging)
• The MCP server's tool invocation logs are subject to data subject access requests (DSAR) — a subject can request all data processing records about them

Lawful basis for MCP tool access

GDPR Article 6 requires a lawful basis for every processing activity. For MCP tools accessing personal data, the basis must be documented before the tool is deployed:

• Contract (Art. 6(1)(b)): Tool accesses customer data necessary to fulfill a contract — get_order_history(customer_id) when the customer requests it
• Legitimate interest (Art. 6(1)(f)): Requires a Legitimate Interest Assessment (LIA) balancing test — cannot override data subject rights
• Consent (Art. 6(1)(a)): Freely given, specific, informed, unambiguous — the hardest to maintain for agentic AI use cases
• Legal obligation (Art. 6(1)(c)): Tool accesses data required for regulatory reporting — e.g., fraud detection required by AML regulations

The key architectural implication: each MCP tool should have a documented lawful basis, and the tool should only be callable when that basis applies to the current session's data subject context. A tool with a "contract" basis for one customer should not be callable for data about a different customer on a different contract.

Purpose limitation: per-tool scoping

GDPR Article 5(1)(b) requires data be used only for the purpose for which it was collected. In MCP server design this means tool-level purpose scoping:

• A search_customer_emails tool collected for customer service purposes cannot be repurposed for marketing segmentation in the same agent session
• Tool arguments should not accept purpose-override parameters that circumvent this restriction
• The agent orchestrator's system prompt cannot instruct the MCP server to process data "for a different purpose" — purpose limitation runs at the data layer, not the prompt layer

Data minimisation: tool interface design

Article 5(1)(c) requires data minimisation — collecting only what's necessary. For MCP server tool interfaces this means:

• Return only the fields needed for the agent's task — not the full record. A get_customer_name(id) should return only the name, not email, DOB, and address too
• Avoid aggregate tools that return lists of personal data when the agent only needs a count or summary
• PII fields should be explicitly declared in the tool's schema — SkillAudit flags undeclared PII in tool return types

Data subject rights: what the MCP server must support

GDPR grants data subjects rights that must be technically implementable. For MCP servers managing personal data:

• Right of access (Art. 15): If the MCP server's audit logs contain personal data, those logs must be retrievable per-subject for DSAR responses within 30 days
• Right to erasure (Art. 17): A delete_customer_data operation must actually delete from all MCP-accessed datastores — not just mark deleted in the primary DB while leaving cached data in MCP server session state
• Right to portability (Art. 20): Where the lawful basis is consent or contract, subjects can request their data in a structured machine-readable format — the MCP tool interface should support export operations
• Right to object (Art. 21): For legitimate interest basis, subjects can object to processing — the MCP server must be able to block tool calls for a specific subject when an objection is registered

Breach notification: when an MCP security incident becomes a GDPR notification

GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. For MCP servers, the following security incidents trigger notification obligations:

• Prompt injection attack that causes the MCP server to exfiltrate personal data to an attacker-controlled destination (SSRF-assisted exfiltration)
• Unauthorized tool calls due to authentication bypass — if personal data was accessed
• MCP server log files containing personal data are exposed via log aggregation misconfiguration
• Supply chain compromise where a malicious npm package in the MCP server exfiltrates data processed by tool calls

The 72-hour clock starts when your security team becomes aware — not when the breach occurred. Your MCP server's audit logging is your primary evidence source for determining scope (which subjects were affected, what data was accessed) and demonstrating the containment response.

Technical measures: Article 32 requirements for MCP servers

Article 32 requires "appropriate technical and organisational measures" including pseudonymisation, encryption, and ongoing testing. For MCP servers specifically:

• Encryption in transit: TLS 1.2+ on all MCP connections, including internal network segments
• Pseudonymisation: Where feasible, replace direct identifiers in tool arguments with pseudonymous tokens resolved by the MCP server — reduces exposure if a tool argument is logged
• Access control: Per-tool authorization based on the authenticated agent session's data subject context
• Ongoing testing: Regular security assessment of the MCP server — SkillAudit's automated scan satisfies the "regular testing" requirement for the static analysis component
• Incident response procedure: Documented process for detecting, containing, and reporting MCP security incidents, with the 72-hour notification timeline explicitly planned

What SkillAudit checks for GDPR-scoped MCP servers

SkillAudit's scan identifies findings relevant to GDPR technical requirements: credential exposure in logs (Article 32 encryption/access control), SSRF vulnerabilities (exfiltration risk → Article 33 breach), missing per-tool authorization (Article 5 purpose limitation), and PII handling patterns in return types. The Team plan audit report includes a GDPR Article mapping table alongside findings — usable as evidence in a Data Protection Impact Assessment (DPIA) or supervisory authority response.

Related: MCP server audit trails for SOC 2 and GDPR · MCP security review checklist · MCP server SOC 2 Type II security