OpenAI API Enterprise Security Controls and Compliance Posture

Enterprises deploying OpenAI's models face a security review with more moving parts than most vendor assessments. The API Platform and ChatGPT Enterprise are two separate control surfaces, each with its own certifications, data rules, identity setup, and logging system. Understanding what each layer actually promises, and where the gaps sit, separates a real due diligence process from a checkbox exercise.

Why the API and ChatGPT Enterprise are different control surfaces that require separate evaluation

Start with the basic split. ChatGPT Enterprise is built for people typing into a chat window. The API Platform is built for applications and agents calling models programmatically. OpenAI's enterprise privacy commitments stretch across both, but the actual controls, defaults, and admin tooling diverge in ways that matter once a legal or security team starts asking specific questions.

That divergence causes a predictable problem. A team that reads only the ChatGPT Enterprise admin docs walks away thinking they understand OpenAI's security posture, when in fact they've reviewed half of it. Flip it around: an engineering team that only checks API documentation misses the admin console features that govern the people-facing product. Both readings are incomplete on their own.

The gap gets worse before formal contracts exist. By late 2025, around 92% of Fortune 500 companies had employees using ChatGPT, and much of that use started informally, through personal accounts, before any enterprise agreement was signed. Shadow use on Free, Plus, or Pro tiers carries none of the contractual protections that come with an enterprise agreement or an API contract. An employee pasting a customer contract into ChatGPT Plus on a personal login is operating in a completely different risk category than the same employee working inside a provisioned enterprise workspace.

So the right way to evaluate OpenAI's security posture is as a stack, with four layers: certifications and third-party attestations, data governance defaults, identity and access management, and compliance observability tooling. Each layer needs its own scrutiny. Passing one doesn't imply the others are covered.

What OpenAI's certifications and third-party attestations cover (and what they leave out)

Certifications tell you what got audited, by whom, and against which standard. They don't tell you the whole story unless you read the scope language closely.

OpenAI's SOC 2 Type 2 report, the most recent one covering July 1, 2025 through June 30, 2026, is available to authenticated users on trust.openai.com. It covers Security, Availability, Confidentiality, and Privacy under the Trust Services Criteria, and the scope includes the API Platform, ChatGPT Enterprise, ChatGPT Edu, and ChatGPT Team. That's a fairly wide net, but notice what it's still not: an endorsement of a specific customer's implementation, or a guarantee that a specific integration is secure.

The ISO portfolio rounds things out. ISO/IEC 27001:2022 and ISO/IEC 27701:2019 cover information security and privacy management systems for the API, ChatGPT Enterprise, and ChatGPT Edu. ISO/IEC 27017:2015 and ISO/IEC 27018:2019 add cloud-specific security and privacy controls. Then there's ISO/IEC 42001:2023, the AI Management System standard, covering both consumer and business AI products in OpenAI's dual role as an AI producer and an AI provider. Independent compliance reviewers have pointed to this one specifically, noting that management standards specific to this technology category are still rare. That's a meaningful claim, since management standards specific to this technology category are still rare, and most vendors don't have one.

Two more pieces round out the picture, each narrower than it sounds. CSA STAR Level 1 is a self-assessment, not an independent audit, covering cloud security transparency principles for the ChatGPT business product and the API Platform. And PCI-DSS compliance is limited strictly to the components of ChatGPT that support delegated payment processing. It says nothing about how OpenAI handles data more broadly. Treating PCI-DSS as a general data-handling attestation would be a mistake, and a fairly common one.

Data governance defaults: what "no training by default" means in practice

The headline commitment is straightforward: by default, OpenAI does not use data from ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu, ChatGPT for Healthcare, ChatGPT for Teachers, or the API Platform to train or improve its models. For the API, that's been the contractual position since March 1, 2023, which gives it a longer track record than most people realize.

Ownership follows the same logic. Customers keep all rights to what they put in, and outputs belong to the customer to the extent the law allows. Fairly clean, on paper.

Where it breaks down is at the consumer tier, and this actually causes damage. ChatGPT Plus, the individual paid consumer product, trains on conversations by default, unless the user manually opts out. That single fact explains most of the real-world data exposure risk tied to OpenAI's products. Enterprise contracts, data processing agreements, and admin console controls apply to managed workspaces. They do nothing for the employee logged into ChatGPT Plus on a personal account, pasting internal documents into a chat window that legal never approved and IT never provisioned. No amount of enterprise-tier contract language reaches outside the managed environment where it was negotiated.

Underneath both surfaces, the baseline encryption is standard and unremarkable in the best sense of that word: AES-256 for data at rest, TLS 1.2 or higher for data in transit, both between customers and OpenAI and between OpenAI and its own service providers.

Zero Data Retention and Private Safety Processing: how OpenAI is reconciling data minimization with safety monitoring

Zero Data Retention, or ZDR, is the strongest data minimization commitment OpenAI offers on the API. Under ZDR, prompts and model responses aren't retained once a request finishes processing, and OpenAI personnel can't pull up customer content for review. That's a meaningfully different posture from the default API behavior, where some retention applies.

ZDR is something every API customer must be approved for, not something granted automatically. It's approval-gated through sales. A customer has to ask for it, qualify for it, and negotiate it into the contract. It is not the out-of-the-box setting.

The tension is this. As models get more capable and more agentic, taking multi-step actions rather than just answering single prompts, abuse detection can't rely purely on a human reading through prompts after the fact. But if ZDR means nothing is retained, how does OpenAI catch misuse? That's where Private Safety Processing comes in: automated systems assess associated activity and generate a limited risk signal, rather than preserving the actual readable prompt or output. Think of it as privacy-preserving telemetry, similar in spirit to how some security tools flag anomalous behavior without storing the full content that triggered the flag.

