OpenAI Zero Data Retention: Research Guide

“Zero data retention” (ZDR) is a specific, requestable configuration on the OpenAI API that stops OpenAI from keeping a copy of your prompts and outputs after the request completes, beyond what it needs to serve the response. It is not a general privacy setting and it is not automatically HIPAA- or FISMA-compliant on its own. For research administrators and PIs deciding whether an AI tool can touch human-subjects, controlled-unclassified, or otherwise regulated research data, ZDR is one piece of a larger compliance picture — useful, narrower than its name suggests, and easy to over-trust.

Last verified 16 August 2026 against OpenAI’s own API documentation (developers.openai.com) and OpenAI’s enterprise privacy page (openai.com/enterprise-privacy), plus Microsoft’s Azure FedRAMP audit-scope documentation for the government-cloud comparison below.

Quick answer: does ZDR alone satisfy your compliance requirement?

Data / regulatory context	Does OpenAI API ZDR alone cover it?	What else you need
Unpublished but non-regulated research data (e.g. draft manuscript text, non-sensitive survey data)	Largely yes, for the retention question specifically	Still confirm your institution’s AI-use policy and any funder/publisher data-sharing terms
HIPAA-covered PHI (clinical research data)	No	A signed Business Associate Agreement (BAA) with OpenAI, and use restricted to BAA-eligible endpoints
FISMA-covered data / Controlled Unclassified Information (CUI) from a federal contract or grant	No	A FedRAMP-authorized processing environment — the direct OpenAI API is not currently FedRAMP-authorized (see below)
FERPA-protected student education records	No	Compliance runs through your institution’s FERPA policy and any data-sharing agreement with the vendor, not through ZDR
Export-controlled research data (ITAR/EAR)	No	ZDR addresses retention, not access control by nationality/location, which export control actually requires

What zero data retention actually does, mechanically

Without ZDR, OpenAI’s standard practice for API traffic is to retain inputs and outputs for up to 30 days for abuse and misuse monitoring, then remove them unless retention is legally required. Under approved ZDR, OpenAI forces the store parameter to false for eligible endpoints, which is meant to prevent that abuse-monitoring copy from being persisted in the first place for your requests.

This is a narrower guarantee than researchers sometimes assume it is:

It is separate from “does OpenAI train on my data.” By default, OpenAI does not use data submitted through the API to train its models unless an organization opts in — that default training exclusion applies whether or not ZDR is also enabled. ZDR is about retention/monitoring, not training.
It only applies to the API, not to consumer ChatGPT. ChatGPT’s free and Plus tiers run under separate consumer terms; ZDR is an API/enterprise data-controls feature, not something a researcher enables from a personal ChatGPT account.
It is endpoint-specific, not account-wide. Approval does not blanket-cover every OpenAI product you might use.

How to actually get ZDR enabled: the procedure

Confirm you’re on the API, not consumer ChatGPT. ZDR is configured for an OpenAI API organization/project. If your lab is currently using the ChatGPT web or desktop app under an individual account, that is a different product with different controls (see the ChatGPT Enterprise/Edu/Healthcare section below).
Check whether your intended endpoints are ZDR-eligible. Per OpenAI’s API documentation, ZDR is available (subject to approval) for endpoints including chat completions, the Responses API, image generation/edits, embeddings, audio, moderations, legacy completions, and realtime — each with its own limitations. It is not available for the Assistants API, Threads, Vector Stores, Conversations, fine-tuning jobs, Batches, or Evals. If your research workflow depends on persistent Assistants/Threads or fine-tuning, plan around the fact that those calls will not get ZDR treatment even after approval elsewhere on the account.
Confirm you have a qualifying use case. ZDR is not self-service by default — OpenAI requires prior approval, generally for organizations with a genuine compliance need (handling sensitive, regulated, or confidential data at scale).
Request approval through OpenAI. For most research organizations this means contacting OpenAI’s sales/enterprise team (via the API platform’s contact-sales flow) and describing the use case, data types involved, and eligible endpoints needed.
Execute the required paperwork. Depending on the data involved, this can include an updated Data Processing Addendum and, separately, a Business Associate and Healthcare Addendum if PHI will ever be in scope (see below — ZDR and a BAA are not the same document and do not substitute for each other).
Enable the control once approved. Organization admins configure ZDR at Settings → Organization → Data controls, at the organization or project level.
Verify in practice. Confirm with your OpenAI account team, and where possible in your own logging, that store is actually being forced to false on the specific endpoints your research pipeline calls — not just that ZDR is “on” for the org generally.

Where ZDR falls short of HIPAA, FISMA, and CUI requirements

HIPAA: ZDR is not a substitute for a Business Associate Agreement

If any prompt, file, or output could contain protected health information (PHI), US law requires a signed HIPAA Business Associate Agreement (BAA) between the covered entity (or its business associate) and OpenAI before that data is ever submitted — regardless of whether ZDR is enabled. ZDR reduces how long OpenAI’s own systems might hold a copy; it does not itself make OpenAI a HIPAA business associate or authorize PHI processing. OpenAI makes BAAs available for eligible API use and separately offers ChatGPT for Healthcare, a workspace product built specifically to support HIPAA-compliant use by clinicians, administrators, and researchers — a different product from the general-purpose consumer app or the raw API. See CASRAI’s HIPAA Privacy Rule entry and the data security incident notification requirements guide for what still applies once a BAA is in place.

