India’s DPDPA raises the bar for consent, rights, and governance

At a glance

What this is: India’s DPDPA creates a consent-centric privacy regime with rights, security, transfer, and governance obligations that only work when operational controls are connected.

Why it matters: Privacy, IAM, and governance teams need to treat consent records, rights workflows, and data visibility as integrated control planes rather than separate compliance tasks.

Context

The core governance problem is not whether organisations have a privacy policy, but whether they can prove that consent, notices, rights handling, retention, and transfer decisions are aligned across systems. The DPDPA raises that bar because the law ties legal obligations to operational evidence, which means privacy compliance now depends on data inventory quality, workflow design, and accountability.

For identity and access programmes, the DPDPA matters because rights requests, consent withdrawal, and data minimisation all depend on knowing who can access personal data, where it moves, and which systems propagate it. That makes privacy governance a practical control issue, not just a legal one, especially where personal data flows into analytics and AI-enabled processes.

Key questions

Q: What breaks when consent data is inconsistent across systems?

A: Customer experiences fragment, privacy requests become harder to honour, and marketing teams lose confidence that they are acting within approved use. The practical failure is not only regulatory exposure. It is operational inconsistency, where one system treats a choice as valid and another ignores it.

Q: Why does the DPDPA make data mapping a privacy requirement?

A: Because access, correction, erasure, and transfer decisions all depend on knowing where personal data lives and how it moves. Without data mapping, teams cannot reliably fulfil rights requests, stop processing where required, or prove that notices and consent terms match actual data use.

Q: What are the signs that rights fulfilment is failing under the DPDPA?

A: Common warning signs include repeated manual lookups, inconsistent responses across business units, late erasure completions, and requests that stop at the first system while replicas, backups, or processors remain untouched. Those symptoms show the workflow is not connected to the full data estate.

Q: How should privacy teams align DPDPA controls with identity governance?

A: They should treat identity assurance, role separation, and audit trails as prerequisites for rights handling and accountability. When employees, customers, guardians, or consent managers can act on behalf of a person, the organisation needs clear identity proofing, authorisation, and evidence of who did what.

Technical breakdown

Consent management becomes a control surface, not a form field

The DPDPA treats consent as a governed lifecycle rather than a one-time capture event. Organisations need consent that is free, specific, informed, unconditional, and tied to clear affirmative action, and they must make withdrawal as easy as grant. That means consent data must remain synchronised with processing systems, downstream processors, and preference stores. If a business unit continues processing after withdrawal, the failure is not only legal but architectural: the control state and the processing state have drifted apart.

Practical implication: Build consent state as an authoritative record that can trigger downstream processing stops and processor updates.

Rights fulfilment depends on data mapping and workflow orchestration

Access, correction, erasure, grievance redressal, and nomination rights only work when an organisation can locate personal data quickly and consistently. The technical challenge is less about the request form than the joins between source systems, backups, third parties, and data consumers. If records are duplicated, loosely governed, or embedded in AI training and analytics pipelines, a rights request becomes a discovery problem. Operational readiness here is a data lineage and workflow issue as much as a privacy one.

Practical implication: Map personal data flows end to end so rights requests can reach all systems that hold or use the data.

Cross-border transfer controls need policy logic, not static legal text

The DPDPA uses a restriction-based transfer model, which shifts the technical burden to policy enforcement and monitoring. Organisations need to know where personal data goes, which jurisdictions are in scope, and which flows may need to stop if the Central Government later restricts a destination. That makes transfer governance an ongoing control process, not a one-off legal assessment. The same discipline also supports vendor oversight, because processor relationships can create hidden cross-border paths.

Practical implication: Maintain live inventories of international data flows and tie them to policy controls that can react to new restrictions.

NHI Mgmt Group analysis

Consent governance is becoming a control-plane problem. The DPDPA does not just ask whether consent exists, it asks whether consent can be proven, withdrawn, and enforced across the processing estate. That pushes privacy teams toward event-driven governance, where consent status must change system behaviour instead of sitting in a legal archive. For practitioners, the lesson is that consent lifecycle control now belongs in operational architecture, not only in policy.

