Data you must keep, and data you must delete

You are collecting more than you think

A live site accumulates personal data whether anyone designed for it or not:

• IP addresses and user agents in web server logs.
• Email addresses, obviously, and also in support threads, in error reports, in a CSV somebody exported.
• Uploaded images with EXIF metadata, which routinely contains GPS coordinates and a device serial number.
• Session records, password reset tokens, login history.
• Whatever your analytics provider set in a cookie.

The first move is not a policy. It is to write down what you have, where it lives and why. That list is usually shorter than feared and longer than expected, and you cannot manage what you have not enumerated.

Collect less

The cheapest way to not leak something is to not have it.

You do not need a date of birth to run a forum. You do not need a full address to send an email. You do not need to store the raw IP when a truncated one or a daily-rotated hash answers the same question. Every field you decline to collect is a field that cannot appear in a breach, cannot be subpoenaed, and cannot be asked about in a data request.

Retention is a number, enforced by a job

“We keep data as long as necessary” is not a retention policy; it means forever. Pick a number for each store and make something delete it:

• Web server and application logs: 14 to 30 days.
• Anything request-level containing an IP or user ID: shorter, 7 days is common.
• Backups: 30 to 90 days, on a rolling schedule.
• Soft-deleted records: purged after 30 days.

Then write the job, schedule it, and alert if it stops running. A retention policy that lives only in a document is a claim you are making publicly and not honouring, which is materially worse than not making it.

Deletion has to reach every copy

When someone asks to be deleted, the row in your primary database is the easy part. The copies are:

• Read replicas: they follow, so this is fine.
• Backups. The one everybody forgets.
• The search index.
• The cache.
• The CDN, if user content is served through it.
• Your analytics and error-tracking providers, which are separate systems with their own deletion APIs.
• The CSV someone exported to a laptop last March.

The honest position on backups is that you cannot surgically remove one person from a backup archive without destroying its integrity. The accepted answer is to state the retention window plainly: deleted from live systems immediately, gone from backups within N days as the backups age out. Write that N in your policy. A specific number is both honest and defensible; silence is neither.

Soft delete, hard delete, and the lawful exception

Soft delete (a deleted_at column) keeps referential integrity, keeps replies from orphaning, and keeps an audit trail. It is the right default for content.

It does not satisfy “erase my personal data”, because the data is still there. So you need a real erasure path: anonymise the identity, replace the display name and email with placeholders, drop the avatar, and keep the content rows if they must stay for others’ sake.

And there are lawful exceptions worth being precise about rather than vague. This project keeps a legal_holds record for content it is legally obliged to preserve and report; that record deliberately survives deletion of the account, and its author reference is intentionally not a foreign key so that erasing the identity does not remove it. That is retention under a legal obligation, and it is a recognised exemption from erasure.

The lesson generalises: name your exceptions in your policy. “We delete everything on request, except records we are legally required to retain, which are X and kept for Y” is honest and correct. “We delete everything” while quietly keeping something is neither.

The rules of thumb, without a lawyer

You do not need legal advice to be broadly right:

• Under the GDPR you have one month to answer an access or erasure request, and 72 hours to notify a supervisory authority of a personal data breach. India’s DPDP Act 2023 is different in detail and similar in shape.
• Tell people what you collect, why, how long, and who else sees it. In plain language, on a page anyone can reach.
• Give them a working button, not an email address that goes to somebody who left.

That is most of it. The failure mode for small teams is not usually the wrong retention period; it is a privacy page that describes a system nobody built.

Never log the secret

Redact at the logging layer, not by remembering: Authorization headers, cookies, passwords, tokens, OTP codes, full card numbers. Configure the redaction in one place, because “we will be careful” fails the first time somebody logs an entire request object during a debugging session and it goes to production.