Help desk data-retention settings

A closed ticket is usually still a stored record. It may contain customer names, addresses, complaint details, internal notes and attachments long after the issue ended. A help desk therefore needs a planned lifecycle: what remains active, what is reviewed, what is kept for a justified purpose and what is erased or anonymised.

The ICO's storage-limitation guidance says the UK GDPR does not prescribe one period for personal data. The organisation should justify retention for its purposes, document standard periods where appropriate and review data it no longer needs. This page helps a buyer test whether a product can carry out that decision; it does not set the legally correct period for your business.

Separate record types before setting a timer

Routine questions, unresolved complaints, refund evidence and security incidents may need different treatment. Define categories that your team can actually identify, and note any other legal or contractual preservation duty. A blanket “delete all tickets after a year” rule could remove evidence still needed for an open complaint; an indefinite “keep everything” rule creates unnecessary exposure. Ask the responsible adviser to approve exceptions and holds.

Create a short schedule with data category, purpose, retention trigger, review or deletion action, owner and exception process. The trigger may be closure, last customer interaction, account termination or another event—choose it deliberately. The same customer may have several tickets with different purposes.

Test the full record, not only the ticket headline

Create a test customer with a message, private note, attachment, custom field and linked order. Search for that person, export the record, redact a sensitive detail and delete the test ticket using the plan's supported path. What remains in search results, reports, audit logs and linked systems? Who can perform the action, and can it be reversed? Confirm whether attachments and transcripts follow the same policy.

Zendesk's trust centre describes ticket and user deletion schedules and more advanced conditional retention on an add-on. Freshworks' data-storage documentation discusses active-account data and termination handling. Treat these as vendor-specific starting points: confirm current terms, edition and the meaning of deletion in a written answer.

Account for backups and exported copies

Deleting a record from the live inbox may not immediately remove it from disaster-recovery backups. Ask for the backup retention cycle, restoration safeguards and how deletion requests are handled after a restore. ICO encryption and backup guidance highlights both recovery and erasure considerations. Do not promise customers instant deletion from every backup unless the provider can support that statement.

Your own CSV exports, spreadsheets, screenshots and AI tools may outlive the help desk. Keep an inventory and apply the same purpose-based review. A clean vendor deletion feature does little if an uncontrolled export remains in a shared drive. Limit who can export, record why and remove copies when the purpose ends.

Prepare for migration and exit

Before importing historic tickets, filter out records that are no longer needed. At exit, ask how to export necessary open cases, how long the provider keeps the account after termination and when data becomes unrecoverable. Test that a sample export includes the context required to continue serving customers. Record the final deletion confirmation rather than assuming cancellation performs it.

Review the schedule after a new channel, AI feature, legal requirement or complaint type changes the data you hold. A retention setting is not “set and forget”; it must continue to reflect the reason you keep the information.

Sources

• ICO: storage limitation
• ICO: encryption and backup scenarios
• Zendesk Trust Center
• Freshdesk data-storage and security information

This is editorial buyer guidance, not legal advice or a recommended retention period.