The Data Deletion Discipline No Team Has

Most teams delete data poorly. The four-step discipline that satisfies GDPR, prevents lawsuits, and reduces storage cost.

Audit what you have

You cannot delete what you do not know about. The audit is the first step and the one most teams skip; the inventory always reveals more stores than expected.

• Full inventory. Every data store with personal data: primary DBs, replicas, warehouses, caches, log archives, backups.
• Tag each store. Source, customer-identifying fields, retention period, deletion mechanism, owner.
• Liability flag. Any store without a deletion mechanism is a regulatory liability; tag it, queue the fix.
• Refresh quarterly. Stores get added; the inventory is only useful if it stays current.

The deletion policy

The policy says what gets deleted, when, and how the action is recorded. Vague policies fail the first regulator request; concrete policies survive.

• Deletion window. Customer request to fully gone within N days; GDPR sets 30 as the floor; pick a defensible target.
• Tombstones. Audit trail records 'deleted at X by request Y' even after the data itself is gone.
• Backups included. Backups are not exempt from GDPR; deletion must propagate or backups must roll over fast enough to obviate it.
• Hard versus soft. Soft delete is not deletion under most regulations; the data must actually be unreadable within the window.

Automate it

Manual deletion is unreliable and unrepeatable. Automation turns a regulator request from a multi-day project into a queued workflow.

• Trigger. Deletion request fires a workflow; the workflow walks every data store in the inventory.
• Audit trail. Every deletion logged with timestamp, store, and request ID; the log is the regulator-facing artefact.
• Pre-prod test. Workflow exercised against synthetic customers; verify the end state in every store.
• Without it. Manual deletion misses backups, secondary stores, analytics warehouses, and shadow exports; the auditor will find them.