Consent as Governance: Understanding DPDP’s Most Misread Obligation

The DPDP framework treats consent as a continuing legal relationship between the data principal and the data fiduciary.

Consent is usually the first word that appears in any data protection discussion and often the first concept businesses assume they already understand. Under India’s Digital Personal Data Protection Act, 2023 (DPDP Act), however, consent is intentionally designed to be more demanding than a checkbox, more consequential than a policy statement, and far more difficult to implement than most organisations expect.

The DPDP framework treats consent as a continuing legal relationship between the data principal and the data fiduciary. It is built on clarity, control, and accountability, not on convenience. Yet in many organisations, consent still lives almost entirely inside onboarding flows and privacy notices. That is where compliance risk begins — quietly, structurally, and often unnoticed until enforcement scrutiny arrives.

The Act permits processing of digital personal data only for a lawful purpose, most commonly on the basis of consent.¹ But the quality of consent matters. It must be free, specific, informed, unconditional, and unambiguous, expressed through a clear affirmative action.² These are not abstract standards. The Act itself illustrates their practical meaning. Where a telemedicine app seeks consent both to provide medical services and to access a user’s contact list, the latter consent is invalid if it is not necessary for the stated purpose.³ The takeaway for businesses is simple: Consent cannot be broader than necessity.

Equally important is what happens after consent is obtained. Under the DPDP Act, consent is not permanent. A data principal has the right to withdraw consent at any time, and withdrawal must be as easy as giving consent.⁴ The Act balances this right with operational realism. If a user places an order on an e-commerce platform and later withdraws consent, the platform may stop enabling future use but can continue processing data strictly to fulfil the already paid transaction.⁵ Consent withdrawal governs future processing; it does not undo completed obligations.

Where most organisations struggle is not at the moment of collection, but at the moment of withdrawal. Modern data environments are fragmented. Personal data flows across internal systems, shared platforms, backups, analytics tools, and external processors. The DPDP Act is clear that once consent is withdrawn, the data fiduciary must cease processing and erase personal data unless retention is required by another law.⁶ The law’s illustrations make this tangible. When a user sells a car through an online marketplace and the transaction is complete, the platform must no longer retain the user’s personal data.⁷ The purpose has ended. The data must exit active use.

At the same time, the Act recognises that erasure is not absolute. Where retention is required under another law such as banking or financial regulations, personal data may be retained for the mandated period.⁸ This reflects a practical compliance reality. DPDP does not require blind deletion, but it does require disciplined boundaries. Retained data cannot be repurposed simply because it still exists.

The Digital Personal Data Protection Rules, 2025 (DPDP Rules) reinforce this governance-centric approach. Consent notices must be clear and understandable, not buried in dense legal text.⁹ Withdrawal must be operationally feasible, not theoretically available. Where data is shared with processors, fiduciaries must ensure that erasure and cessation obligations extend downstream.¹⁰ These requirements expose a common gap: Organisations often have policies that say the right things, but systems that cannot execute them consistently. In practice, organisations that proactively test their consent workflows rather than relying on documentation alone are significantly better placed during regulatory review.

A further shift under DPDP is evidentiary. Where consent is the basis of processing and a dispute arises, the burden lies on the data fiduciary to prove that valid notice was given and lawful consent was obtained.¹¹ Consent is therefore no longer just permission it is proof. Businesses that cannot trace consent across systems, versions, and time-frames will find this difficult to defend.

Consent obligations under DPDP also sit alongside existing Indian laws. The Information Technology Act, 2000 continues to impose liability for failure to maintain reasonable security practices and for unlawful disclosure of personal data. Sector-specific regulations in banking, fintech, healthcare, and telecom may mandate retention or disclosures that coexist with DPDP obligations. Effective compliance lies in reconciling these regimes, not treating DPDP in isolation.

For leadership teams, the real implication of DPDP consent is cultural rather than textual. Compliance does not fail because a clause was missing. It fails when governance, technology, and accountability do not align. Organisations that embed consent into product design, data architecture, vendor management, and internal decision-making will be far better positioned as enforcement matures.

Ultimately, the DPDP framework redefines consent as a matter of governance rather than documentation. The law does not reward eloquent privacy policies; it tests whether consent can be operationalised, evidenced, and enforced across systems and decision-making layers. As regulatory scrutiny increases, the true measure of compliance will lie in an organisation’s ability to demonstrate discipline knowing precisely when data may be processed, when it must cease, and who is accountable at each stage. Consent, under DPDP, is therefore not about permission alone; it is about control exercised responsibly and provably over time.