ChatGPT Enterprise Data Privacy

Key takeaways

• ✓ChatGPT Enterprise does not use your conversation data to train OpenAI's models, which is the single most important distinction from the free tier and from ChatGPT Plus.

• ✓OpenAI provides a data processing agreement (DPA) with Enterprise accounts, but your organisation remains the data controller and retains responsibility for what employees submit.

• ✓Australian Privacy Principles under the Privacy Act 1988 still apply. If staff feed personal information about customers or employees into any AI tool, including ChatGPT Enterprise, your APP compliance obligations follow that data.

• ✓Zero data retention at the API level and enterprise-grade access controls reduce risk significantly, but they do not eliminate it. Prompt content, hallucinated outputs, and third-party integrations each carry residual exposure.

• ✓Technical controls alone are not enough. Teams need clear guidance on what to submit, what to keep out, and how to verify AI-generated outputs before they are acted on.

What does ChatGPT Enterprise actually promise on data privacy?

ChatGPT Enterprise makes three core commitments that distinguish it from OpenAI's consumer and small-business tiers: your prompts and outputs are not used to train OpenAI's models, the platform is covered by a SOC 2 Type II attestation, and all data is encrypted both in transit and at rest.

The no-training commitment is the one most CISOs care about first. Under the ChatGPT Enterprise terms, conversations are excluded from the datasets OpenAI uses to improve its models. That means a staff member drafting a contract, summarising a board paper, or querying internal figures is not inadvertently contributing proprietary information to a shared model that competitors or the public might later query against. OpenAI formalises this through a Data Processing Agreement (DPA), which we cover in more detail in section 4.

On the infrastructure side, data in transit is protected using TLS 1.2 or higher, and data at rest is encrypted using AES-256. These are standard enterprise-grade controls, not differentiators in themselves, but they are the baseline any CISO should confirm before deployment.

SOC 2 Type II is an audit report, produced by an independent third party, that tests whether a vendor's security controls are operating as described over a sustained period (typically six to twelve months). A Type II report is more meaningful than a Type I, which only assesses whether controls are designed correctly at a single point in time. OpenAI publishes its SOC 2 Type II report under NDA to enterprise customers. Requesting it should be a standard step in your procurement process.

The DPA is not automatic

ChatGPT Enterprise includes access to a Data Processing Agreement, but your legal and privacy teams need to review and execute it. Deploying the product without a signed DPA in place means you are relying on OpenAI's standard terms, which carry weaker protections.

One thing worth being precise about: these commitments apply to the Enterprise tier specifically. The free tier, the Plus subscription, and ChatGPT Team all operate under different terms. If staff are accessing ChatGPT on personal accounts or through the free product, none of these protections apply to those sessions. That distinction matters a great deal when you are trying to understand your actual risk surface, not just your contracted one.

How is ChatGPT Enterprise different from the free and Team tiers?

The gap between the free tier and Enterprise is significant. Between Team and Enterprise, it is smaller but still matters for a CISO.

Here is how the three tiers compare on the dimensions that actually affect your risk posture:

A few things are worth unpacking here.

Training opt-out. On the free tier, your conversations are used to improve OpenAI's models unless you manually turn this off in settings. Most users never do. Team and Enterprise both have this off by default, but Enterprise is the only tier where an administrator can enforce this policy across the entire organisation, not just rely on each user doing the right thing individually.

Admin controls. This is where Enterprise separates itself from Team most clearly. With Enterprise, your IT team can manage user access via Single Sign-On (SSO) and SCIM (System for Cross-domain Identity Management, a standard protocol for automating user provisioning and deprovisioning). That means when an employee leaves, their access is revoked automatically through your existing identity management system. On Team, you are managing users manually inside ChatGPT's own console.

Data retention. Enterprise gives administrators the ability to set custom retention windows and, in some configurations, to disable conversation history entirely at the workspace level. Free and Team tiers retain data on OpenAI's infrastructure for defined periods primarily for abuse monitoring, but you have no meaningful control over that window.

The control gap that catches organisations out

Buying the Enterprise tier is not the same as configuring it correctly. The privacy protections on offer are largely opt-in settings, not defaults. An Enterprise deployment with no admin policy applied behaves closer to Team than the documentation implies.

