Customer support data retention is not one timer attached to a ticket. A support system can hold the conversation, attachments, requester profile, call recordings, internal notes, exports, analytics and backups on different schedules. A defensible policy names each copy, the reason it exists and the event that starts its clock.

The practical goal is simple: keep what the team still needs, preserve what law or a live dispute requires, and remove personal data that no longer has a purpose. A generic rule such as “keep support data for seven years” cannot do that work by itself.

Start with the purpose, not a number

The UK Information Commissioner’s Office says organizations must be able to justify how long they keep personal data. UK GDPR does not provide one universal period for every record type. The period follows the stated purpose, relevant legal requirements and the impact on the people in the data.

That matters in support because one ticket can serve several purposes:

  • resolve the customer’s current problem;
  • show what was promised during a complaint;
  • investigate abuse or account takeover;
  • train a support team;
  • measure service quality;
  • defend a legal claim;
  • satisfy an accounting or sector-specific record rule.

Do not combine these into one vague “business need.” Name the purpose and identify the smallest record needed for it. A billing dispute may require transaction references and the decision, but not an old screenshot containing a passport or card details.

Map every place a case can persist

Begin with one real case and follow it through the system. The map should include both obvious and secondary stores.

Store Typical contents Retention question
Ticket or conversation Messages, status, internal notes When is the case genuinely finished?
Attachments Screenshots, identity files, invoices Can sensitive files expire sooner than the conversation?
User profile Name, email, phone, organization Is the profile still needed after the relationship ends?
Voice and chat media Recordings, transcripts, bot context Does the same purpose and notice cover the media?
Search and analytics Indexed text, dimensions, reports Does deleting the source remove personal details from derived stores?
Exports and local copies CSV files, case bundles, downloads Who owns deletion outside the support platform?
Integrations CRM, issue tracker, warehouse, AI tools Which system is authoritative and how are deletions propagated?
Backups Snapshots and disaster-recovery copies When is an expired record overwritten or put beyond use?

The ICO warns that taking data offline is not the same as deleting it. Offline data is still being processed if the organization can retrieve it. Its guidance also says that, when live-system deletion is appropriate, backup copies need to be addressed. If immediate removal from a backup is not technically possible, the right-to-erasure guidance focuses on putting that data beyond use until the established overwrite cycle completes.

Define the event that starts the clock

A period without a start event is ambiguous. “Keep for 12 months” could mean 12 months after creation, last reply, resolution, closure, contract termination or the end of a dispute.

For support records, the most useful events are usually:

  • case closed and no longer editable;
  • last meaningful update;
  • customer relationship ended;
  • refund, warranty or chargeback window ended;
  • complaint or investigation closed;
  • legal hold released.

Choose the event that matches the purpose. If a new message reopens the case, decide whether it resets the period. Record that rule explicitly instead of relying on the platform’s default behavior.

Zendesk’s current documentation illustrates why this detail matters. Its ticket-deletion schedules operate on archived tickets, which are tickets closed for more than 120 days. A schedule can use the last-updated time, and a later modification resets that clock. Zendesk says eligible scheduled deletions begin within 72 hours and are capped at 200,000 tickets per account per day. Those are product mechanics, not a recommended retention period. A team still has to choose and justify its own period.

Separate the classes of data

A useful schedule is granular enough to act.

Record class Possible policy shape
Routine solved questions Short operational window after closure
Product complaints Window aligned with complaint and claim handling
Fraud or security cases Restricted record tied to investigation needs
Identity documents Delete promptly after the verification purpose ends
Attachments Often shorter than the parent ticket
Quality samples Small, purpose-limited sample with access controls
Suppression record Minimal proof needed to honor an opt-out
Legal hold Pause ordinary deletion only for the affected scope

“Possible” is deliberate. The right period depends on jurisdiction, industry, contract and purpose. The policy owner should validate those inputs with the appropriate privacy or legal function. The product team should make the resulting rule enforceable and observable.

Treat deletion as a workflow

Deletion should not be a hidden batch job. It needs states, evidence and failure handling.

  1. Select eligible records. Use the documented class, start event and approved period.
  2. Apply holds and exceptions. Exclude a case only through a named reason, owner and review date.
  3. Preview the batch. Sample the records, attachments and affected integrations before activation.
  4. Delete or anonymize. Choose the action the purpose permits. Pseudonymization alone may still leave personal data identifiable.
  5. Propagate the action. Notify connected systems that hold their own copy.
  6. Handle backups. Prevent ordinary restoration from reintroducing expired data.
  7. Record the outcome. Keep a minimal administrative event about the policy, batch, time and result, without preserving the deleted conversation.

This administrative trail belongs in the same control system described in our guide to audit log retention. It should prove that the policy ran, not become a second archive of the customer data.

Design for erasure requests before they arrive

The ICO states that the right to erasure is not absolute, but a valid request must be recognized and handled without undue delay, normally within one month. A support team needs a repeatable way to locate the person across ticket identities, aliases, attachments and connected products.

Build a case-level erasure runbook:

  • verify the requester without collecting unnecessary new data;
  • search by stable identifiers and known aliases;
  • list each system and data class found;
  • record the applicable purpose, exception or hold;
  • redact or delete in the correct order;
  • propagate the action to recipients where required;
  • explain any backup delay clearly;
  • confirm completion without exposing another person’s data.

Do not promise instant erasure if the platform uses soft deletion or an overwrite cycle. Describe what happens in the live system, what remains temporarily, whether it is beyond use and when the next state will occur.

Test the policy with three cases

The reopened ticket. A customer replies after the original closure. Confirm which clock resets and whether an old sensitive attachment should remain.

The exported ticket. An agent downloaded a CSV or sent a case to an issue tracker. Confirm whether the deletion workflow finds and removes those copies.

The restored backup. A disaster-recovery exercise restores a snapshot containing records that already expired. Confirm that a post-restore process reapplies the deletion ledger before normal use resumes.

Also measure deletion lag, exceptions past their review date, failed integration callbacks and records awaiting backup expiry. A dashboard that shows only successful deletions will miss the risky queue.

A practical review checklist

Before activating a support-data schedule, ask:

  • Does every record class have a named purpose?
  • Is the retention period justified for that purpose?
  • Is the clock’s start event explicit?
  • Are attachments, recordings and profiles handled separately?
  • Are exports, analytics and integrations in scope?
  • Is there a bounded, reviewed legal-hold process?
  • Can the team find a person’s data across aliases?
  • Does backup handling prevent deleted data returning to production?
  • Does the audit record avoid copying ticket content?
  • Has the rule been tested on reopened, exported and restored cases?
  • Can the team explain the actual deletion timeline to a customer?

A support system is easier to trust when the team can answer not only who may open a case, but also when every copy will stop existing.

Reporting & Sources

Reviewed October 14, 2026: