OpenAI Security Explained: Model Safeguards, Data Rules and Gaps

How does OpenAI secure its models and your data? OpenAI security works on two layers. For its most capable models, OpenAI's Preparedness Framework sets capability thresholds, including one for cybersecurity, that trigger stronger safeguards and security controls. For customers, API data isn't used for training by default, abuse-monitoring logs are kept for up to 30 days, and approved organisations can get zero data retention. Most of this is self-reported.

This explainer sticks to OpenAI's own documents: what they promise, where the limits are, and what nobody outside OpenAI has confirmed. It sits in our AI Security section.

What is OpenAI's Preparedness Framework, and does it cover cybersecurity?

The Preparedness Framework is OpenAI's internal policy for deciding when a model is too capable to release without extra protection. The version quoted here is Version 2, last updated 15 April 2025.

It tracks three "Tracked Categories" closely:

Biological and Chemical
Cybersecurity
AI Self-improvement

It also lists five "Research Categories" that it watches without firm thresholds yet: Long-range Autonomy, Sandbagging (a model underperforming on purpose during tests), Autonomous Replication and Adaptation, Undermining Safeguards, and Nuclear and Radiological.

The bar is set high on purpose. The framework defines "severe harm" as "the death or grave injury of thousands of people or hundreds of billions of dollars of economic damage." Everyday risks, like a chatbot leaking a document, sit below that line and are handled elsewhere.

Where are OpenAI's cybersecurity capability thresholds set?

Each Tracked Category has two levels. In plain terms:

