;
};
Retention is a security control, not a storage setting. Data that no longer serves a purpose is
liability without upside — so OpenCX holds every category of information for a defined period,
disposes of it by a defined method, and produces a record proving it happened.
This page is the customer-facing summary of the Open Data Management & Retention Policy
(DMR-001), owned by the CTO/CISO and reviewed annually. It aligns with ISO/IEC 27001:2022
controls A.5.33, A.8.10 and A.8.12, SOC 2 criteria C1.1–C1.2 and P4.1–P4.3, and the
storage-limitation principle in GDPR Article 5(1)(e).
Where your contract with OpenCX defines a retention period, **your contract governs**. The
schedule below is the default applied in the absence of a contractual term, and it is a ceiling —
asset owners may retain less, never more, without written CTO/CISO approval.
## Principles
Information is retained only where there is a defined business, contractual, or legal purpose
for keeping it.
Retention is bounded by the purpose. When the purpose ends, the clock starts.
Every disposal produces a verifiable record — asset, trigger, method, approver, completion time.
Where no explicit rule applies, data is treated as Internal and reviewed for deletion after
12 months of inactivity.
## Retention schedule
The same schedule in full, including the event that starts the retention clock and the method used
to dispose of the data:
| Category | Classification | Retention | Retention trigger | Disposal method |
| ----------------------------------- | -------------- | ------------------------------------------------ | ---------------------------------------- | --------------------------------------- |
| Conversation data | Confidential | Per contract — default active lifetime + 90 days | Contract termination or customer request | Cryptographic erasure |
| Attachments & exports | Confidential | Per contract — default 90 days | Contract termination | Cryptographic erasure |
| Knowledge base content | Confidential | Service lifetime | Contract termination or source removal | Cryptographic erasure |
| Vector embeddings (derivatives) | Confidential | 30 days after source deletion | Source deletion event | Cryptographic erasure |
| Database backups (PITR + snapshots) | Confidential | 30 days rolling | Age | Automated overwrite + key rotation |
| Authentication & authorisation logs | Internal | 12 months | Age | Automated deletion from immutable store |
| System & application logs | Internal | 12 months | Age | Automated deletion |
| Compliance & audit evidence | Confidential | 7 years | Regulatory / audit cycle | Secure deletion after retention |
| Billing & financial records | Confidential | 7 years | Tax / legal obligations | Secure deletion after retention |
| Marketing & prospect data | Internal | 24 months, or on request | Inactivity or data-subject request | Secure deletion |
| Encryption keys (decommissioned) | Restricted | 30-day waiting period, then destroyed | Key revocation | Scheduled destruction, dual approval |
**Derivatives are on the clock too.** Vector embeddings built from your content are treated as
Confidential and deleted within 30 days of the source being deleted — they do not outlive the data
they were derived from.
## Lifecycle
Retention is enforced in code, not by reminder. Each asset carries a classification and a rule from
the moment it is created, and disposal runs automatically when the trigger fires.
## Trigger-based removal
Not every retention clock should be a calendar. Often the right moment to strip a session is the
moment it stops being operationally useful — the ticket closed, the case was resolved in your
ticketing system, the thread went cold. **Workflows** let you bind removal to that event instead of
waiting out a fixed window.
The pattern is the same in every case: a trigger fires, a workflow runs, and the workflow calls
[`POST /redaction/session`](/api-reference/redaction/redact-session) to strip the session's messages
and attachments.
When an agent closes the ticket in Zendesk, Salesforce, HubSpot, or any connected ticketing
system, the webhook closes the matching OpenCX session and fires the **`ticket-resolved`**
trigger. Hang a workflow off it to remove the transcript as soon as the system of record says
the work is done.
Fires on close in OpenCX **and** on close propagated from the connected ticketing system.
Add a **Wait** step for a cooling-off period — long enough to handle a reopen, short enough
to beat the default window. A common choice is 7 days.
Branch on tags, team, or channel so removal only applies where you want it — for example
sessions tagged `payments` but not those tagged `dispute`.
An **HTTP call** step to `POST /redaction/session` with the session id from the trigger
context. The API key needs the `redaction:write` scope.
Redaction is irreversible. Put the reopen window before the removal step, not after — a
session stripped the instant a ticket closes has no transcript left if the customer replies an
hour later and the ticket reopens.
The **`ticket-inactive`** trigger fires when a session has had no activity for a configured
period. Use it to catch sessions that were never formally closed — abandoned chats, one-message
threads, bot-only conversations — which otherwise sit at full fidelity until the org-wide window
expires.
Pair it with a condition on message count or channel so you only sweep the genuinely
low-value ones.
The **`ticket-tag-added`** trigger turns removal into a one-click action for your agents. Add a
tag such as `erasure-request` to a session and the workflow strips it immediately — useful when
a customer asks for erasure mid-conversation and you want the agent to action it without filing
a ticket with your security team.
Gate this one carefully: anyone who can tag a session can trigger deletion. Restrict the tag to
a role that should hold that power.
A **`cron-trigger`** workflow runs on your schedule — nightly, weekly — and applies a rule the
fixed retention window cannot express. For example: strip sessions from a specific channel after
14 days while leaving everything else on the standard schedule, or remove test and internal
sessions on a much shorter cycle than customer conversations.
This is the right tool when the rule depends on data the retention schedule does not know about.
Trigger-based removal runs **in addition to** the org-wide automatic redaction window, which
strips PII from closed sessions after a configurable period (30 days by default). Workflows let
you act **earlier** or **more selectively** — they don't replace the baseline, and no workflow can
extend retention beyond the schedule above.
## Disposal methods
The primary method for data held in cloud-managed services. The encryption keys protecting the
data are scheduled for destruction with a 7–30 day waiting window and dual approval. Once the
keys are destroyed, the ciphertext is permanently unreadable — including any copy that exists in
a backup taken before the deletion.
Applied to customer data on contract termination, to decommissioned backups, and to derivative
datasets such as vector embeddings.
For information that cannot be cryptographically erased — for example shared corporate records
in collaboration tools — deletion follows NIST SP 800-88 Rev. 1. Records are removed from the
primary store, purged from backups at the next backup cycle, and removed from downstream
replicas under a documented ticket.
OpenCX operates no customer-facing physical media. Corporate endpoints are full-disk encrypted;
on retirement the disk is cryptographically erased through device management and the hardware is
wiped or physically destroyed by a contracted provider under certificate of destruction.
Every disposal action produces an auditable record: the asset identifier, the trigger event, the
method, the approving party, and the completion time. Disposal is verified by the asset owner at
the next quarterly access review and sampled by the security function during internal audit.
## Deletion requests
A deletion request is not a single `DELETE`. A copy of a record can exist in the primary store, in
backups, in derived datasets, and at a sub-processor — so the request fans out to every one of them
and is confirmed only when the last leg completes.
**Where OpenCX is a Processor** — your customer data — deletion requests are executed within the
contractual timeframe, 30 days by default, coordinated across the primary store, backups, derivative
datasets, and relevant sub-processors.
**Where OpenCX is a Controller** — employee and prospect data — data-subject requests are logged,
authenticated, actioned, and confirmed in writing to the requester under applicable data-protection
law.
Email [security@open.cx](mailto:security@open.cx). Include the org, the scope of data, and the
legal basis if the request is made on behalf of a data subject.
## Legal holds & exceptions
A legal hold suspends normal retention and disposal for specified data until the hold is released.
Only the CEO, the CTO/CISO, or General Counsel may place a hold.
Scope and justification are recorded before the hold takes effect.
Holds are re-justified or released — they do not become permanent by neglect.
Exceptions to the schedule — for example extended retention for a specific category — require
written CTO/CISO approval, are recorded in the GRC platform, and are subject to periodic review.
## Sub-processors
Sub-processors are contractually required to meet retention periods and disposal rules **at least as
strict** as those above. Compliance is verified annually under the Vendor Management Policy, and on
any change of scope.
## Governance
| Role | Responsibility |
| ----------------------- | ---------------------------------------------------------------------------------------- |
| CTO / CISO | Owns the policy, approves exceptions, authorises legal holds, escalates breaches |
| Data Protection Officer | Data-protection compliance, data-subject rights, sub-processor agreements |
| Engineering | Implements retention rules in code, enforces automated disposal, maintains audit records |
| Asset owners | Identify applicable periods for their assets and sign off on disposal |
| People Operations | Employee and contractor records, in line with employment law |
| All personnel | Apply classification and never retain data beyond its defined period |
## Retention you control
Several retention windows are configurable per organisation, so you can hold data for less time than
the default without a contract change:
Sensitive values are redacted from conversations after session closure — 30 days by default,
configurable for your org.
Grace and retention windows for Connect threads are set per org, and per thread at creation.
Enterprise customers can request the full signed policy (DMR-001), the sub-processor register, and
disposal evidence samples as part of a security review. Contact
[security@open.cx](mailto:security@open.cx).