Consent under DPDP section 6

The elements of valid consent

Consent under s.6 must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. It must also be limited to the personal data necessary for the specified purpose.

The right-hand column gives design patterns, not statutory text. Check edge cases with counsel.

A notice comes with every request (s.5, Rule 3)

Every request for consent must come with a notice (s.5). Under Rule 3, the notice must be understandable on its own, in clear and plain language, and give an itemised description of the personal data and the specified purposes, with the goods, services or uses that the processing enables.

It must also give the means, with a link, to withdraw consent, exercise rights under the Act and complain to the Board. The Data Principal must be able to read it in English or any of the 22 Eighth Schedule languages (s.5(3)). For data collected before commencement, give a notice as soon as reasonably practicable (s.5(2)).

Our consent notice guide shows a worked structure.

Withdrawal and what follows (s.6(4), s.6(6))

• A Data Principal can withdraw consent at any time, as easily as it was given (s.6(4)). Rule 3 asks that withdrawing be comparably as easy as giving consent.
• After withdrawal, the fiduciary must stop processing, and make its processors stop, within a reasonable time (s.6(6)).
• It must then erase the personal data, and make its processors erase it, unless a law requires retention (s.8(7)).

Consent Managers are an option (s.6(7) to s.6(9))

A Data Principal may give, manage, review or withdraw consent through a Consent Manager (s.6(7)). This is a choice for the individual: consenting directly to the Data Fiduciary remains possible.

A Consent Manager is accountable to the Data Principal (s.6(8)) and must be registered with the Board (s.6(9)). Registration under Rule 4 starts on 13 November 2026; see Consent Managers.

Proving consent (s.6(10))

Where consent is the basis for processing, the Data Fiduciary must be able to prove that it gave notice and obtained consent (s.6(10)). The record matters as much as the banner. For each consent, keep:

• who gave it, under a masked identifier (for example DPR-1042, a sample);
• the purpose and the version of the notice shown;
• the action taken and when;
• every later change: withdrawal, rejection or update.

A pre-launch consent check

• Does each purpose have its own request, with the notice shown alongside (s.5, s.6)?
• Is saying no as easy and as visible as saying yes?
• Can a person withdraw in as few steps as it took to agree (s.6(4), Rule 3)?
• Do withdrawals reach every system and processor that uses the data (s.6(6))?
• Can you pull the full consent history for any person on request (s.6(10))?

How TruePrivacy helps

Consent management in TruePrivacy keeps purposes, a consent record per person and purpose, and an event log of every grant, withdrawal, rejection and update, with consent receipts and a preference page. TruePrivacy requires a reject-all option on DPDP banners.

The web consent banner ships interface text in English and all 22 Eighth Schedule languages, and there are SDKs for iOS, Android and React Native. You write and review your own notice text in notices, and run the consent checklist before launch.