Developer data protection
Claude
Choose the right Claude Code account
Approve the account and sign-in arrangement used for company code, not only the Claude Code application. Anthropic’s current documentation distinguishes consumer training preferences, commercial terms, retention options and separate feedback-sharing flows. Confirm which arrangement governs the intended session, then record the organisation’s permitted code and purpose.
For IT procurement and engineering leads
Record the applicable terms before approving company code.
Dated provider categories plus a fictional decision scenario. No real account, agreement or approval is verified.01
Identify the actual sign-in arrangement
A developer can use the same application under a personal subscription, an organisation-managed arrangement or a provider/API route. The appearance of the editor is not evidence that the intended commercial terms apply. Record the account owner, plan, provider and authentication method using non-secret administrative evidence.
Do not collect keys or authentication files for this review. A reference to the approved account and its owner is enough. If a developer changes the sign-in method or introduces a different provider, treat that as a new policy question rather than assuming the earlier application approval follows automatically.
Source context: Claude Code: Data usage
02
Compare the training commitments
For consumer Free, Pro and Max accounts, Anthropic documents a user choice about allowing data to improve future models, including Claude Code use. Under commercial terms, it states that code and prompts are not used to train generative models unless the customer chooses to provide data for model improvement.
The distinction is about the applicable terms and choices, not whether the employer permits disclosure. Company code may still be restricted even where a no-training commitment applies. Record any organisational opt-in programme separately, along with the owner authorised to make that choice.
Source context: Claude Code: Data usage
03
Record retention for the selected route
The data-usage documentation reviewed on 21 September 2026 describes consumer retention of five years when model-improvement use is allowed and 30 days when it is not. It describes a standard 30-day commercial retention period and qualified zero-data-retention arrangements, which require specific enablement rather than being included automatically in every Enterprise plan.
Provider arrangements, agreements and features can change the relevant handling. Record the source and arrangement that apply to the actual session. Keep a blank field when the organisation has not confirmed a term; do not convert an unknown value into a claim of zero storage.
| Arrangement | Documented question | Organisation evidence |
|---|---|---|
| Consumer account | Model-improvement preference and retention | Actual account setting and permitted use |
| Commercial arrangement | Terms and any explicit data-use opt-in | Contract/account owner confirmation |
| Qualified retention variation | Specific enablement and scope | Written agreement and covered features |
| Third-party provider route | Which provider’s handling applies? | Selected route and applicable terms |
Source context: Claude Code: Data usage
04
Keep support sharing and local records visible
Normal session policy is only part of the decision. Feedback reports and optional transcript sharing have separate documented flows and retention. A developer can create a further disclosure by sending a support bundle even when ordinary coding use is approved. Link the support-upload procedure to the account approval instead of duplicating it here.
Also identify where local session records and exported material may remain. A provider policy is not a complete inventory of files on the employee’s device or records held by another connected service. Assign an owner to any additional record required by the organisation’s handling policy.
Source context: Claude Code: Data usage
05
Approve code use within a clear scope
Use the worksheet to record the account, applicable commitments, permitted code classes and tasks, and who can change the arrangement. If the evidence is incomplete, keep restricted material out of the workflow while the responsible owner resolves it. A personal account is not made organisation-approved merely by expensing its subscription.
Revisit the approval when sign-in, plan, provider, data-use preference or feedback practice changes. File and shell permissions remain a separate review. Choosing an appropriate account does not prevent a local tool from reading material the task should not include.
Put it into practice
Claude Code account and policy approval
Pair the actual sign-in arrangement with applicable training, retention and code-use decisions.
Dated provider categories plus a fictional decision scenario. No real account, agreement or approval is verified.
| Category | Dated documentation | Review implication |
|---|---|---|
| Consumer, improvement allowed | Five-year retention described | Employer permission still required |
| Consumer, improvement disabled | 30-day retention described | Confirm actual preference and task |
| Commercial standard | No training absent opt-in; standard 30 days | Confirm agreement and provider route |
| Qualified ZDR | Specific enablement required | Do not infer it from plan name |
| Feedback report (/feedback) | Five-year path, including /bug and /share | Review the exceptional upload |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# Claude Code account review
This pack contains no credentials or active configuration. It does not sign in, contact a provider or approve a disclosure.
Record the actual account/provider and current policy sources in account-review.csv. Use the decision record for employer-owned code. For support disclosures use the separate D09 guide, and for local file permissions use D05. Do not infer zero retention or commercial coverage from the product name alone.
## Guide and sources
Canonical guide: https://aona.ai/resources/guides/claude-code-personal-commercial-data-policy/
Source review: 2026-09-21
- Claude Code: Data usage: https://code.claude.com/docs/en/data-usage
The pack also contains a populated dated policy-category table and a clearly fictional account decision. Those examples are separate from the blank actual-account review.
Download README.mdaccount-review.csvInspect
field,current_evidence,source,owner,status
Account owner,TO_RECORD,,ASSIGN,UNVERIFIED
Plan and provider,TO_RECORD,,ASSIGN,UNVERIFIED
Authentication method without secret values,TO_RECORD,,ASSIGN,UNVERIFIED
Training preference or applicable commitment,TO_RECORD,,ASSIGN,UNVERIFIED
Explicit improvement programme opt-in,TO_RECORD,,ASSIGN,UNVERIFIED
Standard retention,TO_RECORD,,ASSIGN,UNVERIFIED
Qualified retention variation and enablement,TO_RECORD,,ASSIGN,UNVERIFIED
Feedback and transcript-sharing process,TO_RECORD,,ASSIGN,UNVERIFIED
Local and exported records,TO_RECORD,,ASSIGN,UNVERIFIED
Download account-review.csvcode-use-decision.mdInspect
# Company code use decision
Account/provider reviewed: ____________________
Applicable terms and review date: ____________________
Permitted code classes and purposes: ____________________
Restricted material: ____________________
Owner authorised to change data-use choices: ____________________
Feedback-sharing procedure: ____________________
Retention evidence and unresolved questions: ____________________
Decision: NOT YET REVIEWED
Recheck after sign-in, plan, provider, preference or agreement change.
Download code-use-decision.mddocumented-account-categories.csvInspect
checked_at,category,documented_policy,important_boundary,source
2026-09-21,Consumer improvement enabled,Data may improve models and five-year retention described,Actual preference and employer permission to confirm,https://code.claude.com/docs/en/data-usage
2026-09-21,Consumer improvement disabled,30-day retention described,Confirm actual selected account and preference,https://code.claude.com/docs/en/data-usage
2026-09-21,Commercial standard,No training unless opted in and standard 30-day retention described,Provider agreement and feature scope to confirm,https://code.claude.com/docs/en/data-usage
2026-09-21,Qualified zero retention,Specific organisation enablement required,Not automatic with standard Enterprise,https://code.claude.com/docs/en/data-usage
2026-09-21,Feedback report (/feedback plus /bug and /share),Separate five-year retention path,Not ordinary session retention,https://code.claude.com/docs/en/data-usage
Download documented-account-categories.csvfictional-account-decision.mdInspect
# Fictional account decision
SYNTHETIC SCENARIO ONLY. No real account or approval exists.
Hypothetical task: explain a generic toy sum function. No code file is supplied in this account-policy pack.
Candidate A: a fictional employee-funded consumer account with improvement preference unverified.
Candidate B: a fictional organisation-managed commercial account.
Evidence considered: the dated categories in documented-account-categories.csv; actual contract, provider route and account state remain unverified.
Illustrative outcome: select Candidate B for the synthetic exercise only after the account owner verifies the arrangement. Withhold all real employer code until its data owner approves the specific service and purpose.
Feedback condition: no source/history submission without the separate support review.
Unresolved: actual retention variation and any data-use opt-in.
This teaches the decision structure and does not grant permission to any organisation.
Download fictional-account-decision.mdBefore you proceed
Keep these distinctions clear
- Approving the app rather than the account
- Two sessions in the same client can use different sign-in arrangements or terms.
- Treating Enterprise as automatic zero retention
- Verify the specific agreement, enablement and feature scope documented for the organisation.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported employee endpoint input paths alongside the organisation’s account policy.
Aona does not change Anthropic’s terms or supply unverified account restrictions. Local file access and provider handling require their own evidence.
Bring the approved account arrangement and one synthetic coding task to a scoped endpoint review.
Review your use caseFAQ
Questions for this decision
Does a paid personal plan automatically use commercial terms for company code?
Is zero retention included in every Claude Enterprise account?
Can commercial data still be shared through a feedback report?
Does the account review replace .env permission tests?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Claude Code: Data usage
Documents consumer/commercial training policy, retention options and separate feedback flows.
vendor · checked 2026-09-21