Most company data leaks through ChatGPT are not attacks. They are a well-meaning person pasting a client list, a contract or a draft press release into a chat window to save twenty minutes. Whether that is a problem depends far less on the tool than on which version of it your team is using and what rules sit around it. This guide covers what OpenAI says about how it handles data, which settings matter, and the policy a team should have in place before anyone pastes in client material.
Start with the plan, not the prompt
OpenAI draws a clear line between its business products and its consumer ones. By its own published commitments, it does not use inputs or outputs from ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu or the API platform to train its models by default. Business data is also encrypted in transit and at rest. Personal accounts work differently: whether conversations are used to improve the models is governed by a setting on the account, and the person who owns it decides. So the first question for any team is which accounts people are actually using. A company that has bought a business plan but lets staff keep using personal logins has bought the protection and then routed around it.
Know what the controls do
On individual accounts, the relevant setting sits under Settings, then Data Controls, labeled as improving the model for everyone. Turning it off applies to future conversations. Temporary Chat is a separate option: those conversations are not used to improve the models while they stay temporary, but OpenAI may keep a copy for up to 30 days for safety purposes. If someone saves a temporary chat, it becomes a regular chat and follows the account's settings. These controls are useful, but they are per-person switches. A policy that depends on every employee finding and setting them correctly is a policy that will eventually have a gap.
Retention is its own question
Not training on your data and not keeping your data are different promises. On business plans, OpenAI's documentation says each workspace controls how long conversations are retained, and that deleted conversations are removed from its systems within 30 days unless there is a legal requirement to keep them. That legal carve-out matters for regulated work. If a client contract or an industry rule says data must be deleted on request, read the retention terms of your plan against it rather than assuming the delete button settles the question.
Write the rules down
A workable policy is short enough to remember. Name the approved accounts and plans, and say that personal accounts are not for company work. List the categories that never go into a chat, such as customer personal data, credentials and keys, unreleased financials, and anything under a confidentiality agreement. Say who can approve an exception. Make it easy to comply: if the approved route is slower than pasting into a personal account, people will take the personal account.
Strip before you paste
Even inside an approved account, share the minimum. Replace names with roles, remove account numbers, and summarize a document instead of uploading it when a summary would do. Ask what the model needs to see to do the job, and give it only that. This habit protects you regardless of which settings are on, because data that was never sent cannot be retained, reviewed or subpoenaed.
Review it on a schedule
Vendor terms, product settings and plan names change. Assign an owner to re-read the provider's data commitments a couple of times a year, check who is on the workspace, and remove departed staff. Treat it the way you would treat any other vendor that holds company information: with a contract you have read, access you can audit, and a named person responsible.