Claude governance & data-safety brief
Map common enterprise security, legal, and privacy concerns to Claude’s enterprise controls: the basis for a conditional ‘go’ with defined guardrails.
6 min read · Current as of
Executive summary
Claude can be deployed with enterprise-grade controls that satisfy most large-company requirements: your content is not used to train models by default, identity is centralized through SSO/JIT/RBAC, activity is auditable, and sensitive workloads can run under US-only inference, customer-managed encryption keys, and Zero Data Retention (ZDR). The residual risks (inaccuracy, prompt injection, data handling by users) are well-understood and mitigated through configuration, policy, and training.
This is a vendor-neutral internal assessment template. Specific contractual commitments (DPA, ZDR scope, SLAs, sub-processors, certifications) must be confirmed with your Anthropic account team and reflected in your agreement.
1. Data handling
| Concern | Control | Notes / verify |
|---|---|---|
| Will our prompts/outputs train the model? | No model training on your content by default on Team & Enterprise. | Confirm in the Commercial Terms / DPA. |
| Is data retained? | Standard retention for abuse monitoring; ZDR available for qualifying use cases (prompts/outputs not stored). | ZDR has feature-level eligibility; confirm which features your use cases need. |
| Where does inference run? | US-only inference available (Enterprise); API offers data residency routing (global or us). | Confirm regions that meet your data-localization rules. |
| Encryption | In transit and at rest; customer-managed encryption keys (CMEK) on Enterprise. | Confirm key-management model with account team. |
2. Access & identity
| Capability | What it gives you |
|---|---|
| SSO + domain capture | Centralized login via your IdP; auto-claim users on your email domain |
| Just-in-Time (JIT) provisioning | Users provisioned on first SSO login; deprovision via IdP |
| Role-based access control (RBAC) | Admin vs. member roles; workspace segmentation |
| Spend controls | Org- and user-level limits to prevent runaway usage/cost |
3. Auditability, oversight & cost governance
- Audit logs (Enterprise): administrative and usage events for your SIEM/retention.
- Compliance API (Enterprise): programmatic access to usage/compliance data.
- Admin console: central management of members, workspaces, and keys.
Token-spend governance. The same platform makes cost a bounded, attributable line item, not a surprise invoice:
- Usage & Cost API / reporting: spend broken down by workspace, model, and service tier, including cached vs. uncached tokens so you can confirm caching and batching are actually working. (Admin key required.)
- Workspaces as cost centers: scope keys, members, and budgets per team, project, or environment; each workspace has its own isolated prompt cache.
- Hard spend caps + alerts: per-workspace monthly limits and threshold notifications bound the maximum spend (org limits always dominate). Rate limits cap how fast a runaway process can burn budget.
- Accurate accounting: count tokens with the platform’s token-counting endpoint, not a third-party tokenizer, or the cost math is wrong before you start.
Attribution note: native reporting attributes spend to keys / workspaces / models, not to named individuals. For per-user cost, use the Analytics API (named-user reporting) or front the API with an LLM gateway that maps virtual keys to teams/users and can enforce a hard budget at request time. Confirm the current surface with your account team.
4. Plan-level control comparison
| Control | Team | Enterprise |
|---|---|---|
| No training on your content (default) | ✅ | ✅ |
| SSO + domain capture | ✅ | ✅ |
| JIT provisioning, RBAC | ✅ | ✅ |
| Spend controls | ✅ | ✅ |
| Audit logs | ❌ | ✅ |
| Compliance API | ❌ | ✅ |
| Customer-managed encryption keys | ❌ | ✅ |
| US-only inference | ❌ | ✅ |
Confirm exact feature availability per plan and region with your account team; plans evolve.
5. Approved-use data classification (template)
Map your existing data classes to allowed surfaces. Example starting point. Adjust to your policy and complete during Security review:
| Data class | claude.ai (Team/Ent.) | API w/ ZDR | Notes |
|---|---|---|---|
| Public | ✅ Allowed | ✅ | No restriction |
| Internal / Confidential | ✅ Allowed | ✅ | Default for most knowledge work |
| Restricted (PII, customer data) | ⚠️ Conditional | ✅ w/ controls | Minimize; consider US-only + ZDR; honor privacy obligations |
| Highly Restricted (regulated, secrets, MNPI, privileged) | ❌ Until approved | ⚠️ Case-by-case | Requires explicit sign-off + dedicated controls |
6. Residual risks & mitigations
| Risk | Mitigation |
|---|---|
| Inaccuracy / “confident errors” | Mandatory “verify before reliance” policy; human-in-the-loop for decisions; Citations feature for grounded answers |
| Prompt injection (via web, tools, MCP, documents) | Limit tool/MCP scope; treat tool output as untrusted; least-privilege connectors; review autonomous-agent permissions |
| Data leakage by users | Data-classification policy + training (see your staff acceptable-use / do’s-and-don’ts guide); approved-class enforcement; DLP where applicable |
| Shadow IT / personal accounts | Provide sanctioned access quickly; SSO + domain capture to consolidate; block unmanaged use per policy |
| Over-permissioned agents (Claude Code / MCP) | Scoped credentials, sandboxing, review/PR gates, hooks for guardrails, CI controls |
| Third-party/sub-processor exposure | Review sub-processor list and certifications; restrict connectors to approved systems |
| Runaway token spend / surprise invoice | Per-workspace spend caps + threshold alerts; rate limits; usage/cost monitoring with per-team attribution; caching + Batch API for high-volume jobs; retrieve-relevant-context (don’t paste whole corpora) to cut input volume |
7. Shared-responsibility model
| Layer | Anthropic | [Company] (admins) | End users |
|---|---|---|---|
| Model & platform security | ✅ | ||
| No-training default, ZDR, encryption options | ✅ | Configure/contract | |
| SSO, RBAC, spend limits, audit log review | Provide | ✅ Configure & monitor | |
| Approved data classes & acceptable use | Enable | ✅ Define & enforce | ✅ Follow |
| Verifying outputs before reliance | Set policy | ✅ Do it |
8. Pre-rollout controls checklist
- Plan selected (Team vs Enterprise) to match control requirements
- DPA / Commercial Terms reviewed; ZDR scope confirmed for sensitive use cases
- SSO + JIT configured against corporate IdP; deprovisioning tested
- RBAC roles and workspace segmentation defined
- Org/user spend limits set
- Usage/cost reporting and per-team attribution configured (cached vs. uncached visibility); token-spend alert thresholds set
- Audit-log export to SIEM configured (Enterprise)
- Approved data-classification matrix finalized and published
- Acceptable-use policy + your staff do’s-and-don’ts guide distributed
- MCP/connector and Claude Code permission model reviewed (least privilege)
- Incident & escalation path defined
9. Open questions for the Anthropic account team
- Exact ZDR feature eligibility for our intended use cases?
- Current certifications/attestations (e.g., SOC 2, ISO 27001) and sub-processor list?
- DPA terms, data-deletion SLAs, and breach-notification commitments?
- Region/residency guarantees for US-only inference and CMEK specifics?
- Retention windows for abuse-monitoring data on non-ZDR paths?
- Cost-attribution granularity (per workspace vs. per named user) and Analytics API availability on our plan?
Owner: [Security/Privacy lead] · Reviewed by: [Legal] · Status: [Draft/Approved] · Date: [ ]