For Australian organisations under the Privacy Act, the difference between Team and Enterprise is meaningful precisely because of that admin layer. The ability to enforce data handling policies organisation-wide, tie access to your identity provider, and produce a signed Data Processing Agreement (DPA) all sit at the Enterprise tier. If you are processing personal information about customers or employees through ChatGPT and you are on the free or Team tier, you are likely operating without the contractual and technical controls the Act requires of you. The risks that flow from that gap are not hypothetical.

What does OpenAI's data processing agreement cover?

A data processing agreement (DPA) is a contract between your organisation and a vendor that sets out how the vendor may handle personal information on your behalf. Under Australian privacy law and most equivalent frameworks, you need one whenever a third party processes personal data you are responsible for. OpenAI offers a DPA as part of the ChatGPT Enterprise subscription, and understanding what it actually says matters more than simply having a signed copy on file.

OpenAI's DPA for Enterprise customers covers several things your legal and security teams will want to confirm are present. It specifies that OpenAI acts as a data processor (not a controller) for the content you send through the API or the Enterprise interface, meaning OpenAI's use of that content is limited to delivering the service. It commits OpenAI to maintaining appropriate technical and organisational security measures. It provides a list of sub-processors, the third-party infrastructure providers OpenAI relies on to run the service, and it obligates OpenAI to notify you if that list changes.

Cross-border data transfers

This is where Australian organisations need to read carefully. OpenAI processes data on infrastructure based primarily in the United States. Under the Australian Privacy Act 1988, Australian Privacy Principle 8 (APP 8) places obligations on organisations that disclose personal information to overseas recipients. Your organisation remains accountable for what happens to that data once it crosses the border, unless you have taken reasonable steps to ensure the recipient handles it consistently with the APPs.

OpenAI's DPA references compliance with applicable data protection law, but it does not, by default, provide a mechanism specifically tailored to Australian cross-border transfer obligations. That means you need to assess whether the contractual protections in the DPA are sufficient to satisfy your APP 8 obligations, or whether additional contractual clauses or an internal risk acceptance decision by your privacy officer is required. This is not a blocker to using ChatGPT Enterprise, but it is a step that should be documented.

Sub-processor visibility

OpenAI uses sub-processors including major cloud infrastructure providers. The DPA requires OpenAI to maintain and publish a list of these sub-processors, and to give Enterprise customers advance notice before adding new ones. In practice, you should review that list during procurement and set a calendar reminder to check it on a quarterly basis. A new sub-processor could shift where certain data is processed or stored, which has implications for your own data maps and privacy impact assessments.

The DPA is a starting point, not a finish line

Signing OpenAI's standard DPA satisfies the basic contractual requirement, but it does not automatically resolve your APP 8 cross-border transfer obligations or replace your own internal data classification decisions. Treat the DPA as one input into a broader privacy impact assessment, not as a compliance checkbox.

One practical gap worth flagging: the standard Enterprise DPA does not always specify data residency in Australia or the Asia-Pacific region. If data residency is a hard requirement for your organisation, either because of regulatory obligations or internal policy, confirm this explicitly with OpenAI before deployment. Some enterprise customers have negotiated additional terms; others have determined the default arrangement is acceptable given their use cases and the sensitivity of data involved. Neither answer is wrong, but both require a deliberate decision.

Which Australian privacy obligations apply when you deploy ChatGPT Enterprise?

Deploying ChatGPT Enterprise means transferring data to OpenAI's infrastructure in the United States, and that triggers specific obligations under Australian law that many IT teams underestimate.

The primary framework is the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs) that sit beneath it. For most organisations with an annual turnover above $3 million, or those handling health records or certain government-related data, the APPs apply in full. The one that bites hardest in an AI deployment is APP 8.

What APP 8 actually requires

APP 8 governs cross-border disclosure of personal information. Before you disclose personal information to an overseas recipient, you must take reasonable steps to ensure that recipient will handle it in a manner consistent with the APPs. That obligation does not disappear because OpenAI has signed a data processing agreement. The DPA is evidence that you have taken reasonable steps, but it is not a complete shield. If OpenAI were to mishandle data in a way that breached the APPs, your organisation could still be held accountable by the Office of the Australian Information Commissioner (OAIC).

