Research summary — verify current dashboard surfaces with OpenAI Enterprise sales before relying on for compliance

Configure OpenAI Zero Data Retention (2026): Step-by-Step

By DDH Research Team at Digital Dashboard Hub·Updated June 21, 2026

Stop writing AI prompts from scratch.

Tell us your business + your task + your model. We write the prompt — perfectly tuned for ChatGPT, Claude, Grok, Gemini, Midjourney, or any model. Plus 500+ pre-built prompts in your library.

Zero Data Retention (ZDR) is OpenAI's contractual + technical commitment that, for the configured project, OpenAI will not retain prompts or responses past the synchronous inference call. This eliminates the default 30-day abuse-monitoring window during which the standard API stores inputs/outputs encrypted for a small abuse-investigation team to review.

ZDR is the foundational data-handling configuration for regulated workloads using OpenAI directly. It is required for HIPAA-covered traffic (combined with the OpenAI BAA), strongly recommended for GDPR special-category data processing, and useful for trade-secret protection and any sector with persistent-log restrictions.

This guide assumes you are on OpenAI Enterprise (the tier required for ZDR addendum and BAA addendum) or have an active sales engagement to provision Enterprise. If you are on Plus, Team, or pay-as-you-go API without Enterprise, ZDR is not available — you would need to procure Enterprise first.

Related: /vs/zero-data-retention-vendors-2026 (cross-vendor ZDR comparison) · /limits/openai-zdr-eligible-models-2026 (which OpenAI models are ZDR-eligible) · /vs/openai-business-associate-agreement-vs-anthropic-baa (ZDR + BAA for HIPAA).

Digital Dashboard Hub

Following along is one thing; saving the prompt so you can run it tomorrow is another. DDH's AI Prompt Builder + Saved Prompt Library is where the patterns above live, version, and re-export to any model.

Start free 14-day trial — AICHAT30 = 30% off Pro for 3 months. →

ZDR configuration prerequisites and outputs

Feature	Item	Status before ZDR
OpenAI tier	Plus / Team / Standard / API tier	Enterprise (required for ZDR addendum)
Abuse-monitoring retention of inputs/outputs	30 days encrypted, accessible to small abuse team	0 days — not persisted past inference call
Operational metadata (request counts, token counts, latency)	Retained per OpenAI's standard operational logs	Retained per OpenAI's standard operational logs (universal exception)
Project key scope	No ZDR-isolation needed	ZDR-flagged project key — recommended to isolate ZDR traffic on dedicated project keys
Eligible endpoints	All endpoints	Eligible endpoints only — verify the current list on Trust Portal
Caching behavior	Automatic prompt caching applies	Caching applies; cached content evicted per TTL (within the ZDR commitment)
Compatible with BAA for HIPAA	No (HIPAA requires ZDR)	Yes — ZDR is a prerequisite for the OpenAI BAA addendum

Source: openai.com/policies/data-processing-addendum (OpenAI DPA + ZDR addendum reference); trust.openai.com (Trust Portal — ZDR-eligible models, current scope); verify current dashboard surfaces and eligible-endpoints list with OpenAI Enterprise sales as the UI and scope can change.

Why isolate ZDR traffic on a dedicated project

Mixing ZDR and non-ZDR traffic on the same project key is technically possible but operationally messy. The dedicated-project pattern delivers three concrete benefits:

Auditability: the project ID appears in every OpenAI Usage page row and every billing line item. Filtering by project ID instantly shows you which traffic was ZDR-protected. Compare that to filtering by request metadata across a mixed-key project — which requires the application's own audit logs to disambiguate.

Quota isolation: OpenAI's rate limits and usage caps are per-project (depending on tier configuration). A burst of non-ZDR traffic cannot starve the ZDR-protected workload of quota and vice versa.

Membership control: the OpenAI dashboard supports per-project member access. Restrict the ZDR project to a small set of engineers + the security/compliance leader. This satisfies SOC 2 access-control criteria and HIPAA Security Rule access-control requirements for the ePHI-bearing path.

Verifying ZDR is active

After enabling ZDR, verify it is active before routing production sensitive traffic.

Dashboard verification: navigate to the project Settings and confirm the ZDR toggle is on. Capture a screenshot for your audit evidence.

API verification: as of June 2026, OpenAI does not expose a runtime API endpoint to query the ZDR status of a project. The dashboard remains the authoritative surface. Document the verification in your audit log with a timestamp.

Trust Portal verification: log into trust.openai.com, navigate to the document library, and confirm your signed ZDR addendum is in your organization's library. The signed addendum is the contractual proof.

Operational verification: send a test prompt through the ZDR project key, then attempt to retrieve the prompt from OpenAI's stored-completions surface (if applicable to your project). It should not be available. This isn't a proof per se — the 30-day window is opaque to the customer — but a sanity check that the workflow you expected does not surface inputs/outputs to non-runtime retrieval.

ZDR + BAA — the HIPAA combination

For HIPAA-covered workloads, ZDR is necessary but not sufficient. The OpenAI BAA addendum is the contractual artifact that legally permits OpenAI to act as your Business Associate. The combination workflow:

Step 1: confirm Enterprise tier (prerequisite for both ZDR and BAA addenda).

Step 2: request the BAA addendum via OpenAI Enterprise. Expect 2-6 weeks for negotiation and signature.

Step 3: at the same time, request ZDR provisioning on the project(s) that will carry HIPAA traffic.

Step 4: confirm the eligible-endpoints list in your BAA addendum matches the ZDR-eligible-endpoints list. If there is a difference, your usable surface is the intersection.

Step 5: build your application to use only BAA-eligible + ZDR-eligible endpoints on the BAA-scoped project. Add runtime guards to fail fast if the application accidentally requests an ineligible endpoint.

Step 6: document the configuration in your HIPAA SRA and your SOC 2 evidence library. The signed BAA, the signed ZDR addendum, the dashboard screenshot of ZDR enabled, and the application-side endpoint allowlist are the four artifacts an auditor will ask for.