India’s privacy model widens the overlap between identity governance and data governance. Rights requests, grievance handling, and nomination workflows depend on reliable identity proofing, access traceability, and role separation. That creates a real governance bridge between IAM and privacy operations, especially where employees, customers, and guardians can act on behalf of data principals. Practitioners should treat identity assurance and rights fulfilment as linked controls.

Data lineage is the hidden compliance dependency. The DPDPA’s obligations around access, erasure, transparency, and transfer controls all fail when organisations cannot trace where personal data resides and how it propagates. Privacy lineage gap: this is the specific failure mode the law exposes, where organisations know their policy but not their data path. Practitioners should treat lineage quality as a compliance control, not a data project.

The DPDPA will increasingly shape AI governance through personal data controls. The law does not regulate AI systems directly, but it constrains the data those systems depend on through consent, accuracy, and security obligations. That means AI governance programmes cannot operate separately from privacy operations when personal data is used in training, analytics, or decisioning. Practitioners should align privacy controls with AI data usage reviews.

Government rulemaking creates a moving governance target. The Act’s implementation depends heavily on future rules and notifications, which means static compliance checklists will age quickly. Organisations need governance structures that can absorb regulatory change without reworking every workflow from scratch. Practitioners should build for change tolerance, not one-time certification.

From our research library:

• Only 37% of organisations had policies for managing AI or detecting shadow AI, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: IGA Buyer's Guide

What this signals

India’s privacy programmes will increasingly be judged by operational proof, not policy language. The DPDPA’s consent, rights, and transfer rules only matter if organisations can demonstrate that systems behave consistently when consent changes or rights requests arrive. That moves privacy maturity toward evidence, lineage, and workflow control rather than document collection.

Privacy and IAM teams now share more of the same failure modes. When identity proofing, role separation, or access logging are weak, rights handling becomes slow or unreliable and accountability is hard to prove. Organisations that treat privacy as a standalone legal function will struggle to operationalise the DPDPA at scale.

Policy debt will outpace implementation debt unless governance is designed for change. Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. The same gap appears in privacy programmes when rulemaking changes faster than control design; practitioners need governance that can absorb new obligations without rewriting every workflow.

For practitioners

• Map personal data to control points Inventory where digital personal data is collected, stored, transformed, shared, and deleted so each processing step has an accountable owner and an evidence trail.
• Make consent withdrawal operational Connect consent records to processing systems so withdrawal triggers downstream suppression, processor notification, and review of any lawful basis exception.
• Orchestrate rights requests across systems Design access, correction, and erasure workflows that reach production systems, archives, analytics platforms, and third-party processors without manual rekeying.
• Track cross-border data flows continuously Maintain a live register of international transfers and link it to vendor contracts, routing rules, and jurisdictional restrictions that can change through government notification.
• Separate privacy evidence from policy text Preserve notices, consent logs, grievance records, and decision histories so the organisation can demonstrate compliance when challenged by regulators or individuals.

Key takeaways

• The DPDPA turns consent, rights handling, transfer oversight, and breach response into linked operational controls rather than separate compliance tasks.
• The biggest failure mode is not missing legal language but weak lineage and workflow execution across the systems that store or process personal data.
• Organisations that cannot prove consent state, fulfil rights end to end, or track transfers continuously will struggle to satisfy both regulators and data principals.

Key terms

• Consent Management: The process of showing a user what an agent is allowed to do, for how long, and against which systems. In MCP environments, consent is not just a legal formality. It is a control that limits delegated access and creates accountability for agent actions.
• Data Fiduciary: The organisation or person that decides why and how personal data is processed under the DPDPA. The concept is central because it carries accountability for lawful purpose, consent, rights handling, security safeguards, and downstream governance across processors and partners.
• Significant Data Fiduciary: A data fiduciary designated for enhanced obligations because of the volume or sensitivity of data it processes. The label matters because it brings stronger governance expectations, including formal accountability structures and potential future requirements tied to risk and scale.
• Data Principal rights workflow: A Data Principal rights workflow is the end-to-end process for access, correction, erasure, or withdrawal requests across all systems holding a person’s data. It is not complete until the enterprise can coordinate changes in the primary identity store and every downstream repository with consistent results.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle control, and the access patterns that underpin accountable data handling. It is designed for practitioners who need to connect identity governance to broader security and compliance programmes.