Most CMPs stop at the consent banner. The DPDPA does not — withdrawal, expiry and deletion all have to keep working long after the tick box is clicked.
June 2026 · 7 min read
Ask most mid-size Indian enterprises about their consent compliance and they will show you a consent banner, maybe a cookie pop-up alongside it. Very few can show you what actually happens six months after a Data Principal clicks "I agree."
That gap — between consent that was collected and consent that is actually managed — is where a lot of DPDPA compliance programmes quietly come apart.
Collection is the front door: a notice gets shown, a tick gets recorded, a timestamp gets generated. That part is necessary. It is not sufficient on its own.
Most implementations never get past this stage. They can confirm that consent was captured at a specific moment on a specific date. What they usually cannot confirm is whether that consent is still valid, whether processing actually stopped after someone withdrew it, or whether that person's data was deleted once the underlying purpose expired. The DPDPA does not stop at collection, so a platform that does is only covering part of the obligation.
Section 6(1): consent has to be free, specific, informed, unconditional and unambiguous, with a clear, equally easy option to refuse.
Section 6(4): a Data Principal can withdraw consent at any time, withdrawal has to be at least as easy as giving it was, and it has to actually stop processing — not just get logged as a request.
Section 8(7): a Data Fiduciary has to erase personal data once its purpose has been fulfilled, or once consent is withdrawn, whichever happens first.
Section 7: even where Legitimate Interest is the basis being relied on, the Data Principal still has to be able to opt out, and that opt-out has to propagate downstream, not just sit in a preferences record.
Every one of these is a lifecycle obligation. They describe ongoing system behaviour, not a single database write at the moment of collection.
A notice plus an affirmative action — purpose-specific, per recipient, with a separate opt-in for each distinct processing activity. This is where most organisations currently stop.
Tracking exactly which version of a notice was shown when a given consent was given. If the notice changes — a new purpose added, a description reworded — existing consent may need refreshing, and the platform has to catch that automatically and trigger a re-consent campaign rather than leaving it to someone to notice.
Consent periods need a configurable duration, and once one expires, processing under that purpose has to stop. That requires proactively notifying the Data Principal before expiry, and an automated path to either delete or archive the data once it does.
This is the hardest phase to get right. Withdrawal is not a log entry, it is a control that has to actually fire — the signal needs to reach every connected system, every third-party processor, every marketing platform, every analytics tool that was processing data under that consent. Every one of them has to stop, and the platform needs to be able to prove that it happened, not just assert it.
Section 8(7) requires erasure once a purpose is fulfilled or consent is withdrawn. A deletion-validation workflow has to track and evidence this across every system that held the data — not just the primary database it was originally captured into.
Not all consent behaves the same way. A single-transaction consent — order fulfilment, identity verification — has a natural end point: it expires once the purpose is fulfilled, and deletion validation follows. A recurring consent — ongoing marketing, personalisation, loyalty analytics — needs active, continuous management, because withdrawal has to stop every downstream process it feeds. Legitimate Interest sits in its own category again: for things like fraud detection or statutory obligations, the Data Principal still needs an opt-out, and that opt-out still has to propagate.
If a Data Principal withdraws consent for marketing today, can you show me — six months from now — that processing actually stopped across every connected system and vendor, and that their data was deleted where required? And can you produce that evidence in a form the Data Protection Board would accept?
If the answer comes back hesitant, what you have is a collection tool, not a management platform — and under the DPDPA, that distinction is exactly where the exposure sits.
If you're not certain your current platform covers the full lifecycle rather than just the banner, our CMP evaluation service checks it against exactly this gap.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation