The five duties after the banner: where DPDP compliance actually fails
Collecting consent is the step every tool covers. The DPDP Act adds four more - prove it, act on withdrawals, erase on time, answer requests - and that is where the risk sits.
By Promiz · Published · 6 min read · Based on the DPDP Act, 2023 and DPDP Rules, 2025 · Not legal advice
Why is collecting consent the easy part?
A cookie banner or a consent checkbox is a one-time interaction. The DPDP Act treats it as the start of a relationship: the Data Fiduciary must be able to show what was agreed, stop when the person changes their mind, delete when the purpose ends, and answer the person when they ask. Section 6 covers the consent; Sections 6(4), 6(6), 8(7) and 11–14 cover what happens afterwards.
Most consent tools stop at the banner. They record a click and hand the rest to spreadsheets and email. The four duties that follow are the ones the Data Protection Board will ask about, because they are the ones that leave a trail - or fail to.
What does “prove it” require?
Section 5 and Rule 3 require an itemised notice before processing; Section 6 requires free, specific consent per purpose. Proving either later means keeping the notice version, the language it was shown in, the exact choices made and when. A record that can be edited afterwards proves nothing, which is why a chained, append-only record matters more than a nicely designed banner.
The practical test: for any consent given last year, can you produce the screen the person saw, in the language they saw it, with the version number? If the answer involves a developer and a database query, the proof does not yet exist.
Why do withdrawals fail silently?
Section 6(4) makes withdrawal as easy as consent; Section 6(6) requires processing to stop once it is withdrawn. The failure is rarely the withdrawal button. It is the CRM, the ad platform and the collections partner that never hear about it. Each keeps processing because nobody told it to stop, and nobody can show that anyone confirmed.
The control is a stop-processing task with a deadline, opened per withdrawal, delivered to every downstream system as a signed event, and closed only when that system confirms. An unconfirmed task is a visible overdue item, not an unread email.
Why is erasure a clock, not a policy?
Section 8(7) and Rule 8 require personal data to be erased once its purpose is served. A retention policy in a PDF states an intention; it does not count down, and it cannot show when deletion happened. Some purposes - RBI record-keeping, a live dispute - must not be erased on schedule, so the clock also needs legal holds.
The record that satisfies the Board is per-purpose: a retention period, a notice sent before erasure, a hold where the law requires one, and a confirmation from the system that actually deleted the data.
What do rights requests need?
Sections 11–14 and Rule 14 give the Data Principal access, correction, erasure, grievance and nomination. Each request needs a published route in, a deadline, a reply and a log. A shared inbox provides the route and nothing else.
One queue with a clock on every request, reminders before it is due, and a logged reply to the person is the minimum that survives an audit. It is also the part that customers notice first.