Note: ZDR + BAA on OpenAI direct is often less efficient than the equivalent through Azure OpenAI (where Microsoft's BAA covers the service and abuse-monitoring opt-out replaces ZDR). For healthcare buyers already on Azure, the Azure OpenAI path is strongly recommended over OpenAI direct.

Operational metadata exceptions

ZDR is not absolute zero retention — operational metadata is universally excepted across the industry, and OpenAI's ZDR is no different. The retained data after ZDR is enabled:

Request counts per API key, per model, per endpoint.

Token counts (input and output) per request — needed for billing.

Latency / response time per request.

Model identifier, endpoint identifier, project identifier, organization identifier.

Error codes and high-level failure reasons (rate limit, invalid request).

What is NOT retained under ZDR: the prompt content, the response content, any structured output payload, any function-call arguments or results.

Practical implication for audit logging: your application is the source of truth for prompt content audit trails. If your compliance posture requires knowing what was sent (e.g., to defend against a data subject access request 'what did your AI know about me?'), you must log the prompt content yourself in an access-controlled, encryption-at-rest audit log. ZDR does not give you a vendor-side log to fall back on.

Common ZDR misconfigurations and how to avoid them

Mistake 1: enabling ZDR but using a non-eligible model. The call still bills, but the ZDR commitment may not apply. Mitigation: enforce a model allowlist in your application code against the ZDR-eligible list.

Mistake 2: mixing ZDR project keys with non-ZDR project keys in the same application without rigorous logging. The audit trail becomes ambiguous about which traffic was ZDR-protected. Mitigation: isolate ZDR traffic on dedicated keys and log the project ID + key alias with every invocation.

Mistake 3: relying on ZDR to cover all data handling. ZDR is the vendor-side commitment. Your application's own log retention, your UI's prompt history, your fine-tuning datasets (which are designed to persist), and your downstream storage are all under your control and not affected by ZDR. Mitigation: implement your own minimum-necessary controls and DLP for prompts.

Mistake 4: forgetting that prompt caching applies. Cached prompts are stored encrypted per the TTL (5 minutes default). Cached content is evicted per TTL. Mitigation: confirm with OpenAI that cached content is treated consistent with the ZDR commitment for your project; the cache TTL bounds the cached lifetime regardless.

Mistake 5: assuming ZDR retroactively applies to past traffic. ZDR is prospective. Traffic sent before ZDR was enabled is subject to the standard 30-day abuse-monitoring retention. Mitigation: enable ZDR before any sensitive traffic; if you must use a project that previously had non-ZDR traffic, document the time of ZDR enablement clearly in your audit trail.

Annual re-verification

ZDR is not a one-time configuration. Best practice annual re-verification cycle:

Annually: re-pull the signed ZDR addendum from trust.openai.com and confirm it is in your audit evidence library.

Annually: re-screenshot the dashboard ZDR-enabled toggle for the project(s) carrying sensitive traffic.

Annually: re-verify the ZDR-eligible-endpoints list and update your application's model allowlist if any endpoints have been added or removed from scope.

Annually: re-verify the BAA-eligible-endpoints list (if HIPAA) and confirm intersection with ZDR-eligible.

On material change: when you add a new model use case, when OpenAI launches a new model you intend to use, when OpenAI updates the eligible-endpoint list, re-verify before routing sensitive traffic through the new surface.

On vendor change: if you switch to Azure OpenAI or AWS Bedrock for any portion of your sensitive workload, document the cutover and ensure your SRA / SOC 2 evidence reflects the new vendor's data-handling posture.

Step-by-step ZDR configuration

1
Confirm Enterprise tier and ZDR addendum signature
ZDR is gated on OpenAI Enterprise. If you are not on Enterprise: contact OpenAI sales via the Enterprise contact form on openai.com/enterprise. Procurement typically takes 2-6 weeks. The ZDR addendum is part of the Enterprise commercial agreement — confirm with your account team that the addendum is signed and that ZDR is provisioned at the organization level. The signed addendum will reference the eligible models and endpoints in scope.
2
Create a dedicated project for ZDR-protected traffic
In the OpenAI dashboard, navigate to Settings → Projects. Create a new project named explicitly to identify the ZDR scope (e.g., 'PROD-HIPAA-ZDR'). Best practice: isolate ZDR-protected traffic on its own project. Reasons: (1) per-project usage limits prevent ZDR traffic from competing with non-ZDR for tier-level quota; (2) per-project API keys make audit-log filtering trivial; (3) per-project billing makes the cost of ZDR-covered work visible; (4) per-project membership controls limit who can read or modify the configuration.
3
Enable ZDR on the project
Within the project settings, find the data controls or compliance section (UI naming has evolved — verify current name with your account team). Enable Zero Data Retention. Save. The configuration applies prospectively to API calls on this project's keys. Existing logs in the default 30-day abuse-monitoring window are not retroactively deleted; they age out per the standard retention. Best practice: rotate the API keys for this project after enabling ZDR so that there is no ambiguity about whether prior calls were under ZDR scope.
4
Restrict to ZDR-eligible models and endpoints
Not every OpenAI model and endpoint is ZDR-eligible. Verify the current eligible list on the OpenAI Trust Portal (trust.openai.com) or via your account team. As of June 2026, the chat completions, responses API, batch API, and embeddings endpoints are broadly eligible; some experimental surfaces (Code Interpreter in Assistants, file persistence) have caveats. In your application code, restrict the model parameter to the ZDR-eligible models for this project, and add a runtime guard to fail fast if an ineligible model is requested.
5
Wire your application to use the ZDR project key only for sensitive workloads
Provision the ZDR project's API key as a separate secret (separate Vault path or KMS-encrypted secret in your secrets manager). In your application, route only the sensitive workload through the ZDR key — e.g., the HIPAA-covered clinical assistant path. Non-sensitive paths (internal R&D, public marketing chat) can continue using a non-ZDR project key. This isolation makes the BAA-covered traffic auditable and prevents accidental cross-traffic. Log every invocation with the project ID + key alias in your application's audit trail.

Digital Dashboard Hub

Steps work better when they live in a library you own. DDH's Saved Prompt Library versions, branches, and exports to JSON — your prompts, your way, no lock-in.

Try DDH's AI Prompt Builder — free 14 days, no card. AICHAT30 = 30% off Pro. →

Related calculators

OpenAI Pricing Calculator →GPT-5.5, 5.4, mini, nano — full per-call cost in one input.Claude Pricing Calculator →Opus 4.8, Sonnet 4.6, Haiku 4.5, Fable 5 — input + output combined.Context Window Comparison →Max input length and price per 1M for every current model.

Continue your research on adjacent topics — calculators, rate limits, head-to-head comparisons, and guides.

Related prompt tools

Zero data retention vendors 2026→OpenAI ZDR-eligible models 2026→OpenAI BAA vs Anthropic BAA→Implement DLP for LLM apps→

Use the data programmatically

Every page on this site is also exposed as a free, CORS-open JSON endpoint. No auth, no rate limit (fair-use, please cache). License is CC-BY-4.0 — link back to attribution.canonicalUrl in the response.

Endpoint: https://aipromptshub.co/api/tutorial/configure-openai-zero-data-retention

curl

curl -s 'https://aipromptshub.co/api/tutorial/configure-openai-zero-data-retention' | jq .

Python

import requests

r = requests.get("https://aipromptshub.co/api/tutorial/configure-openai-zero-data-retention", timeout=10)
r.raise_for_status()
data = r.json()
print(data["title"])
for source in data.get("sources", []):
    print("source:", source)

JavaScript / Node

// Node 20+ / modern browser
const res = await fetch("https://aipromptshub.co/api/tutorial/configure-openai-zero-data-retention");
if (!res.ok) throw new Error("HTTP " + res.status);
const configure_openai_zero_data_retention = await res.json();
console.log(configure_openai_zero_data_retention.title);
for (const source of configure_openai_zero_data_retention.sources ?? []) {
  console.log("source:", source);
}

Spec: /api/openapi.yaml · Docs: /api/docs

Frequently Asked Questions

Is ZDR available on the standard OpenAI API tier?

No — ZDR requires OpenAI Enterprise. The standard pay-as-you-go API, Plus, and Team tiers do not have access to ZDR. If you need ZDR, you need to procure Enterprise first.

How long does it take to enable ZDR after I sign the addendum?

Once the Enterprise contract and ZDR addendum are signed, dashboard provisioning is typically instant to a few business days. The total time from Enterprise contract initiation to ZDR active on a project is the procurement timeline (2-6 weeks typical).

Does ZDR cover all OpenAI endpoints?

No — only eligible endpoints. The eligible list as of June 2026 includes chat completions, responses API, batch API, and embeddings. Some experimental surfaces (specific Assistants v2 features, Code Interpreter file persistence) have caveats. Verify the current eligible list on the Trust Portal.

Does ZDR mean OpenAI cannot see my prompts at all?

ZDR means OpenAI does not persist your prompts past the inference call. During the synchronous inference, the prompt is in OpenAI's compute environment to be processed by the model. There is no human-eyeball review of ZDR prompts. Operational metadata is retained (counts, latency, model ID), not content.

Is Azure OpenAI's abuse-monitoring opt-out the same as OpenAI ZDR?

Functionally similar — both eliminate the default 30-day abuse-monitoring window. Mechanically different — Azure OpenAI opt-out is approved via the Azure portal application process and applies at the resource / deployment level; OpenAI ZDR is an Enterprise-tier addendum applied at the organization / project level. Both deliver the same data-handling outcome for the inference call.

Do I need ZDR if I have a BAA?

Yes — the OpenAI BAA addendum requires ZDR for the HIPAA-covered traffic. ZDR is a prerequisite, not an alternative, to the BAA. The BAA is the legal contract; ZDR is the technical/contractual configuration that makes the legal contract operationally consistent.

Does ZDR affect fine-tuning datasets?

Fine-tuning datasets are intentionally persistent — the dataset must be stored to enable training. ZDR applies to the inference of fine-tuned models, not the dataset storage. Fine-tuning data is stored encrypted in your OpenAI organization; access is restricted to authorized organization members.

How do I prove ZDR is enabled to my auditor?

Three artifacts: (1) signed ZDR addendum pulled from trust.openai.com under NDA, (2) dashboard screenshot of ZDR-enabled toggle on the specific project ID, (3) your application's audit trail showing every sensitive call routed through the ZDR project key. Combine into your SOC 2 / HIPAA evidence library.

ZDR active. Now ship minimum-necessary prompts.

ZDR removes the vendor-side persistence. Your prompt determines whether the call sends only what it needs. AI Prompts Hub writes minimum-necessary, de-identification-aware prompts so the ZDR-covered call doesn't carry extra payload that defeats the purpose.

Browse all prompt tools →