Data retention + deletion policies: what TrackLayer keeps, for how long

GDPR Article 5(1)(e) puts a simple boundary around storage: personal data should not be kept in a form that permits identification for longer than necessary for the purposes for which it was collected. In practice, that means a tracking system needs documented windows for operational payloads, identifiers, logs, and backups rather than a single vague promise to delete data someday. Storage limitation is not only a legal principle. It is also an architecture rule that shapes tables, queues, exports, suppression logic, and audit evidence.

Shorter windows reduce storage cost, narrow breach exposure, and make deletion requests easier to fulfill. Longer windows can still be justified when they preserve compliance evidence, financial traceability, or business-critical aggregates. The point is not to keep everything forever or delete everything immediately. The point is to match each class of data to its purpose, then enforce that decision consistently enough that security reviewers, privacy counsel, and customers all get the same answer.

TrackLayer separates high-volume operational data from long-lived evidence and summarized reporting. That keeps hot debugging data short-lived while preserving the records teams actually need for audits, account history, and performance trending.

Retention changes should be treated like any other data-governance change: deliberate, reviewed, and tied to a purpose. Tier limits apply, and Enterprise can extend supported ranges where there is a clear operational or compliance justification.

1. Choose the dataset and objectiveStart from the data class, not from a vague request to keep less. Raw payloads are for operational debugging, hashed identifiers are for matching and reconciliation, audit logs are for evidence, and metrics are for trend reporting. The right window should reflect why the data exists and whether a shorter period would still satisfy support, finance, security, and privacy requirements.
2. Set the workspace policyWorkspace admins can set retention by category inside the admin controls. Lower tiers can reduce windows within supported ranges, while Enterprise workspaces can request longer windows for specific categories such as hashed identifiers or audit evidence where the business case is documented.
3. Validate downstream effectsBefore saving a policy, check how the change affects exports, replay workflows, attribution lookbacks, and internal investigations. A shorter delivery log window may be fine for a fast-moving growth team, but it can make slower partner escalations harder to resolve. A longer identifier window may help match quality, but it increases the period during which deletion and access rights must still be supported.

A deletion request is not complete when the primary record disappears from one table. TrackLayer processes deletion across the active event store, hashed identifier indexes, delivery systems, and configured warehouse exports. For most workspaces, that propagation completes within 24 to 48 hours, depending on the number of integrations, warehouse sync cadence, and whether downstream destinations expose deletion or suppression endpoints.

The practical goal is consistency: active systems stop using the record, downstream dispatch halts, and future re-imports are prevented by suppression or tombstone logic where applicable. That gives privacy and support teams a defensible answer when a customer asks not only whether the record was deleted, but whether deletion was propagated across the systems that could otherwise recreate or continue to process it.

TrackLayer backups follow a 30-day rolling window. Those backups exist for disaster recovery, not for ordinary querying or replay. When a deletion request is approved, the deletion is applied to active systems first and recorded so that restored environments do not reintroduce the deleted data into normal processing.

Because backup media is rotated on a rolling schedule, deletion requests are honored within the backup cycle rather than through instant destructive rewriting of every historical snapshot. That is the tradeoff most resilient systems make: fast active deletion, controlled recovery capability, and a bounded window after which the deleted record has naturally aged out of the retained backup set.

Audit logs are retained for a minimum of five years because they serve a different function from event payloads. Their job is to show who changed routing, permissions, destination settings, retention rules, deletion policy, or legal hold status and when those actions occurred. For SOC 2 and ISO 27001 programs, that evidence supports change management, access review, incident reconstruction, and control testing long after the underlying operational event has expired.

Keeping those records longer is not a contradiction of minimization. It is a scoped compliance necessity. The retained fields are administrative and evidentiary, not full copies of raw customer event streams. Enterprise customers that need longer windows for regulated environments can request extensions, but the five-year minimum is the baseline for control-friendly evidence retention.

TrackLayer's retention policy governs TrackLayer's systems. It does not override the independent retention obligations or product rules of your downstream subprocessors and advertising platforms. If an event has already been delivered to a destination, that destination may keep it under its own policy, terms, and account configuration.

The practical implication is straightforward: TrackLayer can enforce deletion and expiry on the TrackLayer side, but customers still need to review each material destination's own retention and deletion support when drafting privacy notices, DPAs, and internal data maps.

Legal hold is an Enterprise feature that pauses scheduled deletion for specific scopes during litigation, investigation, or other documented preservation needs. The hold can be applied to selected workspaces, identifiers, or time-bounded record sets so that routine expiry jobs do not remove material that counsel has asked to preserve.

A legal hold should be exceptional, not a permanent workaround for indecision. Each hold should have a named owner, a reason, a documented scope, and a release trigger. Once the hold is lifted, ordinary retention rules resume and queued deletions can be processed according to the restored policy.