Section 6 of the DPDP Act — how to actually implement "withdraw as easy as give"

Section 6(4) of the DPDP Act 2023 is short and unforgiving: a Data Principal can withdraw consent at any time, and "the ease of doing so shall be comparable to the ease with which such consent was given". One sentence kills most cookie-banner architectures built before 2024.

If you collect consent in one click on a banner, you have to honour withdrawal in one click too — not a five-step form, not an email to grievance@, not a CAPTCHA-gated portal. The Rules explicitly call out "dark patterns" that make withdrawal disproportionately harder; the Data Protection Board has already signalled that asymmetry between Accept and Withdraw will be treated as a Section 6 violation.

The pattern that works: a persistent "Manage cookies" or "Manage consent" link in the footer of every page, plus the banner that re-opens on click and lets the user toggle each purpose. State lives in localStorage and is emitted as a CustomEvent so your analytics SDKs can listen and stop firing. On the backend, every withdrawal becomes an immutable row in your consent log with email/UA/ts — that record is your Section 8 evidence if the Board ever audits.

Don't forget the downstream chain. Withdrawal isn't just stopping new collection — it propagates to your processors. If you sent the user's email to Mailchimp, Salesforce, or Meta CAPI, you need a vendor-side delete or suppression call within a reasonable window. The Rules don't fix that window in days, but the safest reading is 30 days. Build the propagation pipeline now and document it; a documented imperfect pipeline beats a perfect undocumented one.

The checkDPDP banner builder handles the UX side — re-openable preference centre, per-category toggles, localStorage state, audit-event emission — for free. You still own the processor-side propagation; that's the part nobody can automate for you.