Consent Under DPDP

What consent means under DPDP

Under Section 4, personal data may be processed for a lawful purpose for which the Data Principal has given consent, or for certain legitimate uses listed in Section 7. Consent is therefore a primary processing ground — but not the only one. Organizations must assess which basis applies to each processing activity rather than assuming consent is always required.

Section 6 sets the qualities of consent. It must be free, specific, informed, unconditional and unambiguous, and given by a clear affirmative action that signifies agreement to process personal data for the specified purpose. Bundling unrelated purposes into a single “accept all” choice, or relying on silence, pre-ticked boxes or forced consent, sits poorly against those qualities.

Every request for consent under Section 6 must be accompanied or preceded by a notice under Section 5. That notice informs the Data Principal about the personal data and purpose, how rights may be exercised, and how a complaint may be made to the Board.Rule 3 elaborates how consent notices must be presentedonce the relevant Rules commence. Consent without adequate notice is incomplete as a compliance design.

Section 6 also provides that consent may be withdrawn. Withdrawal must be as easy as giving consent. Withdrawal does not affect the legality of processing carried out before withdrawal. After withdrawal, the Data Fiduciary must cease processing within a reasonable time unless another ground under the Act continues to apply.

What it means in practice

In operations, consent is a lifecycle — not a single UI event. Teams need clear purpose catalogues, notice versions, capture channels, records that show context (who, what purpose, when, which notice), and pathways to withdraw or update preferences. Downstream systems that process personal data must be able to honour those decisions.

A practical consent lifecycle:

1. Provide notice (Section 5; Rule 3)
2. Define and present the specified purpose
3. Capture clear affirmative consent
4. Record the decision with enough context for accountability
5. Process only for the consented purpose (or another applicable basis)
6. Support withdrawal or updates with comparable ease
7. Retain audit evidence and align retention or erasure to purpose

Where processing rests on a Section 7 legitimate use instead of consent, document that assessment separately. Do not retrofit a consent artefact onto processing that never relied on consent — and do not skip notice or consent where consent is the applicable basis.

Cross-channel consistency matters. Consent obtained on a website, mobile app, branch form or call centre still needs to meet the Act’s qualities where it applies. Non-digital capture is an operational design choice; it is not a separate statutory category that relaxes Section 6.

Common mistakes

• Treating consent as a one-time checkbox without purpose specificity or a withdrawal path.
• Assuming every processing activity needs consent, and ignoring Section 7 legitimate uses.
• Keeping “accepted” flags without notice version, purpose, channel or timestamp for later review.
• Confusing a product marketed as a “consent manager” with a statutory Consent Manager registered under Section 6(9) — seeConsent Manager under DPDP.