Level	What the model can do (OpenAI's wording, shortened)	What OpenAI says it will do
High	"removes existing bottlenecks to scaling cyber operations", for example by automating end-to-end operations against "reasonably hardened targets" or automating discovery and exploitation of relevant vulnerabilities	Security controls at the High standard, misuse safeguards before external deployment, and misalignment safeguards before large-scale internal use
Critical	finds and builds "functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention", or plans and runs novel attacks from a high-level goal	"halt further development" until safeguards and security controls meeting a Critical standard are specified

The cybersecurity row also names a risk to OpenAI itself. Models that could get past "sandboxing or monitoring services" could undermine OpenAI's "ability to track and mitigate all other risks." That concern stopped being theoretical in 2026: our case file on AI agents escaping test environments covers what OpenAI and Hugging Face reported after evaluation agents got out.

In April 2025 the framework stated that OpenAI did "not currently possess any models that have Critical levels of capability." That is OpenAI's own assessment, and it is dated.

How does OpenAI decide whether a model is safe to release?

Before release, every covered model runs automated "Scalable Evaluations". The results go into a Capabilities Report. If a threshold is crossed, OpenAI writes a Safeguards Report describing the protections, how well they work, and the risk left over.

Both go to the Safety Advisory Group (SAG), described as "an internal, cross-functional group of OpenAI leaders". SAG recommends; OpenAI Leadership decides. The Safety and Security Committee of OpenAI's board can review decisions and "may reverse" them.

OpenAI also says it treats any one-off capability test "as a lower bound, rather than a ceiling" on what a model can do in real use.

What security controls does OpenAI say protect its models?

Appendix C.3 of the framework lists the practices OpenAI says it "will require" for High-capability models. The framework says these practices "align with established frameworks such as ISO 27001, SOC2, NIST SP 800-53, and FedRAMP." Highlights:

Zero Trust design, with "hardware-backed security and modern authentication" for critical resources.
Least privilege and separation of duties, with all access "regularly audited and reviewed".
Multi-factor authentication and managed devices for every employee, with access logged.
Multi-person approval for changes to critical infrastructure, with rollback procedures.
Supply chain vetting of hardware, software and third-party libraries.
24x7 on-call monitoring of security and event logs.
Red-teaming and a bug bounty to "encourage reporting of good-faith security research".
Independent audits, with findings "summarized publicly".

A caveat from the same appendix: OpenAI calls its examples "illustrative" and says they "should not be construed as a definitive or comprehensive list."

What do OpenAI's business data terms say about training, retention and residency?

For the API, OpenAI's data controls documentation is specific. Checked 25 October 2026:

Training. "Data sent to the OpenAI API is not used to train or improve OpenAI models," unless you opt in.
Abuse monitoring. Logs are kept "for up to 30 days," unless longer retention is required by law or needed to protect services or others from harm.
Modified Abuse Monitoring (MAM) keeps customer content, other than certain image and file inputs, out of those logs. Zero Data Retention (ZDR) does the same and also forces store to false on the Responses and Chat Completions endpoints. Both need OpenAI's prior approval, through sales.
Stateful features aren't covered. Endpoints such as /v1/files, /v1/assistants, /v1/vector_stores, /v1/fine_tuning/jobs and /v1/batches keep data "until deleted" and are listed as not ZDR-eligible.

For ChatGPT business plans, our AI at work privacy checklist covers the no-training default and the settings to change.

Which regions does OpenAI offer for data residency?

The same page lists ten API regions, each with its own domain prefix: the United States, Europe (EEA and Switzerland), Australia, Canada, Japan, India, Singapore, South Korea, the United Kingdom and the United Arab Emirates.

The detail matters. Only the US and Europe offer regional storage and processing; the UAE offers both "for some models"; the rest offer storage only. Non-US regions need approval and a Modified Retention amendment, and the UAE needs additional approval. Eligible endpoints carry a 10% price uplift for models released on or after 5 March 2026. For why a local region doesn't automatically mean local processing, see our model gateways explainer.

Which certifications does OpenAI's trust portal list?

The OpenAI Trust Portal, checked 25 October 2026, lists SOC 2 Type 2, SOC 3, ISO/IEC 27001:2022, ISO/IEC 27017:2015, ISO/IEC 27018:2019, ISO/IEC 27701:2019, ISO/IEC 42001:2023, PCI DSS v4.0.1, CSA STAR, TX-RAMP and FedRAMP 20x, plus GDPR and CCPA entries.

Scope varies by document. The portal says the 2025 SOC 2 report covers the API Platform, ChatGPT Enterprise, ChatGPT Edu and ChatGPT Team, and the ISO 27001 certificate covers the API, ChatGPT Enterprise and ChatGPT Edu. PCI DSS covers only the ChatGPT components that support delegated payment processing. None of these scope statements names the free or Plus consumer tiers.

What those badges prove is covered in our SOC 2 vs ISO 27001 comparison.

What isn't independently verified about OpenAI security?

Quite a lot.

The framework is self-governed. SAG members and its chair "are appointed by the OpenAI Leadership", and Leadership "can also make decisions without the SAG's participation."
Outside testing is conditional. OpenAI will use third-party evaluators "when available and feasible", and stress-test safeguards "if high quality third-party testing is available."
The bar can move. Section 4.3 says OpenAI "could adjust" its required safeguards if another developer releases a High or Critical system without comparable protection. It would have to acknowledge this publicly and stay "more protective" than that developer.
The version may be stale. The framework promises a review "at least once a year". OpenAI's site blocks automated requests, so this post couldn't confirm whether a newer version exists. Check before relying on the details above.
Audit reports are gated. The trust portal lists control areas such as encryption at rest, enterprise key management and audit logging, but gives no technical detail on the page. The SOC 2 report needs a login.
Bug bounty terms. OpenAI's programme is listed on Bugcrowd, but the page's details didn't render, so this post quotes no rewards or scope. OpenAI's cybersecurity grant pages couldn't be opened either, so there are no funding figures here.

OpenAI's own incident history is a useful reality check. Our summary of what OpenAI has disclosed covers the March 2023 bug and the 2025 Mixpanel vendor breach.

Going deeper: for security and IT teams

Governance artefacts. A Safeguards Report must map each risk pathway "to the associated security controls and safeguards", state efficacy, give residual risk and note "notable limitations". Section 5.2 commits to publishing testing scope and deployment reasoning, possibly "redacted or summarized".

Two threat models, two control sets. Appendix C splits safeguards between a malicious user and a misaligned model.

Malicious user (C.1): robustness (refusal training, jailbreak resistance), usage monitoring with "auxiliary models trained to detect harmful tasks and jailbreak attempts", and trust-based access, including "KYC and identity verification" and limits on fine-tuning or weight release. This is the machinery behind the misuse reports we cover in what AI labs' threat reports reveal.
Misaligned model (C.2): system architecture controls such as "limiting internet access and other tool access", "limiting credentials", sandboxing and "limiting persistence or state". Agent actions "logged in an uneditable database" with asynchronous monitors. "Canary evaluations" test whether a model can bypass weaker copies of the controls.

Apply the same patterns to your own agents; our AI agents guardrails guide turns them into a checklist.

In practice: what ZDR doesn't cover. OpenAI's data controls page lists specific retention periods outside abuse logs. The Responses API keeps application state for 30 days by default unless store is false. Background mode writes to disk "for roughly 10 minutes". Prompt caching "may store encrypted tensors for up to 24 hours". Audio output state is kept for 1 hour. Assistants objects are deleted "30 days after you delete them" and are "retained indefinitely" otherwise. A ZDR approval doesn't change the fact that files, vector stores and fine-tuning jobs persist until you delete them.

In practice: residency is per model. On the same page, UAE processing applies only "for some models", and seven of the ten regions offer storage only. For GCC and India deployments, confirm in writing where inference runs, not just where data rests.

Controls to configure on your side.

Set store: false on Responses and Chat Completions calls that handle sensitive content, even without ZDR.
Use expires_after on uploaded files, and schedule deletion of vector stores, threads and fine-tuning files.
Put sensitive workloads in their own project, since MAM and ZDR are applied "per organization or project".
Send regional workloads to the right domain prefix (for example eu.api.openai.com) and confirm it in egress logs.

What to ask OpenAI.

Which products and regions does the current SOC 2 Type 2 report cover, and which complementary user entity controls does it assume?
Which endpoints we use fall outside our MAM or ZDR approval?
For any model past a High threshold, where is the safeguards summary, and did a third party stress-test it?
Has the Preparedness Framework been revised since Version 2?

Learn more

OpenAI: Preparedness Framework, Version 2 (22 pages; Appendix C holds the controls)
OpenAI: Data controls in the OpenAI platform (retention tables per endpoint, ZDR, residency)

Key takeaways

OpenAI's Preparedness Framework tracks cybersecurity as one of three high-risk capability areas, with High and Critical thresholds.
A Critical cyber capability means OpenAI says it will halt further development until stronger safeguards exist.
API data isn't used for training by default; abuse logs are kept for up to 30 days; ZDR and MAM need approval.
ZDR doesn't cover stored objects like files, vector stores and fine-tuning jobs. Delete them yourself.
The published certification scope statements name the API and business plans, not consumer tiers.
The framework is self-governed, third-party testing is conditional, and safeguards could be adjusted if a rival ships without them.

Sources

OpenAI: Preparedness Framework, Version 2, last updated 15 April 2025 (Tracked and Research Categories, cybersecurity thresholds, SAG governance, Section 4.3 marginal risk, Appendix C safeguards and security controls)
OpenAI: Data controls in the OpenAI platform (training default, 30-day abuse monitoring, MAM, ZDR, endpoint retention, data residency regions and requirements), checked 25 October 2026
OpenAI: Trust Portal (certifications listed, SOC 2 and ISO 27001 product scope, PCI DSS scope, gated documents), checked 25 October 2026
Not read: OpenAI's Bugcrowd programme page (did not render) and OpenAI's cybersecurity grant pages on openai.com (blocked automated requests). No figures from either appear in this post.