Claude Data Classification Guide: What Data Can You Send to Claude and What Requires Controls?

The most common question in enterprise Claude deployments is deceptively simple: "What data can I send to Claude?" The answer depends on three factors — Anthropic's contractual controls, your regulatory obligations, and your own data classification policy. Getting this wrong creates compliance risk; being overly conservative blocks value.

This guide provides a practical data classification framework specifically designed for Claude deployments, including a ready-to-use classification matrix you can adapt for your organisation. Developed from 200+ enterprise implementations across regulated and non-regulated sectors.

The Four-Tier Claude Data Classification Framework

We recommend a four-tier classification system aligned to the risk profile of data sent to Claude. This maps to most existing enterprise data classification frameworks (which typically use Public / Internal / Confidential / Restricted) while adding Claude-specific guidance for each tier.

What Goes in Each Tier

Tier 1: Public — Approved Without Restriction

Public data is information that is already available externally or carries no confidentiality obligation if disclosed. This is the lowest-risk tier for Claude processing.

• Published company website content, press releases, annual reports
• Publicly available market data, research, and industry statistics
• Generic business templates and frameworks (non-company-specific)
• Hypothetical examples and anonymised case studies
• Training and educational content not containing proprietary information

Tier 2: Internal — Approved with Standard Controls

Internal data is information created for internal business purposes that is not intended for public disclosure but does not carry heightened confidentiality obligations.

• Internal process documentation and standard operating procedures
• Meeting notes and internal communications (non-sensitive topics)
• Internal project plans and timelines (non-sensitive)
• Aggregated analytics and reporting (no individual-level data)
• Internal policy documents (non-regulated)
• Non-personal HR materials (job descriptions, generic training content)

Tier 3: Confidential — Approved with Additional Controls

Confidential data requires Claude Enterprise plan with zero data retention, a signed DPA with Anthropic, and explicit use case approval from your AI governance function. PII minimisation should be applied wherever possible.

• Customer account information (anonymised or with PII removed)
• Non-public financial information (internal budgets, forecasts)
• Proprietary business strategies, M&A planning
• Employee performance data (anonymised)
• Supplier contracts and commercial terms
• Regulated data processed under BAA/DPA with appropriate controls

Tier 4: Restricted — Prohibited Without Explicit Approval

Restricted data should not be sent to Claude without explicit CISO approval, additional technical controls, and documented justification. In most cases, the right answer is to redesign the use case to avoid including Restricted data rather than attempting to implement controls around processing it.

• Authentication credentials (passwords, API keys, tokens)
• Full payment card numbers (PAN, CVV)
• Social security numbers and government ID numbers
• Attorney-client privileged communications (without specific legal approval)
• Classified or security-restricted government information
• Complete PHI records with full patient identifiers
• Biometric data

PII Minimisation: The Practical Solution for Borderline Cases

Many valuable Claude use cases involve documents that contain personal data — a customer complaint, a clinical note, a contract with named parties. The right approach is not to prohibit these use cases but to minimise the personal data included before the prompt is sent.

Minimisation Techniques

Tokenisation: Replace names and identifiers with tokens before sending. "John Smith (Customer ID: 84721)" becomes "[CUSTOMER_001]". Your application maps tokens back to real data after processing.

Redaction: Remove irrelevant personal identifiers. A clinical note being summarised doesn't need the patient's date of birth if only the clinical content is required.

Aggregation: Summarise at a population level rather than individual level where possible. "Customer sentiment analysis across 500 support tickets" rather than processing each ticket individually with customer identifiers.

Template injection: Design prompts that accept only the specific data fields needed, preventing employees from inadvertently including unnecessary personal data.

Implementing Data Classification in Your Claude Deployment

Data classification only works if employees can apply it in practice. Complex frameworks with many edge cases lead to either blanket permissiveness ("I'll just send everything") or blanket restriction ("I won't use Claude for anything sensitive").

Practical implementation steps:

1. Map your existing classification to the four-tier framework. Most enterprises have an existing data classification policy. Map it to the Claude tiers rather than creating a parallel system.
2. Create a one-page decision guide. "Before sending data to Claude, ask: Does this contain names, contact details, or other personal data? If yes, apply PII minimisation. Does this contain passwords, payment data, or privileged communications? If yes, do not send."
3. Build classification into prompt templates. Pre-approved prompt templates should be designed to accept only Tier 1-2 data by default. Tier 3 templates require additional approval.
4. Implement technical enforcement. For API integrations, enforce data classification at the application layer. For end-user Claude access, use system prompts that guide users on permissible data categories.
5. Train and test. Include data classification scenarios in Claude training. Test employee understanding before granting access to Tier 3 approved use cases.