FISMA and CUI: ZDR is not a FedRAMP authorization

Federal grants and contracts frequently carry Controlled Unclassified Information (CUI) marking requirements, and any system processing FISMA-covered federal data on an agency’s behalf generally needs to run in a FedRAMP-authorized cloud environment meeting NIST SP 800-171–equivalent controls. As of this verification, the direct OpenAI API and consumer ChatGPT do not appear on the FedRAMP Marketplace as authorized offerings. The FedRAMP-authorized path institutions actually use for OpenAI’s models against CUI/FISMA-covered data is typically Azure OpenAI Service — Microsoft’s hosted deployment of OpenAI’s models inside Azure — which Microsoft’s own Azure FedRAMP audit-scope documentation lists as FedRAMP High and DoD IL2 authorized. Enabling ZDR on a direct OpenAI API account does not confer that authorization; the two are separate, non-substitutable compliance mechanisms. Confirm current FedRAMP status directly against the FedRAMP Marketplace before relying on this for a live CUI determination, since authorization status can change. See CASRAI’s Who Is Responsible for CUI Compliance at a University? guide and the CUI Basic vs. CUI Specified comparison for the underlying marking and safeguarding rules.

Consumer ChatGPT vs. API vs. Enterprise/Edu/Healthcare — know which product you’re actually using

OpenAI operates several distinct products with different data-handling terms, and mixing them up is a common source of false confidence:

ChatGPT (free/Plus, individual account): consumer terms, no ZDR, no BAA available. Never appropriate for PHI, CUI, or other regulated research data.
OpenAI API (direct): where ZDR and BAAs are available, but only after approval and only for eligible endpoints, as above.
ChatGPT Enterprise / ChatGPT Edu: organization-managed workspaces with admin controls and audit logging (Edu is built for universities — students, faculty, researchers, campus operations); these have their own data-handling commitments, distinct from the raw API’s ZDR setting.
ChatGPT for Healthcare: a secure workspace positioned to support HIPAA compliance for clinicians, administrators, and researchers — again a separate product with its own agreement, not “ZDR turned on.”

Before telling an IRB, sponsor, or research security office that an AI tool is “covered,” confirm which of these four your researchers are actually using — the compliance posture is materially different across all four.

A decision checklist before any research data goes into an AI tool

Data classification	Compliant path (illustrative, verify against your institution’s policy)
Public / already-published data	Generally lowest risk; still confirm no embedded confidential co-author or unpublished-result content
Proprietary/unpublished, non-regulated research data	Institutional AI-use policy + a vendor agreement with acceptable retention/training terms (ZDR is genuinely useful here)
HIPAA PHI	Executed BAA covering the specific product/endpoint in use, plus minimum-necessary and de-identification practices where feasible
CUI / FISMA-covered federal data	FedRAMP-authorized environment (e.g. Azure Government/Azure OpenAI Service at the appropriate authorization level), not the direct consumer-facing API
Export-controlled (ITAR/EAR) data	Access and hosting controls addressing nationality/location, coordinated with your export-control office — a retention setting does not address this

Steps, in order: (1) classify the data itself, not just the tool; (2) check your institution’s AI-use and IT security policy for approved tools per classification; (3) check funder, sponsor, IRB, and any Data Use Agreement restrictions specific to the dataset; (4) match the classification to a compliant product/environment from the table above; (5) document the decision — research security and compliance offices increasingly expect a written basis for why a given AI tool was judged acceptable for a given dataset.

Frequently asked questions

Does OpenAI’s zero data retention automatically make the API HIPAA-compliant?

No. ZDR addresses how long OpenAI retains your data; HIPAA compliance requires a separate, signed Business Associate Agreement covering the specific product and endpoints in use, regardless of whether ZDR is also enabled.

Is ChatGPT (the consumer app) covered by zero data retention?

No. ZDR is an API/enterprise data-controls feature. Individual ChatGPT Free or Plus accounts run under separate consumer terms and are not an appropriate destination for regulated research data.

Does zero data retention mean OpenAI doesn’t train on my data?

They are related but distinct. By default, OpenAI does not train its models on data submitted through the API whether or not ZDR is enabled; ZDR specifically targets retention for abuse-monitoring purposes, not model training.

How long does OpenAI keep API data if I don’t request ZDR?

Per OpenAI’s own documentation, API inputs and outputs may be retained for up to 30 days for abuse-monitoring purposes and then removed, unless longer retention is legally required.

Can a university research group request zero data retention?

Yes — ZDR approval is based on having a qualifying use case (typically involving sensitive or regulated data), not on organization type. Universities and research institutions can request it through OpenAI’s sales/enterprise contact process, the same as any other organization.

Does ZDR satisfy FISMA or CUI requirements for federally funded research?

No. FISMA-covered and CUI data generally require processing within a FedRAMP-authorized environment. The direct OpenAI API is not currently listed as FedRAMP-authorized; institutions handling CUI typically use a FedRAMP-authorized route such as Azure OpenAI Service instead.

Zero Data Retention for AI Tools in Research: How It Works and What It Doesn’t Cover

Ask about Zero Data Retention for AI Tools in Research: How It Works and What It Doesn’t Cover