What must happen when a person withdraws consent under the DPDP Act? Under Section 6 of the DPDP Act, withdrawing consent must be as easy as giving it — you cannot make withdrawal harder, slower or more buried than the sign-up was. When a data principal withdraws consent, you must stop the processing that relied on that consent, and you must ensure your processors do the same for the data you passed to them. Consent withdrawal in DPDP India is not just an unsubscribe link: it means providing an equally-easy withdrawal mechanism, stopping the specific processing (which may be one purpose, not the whole relationship), propagating the withdrawal to every downstream processor, and dealing cleanly with the data already collected before withdrawal — while noting that withdrawal does not affect the lawfulness of processing that already happened. This kit gives you the withdrawal mechanism design, the confirmation and processing-stopped letters, the processor propagation notice and the internal SOP.
Section 6 requires withdrawing consent to be as easy as giving it. A complete kit to build the mechanism, stop the right processing, and propagate withdrawal to every downstream processor.
Section 6 of the DPDP Act sets a design constraint most organisations fail on the first pass: a data principal must be able to withdraw consent as easily as they gave it. If consent was a single tap at sign-up, withdrawal cannot require a phone call, a support ticket, a login through three menus, or an email to an address nobody answers. The practical test is symmetry — put the sign-up flow and the withdrawal flow side by side, and the withdrawal cannot be meaningfully harder. This rules out the common dark patterns: withdrawal buried in settings, a withdrawal option that is technically present but deliberately obscure, or a 'contact us to opt out' that adds friction the sign-up never had.
Symmetry does not mean identical placement, but it does mean comparable effort and prominence. If you obtained consent through an in-app prompt, the withdrawal control should be reachable from a sensible, findable place in the app — not exiled to a legal page. If consent was granular (separate purposes), withdrawal should be granular too, so a person can withdraw marketing consent without being forced to delete their whole account. Designing this correctly up front is far cheaper than retrofitting it after a complaint, and it is one of the clearest, most testable DPDP obligations the Data Protection Board can check simply by using your product.
When a withdrawal comes in, a defined sequence keeps you compliant. First, identify precisely what is being withdrawn — the whole consent, or one purpose (marketing but not the account, analytics but not the core service). Treating every withdrawal as a full account closure is a common and damaging over-reaction; treating a full withdrawal as a mere marketing opt-out is the opposite failure. Second, stop the processing that relied on that consent, promptly. Third, propagate the withdrawal to every processor and third party you passed the data to, so they stop too — your obligation does not end at your own systems. Fourth, confirm back to the person what has stopped. Fifth, deal with the data already collected under the now-withdrawn consent, and log the whole thing.
Two points the SOP makes explicit save teams from mistakes. Withdrawal is forward-looking: it does not make past processing unlawful (the processing that happened while consent was valid remains lawful), so you do not owe the person an apology or a reversal for legitimate prior use — you owe them a stop going forward. And withdrawal of consent for one purpose is not automatically a request to erase the data; if the person also wants deletion, that is a separate erasure request. Keeping these distinct is what prevents a withdrawal from being mishandled as either too little (ignoring downstream processors) or too much (deleting data the person did not ask you to delete).
Consent-based purposes to wire into withdrawal:
Consent withdrawal in DPDP India is often treated as a policy statement — 'you may withdraw consent at any time' buried in a privacy notice — when Section 6 of the DPDP Act actually makes it a product-design obligation: withdrawing consent must be as easy as giving it. That symmetry requirement is unusually concrete and testable. A regulator, a journalist or a data principal can simply try to withdraw and see how hard you made it. If sign-up was one tap and withdrawal takes a support email and a three-day wait, you are not compliant, regardless of what the policy says. This is why the most common gap is not a missing clause but a missing, or deliberately obscure, withdrawal control in the actual product.
The design also has to respect granularity. Where you collected consent for distinct purposes — marketing, analytics, third-party sharing — the person should be able to withdraw one without withdrawing all, and certainly without being forced to delete their account to escape a single mailing list. Building a granular, equally-prominent withdrawal mechanism is both the compliant answer and the one that keeps customers, because it lets people dial down rather than leave entirely.
The part organisations underestimate is what happens after the click. A compliant withdrawal must stop the specific processing that relied on the consent, propagate to every processor and third party you shared the data with so they stop too, and cleanly handle the data already collected. Withdrawal is forward-looking — it does not make past processing unlawful — but the data you hold may now lack a basis to keep for that purpose, which is a decision to make deliberately rather than by default. And withdrawal is not the same as erasure: unless the person also asks for deletion, you are stopping future processing, not necessarily wiping the record.
Getting all of this to happen reliably, every time, across your own systems and your processors, is a small operational process rather than a single feature. Niti Bharat's fixed-price DPDP compliance engagements (₹75,000–₹3.2 lakh) wire consent capture and withdrawal into a working end-to-end consent lifecycle — including processor propagation and audit logging; this kit gives your team the SOP, mechanism specs and letters to honour Section 6 correctly from today.
One real DPDP development explained in plain English, one practical how-to, one number from our own assessment data. Nothing else — no daily noise, no sales pitch.
No spam. Unsubscribe with one click, anytime.