In practice, this means you need to document your assessment of OpenAI's privacy posture before deployment, not after a complaint lands.

How recent Privacy Act reforms raise the stakes

The Australian government has been progressively strengthening the Privacy Act, and the trajectory matters here. Proposed reforms include higher penalties, a statutory tort for serious invasions of privacy, and a shift toward accountability-based compliance. The direction of travel is clear: regulators expect organisations to be able to demonstrate, on request, why they believed a cross-border transfer was safe.

Our article on the Privacy Act and AI: what changed and what training must cover covers the reform timeline in detail. It is worth reading alongside this one if your organisation handles sensitive data at scale.

Sector-specific layers

Some industries carry obligations that sit on top of the APPs. Healthcare organisations must comply with the My Health Records Act 2012 and the Australian Privacy Principles as modified for health information. Financial services firms are subject to APRA's prudential standards on data risk, including CPS 234 (information security) and, for larger entities, the oversight expectations in CPS 230 (operational risk). Legal and professional services firms may also have confidentiality obligations under professional conduct rules that the Privacy Act does not capture.

The practical question for a CISO is whether any data flowing through ChatGPT Enterprise falls into a regulated category. If it does, the DPA alone is not enough; you need a fuller legal assessment.

For organisations in the public sector, the data sovereignty dimension is sharper still. Federal and state agencies handling data classified above OFFICIAL may face restrictions that make a US-based AI platform unsuitable regardless of the contractual protections in place. We cover this in more depth in Data Sovereignty and AI for Australian Government.

The accountability gap is real

Signing OpenAI's DPA satisfies part of APP 8, but it does not transfer liability to OpenAI. Your organisation remains accountable under Australian law for any cross-border disclosure of personal information, and regulators will ask what steps you took to assess the risk before deployment.

The short version: deploying ChatGPT Enterprise without a documented privacy impact assessment is a compliance gap, not just a theoretical risk. The OAIC has been increasingly active, and the reforms already in train give it more tools, not fewer, to pursue organisations that cannot show their work.

What are the residual risks CISOs should not overlook?

Enterprise tier removes OpenAI's right to train on your data and adds encryption and access controls. What it cannot do is prevent your own employees from putting the wrong information into a prompt.

That is the most common residual risk, and it is structural. ChatGPT Enterprise does not inspect or classify what users type. An analyst who pastes a client contract into a prompt to summarise it, a recruiter who includes salary bands and employee names, a lawyer who drops a settlement clause into a chat window: none of that is blocked at the tier level. The data leaves your network, sits in OpenAI's infrastructure for processing, and any retention or logging you have configured applies only after the fact.

Prompt content is the first line of risk, not the last

Your data loss prevention (DLP) controls almost certainly do not cover outbound text typed manually into a browser. Traditional DLP tools watch for file transfers, email attachments, and clipboard events on managed endpoints. A user composing a prompt by hand, or even copying a passage of text, may pass entirely undetected. CISOs deploying ChatGPT Enterprise should review whether endpoint controls or browser proxy inspection can capture outbound ChatGPT traffic, and whether a separate acceptable use policy for generative AI is enforceable and understood.

Connectors and plugins extend the attack surface

ChatGPT Enterprise supports integrations with external tools. When a connector is authorised, data can flow between ChatGPT and a third-party system under that third party's own privacy terms, not OpenAI's. Each integration needs its own assessment. The DPA you signed with OpenAI does not cascade to the CRM, ticketing system, or document store that a plugin pulls from.

Shadow IT on free and Plus tiers

Deploying Enterprise for licensed users does not automatically stop unlicensed staff from using the free or Plus versions of ChatGPT on the same devices or the same network. Free-tier users have no data processing agreement, no opt-out from training, and often weaker audit trails. Without a clear policy prohibiting personal AI tool use for work content, and without the technical controls to back that policy up, your Enterprise deployment may offer protections that only cover a fraction of actual usage.

Enterprise protects what happens inside the Enterprise boundary

