Data Retention & GDPR
Data retention is the set of rules governing how long RapiDesq keeps customer data before permanent deletion. Retention intersects directly with GDPR, CCPA, and similar regulations — data subject rights, controllable retention, clear legal hold mechanisms, and multi-region residency are all tenant-configurable. This guide covers how to configure retention policies per data type, how legal holds work, how to fulfill data subject requests, how data export works, and how multi-region data residency fits into compliance.
Overview
Retention is configured per tenant and per data type. Different data has different appropriate retention windows: billing records might need to be kept for seven years for tax purposes while chat transcripts might be deleted after two. RapiDesq lets you configure these independently rather than imposing a single tenant-wide retention period.
Deletion in RapiDesq is a two-stage process. When data crosses its retention threshold, it enters a soft-deleted state where it's no longer visible in normal views, search results, or reports. After an additional configurable period (typically 30–90 days), soft-deleted data is hard-deleted — permanently removed from live databases and backups on a scheduled rotation. This two-stage design supports recovery from accidental deletion while still ensuring permanent erasure after a defined window.
Configuring Retention Policies
Navigate to Admin > Data & Compliance > Retention. Retention is configured per data type.
| Data type | Typical retention considerations |
|---|---|
| Conversations | Message content from chat, email, web forms, and bot conversations. Often the largest data volume. |
| Tickets | Ticket records including status, assignments, custom fields, and history. |
| Contacts | Customer contact records, custom fields, interaction history. |
| File attachments | Files uploaded to conversations, tickets, and the knowledge base. |
| AI analysis data | AI-generated outputs like sentiment scores, extracted key points, and summaries. |
| Audit logs | Records of who did what in the platform. Often has longer retention than content data for compliance. |
| CSAT responses | Customer satisfaction ratings and comments. |
| Reporting rollups | Aggregated metrics; typically retained longer than raw data because they don't contain personal information. |
For each type you configure:
- Retention period — how long to keep active data (e.g., 24 months for conversations, 84 months for tickets).
- Soft-delete grace period — how long soft-deleted data is recoverable before hard deletion (e.g., 30 days).
- Retention anchor — the date retention counts from. Usually creation date or last-activity date.
Legal Holds
A legal hold suspends deletion for specific data that would otherwise be eligible. Used during litigation, regulatory investigation, or internal inquiry when deletion would be legally problematic.
Legal holds can be applied to:
- Specific contacts (and all their associated data)
- Specific tickets (and their conversations and attachments)
- Date ranges (all data created during a specified period)
- Tag-based scope (all tickets tagged with a specific value)
Data under legal hold is exempted from automatic deletion regardless of retention policy until the hold is released. An audit entry records when the hold was applied, by whom, and the stated reason.
Releasing a legal hold doesn't immediately delete the data — it resumes normal retention from that point forward, so data still within retention remains normally accessible, and data that would have been deleted catches up to the schedule.
GDPR Data Subject Rights
GDPR and similar frameworks give data subjects (customers) specific rights over their data. RapiDesq provides tooling to fulfill each.
Right of access (Article 15)
Customers can request a copy of all data you hold about them. In RapiDesq, locate the contact and use Export Contact Data to generate a complete package containing the contact record, all conversation transcripts, all tickets, all file attachments, all CSAT responses, and associated metadata. The package is produced as a structured archive (JSON or CSV depending on configuration) that you can send to the data subject.
Right to data portability (Article 20)
Closely related to access, but specifically provides data in a structured, machine-readable format the subject can take elsewhere. The export generated above is designed to satisfy both access and portability requirements.
Right to rectification (Article 16)
Customers can request correction of inaccurate personal data. This is typically handled by an agent updating the contact record directly — contact custom fields, email address, name, and other attributes can be edited from the contact detail view with the changes logged in the audit trail.
Right to erasure / right to be forgotten (Article 17)
Customers can request deletion of their data. The contact detail view includes a Delete Contact action that:
- Soft-deletes the contact record and all directly associated data (conversations, tickets, attachments, CSAT responses)
- Anonymizes references elsewhere in the platform (for example, an agent's ticket history will show the deleted customer as "Deleted User")
- Records the deletion request in the audit log with timestamp and requester
- Hard-deletes the data after the soft-delete grace period expires
If the customer is subject to a legal hold, the erasure request is deferred until the hold is released. The customer is notified that their request has been received but is subject to legal constraints.
Right to restriction of processing (Article 18)
When a customer disputes the accuracy of their data or the lawfulness of processing, they can request that processing be restricted pending resolution. In RapiDesq this is implemented by flagging the contact as "Processing Restricted" — the contact and associated data remain stored but are excluded from new processing (no AI analysis, no automated enrichment, no inclusion in reports) until the restriction is lifted.
Right to object (Article 21)
Customers can object to specific processing activities. Objections are recorded on the contact record and can be honored by (for example) excluding the contact from marketing communications while continuing essential support communications.
Data Export
Beyond individual data subject requests, tenants can export bulk data for their own records, migration, or backup purposes. Navigate to Admin > Data & Compliance > Export.
Available export types:
- Full tenant export (everything you have in the platform)
- Scoped exports (specific contacts, specific date ranges, specific teams)
- Structured archives (JSON or CSV) or PDFs for archival
Exports are generated asynchronously; you receive a secure download link when the archive is ready, typically within minutes for small exports and hours for large ones.
Multi-Region Data Residency
Data residency compliance overlaps with retention but addresses a different question: not "how long?" but "where?" RapiDesq's multi-region architecture ensures your data stays in the region where your tenant was created — conversations, tickets, contacts, attachments, and audit logs all remain in that region for their entire lifetime.
A tenant created in the EU has its data processed and stored in an EU region, supporting GDPR requirements around cross-border data transfer. The roadmap describes expansion to additional regions (UK, APAC, Canada) based on customer demand.
Sub-processors
RapiDesq maintains a public list of sub-processors — third-party services that process tenant data on RapiDesq's behalf. The current list is available in the trust center at /trust/sub-processors and includes:
- Cloud infrastructure providers (for compute, storage, and database hosting)
- AI providers (Anthropic, OpenAI, Azure OpenAI) for bot conversations and AI analysis
- Payment processor (Stripe) for billing
- Email delivery provider for transactional email
- Virus scanning service for file uploads
- Telemetry and error tracking for platform operation
Tenants can configure notification preferences to receive updates when the sub-processor list changes. A Data Processing Agreement (DPA) is available on request for tenants handling EU personal data, with standard contractual clauses (SCCs) for transfers outside the EU where applicable.
Best Practices
- Configure retention before launching. Don't leave it at defaults and figure it out later; retention rules are easier to tighten than to loosen once data has accumulated under a permissive default.
- Align retention with industry and regulatory requirements. Financial services, healthcare, government, and similar regulated industries have specific minimum retention periods that must be respected.
- Document your retention decisions. The retention policy configuration UI shows what you set; accompanying internal documentation should explain why (compliance driver, regulatory citation, business rationale).
- Test data export processes before you need them. When an actual GDPR request arrives is not the time to discover your export workflow has gaps. Run a test export on a test contact once a year.
- Treat legal holds seriously. A botched legal hold (missing data, premature release) has bigger consequences than almost any other compliance issue. When in doubt, consult legal counsel before applying, modifying, or releasing a hold.
- Review retention annually. Regulations change, business needs change, data volumes change. Annual review catches drift between what your policy says and what you actually need.
Related Topics
- Audit Logs — the log that records retention policy changes, legal hold applications, and data subject request fulfillment.
- Contact Management — where contact deletion and rectification workflows are initiated.
- File Attachments — retention and deletion specifically for file data.