DPDP data governance operating model

Summary

India's Digital Personal Data Protection framework requires coordinated work across policy, data, applications, security, and operations. Begin with a verified inventory of personal data and processing purposes. Connect each purpose to collection, access, sharing, retention, deletion, and rights workflows. Store evidence that shows who approved a control, where it runs, and whether it worked. The Digital Personal Data Protection Rules, 2025 were notified on November 14, 2025. The related commencement notification uses a phased schedule. Organizations should map each obligation to its applicable date and confirm the interpretation with counsel. This guide describes an engineering operating model. It does not provide legal advice.

Define the operating boundary

Start with the products, processes, legal entities, and systems in scope. Name an accountable business owner for each processing activity. Record: Use system evidence to verify the inventory. Interviews and spreadsheets can seed the work. Database scans, schemas, event contracts, application forms, data catalogs, and access records make the inventory testable. Two discovery passes beat one. The first pass asks teams what they collect. The second pass scans schemas, query logs, file shares, and application event contracts for personal-data patterns and compares the result with the declared inventory. Columns that appear in the scan and not in the inventory are the real backlog, and they cluster in the same places in most organizations: analytics copies, log archives, support exports, and test environments.

The category of personal data
The data principal or user group
The purpose of processing
The collection channel
The source system
The systems that copy, transform, or serve the data
Internal and external recipients
Storage location and jurisdiction
Retention rule
Deletion or anonymization path
Business and technical owners

Connect notice and purpose to the data path

Create a purpose record that the data platform and application teams can use. Give each purpose a stable identifier. The record should link: The visible notice or approved language The data fields collected for that purpose The applications and pipelines that process those fields The roles and services allowed to use them The recipients and sharing conditions The retention and deletion rule The owner who approves a change This link helps reviewers answer a practical question: where does data collected for one purpose enter another use? Implement the link as a registry table that engineering systems can query, with one row per purpose and version. A pipeline that processes personal data declares the purpose identifiers it serves, and a nightly job compares declared purposes against the fields the pipeline actually reads. A mismatch, such as a pipeline reading a phone number under a purpose registered only for email, becomes a review task with a named owner. The registry turns purpose limitation from a document into a check that runs.

Make consent and withdrawal operational

If consent is the applicable basis, store the consent event with the notice version, purpose, time, channel, and data-principal reference. Keep withdrawal as a first-class event. A withdrawal workflow needs to identify affected systems, stop future processing where required, and trigger downstream actions. The workflow should produce a result for each target system: Avoid a single database flag with no downstream enforcement. A reliable workflow records the work performed in each system. Derive the affected-system list from the purpose registry, and maintain a per-system handler that knows how that store deletes or suppresses a record. Some targets cannot delete a row on demand, such as an append-only event log or a warehouse partition built last quarter. For those, record the mechanism the system does support, such as crypto-shredding a per-person encryption key or a suppression list that downstream queries must apply, and confirm the interpretation of each mechanism with counsel.

Completed
No matching record
Exempt or retained under an approved rule
Failed and queued for operator review

Implement access controls around purpose and role

Use the smallest practical access scope. Separate human access, service access, administrative access, and emergency access. The control design should cover: Record the policy owner, enforcement point, approval, and last test. An access policy that exists without an assigned resource does not protect the data. Test effective access, and include the paths people forget. A masked column in the warehouse does not protect the same value in a business intelligence extract, an exported spreadsheet, or a support tool that queries the source application directly. The test suite should follow the field, and each hop should show the same classification and the same rule.

Identity and role assignment
Service accounts and workload identities
Dataset, table, row, and column access
Masking or tokenization
Export and download controls
Non-production data handling
Time-limited privileged access
Access review and revocation

Build a rights-request workflow

Treat a data-principal request as a tracked case. Define identity verification, search scope, due dates, approvals, exceptions, response generation, and evidence retention with counsel. The technical workflow can include: Register the request. Verify the requester through an approved process. Resolve the person's identifiers across systems. Dispatch scoped tasks to system owners. Collect results and exceptions. Review the response. Deliver the response through the approved channel. Store the case evidence and completion status. Test the workflow with difficult cases, including duplicate identities, shared accounts, archived records, derived data, and failed downstream jobs. Identifier resolution is the step that breaks under real data. A person may appear as a phone number in the commerce system, a loyalty identifier in the marketing platform, and an email address in support tickets. Maintain a resolution map with confidence levels, and require human review below a defined confidence threshold. Over-matching exposes another person's data in the response; under-matching leaves the request incomplete. Both outcomes carry regulatory risk, so the workflow should record which identifiers were matched and why.

