> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention.md).

# 4.4 Retention and Zero Data Retention

Where conversations, prompts, files, logs, and tool data live, for how long, and what Zero Data Retention does and does not cover.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
Retention settings decide what the provider keeps. They do not automatically cover every feature, log, connector, local file, or downstream system.
{% endhint %}

## What security teams need to know about retention and Zero Data Retention

Retention is a contract and architecture topic. A provider may handle API prompts differently from chat messages, files, compliance exports, abuse monitoring, or feature-specific data.

Zero Data Retention can be valuable for sensitive workflows, but it has scope limits. Treat ZDR as one control in a broader data-flow review.

## Common retention and Zero Data Retention security failures

* ZDR is assumed to cover features that are excluded.
* Local conversation stores and downloaded files are ignored.
* Telemetry keeps prompts or tool parameters longer than expected.
* Compliance exports are retained without a lifecycle owner.
* Users rely on consumer settings for enterprise data.

## Retention and Zero Data Retention security controls checklist

* Record retention behavior by product surface, feature, endpoint, authentication path, and storage location.
* Inventory prompts, responses, files, tool payloads, memory, retrieval indexes, embeddings, fine-tuning and evaluation data, caches, logs, compliance exports, backups, and abuse-monitoring copies.
* Confirm Zero Data Retention scope and exclusions before regulated use.
* Map every derived store back to its source data class and owner.
* Define region, encryption, key ownership, access, retention, deletion, legal hold, and privacy-request handling for each store.
* Synchronize source-system permissions and deletions with knowledge bases and vector stores.
* Test deletion propagation, including provider systems, downstream SaaS, indexes, caches, backups, exports, and generated artifacts.
* Define retention for local artifacts and investigation evidence.
* Review lifecycle controls after new features, connectors, models, or execution paths are enabled.

## AI data stores and derived copies

AI systems create copies that are easy to miss in a SaaS retention review:

| Store                               | Security questions                                                                                                                                                  |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Retrieval and knowledge sources     | Does retrieval enforce the source user's current permissions? How quickly do permission changes and deletions propagate?                                            |
| Embeddings and vector stores        | Can records be tied back to their source, tenant, classification, region, and deletion request? Are metadata filters authorization controls or only search filters? |
| Fine-tuning and evaluation datasets | Who can add, label, export, reuse, and delete examples? Are production records allowed?                                                                             |
| Memory and session state            | Is state personal, shared, channel-based, project-based, or agent-owned? Can poisoned or obsolete state be removed selectively?                                     |
| Caches and temporary files          | What is cached, for how long, in which region, and under which key? Does Zero Data Retention exclude any cache or feature?                                          |
| Logs, traces, and exports           | Are prompts, tool arguments, file paths, identifiers, and outputs copied into systems with broader access or longer retention?                                      |
| Backups and legal holds             | When does deletion become effective, and what exceptions prevent or delay removal?                                                                                  |
| Generated artifacts                 | Can files, links, sites, messages, code, or downstream records outlive the source conversation?                                                                     |

Do not accept “deleted” as a single control state. Record the deletion request, affected stores, completion time, exceptions, and verification evidence. Where a provider cannot verify deletion at the required granularity, restrict the data class or use an architecture with customer-controlled storage.

Encryption scope also needs precision. Distinguish provider-managed encryption, customer-managed keys, connector-side encryption, local device encryption, and encryption applied through sensitivity labels. A customer-managed key for one service does not automatically cover every AI feature or downstream copy.

## Anthropic

### Overview

The headline fact for regulated workloads: Managed Agents sessions persist state server-side and are not currently eligible for zero data retention or HIPAA BAA coverage, so a ZDR commitment on the API does not extend to a Managed Agents deployment. Check eligibility at design time, not after the pilot.

For the API itself, Anthropic documents data retention controls, including zero data retention options. Claude Code documents local and cloud execution separately. Cowork remote sessions save sessions and files to the user's Claude account and process any local files they open on Anthropic's servers. The Claude for Excel, PowerPoint, Word, and Outlook add-ins have a sharper exception: inputs and outputs are deleted within 30 days, but the add-ins do not inherit custom organization retention settings and are not in Enterprise audit logs, the Compliance API, or data exports.

Claude chat has its own Enterprise custom-retention controls. Claude Tag has a different rule: it retains channel memory and session transcripts and is unavailable to organizations with Zero Data Retention enabled. Slack conversations follow the Slack workspace's retention policy, while Anthropic says its copy is deleted within 30 days after the integration is disconnected or uninstalled. Put both systems on the retention map.

### Anthropic documentation

