Data retention policy - Open.cx Docs

Retention is a security control, not a storage setting. Data that no longer serves a purpose is liability without upside — so OpenCX defines a rule for every category of information, a trigger that starts disposal, a method that carries it out, and a record proving it happened. This page is the customer-facing summary of the Open Data Management & Retention Policy, 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).

Your data stays with you for as long as you are a customer. OpenCX runs no scheduled job that deletes or redacts customer data after a fixed age — removal happens when you ask for it, when a workflow you built fires, or when your account is terminated. Where your contract with OpenCX defines a retention or deletion term, your contract governs.

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 deletion produces a verifiable record — what was requested, what was executed, against which stores, by whom, and when.

Reviewed, not forgotten

Data storage systems are reviewed quarterly and the full data inventory annually. Nothing is held without someone owning the reason.

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
Session data (messages, transcripts, metadata)	Confidential	Retained while your account is in good standing. At least 30 days after termination, so you can bring the account back. Deleted within 30 days of a deletion request.	Account termination or deletion request	Scoped hard deletion in the production database — cascading where the schema defines a cascade, explicit cleanup where it does not
Attachments & exports	Confidential	Same as session data	Account termination or deletion request	Metadata removed, then a permanent object-removal request to our storage service; failures logged and followed up
Knowledge base content	Confidential	Same as session data	Account termination, deletion request, or source removal	Scoped hard deletion in the production database
Search & reporting derivatives	Confidential	Deleted with the records they were built from	Deletion of the source record	Tombstoned, excluded from reads immediately, physically removed as the store merges
Recovery backups	Confidential	Bounded recovery window	Expiry of that window	Backups age out on their own schedule; individual records are never selectively removed from an existing backup
System & application logs	Internal	Held only as long as they serve operations and security	Age	Expiry from the logging store
Audit logs & security records	Confidential	At least 5 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	Until the contact opts out, asks for erasure, or the relationship lapses	Opt-out, inactivity, or data-subject request	Secure deletion

Derivatives never outlive their source. The search and reporting copies built from your content are Confidential too. Deleting a record tombstones its derivatives in the same operation — they drop out of every read immediately, and the bytes go when the store next merges.

Lifecycle

Every asset carries a classification and a retention rule from the moment it is created. Disposal is a controlled operation, not a background timer: a trigger fires — an account termination, a deletion request, a workflow you built — an engineer executes the removal against every store that holds a copy, and each leg is verified before the request is closed.

Trigger-based removal

Retention does not have to wait on a calendar. Often the right moment to strip a session is the moment it stops being operationally useful — the session closed, the case was resolved in your ticketing system, the thread went cold. Workflows let you bind removal to that event. 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.

Ticket closed in your ticketing system
Session went inactive
Tag-driven removal
Scheduled sweep

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.

Trigger: Ticket resolved

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

Optional: Wait

Add a Wait step for a cooling-off period — long enough to absorb a reopen, short enough that the transcript is not sitting around. A common choice is 7 days.

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.

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.

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 sessions — which otherwise sit at full fidelity for as long as you hold them.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-session and you want the agent to action it without escalating to 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 no static schedule could express. For example: strip sessions from a specific channel after 14 days, or remove test and internal sessions on a much shorter cycle than customer sessions.Age-based removal is available to you here, and only here: you define the rule and own the schedule. OpenCX runs no age-based sweep over your data on your behalf.

There is no automatic redaction window. Nothing in OpenCX strips a session because it reached a certain age. Two real controls sit either side of that gap. PII redaction at ingest is an opt-in, per-organisation setting — off until you turn it on — that detects and strips sensitive values from chat, email, and live voice transcripts as messages arrive, in either redact at rest, where the original is never stored, or preserve original, where the original stays retrievable behind the redaction:write permission and every reveal is audit-logged. Redaction on demand is the POST /redaction/session and POST /redaction/message endpoints, called by hand or by the workflows above, for anything already stored.

Disposal methods

Scoped hard deletion

The primary method for your records in the production database. Deletion is scoped to exactly the rows in the request — cascading to dependents where the schema defines a cascade, with explicit cleanup where it does not. There is no soft-delete flag left behind; the rows are gone.Org-level deletion is coordinated by an engineer, executed against every table that holds a copy, and verified before the request is closed.

Permanent object removal

For files — attachments, exports, call recordings. The metadata record is deleted and a permanent object-removal request is issued to our storage service. Org-level deletion enumerates every attachment, export, and recording explicitly rather than trusting a prefix sweep, and any removal that fails is logged and followed up until the object is confirmed gone.

Tombstones in derived stores

The search and reporting stores do not support row-level deletes. A deletion writes a tombstone instead: the record is excluded from every read the moment the tombstone lands, and the bytes are physically removed as the store merges its data files.

Backups

Individual records are not selectively removed from an existing recovery backup — residual copies can persist until the recovery window expires and the backup ages out on its own. If a backup is ever restored, the deletion is reapplied before the system returns to service.

Physical media

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.

Evidence of disposal

Every deletion request produces a record: what was requested, what was executed, against which stores, by whom, and when. Data storage systems are reviewed quarterly, the full data inventory annually, and backups are tested annually for integrity.

Deletion requests

A deletion request is not a single DELETE. A copy of a record can exist in the production database, in object storage, in derived search and reporting stores, in backups, and at a sub-processor — so the request fans out to every one of them and is confirmed only when the last live leg completes. Where OpenCX is a Processor — your customer data — ask us and all data we have no legal or business obligation to retain is deleted within 30 days. The request runs against the production database, object storage, the derived search and reporting stores, and the relevant sub-processors, and each leg is verified before the request is closed. Backups are the stated exception: they are not selectively edited, they age out on their own schedule, and a restored backup has the deletion reapplied before it returns to service. 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.

Legal holds & exceptions

A legal hold suspends normal retention and disposal for specified data until the hold is released.

Initiated by an authorised party

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

Documented in writing

Scope and justification are recorded before the hold takes effect.

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

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	Executes and verifies deletion requests across every store, maintains disposal 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

You can hold less than the schedule allows, without a contract change. These controls are yours, set per organisation:

PII redaction

Opt in and sensitive values are stripped from chat, email, and live voice as messages arrive — per category, in redact-at-rest or preserve-original mode.

Workflow-driven removal

Bind removal to a session closing, going inactive, or picking up a tag — or to a schedule you define.

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 Data Management & Retention Policy, the sub-processor register, and disposal evidence samples as part of a security review. Contact [email protected].

​Principles

Data minimisation

Storage limitation

Auditable disposal

Reviewed, not forgotten

​Retention schedule

​Lifecycle

​Trigger-based removal

​Disposal methods

​Deletion requests

Submit a deletion or data-subject request

​Legal holds & exceptions

​Sub-processors

​Governance

​Retention you control

PII redaction

Workflow-driven removal

Connect thread lifecycle

Principles

Retention schedule

Lifecycle

Trigger-based removal

Disposal methods

Deletion requests

Legal holds & exceptions

Sub-processors

Governance

Retention you control