Every conversation that occurs outside that boundary, whether on a free account, a personal device, or an unsanctioned tool, carries the full exposure of consumer-grade terms. The boundary is only as secure as your access governance and training culture make it.

Model output confidentiality

Outputs generated by ChatGPT are only as confidential as the environment they sit in. A response containing sensitive information can be copied, shared, or forwarded like any other text. ChatGPT Enterprise does not apply sensitivity labels or rights management to its outputs, and there is currently no native integration with Microsoft Purview or equivalent classification tools that would follow the content downstream. If your organisation classifies information at the point of creation, that classification chain breaks the moment content is generated inside ChatGPT and pasted elsewhere.

The audit log gap

Enterprise does provide admin access to usage data, but logging depth varies. You can see who used the platform and when, but the content of individual conversations may not be captured depending on your configuration. In a regulated environment where you need to demonstrate what was discussed, what data was submitted, and what outputs were produced, that gap matters. Before deployment, confirm what your logging configuration actually captures and whether it meets your obligations under the Privacy Act or any applicable sector regulation.

These risks are manageable. They require policy, training, and technical controls working together. The Enterprise tier is a sound foundation; it is not a substitute for the governance layer that sits above it.

How should your team be trained to use ChatGPT Enterprise safely?

Technical controls set the floor, not the ceiling. OpenAI's data processing agreement, your SSO configuration, and your domain-level admin console all do their jobs. But the moment a staff member pastes a customer contract into a prompt to ask for a summary, the protection those controls offer depends entirely on what that person understands about data classification.

Most data incidents in AI deployments are not the result of a misconfigured API. They come from a well-intentioned employee who did not know that a particular document was classified, or did not think about whether the output they were generating would end up somewhere it should not.

Prompt hygiene is a governance requirement, not a soft skill

The phrase "prompt hygiene" gets used loosely. In a governed enterprise context, it means something specific: knowing which categories of information should never appear in a prompt, how to restructure a task so sensitive details are removed or anonymised before they reach the model, and what to do when an output contains information that should not be shared or stored.

That is not intuitive behaviour. It needs to be taught explicitly, with examples drawn from the workflows your teams actually use.

The policy gap most teams miss

An acceptable use policy tells employees what not to do. Training shows them how to do the same work safely. Without the second piece, the policy creates liability without changing behaviour.

A finance team member who understands that account numbers and client identifiers should be replaced with placeholders before prompting will make better decisions than one who has signed a policy document they have not thought about since onboarding. The same applies in legal, HR, and any team handling personal information covered by the Privacy Act.

What good ChatGPT Enterprise training covers

Training for a governed deployment goes beyond "here is how to write a better prompt." The content that actually reduces risk includes:

• Data classification in context. Which information in your organisation is sensitive, and what does that mean for AI use? Not everyone knows where the line sits.

• Prompt construction with sensitive data. How to complete real tasks without exposing regulated or confidential information. This is most effective when it uses your team's actual workflows rather than generic examples.

• Output handling. What happens after the model responds? Where does that output go, who can see it, and what review is required before it is acted on or shared?

• Knowing when not to use AI. Some tasks are not appropriate for any AI tool, regardless of contractual protections. Training should name those categories clearly.

• Incident recognition. If something goes wrong, what does it look like and who do you tell?

The residual risks covered in the previous section, including output confidentiality, third-party data, and agentic tool use, all become significantly more manageable when the people using the platform understand them.

If you are rolling out ChatGPT Enterprise across a team or a whole business unit, our ChatGPT training for business program is built around exactly this kind of operational, governance-aware delivery. The focus is on real tasks, real data classification decisions, and building the prompt habits that hold up under audit, not just a demo of what the tool can do.

Is your team using ChatGPT Enterprise with the right guardrails?

We cover data classification, prompt hygiene, and output handling using your team's actual workflows. The session is practical, governance-focused, and can be delivered onsite or remotely across Australia.

See the ChatGPT training program →

Frequently asked questions

Does OpenAI train its models on prompts submitted through ChatGPT Enterprise?