* [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention)
* [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview)
* [Claude Code data usage](https://code.claude.com/docs/en/data-usage)
* [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview)
* [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps)
* [Configure custom data retention controls for Enterprise plans](https://support.claude.com/en/articles/10440198-configure-custom-data-retention-controls-for-enterprise-plans)
* [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag)
* [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data)

### Applicable Harmonic guides for Anthropic

* [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide)

## OpenAI

### Overview

For ChatGPT Enterprise, Edu, and Healthcare workspaces, chats and files saved to Library are retained according to the workspace's configured retention policy, which workspace admins control. Deleted chats are scheduled for permanent deletion from OpenAI systems within 30 days unless de-identified or retained for security or legal obligations. Two details catch teams out: for Enterprise users, files not saved to Library expire after 48 hours, and data deleted via the Compliance API is retained internally for no more than 30 days after the deletion request — with canvas events not yet supported by that API.

On the API Platform, data-control behavior varies by endpoint and feature. For ChatGPT Work, data stored by ChatGPT follows the workspace retention policy, while connected applications retain and delete their own data under separate policies. Work can create conversation content, files, artifacts, and execution metadata; Codex can add repository metadata, command output, diffs, and logs. Verify the current product and Compliance API schemas before claiming that a workspace deletion covers every artifact or tool-side copy.

### OpenAI documentation

* [Chat and File Retention Policies in ChatGPT](https://help.openai.com/en/articles/8983778-chat-and-file-retention-policies-in-chatgpt)
* [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers)
* [Enterprise privacy at OpenAI](https://openai.com/enterprise-privacy/)
* [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data)
* [Codex Governance](https://developers.openai.com/codex/enterprise/governance)
* [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq)

### Applicable Harmonic guides for OpenAI

* [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide)

## Frequently asked questions about retention and Zero Data Retention

### What is Zero Data Retention?

Zero Data Retention is a provider mode or contract term under which eligible prompt and response data is not retained on the provider's systems after the request completes. It is typically an API-side control granted per agreement rather than a settings checkbox, and eligibility varies by endpoint and feature. Both Anthropic and OpenAI document ZDR options for their API platforms.

### Does ZDR cover every AI feature?

No. Scope is defined per endpoint and feature, and some services sit explicitly outside it — Claude Managed Agents sessions, for example, persist state server-side and are not currently ZDR-eligible. Read the current vendor documentation and your amendment together before assuming coverage for a new feature.

### What data should be checked for retention?

Check prompts, responses, files, images, tool calls and parameters, logs, telemetry, compliance exports, and local stores such as CLI history and downloaded files. Feature-level differences matter: in ChatGPT Enterprise, a file saved to Library follows workspace policy while one that is not expires after 48 hours. Remember that provider-side settings never govern the local copies.

### Is training opt-out the same as retention?

No. Training controls govern whether the provider may use your content to improve models; retention controls govern how long the provider stores it. Data can be retained without being trained on — abuse-monitoring copies are a common example — and a ZDR amendment does not substitute for a training opt-out or the reverse. Review both, per surface, as described in 4.5.

### Who owns retention evidence?

Compliance usually owns the evidence requirement and the retention schedule; security and platform teams own the technical data-flow map that proves the schedule is real. Give compliance exports themselves a lifecycle owner — they are copies of the most sensitive conversations and will outlive the source data if nobody deletes them.

## Applicable regulations and frameworks

| Governance page                                     | Relationship to this article                                                                                                                       |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| G.1 Map your controls to NIST AI RMF and CSF 2.0    | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.                                              |
| G.2 EU AI Act obligations for deployers             | Conditional: for an in-scope high-risk system, this supports retention of deployer-controlled automatic logs.                                      |
| G.3 DORA and AI resilience in financial services    | Conditional: for a DORA-regulated workflow, this supports data protection, integrity, and third-party service review.                              |
| G.4 Colorado AI Act and the US state patchwork      | Conditional: for covered Colorado ADMT, this supports retention of required system, notice, and decision records.                                  |
| G.5 SANS Critical AI Security Guidelines mapping    | This article implements relevant SANS Data Protection guidance.                                                                                    |
| G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy.                                                    |
| G.7 Ownership and RACI for AI security              | This control depends on the ownership and evidence responsibilities defined in the RACI.                                                           |
| G.9 HIPAA controls for AI systems handling PHI      | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. |

*G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.*

## Related handbook guidance

* [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency.md)
* [4.3 Data residency and regional inference](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference.md)
* [4.5 Training opt-out and data usage](/handbook/4.-data-protection-and-residency/4.5-training-opt-out-and-data-usage.md)
* [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform.md)
* [G.2 EU AI Act obligations for deployers](/reference/governance-and-frameworks/g.2-eu-ai-act-obligations-for-deployers.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
