Data Handling Controls Every Admin Should Configure
Before any team starts using Claude day to day, a handful of workspace settings should be reviewed and deliberately set, not left on their defaults.
This checklist walks through those settings in a sensible order, from the foundational ones to the ones that depend on having the basics already in place.
How to Use This Checklist
- Work through the tiers in order - later items assume the earlier ones are already configured.
- Record each decision and the reason behind it, not just the final setting - future reviews and audits will need that context.
- Revisit this checklist whenever a new team, project, or data type is added to the workspace, not only during initial setup.
- Assign a single owner for keeping these settings current, so they don't quietly drift after the initial rollout.
Tier 1: Foundational Settings
- Confirm workspace/admin access is limited to the right people: review who currently holds admin rights and remove anyone who no longer needs them.
- Set the data retention window deliberately: don't leave it on the platform default without checking whether it fits your organization's data sensitivity.
- Enable the training opt-out if your data warrants it: for workspaces handling regulated or proprietary data, opt conversations out of being used for model training.
- Verify these two settings independently: retention and training opt-out are separate controls, and confirming one is set correctly doesn't confirm the other.
- Document the reasoning behind each setting: a one-line note on why the retention window is what it is saves time during a later audit.
Tier 2: Access and Identity Controls
- Review how new users are provisioned into the workspace: confirm there's a defined process, not an ad hoc one.
- Confirm role-based permissions match actual job functions: admins should be admins because they need to be, not because it was convenient during setup.
- Set a cadence for periodic access reviews: quarterly is a reasonable starting point for most organizations.
- Remove access promptly when someone leaves the team or organization: stale access is one of the most common findings in a security review.
Tier 3: Monitoring and Accountability
- Turn on and locate the audit log: confirm you know where it lives and what it's currently capturing before you need it during an incident.
- Assign ownership of audit log review: a log nobody reviews provides little practical value.
- Set a review cadence for the audit log: quarterly review plus ad hoc review after any unexpected change is a reasonable baseline.
- Confirm what the audit log does and doesn't cover: it captures admin actions and access events, not conversation content, so plan your other controls accordingly.
Tier 4: Data-in-Use Guidance
- Write a short internal note on what data categories are OK to paste into Claude and what aren't: cover customer PII, credentials, and unreleased financials at minimum.
- Distribute that guidance during onboarding, not after an incident: the point is prevention, not cleanup.
- Identify which teams handle the most sensitive data and give them extra attention: legal, finance, and customer support often warrant tighter guidance than general teams.
- Revisit the guidance whenever a new regulated data type enters the organization's workflow: a new client contract or new product line can change what's in scope.
Tier 5: Compliance Alignment
- Confirm which compliance frameworks actually apply to your organization: SOC2, GDPR, both, or neither in a formal sense - this determines how strict the rest of this checklist needs to be.
- Map your retention and training settings to your organization's stated data-protection obligations: be able to explain, in writing, why the current settings satisfy those obligations.
- Keep evidence of these settings together with other vendor risk documentation: so it can be produced quickly during an audit or customer review.
- Schedule a recurring review of this entire checklist: annually at minimum, and again whenever the organization's data usage changes meaningfully.
Applying the Checklist in Order
- Tier 1 (1-5) comes first because retention, training opt-out, and admin access are the foundation everything else depends on - get these wrong and later tiers won't matter.
- Tier 2 (6-9) builds on that foundation by making sure only the right people can change those foundational settings in the first place.
- Tier 3 (10-13) adds visibility - once access and settings are right, you need a way to confirm they stay right over time.
- Tier 4 (14-17) shifts focus to what employees actually do day to day, since settings alone don't prevent someone from pasting sensitive data into a conversation.
- Tier 5 (18-21) ties everything back to the organization's actual compliance obligations, closing the loop between technical settings and documented posture.
FAQs
Do I need to complete every tier before rolling Claude out to my team?
Tier 1 and Tier 2 are close to non-negotiable before any rollout.
Tiers 3 through 5 can reasonably be completed in the first weeks after rollout, but should not be indefinitely deferred.
What's the single most commonly skipped item on this list?
Assigning ownership of audit log review (item 11) - the log gets turned on during setup and then nobody actually looks at it again until something goes wrong.
How often should this whole checklist be revisited?
At least annually, plus any time a new team, project, or regulated data type is introduced - those events are natural triggers to re-check whether the settings still fit.
Is the training opt-out setting relevant for every organization?
It's most clearly relevant for organizations handling regulated or proprietary data.
Lower-sensitivity, general-purpose workspaces may reasonably decide it matters less, but the decision should still be deliberate rather than default.
Why does the checklist separate "settings" from "guidance for employees"?
Because they solve different problems - settings control what the platform does with data, while guidance controls what employees choose to paste in the first place.
Both are needed; neither substitutes for the other.
What should I do if I inherit a workspace where none of this has been configured?
Start at Tier 1 and work through in order - treat it the same as a fresh rollout, since an unconfigured workspace is functionally running on whatever defaults the platform ships with.
Should smaller teams skip the compliance alignment tier?
Not entirely - even a small team should know whether any formal compliance framework applies to them, since that answer determines how much of the rest of the checklist actually matters.
How does this checklist relate to the enterprise-wide rollout checklist?
This checklist is the baseline settings every admin should configure for a single workspace; the enterprise-wide rollout checklist builds on top of this when expanding Claude across an entire organization.
What's the fastest way to tell if a workspace's settings have drifted?
Compare the current retention window, training opt-out, and admin access list against what was documented at the last review - any unexplained difference is worth investigating.
Who should own this checklist inside an organization?
Usually a workspace admin in coordination with security or compliance stakeholders - the technical settings sit with the admin, but the "why" behind them often needs input from compliance or legal.
Related
- Governance & Compliance Basics - the walkthrough this checklist expands on
- How Claude Handles Data Retention and Training Opt-Outs - the mental model behind Tier 1
- What Audit Logs Capture in the Claude Console - detail behind Tier 3
- Compliance Checklist Before Rolling Out Claude Enterprise-Wide - the enterprise-scale version of this checklist
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.