Claude Enterprise Security and PII: What UK Businesses Need to Set Up (and What Stays Your Job)

The Short Version for Leaders#

Claude Enterprise is safe to use if you set it up deliberately. Out of the box it protects you from the big risks - your data isn't used to train AI, it's encrypted, and access can be tied to your company logins. What it doesn't do is decide what data your people put into it, and some of its default settings keep more data, for longer, than most UK businesses would choose.

Under UK data protection law, your business stays responsible for the personal data your staff put into Claude - not Anthropic. So the question for you isn't "is Claude safe?" It's "have we set it up and briefed our people so that how we use it is safe?"

What You're Getting - and What You're Not#

Five Defaults That Surprise Leaders#

1. Chats are kept forever by default. Unless someone sets a retention period, every chat - including any customer details in it - stays indefinitely. UK data protection law expects you to keep personal data no longer than needed.

2. Feedback is kept for five years. When a staff member clicks thumbs up or down on an answer, that conversation can be kept for five years and used to improve Anthropic's models - outside your normal retention period.

3. The audit trail only starts when you switch it on. Anthropic's Compliance API keeps six years of activity - but only from the day it's enabled. If you wait until something goes wrong, there's no history to look at.

4. Your data is stored in the US. There's currently no option to keep Claude Enterprise chat data in the UK or EU. That's allowed under UK law, but it means extra paperwork - and it's a question your clients may ask.

5. "Zero data retention" isn't what it sounds like. It isn't a setting you can turn on. Anthropic arranges it for qualifying customers, and it only covers Claude Code - the developer tool - not everyday chats. Don't let anyone promise it to a client unless you have it in writing.

Can We Stop Customer Data Reaching Anthropic at All?#

Yes - with some engineering. The approach works like a redacted file:

1. When Claude needs a customer record, a small piece of software inside your own systems fetches it and replaces personal details with codes - "Jane Smith" becomes "Customer 7F3A".
2. Claude does its work using the codes: summarising complaints, drafting replies, spotting patterns.
3. When Claude sends a reply or updates a record, your software swaps the codes back to the real details - again inside your own systems.

Anthropic only ever sees the codes. The customer still gets an email with their real name.

Do you lose quality? For most business tasks - summaries, drafts, triage, analysis - no. Claude doesn't need to know a customer's name to write a good reply. It does struggle with tasks that depend on the real detail, such as checking a name's spelling or validating an address. And it can't protect against someone copying data into a chat by hand, which is why staff guidance still matters.

This software is called a custom MCP server (MCP is the standard way Claude connects to other systems - explained here). It's a build project, typically measured in weeks, not a setting.

Why It's Worth Getting an Expert to Check the Setup#

The settings are spread across several admin screens, developer configuration files and your own legal documents. An expert review pays for itself in four places:

• Some choices can't be undone. Claiming every account on your email domain is one-way. Customer-managed encryption keys only protect data created after you switch them on. Audit history only exists from the day it's enabled. The order matters.
• Settings interact. Project retention settings override chat retention settings. Permission to "manage libraries" also lets someone add new connections to your systems. These are easy to miss.
• Settings must match your paperwork. Your DPIA should describe what's actually configured - and vice versa. Regulators and enterprise clients check both.
• No setting keeps personal data away from the model. That takes the engineering described above.

Your Action Plan#

This week#

1. Name an owner. One person accountable for Claude Enterprise settings - usually IT or security, with your data protection lead alongside.
2. Set a chat retention period. Agree a number with your data protection lead (the minimum is 30 days) and have your admin set it.
3. Switch on the Compliance API so your audit history starts today.
4. Decide on feedback. If you don't want conversations kept for five years via thumbs up/down, have the admin turn off chat rating.
5. Send a one-page staff rule: what may and may not go into Claude. Start with the traffic-light table further down.

This month#

1. Make sign-in automatic and removal instant. Company single sign-on (SSO), and automatic removal of leavers (SCIM) so access ends the moment HR processes a departure.
2. Set up roles. Not everyone needs every feature. Most staff need chat; fewer need connections to your CRM or email; only developers need Claude Code.
3. Turn off public sharing of Claude's outputs unless there's a business reason.
4. Complete a DPIA and transfer risk assessment, and ask Anthropic to confirm how the UK data transfer rules (the UK Addendum or IDTA) apply to your contract - we couldn't find this in their public documents.

This quarter#

1. Decide which systems Claude may connect to, and whether each connection may only read, or also change things.
2. Plan a masking connector for any system holding customer or employee data you want Claude to work with.
3. Review the settings quarterly. Anthropic adds features regularly - check new ones are off until you've decided on them.

