Consent and Retention

Consent and Retention

Consent is a record, not a checkbox; retention is a daily delete job.

Why it matters

Most regulators care less about your privacy policy and more about whether your system actually honours it (deletes when consent is withdrawn, ages out beyond retention).

Going deeper

The engineering behind Retention and Consent:

1. Immutable Consent Logs: A consent table should be append-only. (user_id, granted, purpose, timestamp, policy_version). When they withdraw, you append a new row granted = false.
2. Time-to-Live (TTL): Modern systems use TTL configurations on storage layers (like DynamoDB TTL or S3 Lifecycle policies) to automate retention.
3. Tombstone tables: In an RDBMS, instead of running random DELETE queries, teams often move expired data to a cold tombstone table, which is periodically wiped by an automated, auditable script.

If retention requires a human to remember to run a script, you are already non-compliant.

Consent and Retention is like a library book's checkout slip.

When you check out a book, the slip inside the cover (or in the system) shows exactly when it's due back. When the due date hits, the librarian expects you to return it. If the librarian gives you a book but has no system for tracking when you checked it out, they've essentially given it to you forever. In data terms, a checkbox that says 'I agree' without storing when, what version of the policy, and when to delete is useless against an audit. Retention means writing the 'due date' on the data, and having a robotic librarian that strictly shreds it when time's up.