Zero Data Retention: what it actually requires, and where "ZDR enabled" overstates it

Someone has told you the deployment will have zero data retention. It might have been a supplier scoping a build, or a vendor's sales team, or an internal note summarising a call. You took it to mean what the phrase says: nothing is stored, anywhere, ever.

That sentence is now heading for a DPIA, a client security questionnaire, or an answer to your insurer. Before it lands in a document with your name on it, it is worth knowing exactly what Zero Data Retention is, because the gap between the control and the way the control gets described in sales conversations is wide enough to matter.

None of what follows is an argument against OpenAI. Every major model vendor gates its equivalent controls behind a contract and keeps similar safety carve-outs. The problem is not the control. It is the shorthand, which gets repeated by suppliers until it hardens into a fact nobody checked.

ZDR is an approval you are granted, not a setting you find

Start with the mechanic that decides everything else. Zero Data Retention is subject to prior approval by OpenAI and acceptance of additional requirements. OpenAI's own developer documentation says eligible customers "may have their customer content excluded from these abuse monitoring logs" by getting approved, and directs readers to contact its sales team about eligibility.

Once granted, it is configured per organisation or per project, in a Data Retention tab under the organisation's data controls. Which means two things a buyer should hold on to.

First, "ZDR is available on OpenAI" and "ZDR is approved for the organisation and project your data will actually run through" are different statements. Only the second one is worth anything in a compliance document, and only the second one is a thing a supplier can evidence.

Second, ZDR is an API organisation-level control. It is not a feature of a ChatGPT subscription tier, and it does not appear on OpenAI's Business versus Enterprise comparison table at all. ChatGPT Business does not offer it. If a supplier is describing seats in a ChatGPT workspace and using the phrase "ZDR enabled", the two halves of that sentence do not belong together.

What ZDR switches off is the abuse-monitoring log, not storage in general

The scope is narrower and more specific than the name suggests.

By default, OpenAI generates abuse-monitoring logs for API usage and retains them for up to 30 days, unless longer retention is required by law. ZDR excludes your customer content from those logs. It also forces the store parameter to false on the responses and chat completions endpoints, even if a request tries to set it to true, so application state is not held server-side either.

That is a real and meaningful control. It is not the same claim as "nothing is retained anywhere". It is a claim about one specific class of logging and one specific storage behaviour, on the endpoints where it applies.

The carve-outs are the part that breaks a "no data is retained" statement

This is the detail that most often goes missing between OpenAI's documentation and the summary a buyer is given.

Even with ZDR in place, OpenAI reserves the right to apply two other treatments to specific models for specific customers. Eyes Off means content is excluded from human review but still logged. Safety Retention means content is retained and human-reviewed. OpenAI states these are applied as notified in advance in writing, and are aimed at cases such as work under a business associate agreement involving health data, or severe-risk scenarios.

Read that against a sentence in a DPIA saying no data is retained and none is human-reviewed. The sentence is not defensible, because the contract you are relying on contains a documented mechanism for both. If the control has conditions, the assessment has to describe them.

The honest version is narrower and still perfectly usable: customer content is excluded from abuse-monitoring logs and not stored as application state on the eligible endpoints, subject to notified safety-retention and eyes-off provisions. That is a sentence you can stand behind in front of an auditor.

It does not apply to every endpoint, and the exclusions are the stateful ones

Eligibility varies by endpoint, and the pattern is logical once you see it: the endpoints that exist to hold state are the ones ZDR cannot cover.

This is where a supplier claim most often falls apart in practice. A system that uses vector stores for retrieval, or the Conversations API to hold chat history, is retaining your content on OpenAI's side until something deletes it, and an organisation-level ZDR approval does not change that. The approval and the architecture have to agree with each other.

Worth noting alongside this: the Assistants API retires on 26 Aug 2026, so anything built on assistants, threads and vector stores has a migration in front of it regardless of its retention posture. That is the moment to fix both at once.

ZDR usually relocates the retention rather than removing it

Here is the part that rarely comes up before a build, and always comes up during one.

