DPDP Compliance for Database Administrators: Protecting Personal Data in Production Databases
Backups, replicas, query logs and staging copies all extend where personal data lives. A practical checklist for DBAs.
Your database is bigger than your schema
When a compliance team asks 'where does personal data live', most database administrators can answer for the primary tables in seconds. The harder question is everything that copies that data outside the primary schema: read replicas, nightly backups, point-in-time snapshots, query logs, and staging or QA copies restored from production for testing.
Under Section 8(5) of the DPDP Act, reasonable security safeguards apply to personal data 'in its possession or under its control' — which does not stop at the primary table. A breach in a forgotten staging copy is still a breach.
A practical inventory pass
Walk through your backup retention settings and confirm they don't silently exceed the retention period documented for the underlying data — a common gap is a database with a 90-day active retention policy sitting behind backups kept for two years by default.
Check whether query logs or slow-query logs capture literal parameter values (which may include personal data) rather than just query shapes, and adjust logging configuration accordingly.
Identify every non-production environment (staging, QA, developer sandboxes) that has ever been seeded from a production snapshot, and either replace that data with masked/synthetic data or bring those environments under the same access controls as production.
Access control and encryption baseline
Encryption at rest for the primary database is the easy part — extend the same expectation to backup storage, replica instances, and any exported dumps used for analytics or migration.
Use role-based access control with logging for anyone querying tables containing personal data directly, rather than relying solely on application-layer access controls that a direct database connection can bypass.
Retain access and query logs for at least one year, consistent with the DPDP Rules' baseline for breach detection and investigation.
When erasure requests reach the database layer
A Section 12 erasure request is often implemented as a soft delete or status flag at the application layer — but if replicas, backups, and analytics exports aren't included in the erasure workflow, the data hasn't actually been erased.
Build a documented process (even if manual at first) for how an erasure request propagates from the application layer down to backups and replicas, including a defined maximum time before backups rotate out the erased record.
Where to go next
Use the Personal Data Inventory to document every copy of production data, and the Retention Planner to set explicit backup retention periods rather than relying on platform defaults.