No. OpenAI explicitly commits that customer data submitted through ChatGPT Enterprise is not used to train its models. This is one of the fundamental distinctions between the Enterprise tier and the free consumer product, where data may be used for training unless users opt out. The commitment is documented in OpenAI's terms of service for Enterprise customers and reinforced in the data processing agreement.

Where is ChatGPT Enterprise data stored, and is any of it stored in Australia?

As of mid-2025, OpenAI processes and stores ChatGPT Enterprise data in the United States. There is no Australian data residency option. Data in transit is encrypted, and data at rest is encrypted using AES-256, but the physical infrastructure sits outside Australian borders. For organisations subject to Australian Privacy Principle 8, which governs cross-border data disclosure, this means you need to assess whether sending personal information to a US-based processor is adequately covered by your DPA and whether you have obtained appropriate consent or applied the right contractual safeguards. If data residency within Australia is a hard requirement, ChatGPT Enterprise cannot currently meet it.

Is ChatGPT Enterprise suitable for sensitive or regulated data?

It depends on the sensitivity level and the regulatory regime. ChatGPT Enterprise is a reasonable choice for business-sensitive information that does not carry specific regulatory restrictions, provided your DPA is in place and staff are trained on what not to paste in. It is not appropriate, without significant additional controls, for data classified as Protected or higher under the Australian Government's Information Security Manual, for patient health information covered by the My Health Records Act, or for matter-specific legal information where professional secrecy obligations apply. The encryption and contractual protections are real, but they do not substitute for data classification and access controls you apply before a prompt is written.

How does ChatGPT Enterprise compare to Microsoft 365 Copilot on data privacy?

The two products have meaningfully different architectures. Microsoft 365 Copilot runs inside your existing Microsoft 365 tenant, which means your data stays within the Microsoft environment you already govern. It inherits your existing DLP policies, conditional access rules, and sensitivity labels. ChatGPT Enterprise operates as a separate SaaS service with its own data boundary, requiring a standalone DPA and deliberate governance decisions about what employees are permitted to share. Neither product is automatically safer than the other: Copilot's tighter integration is an advantage for governance, but it also means that poorly configured permissions within your Microsoft environment can expose more data than intended. For a fuller comparison, see Claude vs ChatGPT vs Gemini for Enterprise.

What should our DPA with OpenAI actually cover?

A ChatGPT Enterprise data processing agreement should, at minimum, confirm that OpenAI acts as a data processor under your instructions rather than as an independent data controller, that prompts and outputs are not used for model training, that sub-processors are disclosed and bound by equivalent obligations, that breach notification timelines meet your obligations under the Notifiable Data Breaches scheme (72 hours to the OAIC for eligible breaches), and that data deletion procedures apply at contract end. Review the agreement against the requirements of the Australian Privacy Act rather than treating OpenAI's standard terms as automatically sufficient. If your organisation handles health, financial, or government data, have legal counsel review the DPA before deployment, not after.

Assess your deployment before it becomes a board issue

ChatGPT Enterprise gives your organisation a defensible privacy foundation. What it does not give you is automatic compliance, safe user behaviour, or a workforce that understands where the boundaries sit. Those come from deliberate configuration, governance work, and training.

The gap between "we have the enterprise licence" and "we are using it responsibly" is where most Australian organisations currently sit. Closing it does not require months of policy work. It requires a clear-eyed review of how your instance is configured, what your staff actually do with it, and whether your acceptable use policies reflect the real risks rather than a generic template copied from a vendor's documentation.

If your team is already using ChatGPT Enterprise but has not had structured guidance on what to put in, what to keep out, and how to recognise when a task crosses a compliance line, that is a training problem with a compliance consequence.

Ready to train your team to use ChatGPT Enterprise safely?

Our ChatGPT for business sessions are built around your actual workflows and Australian privacy obligations. We cover safe prompting practice, data handling boundaries, and the governance questions your team will face in day-to-day use.

Explore ChatGPT training for business →

The organisations that avoid board-level AI incidents are not necessarily the ones with the most sophisticated technology stack. They are the ones where staff understand what the tool can see, what it retains, and what the consequences of a misstep look like. That understanding does not come from a terms-of-service summary in an onboarding email. It comes from training that is specific, practical, and tied to the work people actually do.