Withdrawal of Consent Under DPDP

Audience: founders, ops, product, marketing · Last reviewed: March 2026

See also: Compliance portal · Official resources · Guides index

Withdrawal of consent is where nice-looking collection flows meet messy operational reality. Teams need a process for suppression, routing, vendor propagation, and proof that action was taken.

What the Act actually requires

Section 6(4) gives the Data Principal the right to withdraw consent at any time, with the ease of withdrawal comparable to the ease of giving it — a harder-to-use withdrawal flow than the consent flow is itself a problem. Section 6(6) then requires the Data Fiduciary (and its processors) to cease processing within a reasonable time — the Act does not set a fixed number of days. Withdrawal does not undo the legality of processing that already happened before it (Section 6(5)), and the Data Principal bears the consequences of withdrawing, such as losing access to a service that depends on that processing.

What teams should operationalize

1. One intake path for withdrawal requests
2. Suppression across marketing and lifecycle tools
3. Routing to owners of affected systems
4. Update of downstream vendors/processors where relevant
5. A simple log showing request, action, and closure

Common failure points

• Email suppression happens but CRM/analytics copies remain active
• Support teams do not know where to send the request
• No evidence is kept showing what changed and when