Skip to main content
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

Data minimisation

Information is retained only where there is a defined business, contractual, or legal purpose for keeping it.

Storage limitation

Retention is bounded by the purpose. When the purpose ends, the clock starts.

Auditable disposal

Every disposal produces a verifiable record — asset, trigger, method, approver, completion time.

Default delete

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:
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 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.
1

Trigger: Ticket resolved

Fires on close in OpenCX and on close propagated from the connected ticketing system.
2

Optional: Wait

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.
3

Optional: Condition

Branch on tags, team, or channel so removal only applies where you want it — for example sessions tagged payments but not those tagged dispute.
4

Action: Redact the session

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.
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.

Submit a deletion or data-subject request

Email [email protected]. Include the org, the scope of data, and the legal basis if the request is made on behalf of a data subject.
A legal hold suspends normal retention and disposal for specified data until the hold is released.
1

Initiated by an authorised party

Only the CEO, the CTO/CISO, or General Counsel may place a hold.
2

Documented in writing

Scope and justification are recorded before the hold takes effect.
3

Reviewed at least every six months

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

​
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:

PII redaction window

Sensitive values are redacted from conversations after session closure — 30 days by default, configurable for your org.

Connect thread lifecycle

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 [email protected].