Privacy engineering for DPDP: find, map and automate personal data

Most DPDP programmes start with documents: a privacy notice, a retention policy, a rights procedure. Those documents matter, but the obligations that apply from 13 May 2027 are tested on systems. When a customer withdraws consent, the marketing tool has to stop sending. When someone asks what you hold about them, someone has to pull it from every database, ticket and spreadsheet.

Privacy engineering is the work of making those things happen reliably. This page explains how a team finds every place personal data lives, classifies it, maps it to purposes and vendors, automates consent, rights requests and deletion, and keeps proof that it works. It is also how we typically run a privacy engineering engagement, working with your engineers and alongside your legal counsel, who own the legal interpretation.

What is privacy engineering for DPDP?

It is the set of technical controls that turn DPDP obligations into system behaviour. Several provisions only work if you know where personal data is and what it is for:

• Notice. Rule 3 asks for an itemised description of the personal data in each privacy notice. You can only itemise what you have found.
• Access. Section 11 gives people a right to a summary of their personal data and its processing, and the identities of the fiduciaries and processors it was shared with, with a description of what was shared.
• Erasure. Section 8(7) requires you to erase personal data when consent is withdrawn or the purpose is no longer served, unless a law requires retention, and to make your processors erase it too.
• Proof. Section 6(10) puts the burden of proving that notice was given and consent obtained on you.
• Breach. Rule 7 asks you to describe the nature and extent of a breach to the Board, which depends on knowing what data sat in the affected system.

The work runs in five steps. Each one produces something the next step needs.

The order matters. Starting with automation, such as a consent tool or a rights request portal, risks building something that reaches only the systems someone remembered to connect. Discovery first means the automation covers what actually exists.

How do you find every place personal data lives?

DPDP data discovery combines three sources: what people tell you, what your system inventories show, and what scanning finds. Interviews give purpose and context, inventories list the places data could be, and scanning shows what is actually inside them.

Where to look

• Databases and warehouses: production tables, read replicas, analytics copies, and columns added for one feature and never removed.
• Logs: application, API gateway and infrastructure logs, which pick up phone numbers, email addresses and full request bodies.
• Backups and snapshots: plus copies made for testing, migration or debugging.
• File and object storage: uploaded identity documents, invoices, reports and data exports.
• SaaS tools: CRM, support desk, marketing email, HR and payroll, analytics and form builders.
• Spreadsheets and shared drives: lists exported for a campaign or an audit, email attachments, chat exports.
• Digitised paper: the Act covers personal data collected offline and later digitised (section 3), so scanned forms and registers count.

How scanning works

PII discovery and classification tools sample rows and files and look for patterns: Indian mobile numbers, email addresses, PAN and Aadhaar number formats, bank account and IFSC formats, dates of birth, addresses. They also read column names, file names and surrounding context, and give each finding a confidence score. A person then confirms or rejects findings, because patterns alone produce false positives (an order number that looks like a phone number) and miss free-text notes.

We aim to run scanners inside your environment with read-only access, so what leaves the system is metadata (where, which data type, roughly how many records), not copies of the data. Scans repeat on a schedule, because new tables and tools keep appearing.

How do you classify personal data once you find it?

Classification turns a list of findings into something you can act on. Each data item gets a small set of tags:

• Data type: contact details, identity numbers, financial, health, location, behavioural, and so on.
• Whose data: customers, employees, vendors' staff, or children. A child is anyone under 18 (section 2(f)), and section 9 requires verifiable consent of a parent before processing a child's data, so this tag drives a separate set of controls. Our children's data guide covers them.
• Purpose: the specific reason the data is held, in words a product owner would recognise.
• Ground: consent or one of the legitimate uses in section 7. Counsel should confirm this tag, because it decides what happens on withdrawal.
• Owner: a named person or team who approves changes and answers questions.
• Sensitivity tier: your own internal tiers, used to prioritise controls such as masking and access review.

Keep tags machine-readable (catalogue column tags, bucket labels, map fields). A tag in a slide deck cannot drive automation.

What goes into a DPDP data map?

Data mapping for DPDP links each system to its data, purpose and vendors. The table below shows the fields we typically capture and the obligation each one serves.

The map is only useful if it stays current. Tie it to change management: a new table, a new vendor or a new purpose should trigger an update, and the scheduled scans should flag anything the map does not know about. Hosting location also feeds decisions about where data sits, which our data localisation work covers.

What can you automate: consent, rights requests and deletion?