Questions to ask your IT team#

• What's our chat retention period, and who agreed it?
• When did we switch on the Compliance API?
• Who can add new connections (connectors) to our systems?
• If someone pastes customer data into Claude today, how would we know?
• Which of our Claude settings does our DPIA describe - and do they match?

If someone pastes personal data into a chat#

Don't panic, and don't ignore it. Delete the chat - Anthropic removes deleted chats from its systems within 30 days (longer only if a chat was flagged for a safety policy breach). Tell your data protection lead so they can decide whether it needs recording, and use it as a reason to tighten the controls above.

What Enterprise Gives You Out of the Box#

• No training on your data by default. The exceptions are explicit feedback (thumbs up/down, retained for 5 years) and organisation opt-ins. Owners can disable feedback with "Rate chats" under Organization settings → Data and Privacy.
• Certifications: SOC 2 Type I and II, ISO 27001:2022, ISO/IEC 42001:2023.
• Encryption: AES-256 at rest, TLS 1.2+ in transit. Eligible Enterprise orgs can use customer-managed encryption keys (CMEK) via AWS KMS, Google Cloud KMS or Azure Key Vault - applied to new data only.
• DPA with Standard Contractual Clauses, incorporated into the commercial terms. We couldn't find the UK Addendum or IDTA stated in Anthropic's public DPA pages - confirm it for your contract.
• Residency: data is stored in the US; processing may be routed through the US, Europe, Asia or Australia. The only claude.ai Enterprise option is US-only inference (usage-based plans, billed at 1.1x). UK/EU residency is only available via the API on Bedrock, Vertex or Foundry.

Defaults and Gotchas#

Identity and Access#

• SSO: SAML (via WorkOS), with DNS TXT domain verification. We found no OIDC option documented.
• SCIM: Enterprise only - use it so offboarding is automatic.
• Session length: force re-authentication after 1, 7, 14 or 28 days. No idle timeout is documented.
• IP allowlisting: CIDR ranges, configured by Anthropic support.
• Roles: Primary Owner, Owner, Admin, User. Only Owners manage SSO and export audit logs.

Custom Roles: Your Main Control Surface#

Organization settings → Roles (Enterprise). Four tabs:

• Capabilities: Chat, Claude Code, Cowork, web search, memory, projects, artifacts, extended thinking, research.
• Connectors: per connector - Always allow, Needs approval or Blocked - with per-tool overrides via Custom. Use this to grant read tools on your CRM while blocking write tools.
• Models: enable models per role and cap the effort level per model.
• Permissions: delegated admin across Identity & Access, Billing, Analytics, Privacy, User Management, Libraries and Directory (No access / Can view / Can manage).

Least privilege in practice: few people should have Libraries: Can manage, because custom connectors can be added by Owners and by roles that manage libraries.

Feature and Sharing Toggles#

• Artifacts: separate toggles for artifacts, External sharing (public links) and external email invites. Disable external sharing by default.
• Project sharing: Data and Privacy → Sharing → "Share projects", and per role.
• Memory: off by default on Enterprise.
• Web search and code execution / file creation: Organization settings → Capabilities.
• Claude Desktop policies: isLocalDevMcpEnabled, isDesktopExtensionEnabled, isClaudeCodeForDesktopEnabled, secureVmFeaturesEnabled, forceLoginOrgUUID, plus a desktop extension allowlist (off by default).
• Claude in Chrome: org toggle with site allow and block lists.

Claude Code Managed Settings#

Deploy from the admin console (Admin Settings → Claude Code → Managed settings) or as managed-settings.json at:

• macOS: /Library/Application Support/ClaudeCode/
• Linux/WSL: /etc/claude-code/
• Windows: C:\Program Files\ClaudeCode\

A reasonable baseline:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "cleanupPeriodDays": 7,
  "forceLoginOrgUUID": "<your-org-uuid>"
}

• disableBypassPermissionsMode stops developers turning off permission prompts.
• deny rules block reads of secrets files.
• allowManagedPermissionRulesOnly and allowManagedMcpServersOnly stop local config overriding yours.
• forceLoginOrgUUID ensures Claude Code only signs in to your organisation.

For MCP, either ship an exclusive managed-mcp.json (same paths; an empty mcpServers map disables MCP) or use allowedMcpServers / deniedMcpServers, matching on serverUrl, serverCommand or serverName. The deny list always wins. Anthropic notes serverName matching is not a security control - match on URL or command.

