DPDP consent notices: what product teams need to ship

Start with the notice, not the checkbox

Section 5 and Rule 3 require the individual to receive a clear account of the personal data and the specified purpose before consent is requested. Product teams should translate the legal purpose into language a user can understand without opening a separate policy.

The notice should stand on its own. Linking to a long privacy policy may provide additional context, but it should not carry the information the consent screen itself is required to communicate.

• Itemise the personal data or meaningful categories involved.
• Describe each purpose specifically enough to distinguish it from another use.
• Explain withdrawal, rights, grievance handling and access to the Board.

Treat each purpose as a system decision

Consent under section 6 must be free, specific, informed, unconditional and unambiguous. A bundled decision creates operational ambiguity: when a person withdraws one purpose, the system cannot reliably determine which processing must stop.

Maintain a purpose identifier that connects the wording shown to the individual with the systems, processors and retention rule activated by that choice.

• Version the exact notice and consent language.
• Record the affirmative action, timestamp and purpose identifier.
• Test partial withdrawal and re-consent as first-class scenarios.

Design withdrawal before launch

Withdrawal must be as easy as giving consent. That requires more than a preference screen: processing based on the withdrawn consent must cease, processors must receive the change, and erasure must occur unless another law requires retention.

A launch checklist should therefore include negative-path testing. Confirm what happens when the user has multiple accounts, a processor is temporarily unavailable, or a lawful retention override applies.