Section 6: Consent

Quick summary

What Section 6 says

• Sub-section (1) — consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action, signifying agreement to processing limited to the personal data necessary for the specified purpose.
• Sub-section (2) — any part of a consent which itself constitutes an infringement of the Act, the rules, or any other law is invalid to the extent of that infringement.
• Sub-section (3) — every consent request must be presented in clear, plain language, with the option to access it in English or an Eighth Schedule language, and must provide contact details of a Data Protection Officer (where applicable) or another authorised person to respond to the Data Principal.
• Sub-section (4) — where consent is the basis of processing, the Data Principal has the right to withdraw it at any time, as easily as it was given.
• Sub-section (5) — the consequences of withdrawal are borne by the Data Principal, and withdrawal doesn't affect the legality of processing based on consent before the withdrawal.
• Sub-section (6) — if consent is withdrawn, the Data Fiduciary shall, within a reasonable time, cease (and cause its Data Processors to cease) processing, unless that processing without consent is otherwise required or authorised by law.
• Sub-section (7) — the Data Principal may give, manage, review or withdraw consent through a Consent Manager.
• Sub-section (8) — a Consent Manager is accountable to the Data Principal and shall act on her behalf in the prescribed manner.
• Sub-section (9) — every Consent Manager must be registered with the Board, subject to prescribed technical, operational, financial and other conditions.
• Sub-section (10) — where consent is the basis of processing and a question arises about it in a proceeding, the Data Fiduciary bears the burden of proving that notice was given and consent was obtained in accordance with the Act.

Breaking it down

• Free
• Specific
• Informed
• Unconditional
• Unambiguous

What “free, specific, informed, unconditional, unambiguous” actually rules out. The Act's own illustration makes the “specific” and “unconditional” requirements concrete: a telemedicine app asking for consent to process personal data for two purposes — providing telemedicine services, and accessing the phone's contact list — where the user only agrees to both together. Since the contact list isn't necessary for telemedicine, consent is limited to just the telemedicine purpose; bundling an unnecessary permission into a single yes/no doesn't make it validly consented to.

An invalid clause doesn't poison the whole consent. Sub-section (2)'s illustration: an insurance buyer consents both to processing for issuing the policy, and to waiving her right to complain to the Board. The policy-processing consent is valid; the complaint-waiver part is invalid, because it itself infringes the Act — but only that part falls away.

Withdrawal is symmetric with giving consent. Sub-section (4)'s “as easily as it was given” standard means a consent flow that takes one tap to accept but requires a phone call or written request to withdraw likely fails this test.

Withdrawal isn't retroactive, but it is forward-looking and consequential. Sub-section (5)'s e-commerce illustration: withdrawing consent doesn't undo the legality of an order already placed and paid for, but going forward the Fiduciary can stop letting that user place new orders through the app if continued use depended on that consent. Sub-section (6)'s telecom illustration goes further: a customer who withdraws consent for a Data Processor to email their bills forces the Data Fiduciary itself to stop, and to cause the Processor to stop, sending data for that purpose — not just adjust one channel.

Consent Managers are a specific registered role, not just a UI pattern. Sub-sections (7)–(9) create a distinct, Board-registered intermediary a Data Principal can use to manage consent across multiple Fiduciaries from one place — this is the framework that becomes operational under the DPDP Rules' 13 November 2026 date, tracked separately from the rest of this section's core consent-validity requirements, which take effect 13 May 2027 alongside the rest of Chapter II. See Rule 4 for the registration mechanics.

The burden of proof sits with the Fiduciary, not the individual. Sub-section (10) means that if it's ever disputed whether valid notice and consent were obtained, it's the Data Fiduciary's job to prove it happened — not the Data Principal's job to prove it didn't.

Why this section matters

Consent is the backbone lawful basis under the Act, and Section 6 is what stops “consent” from becoming a rubber stamp. The specificity requirement blocks bundled, take-it-or-leave-it permissions; the symmetric-withdrawal requirement blocks dark patterns that make opting out harder than opting in; and the reversed burden of proof means Fiduciaries need to actually keep records of what was consented to and when, because they're the ones who'll have to prove it.

Real-world example

Who needs to care about this section

• UX and product teams designing consent screens — bundled, pre-ticked, or hard-to-withdraw consent flows are the most common way this section gets violated in practice.
• Compliance teams building audit trails — sub-section (10)'s reversed burden of proof means consent records need to be retained and retrievable, not just collected and forgotten.
• Organisations planning to integrate with Consent Managers — sub-sections (7)–(9) are the legal basis for that role; see Rule 4 for how registration actually works.

Common questions

Related sections