Sensible defaults for every regulated class of data.

Anchored to regulatory citations

Every seeded policy carries the regulatory citation that justifies the retention period. When the privacy team is asked "why does this dataset live for seven years?" the answer is in the policy — not in the head of the operator who set it up four years ago.

• GDPR — Articles 6(1)(b) (contract), 6(1)(c) (legal obligation), 6(1)(f) (legitimate interest), and 7 (consent).
• HIPAA — 45 CFR § 164.530(j), six-year retention for documentation.
• SOX — § 404 plus IRS retention schedules for financial records.
• CCPA / CPRA — Cal. Civ. Code § 1798.105, deletion right with statutory exceptions.
• ePrivacy Directive — Article 5(3), cookie and similar-technology consent retention.

Two assignment modes

Per-datastore. Apply a retention policy to an entire datastore — every column inherits unless overridden. Useful for warehouse-style stores where the retention rule applies uniformly.

Per-master-attribute. Apply different retention to different categories within the same datastore. Email addresses retained under marketing-consent rules while transaction IDs retained under SOX. The discovery and classification engine identifies which columns belong to which master attribute, so the policy applies surgically.

Notifications before expiry

The retention engine surfaces upcoming expirations on a configurable lead time — 30, 60, 90 days. The privacy team sees what's about to lapse and can extend, reclassify, or proceed with deletion. No record silently expires without an operator decision.

Two enforcement paths

Marketing-class data eligible for auto-deletion. Email lists, behavioural records, ad-targeting data — these classes can self-purge on policy expiry without operator intervention. The audit log captures the deletion event with the policy citation that triggered it.

Sensitive categories require operator approval through the deletion runbook. PHI, PCI, biometric, genetic, financial, and authentication data never self-delete — an operator confirms the deletion against the runbook, the runbook validates retention policy and legal-hold constraints, and only then does the deletion execute.

Legal hold overrides retention

Litigation hold, regulatory investigation, or internal-investigation hold pins specific entities so they cannot be deleted, archived, or purged regardless of retention configuration. The hold is logged with actor, timestamp, scope, and justification. Release of the hold is logged the same way. The retention policy resumes governing the held entity on release.

Retention awareness on marketing list export

Marketing list exports respect retention by default. A subject whose record has crossed the retention threshold is excluded from the export — even if the marketing platform still has them in its address book. Marketing sees the current valid universe, not the historical universe. See compliant marketing lists →