How a 450-person company in Germany kept Claude away from Salesforce while its GDPR review ran

A 450-person B2B software company in Germany keeps its customer contacts, deal notes, and support history in Salesforce. Most of that is personal data under GDPR. The company had rolled out Claude to sales, customer success, and engineering, and the sales team wanted Claude to read and update Salesforce records for them.

The data protection officer (DPO) wanted a data protection impact assessment (DPIA) first, covering what Claude would read, where that data would go, and on what terms. Until it was done, the ruling was simple: Claude must not reach Salesforce data.

IT turned off the Salesforce connector in the company's Claude admin settings on day 1. That setting covers the connectors the company offers centrally. It doesn't cover an MCP server someone adds to Claude Desktop on their own device, or a plugin that brings one with it. Nobody knew how many of those existed.

IT tested the package on its free devices on day 2, pushed it to the rest of the fleet through the same Workspace ONE policy, and had all 450 devices checked in by day 4. Each device needed one enrollment code approved in Control Plane.

A search for "salesforce" in Control Plane returned 23 devices. On 6 of them, the connector came from a Salesforce plugin from a public marketplace, which bundled a skill for updating opportunities and an MCP server that signed in to Salesforce. On the other 17, someone had added a Salesforce MCP server to Claude Desktop by hand, most of them in sales and customer success.

None of the 23 matched a threat rule. The components weren't malicious. They broke the DPO's rule, and that made them a policy problem to fix.

Control Plane received the component names, versions, hashes, and the devices that had them. Prompts, skill content, usernames, and file paths stayed on each device, so the check itself sent no customer data anywhere. The DPO asked about that first.

The plugin. Supply Chain can block plugins, so IT blocked the Salesforce plugin on day 5. The block status showed as applied on all 6 devices, and the plugin, with the MCP server it carried, could no longer load in Claude. Two people had it loaded in an open session, and Control Plane flagged their devices until each started a new one.

The hand-added servers. Supply Chain lists MCP servers and the devices that have them, which told IT exactly whom to ask. A hand-added server is removed in Claude Desktop's own settings, so IT wrote to the owners of the 17 devices, explained the DPO's ruling, and asked them to remove the server in Claude Desktop's settings. IT watched the count in Control Plane after each check-in: 17, then 9 by the end of week 1, then 0 by the end of week 3. Three people needed a call before they removed theirs.

Claude Code. About 40 people in revenue operations and engineering use Claude Code, and several had the Salesforce command line tool installed with a working sign-in. An agent could query customer records from the terminal without any connector. IT added Runtime to those 40 devices with a rule covering the Salesforce command line tool and network calls to the company's Salesforce domain. It ran in log mode for a week, which showed 4 attempts and no legitimate use the team needed to keep, and then switched to block. Runtime blocked 11 attempts in the first month, and each time Claude Code told the developer which rule matched.

Keeping it that way. New components start as unreviewed in Supply Chain, so IT saved the "salesforce" search and checks it each week. When the DPIA is signed off, IT will turn the admin connector back on, unblock the plugin if the DPO approves it, and switch the Runtime rule to ask for approval instead of blocking.

Signals Corps gave the DPO a record of where Salesforce connectors had been, when each one went, and what was blocked, to file with the impact assessment. The compliance decision stayed with the DPO. Claude used in a web browser, and data people paste into it, sit outside what Signals Corps covers.