Loading the catalogue…
Loading the catalogue…
Compliance posture
Stav's assessment · serving-side
OpenAI operates as a US-incorporated entity under US jurisdiction with full CLOUD Act and FISA 702 exposure, serving inference by default from US infrastructure across a multi-cloud stack of Azure, Oracle, AWS, and Google Cloud — no EEA-resident serving path is available to standard-tier API customers. Stav's operational verdict: sovereign serving is not available on standard-tier; enterprise-tier configuration with executed DPA, ZDR approval, and EU-region endpoint is required as a minimum, and even then a CLOUD Act / FISA 702 derogation assessment under GDPR Art. 49 or a full Transfer Impact Assessment should be completed before deploying regulated EEA workloads.
Default API inference runs on US infrastructure (Azure US regions, Oracle, AWS, GCP); EU data residency is a non-default, enterprise-tier, approval-gated option unavailable for all models/endpoints, meaning EEA personal data is processed in the US by default.
OpenAI, Inc. is US-incorporated with full CLOUD Act and FISA 702 exposure over all inference traffic regardless of physical data-center location; the EEA contracting entity (OpenAI Ireland Limited) transfers data onward to US affiliates and US-hyperscaler sub-processors, and the EU-US DPF adequacy decision faces an active ECJ challenge filed October 2025.
API business data is not used for model training by default, but prompts and outputs are retained for up to 30 days for abuse monitoring by default; Zero Data Retention requires sales-team approval and is not self-service, and a US federal court litigation-hold (May–September 2025) forced retention of standard API output logs in conflict with GDPR Art. 17 erasure rights.
Risk assessment
OpenAI, Inc. is incorporated in the United States. All inference traffic routed through the standard API (openai.com endpoints) is subject to CLOUD Act and FISA 702 compelled-disclosure reach regardless of physical data center location. US courts can compel production of customer prompt/output data held on OpenAI's servers. This is a structural, non-waivable risk for EEA regulated-sector customers. source ↗
LEGAL_EXPOSUREDefault API processing runs on US infrastructure (primarily Microsoft Azure US regions, with additional capacity on Oracle, AWS, and Google Cloud). API EU residency options exist but require enterprise-tier configuration and are not available for all endpoints or model snapshots. Standard-tier API customers have no guaranteed EEA data residency. source ↗
DATA_RESIDENCYBy default, abuse monitoring logs containing prompts and responses are retained for up to 30 days for all API usage. The Responses API additionally stores application state for 30 days by default when store=true. Zero Data Retention (ZDR) is approval-gated — it requires a sales-team approval process and is not a self-service dashboard toggle — creating a gap for standard-tier customers who have not completed the approval process. source ↗
SERVING_RETENTIONSafeguards
ISO/IEC 27001:2022 certificate publicly viewable via OpenAI Trust Portal (trust.openai.com, powered by SafeBase). Full certificate inventory confirmed by CompanyScope review dated 2026-04-29. source ↗
SOC 2 Type II report available behind NDA/registration gate at trust.openai.com, covering all products. source ↗
ISO/IEC 27701:2019 (Privacy Information Management), ISO/IEC 27017 (Cloud Security), ISO/IEC 27018 (Cloud Privacy), and ISO/IEC 42001:2023 (AI Management Systems) confirmed via CompanyScope review. source ↗
EU-US Data Privacy Framework (DPF) certification active as of 2026-03 per CompanyScope review; provides an adequacy-based transfer mechanism supplementing SCCs. source ↗
API business data is not used to train OpenAI models by default (confirmed since March 1 2023). Business users including ChatGPT Team, ChatGPT Enterprise, and API are opted out of training by default; opt-in is explicit. source ↗
Privacy-policy issues
Default 30-day prompt/output retention at serving boundary for abuse monitoring. source ↗
All standard API requests generate abuse monitoring logs retaining prompts and responses for up to 30 days; GDPR data-minimisation obligations require customers to actively apply for ZDR rather than receiving it by default.
ZDR not self-serve: approval-gated, not a dashboard toggle. source ↗
Zero Data Retention requires sales-team approval and additional contractual requirements; standard-tier and SME customers who are not enterprise-managed cannot achieve zero retention without a qualification process.
Default API endpoint is not EU-resident; EU residency requires enterprise configuration. source ↗
Default API processing runs on US infrastructure; EU data residency is a non-default, enterprise-tier, approval-gated option that most API customers will not have configured, making US data transfer the default state for EEA personal data in prompts.
Certifications & legal documents
Endpoints served · 14
Multiple current certifications are in place (ISO 27001:2022, ISO 27017, ISO 27018, ISO 27701, ISO 42001, SOC 2 Type II, PCI DSS v4.0.1, CSA STAR) with AES-256 at rest and TLS 1.2+ in transit; a 2024 internal forum breach did not compromise customer data, and the November 2025 Mixpanel sub-processor breach exposed only developer metadata with proactive public disclosure, though the multi-cloud sub-processor chain introduces residual uncertainty.
A publicly accessible DPA incorporating EU 2021 SCCs (Modules 2 and 3), UK Addendum, and Swiss FADP provisions exists with OpenAI Ireland Limited as the EEA counterparty and a published sub-processor list updated 2026-02-11; however, the DPA must be actively executed by customers (not auto-applied), ZDR requires enterprise approval, general written authorisation (Option 2) is used for sub-processor changes, and audit rights are not explicitly documented in the research findings.
A US federal court (SDNY, Magistrate Judge Wang, May 2025) issued a litigation-hold order requiring OpenAI to retain all consumer ChatGPT and API content indefinitely, including previously deleted data, in connection with NYT copyright litigation. The order was in force April–September 2025. OpenAI stated ZDR API traffic was not affected, but consumer and standard API data was subject to the hold, directly conflicting with GDPR Art. 17 erasure rights for EEA data subjects. source ↗
SERVING_RETENTIONOpenAI operates a multi-cloud inference stack across Microsoft Azure, Oracle, AWS, and Google Cloud (as of 2025 restructuring). Each sub-processor may independently be subject to US surveillance law. The sub-processor list is published but general written authorisation (GDPR Annex SCCs Option 2) is used, meaning customers receive notice of sub-processor changes rather than affirmative consent. source ↗
SUBPROCESSINGIn November 2025, third-party analytics sub-processor Mixpanel suffered a breach that exposed OpenAI API developer account metadata (names, emails, browser/OS details, approximate location). No prompt content or API keys were compromised, but the incident revealed that Mixpanel had access to platform.openai.com user metadata. OpenAI subsequently terminated Mixpanel. source ↗
SUBPROCESSINGOpenAI's DPA nominates OpenAI Ireland Limited as the EEA contracting entity for EEA/Swiss data. However, OpenAI Ireland Limited transfers data onward to US affiliates and sub-processors under SCCs. The EU-US DPF adequacy decision faces active ECJ challenge (appeal filed October 2025, ruling expected late 2026 at earliest); invalidation would remove the DPF transfer mechanism and force sole reliance on SCCs. source ↗
LEGAL_EXPOSUREIn early 2024, a threat actor breached OpenAI's internal employee discussion forums. The company did not notify law enforcement, determining the attacker was a private individual. No production model weights or customer data systems were reportedly accessed, but the incident exposed internal communications and generated internal safety governance concerns. source ↗
SECURITYIn February 2025, a BreachForums actor claimed to possess 20 million OpenAI login credentials. Cybersecurity firm KELA analysed a sample and determined the credentials originated from infostealer-compromised end-user devices, not a breach of OpenAI's own systems. No evidence of direct infrastructure compromise was established. source ↗
SECURITYOpenAI's DPA uses general written authorisation for sub-processor changes (GDPR SCC Clause 9, Option 2): customers receive advance notice and an opportunity to object, but affirmative consent is not required. This is standard practice but operationally significant for compliance teams managing vendor-change processes under Article 28. source ↗
CONTRACTUALOpenAI's multi-cloud 2025 restructuring (Azure, Oracle, AWS, GCP) distributes inference across providers with differing SLA, security, and sub-processor transparency regimes. For EEA customers, the contracting entity is OpenAI Ireland Limited for EEA data but the operational accountability chain for specific inference runs is not fully transparent as to which cloud provider processes a given request. source ↗
GOVERNANCEZero Data Retention (ZDR) option available for approved enterprise customers on eligible endpoints: prompts and outputs are never logged and not retained after request completion. ZDR API traffic was explicitly exempted from the 2025 US court litigation-hold order. source ↗
DPA published and publicly accessible at openai.com/policies/data-processing-addendum/. Incorporates EU 2021 SCCs (Module 2 C2P and Module 3 P2P), UK Addendum, and Swiss FADP provisions. OpenAI Ireland Limited named as EEA contracting entity. UK ICO named as competent supervisory authority in SCC Clause 18. source ↗
Sub-processor list published at openai.com/policies/sub-processor-list/ and last updated 2026-02-11, providing disclosure of downstream processing partners per GDPR Article 28(3)(d). source ↗
AES-256 encryption at rest and TLS 1.2+ in transit for all customer data, confirmed in OpenAI enterprise privacy documentation. source ↗
Public Trust Portal at trust.openai.com (SafeBase) provides access to compliance documents, certification artifacts, and security questionnaire responses for enterprise reviewers. source ↗
OpenAI issued a proactive public disclosure and user notification regarding the November 2025 Mixpanel sub-processor breach, including transparent description of affected data categories, confirmation that no prompt/API content was exposed, and notification to all impacted users. source ↗
EU data residency option available for ChatGPT Enterprise tier; API EU residency also available for eligible enterprise contracts requiring configuration. API docs confirm a regional support table for EU-region processing (not available for all models/endpoints). source ↗
US court litigation-hold (May–September 2025) conflicted with GDPR Art. 17 erasure rights. source ↗
A US federal court order required OpenAI to retain and segregate consumer and API output log data that would otherwise be deleted, directly overriding erasure requests from EEA data subjects during the April–September 2025 period; OpenAI acknowledged this conflicted with EU privacy standards while challenging the order.
EU-US DPF adequacy decision subject to active ECJ challenge. source ↗
An ECJ appeal on the DPF's adequacy was filed in October 2025 with a ruling expected no earlier than late 2026; invalidation would remove the DPF as a transfer mechanism, leaving SCCs as the sole basis, which require a Transfer Impact Assessment given US FISA 702 surveillance laws.
DPA is opt-in / must be actively executed by API customers. source ↗
OpenAI's DPA is not automatically applied to all API use; customers must execute it, meaning developers who call the API without a signed DPA are making cross-border transfers of personal data without adequate GDPR Article 46 safeguards in place.
Sub-processor Mixpanel breach (November 2025) exposed API developer metadata. source ↗
A breach at analytics sub-processor Mixpanel exposed account names, emails, browser details and approximate location of some platform.openai.com API users; no prompt content was involved, but the incident demonstrated that third-party sub-processors had access to user-identifiable metadata.