Add the sandbox (sandbox.enabled, allowUnsandboxedCommands: false, sandbox.failIfUnavailable) - Seatbelt on macOS, bubblewrap on Linux - for filesystem and network isolation.

Anthropic is explicit that managed settings are "a client-side control, not a security boundary." They prevent mistakes; they don't stop a local admin. Pair them with MDM and endpoint controls.

Monitoring and DLP#

• Audit logs: Data and Privacy → Export logs (180 days): SSO sign-ins, file uploads, project visibility changes.
• Compliance API: activity feed (6 years) plus content endpoints for chats, files, projects, and Claude Code and Cowork transcripts including tool results. Anthropic lists 60+ integrations, including Microsoft Purview, Nightfall, Splunk and Relativity. ZDR and HIPAA orgs are excluded from session data.
• Inference hooks (beta, Enterprise, Owners configure): every prompt, tool response and uploaded file's text goes to your server before it reaches Claude, across Claude, Claude Code and Cowork. Your server returns allow or deny - no redaction. Netskope, Palo Alto Networks, Proofpoint and Zscaler support it. It runs in Anthropic's infrastructure, so there's no endpoint agent to deploy.

Inference hooks are the safety net for pasted data. They can't clean a payload, only block it - so masking has to happen upstream.

Masking PII With a Custom MCP Server#

Where connector data goes#

For custom connectors in claude.ai, Anthropic's cloud calls your remote MCP server - so it must be internet-reachable and authenticated, and whatever it returns enters the conversation and is sent to Anthropic. For local MCP servers in Claude Code or Claude Desktop, the server runs on the device, but its tool output still goes to the model.

So the control point is the tool response. Raw PII must never be in it.

Mask on read, unmask on write#

Read tools return tokens. Write tools accept tokens and detokenise server-side, so the outbound email has the real name and the model never saw it.

Choosing the technique#

Use HMAC with a server-held secret, not a bare SHA-256: emails and phone numbers have small enough spaces to brute-force an unkeyed hash.

Minimal example (Python, official MCP SDK)#

import hashlib, hmac, os
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("crm-safe")
SECRET = os.environ["PSEUDONYM_KEY"].encode()  # never leaves your server
VAULT: dict[str, str] = {}  # use an encrypted store with access logging in production

def mask(kind: str, value: str) -> str:
    code = hmac.new(SECRET, value.lower().encode(), hashlib.sha256).hexdigest()[:8]
    token = f"[{kind}_{code}]"
    VAULT[token] = value
    return token

@mcp.tool()
def get_ticket(ticket_id: str) -> dict:
    """Fetch a support ticket with personal details masked."""
    t = crm.get_ticket(ticket_id)  # your own CRM client
    return {
        "customer": mask("PERSON", t.name),
        "email": mask("EMAIL", t.email),
        "town": t.town,
        "issue": redact_free_text(t.description),  # run a PII detector here
    }

@mcp.tool()
def send_reply(ticket_id: str, body: str) -> str:
    """Send a reply. Placeholders are replaced with real values server-side."""
    for token, real in VAULT.items():
        body = body.replace(token, real)
    crm.send_email(ticket_id, body)
    return "sent"

mcp.run()

Production checklist for this pattern:

• Free text is the hard part. Structured fields are easy; PII inside sentences needs a detector (Microsoft Presidio is a common open-source starting point) and will never be perfect. Test it against real samples.
• Scope write tools tightly. send_reply should only detokenise tokens belonging to that ticket, and ideally sit behind Needs approval in the role's connector settings.
• Authenticate the remote server (OAuth) and log every detokenisation.
• Store the vault encrypted, with its own retention period.
• Pseudonymised data is still personal data under UK GDPR while you hold the key. Masking reduces risk and strengthens your DPIA; it doesn't remove your obligations.

Does quality hold?#

For summarisation, drafting, classification, trend analysis and triage - yes, largely. It degrades where the task depends on the literal value (spelling, address validation, cross-system matching without the shared key) and wherever the detector misses PII in free text. In claude.ai, users see tokens in the chat; design the workflow so real values surface in your systems, not the transcript.

Implementation Order#

1. Enable the Compliance API and set chat retention (day one).
2. SSO, SCIM, session length, IP allowlist.
3. Custom roles; external sharing off; feedback decision.
4. Claude Code managed settings, MCP allowlist and sandbox.
5. Inference hooks with your DLP vendor.
6. Masking MCP servers for each system holding personal data.
7. DPIA and transfer risk assessment updated to match the actual config; quarterly review of new features.