Make retention enforceable

Translate the retention schedule into data rules. Apply rules to primary stores, analytical copies, files, caches, indexes, and backups according to the approved policy. Each rule needs: Measure the age of eligible records, failed deletion jobs, unresolved holds, and systems without an implemented rule. Design deletion for the storage engine in use. In a partitioned warehouse table, expiring a partition is cheap and verifiable, while row-level deletion across unpartitioned history scans large amounts of data on every run. Aligning table partitioning with the retention trigger date turns the deletion rule into a metadata operation. Backups need a documented position: the organization should know whether backups expire on a fixed cycle, how long a deleted record persists inside a backup, and what the restore procedure does about records that were lawfully deleted after the backup was taken.

Scope
Trigger date
Retention period
Hold conditions
Deletion or anonymization action
Downstream propagation behavior
Verification method
Named owner

Prepare for personal-data breaches

Connect security detection to the personal-data inventory. An incident team needs to know which data was affected, whose data was involved, where the data moved, and which control failed. Maintain: Run exercises that include legal, security, product, data, communications, and executive owners. The inventory decides the speed of the response. A team that can answer "which people and which fields" from the registry in an hour can make a notification decision on facts. A team that starts the inventory during the incident cannot. Rehearse the query, and time it.

Data classification and system ownership
Security logs and access history
Incident severity criteria
Investigation and evidence procedures
Notification decision records
Containment and recovery actions
Post-incident control changes

Failure modes in a DPDP program

Several failure modes repeat across implementations. The first is the orphan copy. The inventory covers primary systems, and the analytics export, the data science sandbox, and the email attachment escape it. The second discovery pass, repeated quarterly, is the control. The second is the unenforced flag. A consent attribute exists in the customer table, and no pipeline checks it. The control is the declared-purpose comparison job, because it tests what systems do rather than what schemas declare. A third failure hides downstream. A withdrawal completes in five systems and fails in a sixth, and the workflow reports success because nobody read the per-system result. Alert on any result other than completed, no matching record, or an approved exemption. The fourth is evidence decay. Controls pass their first test and drift as schemas, roles, and vendors change. Every control record needs a last-tested date, and the review should alert on age.

Monitoring, metrics, and program cost

Track a small set of measures monthly: inventory coverage against scan results, percentage of personal-data fields linked to a purpose, withdrawal completion rate by system, median and tail time to close a rights request, records past their retention date, failed deletion jobs, and controls with an expired test date. Program cost concentrates in three places: discovery scans across storage, deletion execution in systems that were not designed for it, and manual review in rights and withdrawal workflows. Partition alignment, per-system handlers, and confidence-scored identity resolution each convert recurring manual effort into engineering work that is paid once. Teams should expect the first rights-request exercise to be slow and manual, and should treat each repeated manual step as backlog for the next cycle.

A 90-day engineering sequence

Days 1 to 30 establish scope. Confirm the legal interpretation and phased dates, select the first business process, inventory personal data and purposes, map source, processing, sharing, and storage systems, and assign owners. Days 31 to 60 implement one complete path. Connect notice and purpose records, implement access and retention controls, build one withdrawal or rights-request workflow, and attach control evidence and exception handling. Days 61 to 90 test and extend. Run a request exercise, run a breach exercise, test deletion and downstream propagation, review access and service identities, record gaps, and prioritize the next process. One complete, evidenced path through one business process teaches the organization more than partial coverage of every process. The second process then proceeds faster because the registry, handlers, and evidence patterns already exist.

Lessons from delivery

Start with the process that hurts. A business process with an active complaint channel, a regulator-facing obligation, or a known data sprawl problem produces organizational attention that a quiet system never will. Counsel and engineering need a shared artifact. The purpose registry works because lawyers can read it and pipelines can query it. Programs that keep the legal record in documents and the technical record in code discover the gap during an audit. Every exercise should end with a dated control change. An exercise that produces only a report trains the organization to hold exercises.