Once the map exists, privacy automation can do the repeatable work. Three areas usually give the most value.

Consent sync

Section 6(4) lets a person withdraw consent at any time, as easily as it was given, and section 6(6) requires you to stop processing within a reasonable time and make your processors stop too. In engineering terms, that means one consent record per person and purpose, and a way to push every change to the systems that use the data: marketing email, messaging, analytics, ad audiences and the vendors behind them.

The usual pattern is a consent service that publishes change events, downstream systems that subscribe to them, and a reconciliation job that checks each downstream tool against the consent record and flags any mismatch. Each record should keep the notice version shown and the time of each change. Rule 4 on consent manager registration applies from 13 November 2026, though no consent manager has been registered so far. Design the consent store so it can accept signals from one later. The consent guide covers the legal side.

Rights requests

DSAR automation in India means handling requests for access, correction, completion, updating and erasure under sections 11 and 12, and grievances under section 13. Rule 14 asks you to publish how people can make requests and the identifiers you need, and to publish a grievance response period of no more than 90 days. A typical pipeline:

1. Intake through your website or app, with identity checks proportionate to the request.
2. Fan-out: the data map tells the workflow which systems and processors hold this person's data.
3. Collection or action: connectors pull records, or apply corrections and erasure, and processors receive tickets with a due date.
4. Review: a person checks the response before it goes out, removing other people's data and noting records a law requires you to keep.
5. Response and record: under Rule 9, each response carries the contact details of your DPO or the person who answers questions, and the request, actions and dates are logged.

Our data principal rights guide covers each right in detail.

Retention and erasure jobs

Automated data deletion starts with retention rules written as code: each data category, its retention period, the event that starts the clock and the legal source. Scheduled jobs then delete or anonymise records that have passed their period, send erasure instructions to processors and record confirmations. Rule 8(3) sets a floor: every fiduciary keeps personal data, associated traffic data and processing logs for at least one year from processing, then erases them unless another law requires more. Large e-commerce, gaming and social media platforms in the Third Schedule must also erase after three years without contact, with notice at least 48 hours before.

Two details need deliberate design. First, legal holds: a flag that pauses deletion for records a law or a dispute requires you to keep. Second, backups: the Rules do not single out backups, so a common approach is to let them expire on a documented schedule and keep a deletion list that is re-applied if a backup is ever restored. Logs have their own clock too: CERT-In's directions of 28 April 2022, issued under section 70B(6) of the IT Act, require logs of all ICT systems to be kept securely for a rolling 180 days within Indian jurisdiction. Your retention rules should carry every applicable period, and your retention schedule should name the source of each.

How do you prove the system works?

Automation that leaves no trace is hard to defend. Since section 6(10) puts the burden of proving notice and consent on you, and the Board may ask what happened to the data after a complaint or incident, each automated step should write a record:

• Discovery: scan history, with findings confirmed, rejected or fixed.
• Consent: event logs with notice version, timestamps and downstream sync status, plus reconciliation reports.
• Rights requests: a register with dates received, actions taken per system and date closed.
• Deletion: job run logs showing which category, how many records and when, without repeating the data itself.
• Processors: erasure and stop-processing confirmations from each vendor.

Keep these logs minimised: record IDs and counts, not names and phone numbers. The security safeguards guide explains how Rule 6 logging and minimisation fit together.

How does a privacy engineering engagement typically run?

We follow the same five steps. A scoping call sets the systems in scope and the access we need. Discovery runs with read-only access inside your environment. Classification and mapping happen in short workshops with system owners and your counsel. We then build the automation with your engineers, inside your stack, so your team can run and change it after we leave. We aim to hand over working controls and runbooks, not a black box.

The inventory and map are reused in enterprise data readiness for AI, and in API security reviews.

How to start

1. Name an owner. One person accountable for the inventory and map, with time to do it.
2. List what you know. Systems, SaaS tools and vendors that hold personal data, from finance and IT records as well as memory.
3. Run a pilot scan. Pick a few high-volume systems, including one log store and one shared drive, and compare findings with what you expected.
4. Agree the tags. Settle the classification scheme and the purpose and ground for each data category with your counsel.
5. Automate by risk and volume. Start where manual handling fails first: consent sync if you run heavy marketing, rights requests if you serve many consumers, deletion where data piles up.

Privacy engineering sits under several items in the DPDP compliance checklist and the implementation roadmap. To see our other engineering work, visit services. If you want engineers to run discovery and build the automation with your team, book a scoping call.