I've worked on DSR (data subject request) infrastructure across multiple teams. The pattern is consistent: the teams that built privacy-aware systems from the start handle requests in hours. The teams that didn't spend weeks inventorying their own data, discovering stores they forgot existed, and writing one-off deletion scripts that they hope they got right.
This is not about compliance frameworks or legal checklists. It's about a handful of engineering habits that, if adopted early, make the difference between a DSR being a routine workflow and a DSR being an incident.
Keep a data inventory and actually maintain it
The first time you receive a deletion request, you need to know where the user's data lives. If you don't have a data inventory, you will spend most of your time answering that question instead of running the deletion. The inventory doesn't need to be sophisticated — a spreadsheet that maps data categories to stores, owners, and retention periods is enough to start. What matters is that it's maintained. Every time a new store is created or a schema changes significantly, the inventory gets updated. Treat it like a dependency you have to keep current.
Classify PII at the field level, not the table level
It's tempting to say "the users table contains PII" and call it done. That's too coarse. When you need to respond to an access request, you need to know which specific fields are personal — not just which tables. When you need to anonymize rather than delete, you need to know which fields can be zeroed out and which need to be replaced with synthetic values to preserve referential integrity. Tag your fields. It's a one-time annotation that pays off every time you touch the data for privacy reasons.
In practice, this means documenting column-level metadata — whether a field is directly identifying (name, email, phone), indirectly identifying (IP address, device ID), or sensitive (health data, financial data). Most schema migration tools can carry this as a comment. Some ORMs support it natively. The format matters less than the habit.
Log access to personal data separately from application logs
Application logs tell you what your system did. Access logs tell you who touched whose data and when. These are different things with different retention requirements and different audiences. An access log that answers "which internal users or services read user X's data in the last 90 days" is a standard ask in a privacy audit. If your application logs are your only source of truth for that question, you're going to have a bad time.
The access log doesn't need to be elaborate. A structured log event with user ID, accessor identity, data category, and timestamp is sufficient. What matters is that it's separate, retained appropriately, and queryable without digging through noise.
Build the deletion path before you need it
The worst time to figure out how to delete a user's data is when someone is asking you to do it. The deletion path has dependencies you won't anticipate until you try to trace them: foreign key constraints, derived data in analytics stores, cached copies in Redis, data exported to third-party systems, backups that predate the request.
Build a deletion runbook early — even a manual one — and run it against a test account. The act of tracing the deletion path will surface every store you forgot to include in the inventory. Automate it when the runbook is stable, not before. An automated deletion workflow built on an incomplete inventory is worse than a manual one, because it creates a false sense of completeness.
Treat third-party data flows as first-class obligations
If you send user data to a third-party service — analytics, support tooling, error tracking, marketing platforms — that data is still your responsibility under most privacy regulations. Your deletion obligation extends to instructing the third party to delete. Most third-party services have an API for this. Fewer teams have integrated it into their deletion workflow.
The inventory should include every third-party destination that receives personal data, the mechanism for deletion, and who owns the relationship with that vendor. This is the part that's most often missing when teams do their first real DSR audit.
The compounding benefit
None of these habits are expensive to build in early. All of them become expensive to retrofit. The teams I've seen handle privacy well aren't doing anything extraordinary — they're treating their data infrastructure with the same discipline they'd apply to any other system: known schema, known ownership, known behaviour under failure conditions. Privacy is just the failure condition where the cost is measured in user trust and regulatory exposure rather than latency and downtime.