How Claude handles your data: security, residency, and compliance

a third vector reference · last reviewed july 2026

Accurate as of writing. Treat Anthropic's own documentation as authoritative and confirm current details before you sign anything. This is guidance, not legal advice.

This guide explains where Claude processes data, who can access it, and how to meet EU and UK data-protection requirements. It covers the default account posture, an EU view and a UK view for residency and compliance, a section for regulated industries and the public sector, and a decision table for choosing a setup. What changes between cases is where the data is processed; the underlying controls stay the same.

The default posture

Anthropic runs two regimes, and which one you use determines the protections that apply.

Commercial accounts, meaning the Claude API and Claude for Work (the Team and Enterprise plans), are intended for sensitive data. Inputs and outputs are not used to train models. Retention is short, currently seven days, and can be deleted sooner. Data is encrypted in transit and at rest. Anthropic holds SOC 2 Type II, ISO 27001, ISO 42001 for AI management systems, and UK Cyber Essentials. A Zero Data Retention option is available for regulated workloads, where nothing is written to disk once the response is returned.

Consumer accounts, meaning Claude Free, Pro, and Max on claude.ai, are a separate regime. They are not covered by the commercial Data Processing Agreement, and conversations can be used to train models unless the user opts out (opting out also shortens retention to 30 days). A training opt-out does not substitute for the commercial DPA. Personal consumer logins should stay out of any workflow that touches client or personal data. Client work belongs on a commercial account.

Where processing happens

Anthropic's first-party API processes inference on US infrastructure by default. The API exposes a US or a global inference region, with no EU-only or UK-only option today. To keep data physically in a given region, run Claude through that region of a major cloud rather than through Anthropic's direct API.

Claude runs natively on Amazon Bedrock, Google's Gemini Enterprise Agent Platform (formerly Vertex AI; Google now delivers all Vertex AI services through the Agent Platform), and Microsoft Foundry. Deployed through one of these in a specific region, the data stays inside that cloud provider's security boundary, the deployment inherits the provider's regional accreditations, and Anthropic personnel have no access to the inference infrastructure. This is the mechanism behind both regional views below.

The EU view

For a European business on a commercial account, Anthropic supports GDPR-compliant use. It offers a Data Processing Agreement under Article 28, with the customer as controller and Anthropic as processor, acting only on the customer's instructions. The DPA incorporates the EU Standard Contractual Clauses as the lawful mechanism for transferring data to the US, is governed by Irish law, and provides fifteen days' notice with a right to object when a new sub-processor is added.

Residency requires a deployment decision. Because the first-party API processes in the US, keeping data inside the EU means running Claude through an EU region of Amazon Bedrock (Frankfurt, Ireland, Paris, or Stockholm) or the Gemini Enterprise Agent Platform (Vertex AI). Claude is generally available on Microsoft Foundry as of July 2026, but Foundry does not yet provide EU data residency, so EU-resident deployments currently run on Bedrock or Vertex AI. Not every member state has a local cloud region, so for most EU companies residency in practice means the nearest available EU region, often Frankfurt or Ireland.

A commercial Team or Enterprise plan with the DPA in place covers standard EU use. EU-region deployment is required only when a contract or data type requires the data to remain in the EU.

The UK view

Since Brexit the UK is a separate data-protection regime, running UK GDPR alongside the Data Protection Act 2018. A UK client frames the same questions in UK terms and may require the data to stay in the UK specifically. The commercial account posture above applies unchanged: DPA, no training, short retention, the same certifications.

Residency works as in the EU case, pointed at a different region. Run Claude through a UK region of a supported cloud, and the data stays inside that cloud's boundary with its UK accreditations attached. Model availability varies by region, so confirm that the specific Claude model you need is offered in the UK region before committing to it.

Anthropic has existing engagements with the UK public sector: a memorandum of understanding with the UK government, work on an assistant for GOV.UK, and a listing on the government's Digital Marketplace.

Regulated industries and the public sector

Some sectors sit under a higher bar regardless of region, including financial services, healthcare, government, and defence. The controls above still apply; what changes is the level of assurance and accreditation the client's own rules require.

Two principles apply in most cases. First, use an in-region cloud deployment with Zero Data Retention, so the deployment inherits the cloud provider's sector accreditations rather than certifying Claude directly. Second, design the workflow to keep the most sensitive material out of the model where the task allows, working on de-identified or non-classified inputs, so the model handles the reasoning while regulated data stays in systems already accredited for it.

For sovereign or classified requirements, the route is an accredited region or enclave scoped with the client's accreditor from the start, with their security team involved from the outset. Anthropic's dedicated national-security models, Claude Gov, are built for US classified environments and do not transfer directly to European or UK requirements, so European sovereign work runs through the accredited-cloud route rather than a ready-made government model.

When a regulator or a security function is involved, involve them in the design early, as their requirements determine the architecture.

Decision table

Use case	Account or route	Where data is processed	Controls in play
Internal or non-sensitive work	Commercial API, Team, or Enterprise (default)	US infrastructure	No training, 7-day retention, encryption, SOC 2 / ISO
EU client, personal data, residency required	Claude via Bedrock or Vertex AI (Gemini Enterprise Agent Platform) in an EU region (often Frankfurt or Ireland)	Stays in the chosen EU region	DPA and EU SCCs, no Anthropic operator access, optional ZDR
UK client, personal data, residency required	Claude via a supported cloud in a UK region (confirm model availability)	Stays in the UK region	UK GDPR posture, inherits the cloud's UK accreditations, optional ZDR
Regulated sector or public sector (finance, health, gov, defence)	In-region cloud deployment with ZDR; sensitive data kept out of the model where possible	Stays in the chosen region, inside the cloud's boundary	Inherits the cloud's sector accreditations, no Anthropic operator access
Sovereign or classified requirement	Accredited enclave, client security team engaged from day one	Client-controlled accredited environment	Heavier lift; workflow designed to keep classified data out of the model
Quick personal experiments only	Consumer Free, Pro, or Max	US infrastructure	Not covered by the DPA; may be used for training unless opted out. Keep client and personal data out

Summary

Use a commercial account, not a consumer login, for anything touching client or personal data. US processing applies by default and is appropriate when the work is not region-sensitive. Deploy through an EU or UK cloud region when a client requires the data to stay in region, and confirm model availability in that region first. Involve the client's security or compliance function early whenever a regulator or accreditation is in scope.

Sources

Primary (Anthropic):

Secondary (reporting and analysis):