Withdrawal of Consent Under DPDP
- Operationalize intake, identity checks, and closure—not just policy language.
- Keep records that show what the user saw and what you did.
- Route marketing suppression separately from account deletion when needed.
- Verify edge cases with counsel; public pages are informational.
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.
The useful question is not just “can a user withdraw consent?” but “what systems, teams, and vendors must change after that happens?”
What teams should operationalize
- One intake path for withdrawal requests
- Suppression across marketing and lifecycle tools
- Routing to owners of affected systems
- Update of downstream vendors/processors where relevant
- 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