The result is that ZDR means the readable content is gone, but a signal pathway for safety monitoring still exists underneath it. It means the readable content is gone, but a signal pathway for safety monitoring still exists underneath it. For most customers that distinction won't matter much. For regulated industries, it might matter quite a bit. GDPR's Article 5 minimization principle and HIPAA's minimum necessary standard both draw a line between "no prompt retention" and "no metadata retention," and those are not the same line. A privacy or compliance team evaluating ZDR needs to ask specifically what Private Safety Processing captures. Since ZDR itself has to be explicitly negotiated, confirm it during procurement rather than assuming it's baked into the default agreement.

Data residency options: what "data stored in-region" covers

Data residency, for eligible ChatGPT Enterprise, ChatGPT Edu, and API Platform customers, is available across ten regions: the U.S., Europe, UK, Japan, Canada, South Korea, Singapore, Australia, India, and UAE. That covers data at rest, meaning where stored data physically lives.

Inference residency is a narrower promise. In-region GPU inference, the actual model computation happening on hardware located in that region, is currently available in the U.S. and Europe for eligible customers. For select enterprise and healthcare clients, Europe also offers inference on regional GPUs with requests and responses processed locally under zero data retention. That's a tighter guarantee than the general data-at-rest residency list, and it applies to fewer customers.

Turning residency on isn't automatic. Enterprise customers approved for advanced data controls create a new Project inside the API Platform dashboard and pick a region there; requests routed through that project get handled in-region. What happens by default, before anyone configures a project? The answer is that standard API traffic is not EU-resident out of the box. EU residency is something a customer configures, not something that ships turned on. For any organization sending prompts that contain personal data covered by GDPR, confirm that before assuming residency is handled.

Identity and access management controls: availability by tier and dependence on the customer's own IdP

At enterprise tier, the core identity toolkit includes domain verification, SSO through SAML, SCIM provisioning, and IP allowlists. These are the standard building blocks security teams expect from any enterprise SaaS product, and OpenAI's implementation follows familiar patterns.

SCIM and SSO get lumped together in casual conversation, but they do different jobs. SCIM manages the user lifecycle: provisioning accounts, syncing groups from the customer's identity provider, and enabling role-based access control by mirroring IdP group structures. Through SCIM, admins manage permissions, spend controls, feature access, and staged feature rollouts. SSO, by contrast, handles the actual sign-in event, verifying who someone is at the moment they log in. One governs who exists and what they can touch; the other governs how they get in the door.

Tenant-wide SCIM has a specific eligibility requirement: at least one verified domain, plus an eligible ChatGPT Enterprise workspace, ChatGPT Edu workspace, or Ads account. Notably, it's unavailable on standalone ChatGPT Business. That's a meaningful gap for smaller organizations that adopted Business as a stepping stone before Enterprise.

One thing worth flagging clearly: multi-factor authentication, device restrictions, and conditional-access policies aren't things OpenAI enforces on its own. They're configured inside the customer's own identity provider, and OpenAI applies them at the point of authentication through that provider. If a customer's IdP has weak MFA policy, that weakness carries straight through, since OpenAI isn't independently layering its own enforcement on top.

One exception exists. Individual members of Trusted Access for Cyber, when accessing the most capable and permissive models, are required to enable Advanced Account Security. Organizations can alternatively attest that phishing-resistant authentication is already part of their SSO workflow. That's a narrower program, but it shows OpenAI does step in with mandatory controls for its highest-risk access tier, rather than leaving everything to customer discretion.

Compliance observability: what the Compliance Logs Platform delivers and its retention limits

Logging is where a lot of compliance programs either work or quietly fail, and OpenAI consolidated its approach here into what it calls the Compliance Logs Platform. It exports observability and compliance data as immutable, time-windowed JSONL log files, with minutes-level latency and one consistent ingestion pattern across different log categories, rather than a separate export mechanism for each type.

The categories currently available include Admin Audit, User Authentication, and Codex Usage logs, among others. That's a reasonably complete picture for an enterprise security team building out its own log-management pipeline or compliance archive.

A migration detail needs to be tracked closely if it applies to a given deployment. A new conversation logs system rolled out March 5, 2026, replacing the old stateful route, and that older route was removed entirely on June 5, 2026. Any enterprise still relying on the old system past that date lost access. It's the kind of deprecation that's easy to miss if a security team isn't actively watching OpenAI's release notes, and the consequence, losing log access, is not a small one for anyone under a regulatory retention obligation.

One more limit to flag: the Compliance Logs Platform itself is available only to OpenAI Enterprise and Edu customers. Anyone on a lower tier needs to build their own logging discipline around whatever more limited export options their plan actually includes.

Regulatory compliance posture: what OpenAI supports contractually

For organizations operating under GDPR, OpenAI can execute a Data Processing Addendum covering ChatGPT Business, ChatGPT Enterprise, and the API. OpenAI has established a legal entity serving users in the EEA and Switzerland, a structural detail that determines which supervisory authority has jurisdiction over those users. That's a meaningful detail for any legal team in that region mapping out which regulator actually has jurisdiction over a given complaint or audit.

What ties the whole stack together is plan tier. Certifications apply broadly across products, but the controls that actually make those certifications operationally meaningful, things like ZDR, in-region inference, tenant-wide SCIM, and the Compliance Logs Platform, are gated behind Enterprise or Edu agreements, and sometimes behind a specific sales approval on top of that. A team evaluating OpenAI for a regulated workload needs to check not just whether a control exists somewhere in OpenAI's documentation, but whether that control is actually included in the specific contract on the table. That's the step a surface-level read of a trust page will never catch, and it's exactly the step a real due diligence process is built to catch instead.