OpenAI Zero Data Retention Needs an Endpoint Acceptance Matrix

OpenAI zero data retention is an approved control for a named API organization or project, followed by an endpoint and capability decision. OpenAI's current data-controls guide says eligible customers can apply for Zero Data Retention or Modified Abuse Monitoring. It also lists endpoints that remain ineligible because they store application state. I would reject an assessment that records "ZDR enabled" once and applies that answer across Responses and Conversations, or across Files, Batches, Realtime, and audio, without checking the production route.

TL;DR

• Confirm OpenAI approval for the exact API organization or project and preserve the enrollment evidence with a named owner.
• Build one acceptance row per production endpoint and feature set. Record abuse-monitoring treatment and application-state retention separately.
• Treat Responses and Chat Completions as conditionally eligible, then verify limitations. Conversations and Files need separate decisions, as do Batches and other stateful surfaces.
• A gateway can enforce an approved route and preserve customer-side request evidence. OpenAI still owns enrollment and provider storage, including deletion and service-side exceptions.

Start with enrollment and scope

OpenAI's data-controls guide says abuse-monitoring logs are generated by default for API usage and retained for up to 30 days, subject to legal and service-protection exceptions. Eligible customers may apply to exclude customer content from those logs through Zero Data Retention or Modified Abuse Monitoring. Approval and additional requirements apply.

Put the legal entity and OpenAI API organization ID at the top of the matrix. Add the project ID, control type, approval reference, effective date, reviewer, and account owner. Then map the production API key or service account to that organization and project. A procurement PDF and a secret-store entry can sit in two browser tabs and still point to different scopes. The acceptance test should catch that mismatch.

Keep OpenAI API controls separate from ChatGPT workspace controls covered in OpenAI enterprise security. The logo and vendor are shared. The enrollment surface and credentials differ, as do the endpoints and state behavior.

Split abuse monitoring and application state

OpenAI describes abuse-monitoring retention and application-state retention as separate fields. Preserve both retention fields in every row. ZDR excludes customer content from abuse-monitoring logs for covered usage, while endpoint capabilities may still store state. A single "retention" column loses the decision that matters.

The current guide says ZDR also changes endpoint behavior. For /v1/responses and /v1/chat/completions, the store parameter is treated as false even when a request attempts to set it to true. The same page warns that endpoints and capabilities marked ineligible may store application state with ZDR enabled.

Use these matrix columns:

• API organization and project, plus the credential route and approval reference
• Endpoint and request mode, with the model, tools, modalities, and enabled capabilities
• Default abuse-monitoring retention and approved control
• Application-state retention and deletion owner
• Published ZDR eligibility plus every stated limitation
• Synthetic validation request and request ID, with the timestamp and deployed application version
• Technical owner and privacy owner, followed by the review date, exception, evidence owner, and change trigger

The field names look repetitive because they prevent a dangerous shortcut. Enrollment answers who has the control. Endpoint and capability fields answer where it applies.

Make endpoint rows explicit

OpenAI's table currently marks /v1/chat/completions and /v1/responses as ZDR eligible with limitations. It marks /v1/conversations and /v1/conversations/items ineligible, with state retained until deletion. Files and Batches also appear as ineligible and have their own application-state treatment. Realtime and several audio endpoints carry different rows again.

Create a separate acceptance row for each route the application can call. For Responses, record File Search and Web Search individually. Remote MCP and hosted code capabilities also need their own rows because capability-specific limitations can change the result. For Chat Completions, record modalities and any stateful behavior. Identify who deletes each File object and which workflow depends on it. A Batch row should preserve the asynchronous job and input or output object lifecycle.

Avoid converting the table into a vendor-wide statement. "OpenAI ZDR applies" lacks the endpoint and capability, along with the application-state decision. The useful sentence is narrower: "Project P-17 is approved for ZDR, and release 4.8 sends plain text Responses calls through the reviewed route with store treated as false."

The Anthropic zero data retention guide uses the same route-level discipline for a different provider. Keep the provider matrices separate because the eligible endpoints and exceptions differ.

Run a production-route acceptance test

Use a synthetic prompt with a unique marker such as VIOLET-ROUTE-83 and no confidential data. Send it through the exact production identity and project. Preserve the host, endpoint, model, request mode, tools, capability flags, and application release. Preserve the request ID and timestamp. Record the request construction and the route policy that approved it.

Compare the captured configuration with OpenAI's current table. The test passes when the organization or project has documented approval, the endpoint is eligible, each capability is allowed under the stated limitations, and the evidence identifies the route without guesswork. This test cannot inspect OpenAI storage. It proves that the application used the route the organization approved against OpenAI's published treatment.

Add controlled negative tests in a nonproduction project. Attempt a known ineligible endpoint and a Responses configuration outside the approved capability set. Confirm that the application or gateway rejects the route before sensitive content reaches it. A check that matches only api.openai.com is too broad.

Store the result beside the deployed configuration. A yearly questionnaire detached from the API client will miss a capability added in a Tuesday release.

Join public assurance evidence carefully

The OpenAI Trust Portal publishes security and compliance material, including a SOC 2 Type 2 report access path and ISO certifications. Treat those materials as assurance evidence for the services they scope. They do not replace the ZDR approval or endpoint table.

For procurement, preserve the current report or vendor-authorized trust-center evidence and identify the exact scoped service. Record the report period and exceptions. Add bridge evidence where available. A public certification sentence cannot prove that project P-17 has ZDR or that /v1/files inherits the treatment of /v1/responses.

Put assurance documents and route tests in the same acceptance packet with separate labels. The trust material supports vendor-control review. The endpoint matrix supports the production-route decision. I prefer two clearly scoped records over one polished document that blurs them.

Set expiry and change triggers

Give every accepted row an expiry date. Trigger a new review when the OpenAI organization or project changes. A moved credential and endpoint change also expire approval, as does a new tool or stateful capability. Include changes to the model and request mode, plus OpenAI's table or exception wording. Contract renewal and account migration also belong on the list.

Assign a technical owner to rerun the synthetic route test and a privacy or procurement owner to confirm approval. The organization's own request evidence may need longer retention than provider content. LLM audit log retention covers that separate policy decision.

A route can lose acceptance without a contract change. One new File Search tool or conversation object may change the state treatment. The matrix should fail closed when the deployed request no longer matches its accepted row.

DeepInspect

DeepInspect can enforce the accepted route when an authenticated application sends its OpenAI API request through the DeepInspect HTTP proxy. It can bind caller identity and data class to an approved organization or project. The policy can then restrict the endpoint, model, capability profile, and request mode. The resulting per-decision record shows which policy approved or blocked that specific request.

OpenAI remains responsible for ZDR enrollment and provider storage, including deletion behavior and service-side exceptions. DeepInspect cannot inspect provider storage or turn an ineligible endpoint into an eligible one. ChatGPT sessions and provider-hosted application state remain outside its evidence claim. Files lifecycle, Batch processing, stateful service behavior, and direct calls that bypass the customer-controlled route remain outside as well. Book a demo today.