The hardest part of data deletion is rarely deleting one row from the production database.
The difficult part is understanding every place that row travelled.
Primary databases
Read replicas
Search indexes
Caches
Analytics stores
Logs
Queues
Warehouses
Snapshots
Backups
Once data has been copied into several systems, a user deletion request becomes a lifecycle problem rather than a SQL command.
For Indian organisations preparing for the substantive DPDP obligations scheduled for May 13, 2027, I think this is exactly the kind of engineering work worth starting before enforcement reaches the application team.
First understand the timeline
The DPDP Rules were notified in November 2025, but key substantive obligations are being introduced in phases.
As of September 2026, teams should not describe every right and erasure workflow as if the full compliance date had already arrived.
The practical opportunity is preparation.
Map where personal data exists now so the organisation is not building deletion infrastructure under deadline pressure later.
Production deletion is the easy part
Imagine a user asks to erase an account.
The application identifies eligible personal data and deletes it from the active relational database.
That might take seconds.
But the same user's information may also exist in backups taken yesterday, last week, and last month.
Immediately rewriting every immutable historical backup whenever one user submits a request can undermine the integrity and operational simplicity that make backups reliable.
This is why privacy engineering and backup engineering must be designed together.
A managed database platform should fit into an organisation-wide retention model rather than becoming an isolated copy of personal data.
Backups need a defined lifecycle
I prefer explicit backup retention.
Keep backups only as long as they have a legitimate operational or legal purpose.
Apply automatic expiration.
Control access tightly.
Encrypt them.
Do not use historical backups as convenient secondary datasets.
The shorter and clearer the backup lifecycle, the easier it becomes to reason about personal data inside historical copies.
Indefinite backup retention is difficult to defend operationally even before privacy requirements enter the discussion.
Restoration is the moment many teams forget
Suppose a user's active data was erased on Monday.
On Friday, the production database suffers a major incident and the organisation restores a backup created on Sunday.
The erased user's data may reappear.
This is the part I want teams to design for.
A deletion ledger or equivalent mechanism can preserve the knowledge that certain data was previously erased.
After restoration, the system can reapply deletions that occurred after the backup was created and before the restored production point.
The exact design depends on the application and legal basis.
The principle is that recovery should not permanently undo privacy operations.
Separate active use from recovery-only copies
A backup should not become a shadow production database.
Restrict who and what can access it.
If personal data remains temporarily inside an unexpired recovery copy, the organisation should ensure that copy is not used for marketing, analytics, customer support searches, or unrelated processing.
This separation reduces risk.
It also makes the purpose of retaining the backup much clearer.
Deletion needs to propagate beyond SQL
Applications increasingly use many data systems.
A user profile may be stored in PostgreSQL.
The session is in Redis.
Events are in Kafka.
Search data sits somewhere else.
Analytics receives another copy.
Object storage contains uploaded files.
Deleting only the relational row leaves a fragmented identity behind.
I create a data map linking personal-data categories to every downstream processor.
That map becomes the foundation for deletion orchestration.
Logs need special treatment
Teams often write personal data into logs without noticing.
Email addresses
Phone numbers
Tokens
Query parameters
Request bodies
Database errors containing user data
These logs can have completely different retention policies from the main database.
The best deletion strategy is often not to put unnecessary personal data there in the first place.
Data minimisation makes future erasure dramatically easier.
Infrastructure scaling should not create invisible copies
Cloud systems make cloning easy.
Development teams create database snapshots.
QA teams copy production datasets.
Engineers export tables to debug incidents.
Analytics teams create temporary stores.
Every copy increases deletion complexity.
I want policies around cloning and test data built into cloud infrastructure operations rather than depending on individual engineer judgement.
Masking and synthetic test data can eliminate many unnecessary personal-data copies.
Build the deletion system as a workflow
I think of erasure as a state machine.
Request received
Identity verified
Legal and retention requirements checked
Active systems identified
Deletion jobs triggered
Downstream systems updated
Evidence recorded
Backup-restoration handling preserved
Completion communicated
Some data may need to remain where another law requires retention.
That is why engineering should implement policy rather than invent policy.
Legal and privacy teams determine what may or must be retained.
Database engineers make that decision technically enforceable.
The backup question does not make privacy deletion impossible.
It simply proves that data lifecycle management must include recovery systems.
Prepare that architecture before the first high-pressure request exposes how many copies your organisation forgot it created.
Top comments (0)