With ZDR in force, OpenAI is not storing your requests and responses, and its abuse logs do not contain your content. So when a user reports that the system produced a wrong answer last Tuesday, there is nothing to go back to unless you logged it yourself. The same applies to evaluating output quality, debugging a regression and showing a client what the system actually said.

In practice, teams respond by logging prompts and completions into their own database. Which is a perfectly sound engineering decision, and it means the retention has not been eliminated. It has moved into your estate, where it is now your retention policy, your access controls, your breach exposure and your subject access requests. That can be exactly what you wanted, because you control it. It is not what a reader of the phrase "zero data retention" pictures.

The other cost is architectural. Because state is not held server-side, your own system has to carry conversation context, and retrieval has to run on infrastructure you provide rather than on OpenAI's stateful endpoints. That is more build, more to run, and more to secure.

What to ask, and what to ask for in writing

Four questions, in this order. All four have documentary answers, so a supplier who cannot answer them is telling you something.

1. Is ZDR approved for the specific organisation and project our data will run through? Not

"available", not "we can request it". Approved, and visible in the data controls for that organisation. Ask when it was granted.

1. What are the carve-outs, in writing? Specifically, what has been notified regarding eyes-off

and safety retention for the models in use, and what the notification process is if that changes.

1. Which endpoints does our system actually call? Then check them against the eligibility list

above. If the architecture uses conversations, threads or vector stores, ZDR does not cover that content and someone needs to say so out loud.

1. What are we giving up, and where does the logging go instead? If the answer is that the

supplier logs everything in their own environment, you have not reduced retention. You have changed who holds it, and you should assess them accordingly.

Two facts for the paperwork while you are in it, because both are commonly written up wrong. For a UK customer, the counterparty under OpenAI's Data Processing Addendum is OpenAI OpCo, LLC, the US entity. And the transfer mechanism the DPA names is the EU Standard Contractual Clauses as amended by the Information Commissioner's UK Addendum. Write "UK Addendum" in your assessment.

For most businesses, ZDR is not the control they needed

This is the conclusion that tends to annoy people who have spent three weeks chasing it.

Work back from the risk you are actually managing. If the concern is that your data trains someone else's model, the control you needed already applies: OpenAI does not train on inputs or outputs from ChatGPT Business, ChatGPT Enterprise or the API by default. Consumer ChatGPT is the opposite, opted in unless the user turns it off, which is why the real exposure in most companies is the staff still on personal accounts rather than anything in the corporate contract.

If the concern is where data sits, the lever is data residency, covering the UK, the EU and other regions on eligible API accounts and on new ChatGPT Enterprise and Edu workspaces. The constraint that catches people out is that it is set at creation time and cannot be added to an existing project or workspace. OpenAI also states that in-region API requests run with zero data retention for model requests and responses at rest, so residency and retention are worth scoping together.

If the concern is who can see the data, the levers are access control and provisioning: single sign-on, directory sync, role-based access and log export, most of which are Enterprise-tier controls rather than retention controls.

And if the concern is the data itself, the strongest lever is the least discussed. Do not send it. Redact, tokenise or aggregate at the boundary so the sensitive field never leaves your systems. A retention control governs what a third party does with data you gave them. Not giving them the data governs itself, needs no approval, survives a change of vendor, and is usually cheaper than the compliance programme built to compensate for sending it.

The decision in front of you

If a document you are about to sign off says no data is retained, the question is not whether you trust the supplier. It is whether that sentence survives contact with the endpoint list and the safety carve-outs. Usually it needs rewriting rather than retracting, and the rewritten version is still a good answer.

Then ask the more useful question underneath it: of the four levers, which one actually addresses the risk you were worried about? Often it is not ZDR, and finding that out before the architecture is built saves considerably more than the approval process costs.

Where this fits the rest of the picture is set out in the complete view of ChatGPT and the OpenAI API for UK businesses.

If you want that worked through against your own systems rather than in the abstract, it is part of how we scope OpenAI implementation work. The same test applies to a Claude implementation, which is why these questions sit under AI implementation rather than under any one vendor. We resell nothing and take no margin on your usage, so we have no reason to talk you into a control you do not need. To get the retention position documented before you commit to a build, request a quote.