DPDP consent requirements: what section 6 actually demands

Consent is 1 of only 2 lawful grounds for processing personal data under the Digital Personal Data Protection Act, 2023, and section 6 is where the Act says what consent has to look like. It runs to 10 sub sections, carries 4 illustrations, and places the burden of proving valid consent on the Data Fiduciary rather than on the person who clicked. None of it is in force yet, which is the most useful planning fact on this page and the one most vendor decks leave out.

The 10 sub sections, and when each starts

The split is not an editorial choice. Commencement notification G.S.R. 843(E) names "sub-sections (1) to (8) and (10) of section 6" in the group due 18 months after publication, and "sub-section (9) of section 6" in the group due at 1 year. Computed from the publication date printed on Gazette issue No. 757, the 1 year group falls on 13 November 2026 and the 18 month group on 13 May 2027. Both calendar dates are interpretation until officially confirmed: the notification states a period rather than a date, it does not state how that period is counted, and the eGazette record of this same issue carries 14 November 2025 in its file code, which would move both by 1 day. The 1 day discrepancy is set out separately.

Read practically: the machinery that lets a Consent Manager register with the Board switches on roughly 6 months before the consent rules those managers exist to serve. Both halves of that machinery move together, because Rule 4, which carries the registration procedure, sits in the 1 year group of Rule 1(3) just as section 6(9) sits in the 1 year group of the Act notification.

5 qualities plus an action

"The consent given by the Data Principal shall be free, specific, informed, unconditional and unambiguous with a clear affirmative action, and shall signify an agreement to the processing of her personal data for the specified purpose and be limited to such personal data as is necessary for such specified purpose."

5 adjectives, 1 required action and 1 limit. The adjectives are not defined anywhere in the Act, and the Act carries no recitals to lean on, so the honest position today is that their edges are unmapped until the Board or a court draws them. What is not ambiguous is the structure: the burden of showing the words were satisfied is yours, so a design that cannot evidence them is a design that fails.

2 readings follow that this site treats as interpretation rather than as printed law. A pre ticked box, or continued use of a site, is hard to reconcile with "a clear affirmative action", because in neither case is there an act directed at the request. And a consent bundled so that the service is unavailable unless the person also agrees to unrelated processing sits badly with "free" and "unconditional". Neither pre ticked boxes nor bundling is named in the Act.

The consent is capped by what the purpose needs

The final limb of section 6(1) does more work than the adjectives. Consent is "limited to such personal data as is necessary for such specified purpose", and specified purpose is a defined term meaning the purpose mentioned in the notice. Ask for more than the purpose needs and the surplus is not consented to, however clearly the person clicked.

The Act illustrates it rather than leaving it abstract. An individual downloads a telemedicine app and consents both to processing for telemedicine services and to access to her mobile phone contact list. Because the contact list is not necessary for telemedicine, her consent is limited to the processing for telemedicine services. The extra permission does not become valid because it was clearly presented and freely given.

Invalid parts fall away, the rest stands

"Any part of consent referred in sub-section (1) which constitutes an infringement of the provisions of this Act or the rules made thereunder or any other law for the time being in force shall be invalid to the extent of such infringement."

This is a severance rule, not a nullity rule, and the distinction matters when you are reviewing a consent screen. The Act's illustration is an insurance customer who consents both to processing for issuing her policy and to waiving her right to complain to the Board. The waiver is invalid. The consent to processing for the policy is untouched. So a single defective clause does not take down the consent you actually rely on. The Act stops at invalidity: it does not, in terms, require you to remove the defective wording. Taking it off a live consent screen anyway is a recommendation of this site, because the clause gives you nothing and misdescribes the position to the person reading it.

The request has requirements of its own

Section 6(3) attaches duties to the consent request as an artefact, separate from the notice that must accompany or precede it. The request must be presented in clear and plain language, must give the individual the option to access it in English or any language specified in the Eighth Schedule to the Constitution, and must carry the contact details of a Data Protection Officer where applicable or of another person authorised to respond about rights. The same language option appears for the notice in section 5(3), so the translation capability you build is used twice.

The notice is the other half of the pair. Section 5(1) requires that "Every request made to a Data Principal under section 6 for consent shall be accompanied or preceded by a notice", and Rule 3 sets out what that notice contains: presentation understandable independently of anything else, an itemised description of the personal data, the specified purpose with a specific description of the goods, services or uses enabled, and the communication link for withdrawing consent, exercising rights and complaining to the Board. Check a notice against Rule 3 element by element rather than against a template written for a different jurisdiction, and see what a DPDP notice must contain under section 5 and Rule 3 for the full pair.

Withdrawal is a build requirement

"Where consent given by the Data Principal is the basis of processing of personal data, such Data Principal shall have the right to withdraw her consent at any time, with the ease of doing so being comparable to the ease with which such consent was given."

Comparable ease is the operative test, and it is a product constraint rather than a policy sentence. On this site's reading, consent taken with 1 tap in an app is hard to square with a withdrawal route that runs only through a written request to a postal address, though the Act names no such example and no Board or court has yet applied the test. Rule 3(c) reinforces it from the other side by requiring the notice itself to carry the link through which withdrawal happens.

What follows a withdrawal is a sequence, not a single event:

• Processing already done stays lawful. Section 6(5) says withdrawal "shall not affect the legality of processing of the personal data based on consent before its withdrawal", and its illustration lets an ecommerce operator finish supplying goods already ordered and paid for while it stops enabling new orders.
• Consequences of the withdrawal fall on the individual. Losing access to the feature the consent enabled is her cost, and the Act does not ask you to soften it.
• You cease, and you make your Data Processors cease, within a reasonable time, unless the processing without consent is required or authorised by law. The Act's illustration is a telecom provider that must itself stop, and cause its emailing vendor to stop, processing a customer's data for emailed bills once she chooses in app delivery.
• Erasure follows separately. Section 8(7)(a) requires erasure on withdrawal or when the specified purpose is no longer being served, whichever is earlier, unless retention is necessary for compliance with any law. The Act's own example of lawful retention is a bank keeping client identity records for 10 years after an account closes.

What happens when consent is withdrawn under the DPDP Act, drawn as 4 steps rather than 1. Step 1, section 6(4): she withdraws at any time, with ease comparable to the ease with which consent was given, and Rule 3(c) puts the link in the notice itself. Step 2, section 6(5): the past stays lawful, because withdrawal does not affect the legality of processing done before it, and its consequences are borne by the Data Principal. Step 3, section 6(6): you cease and cause your Data Processors to cease within a reasonable time, unless processing without consent is required by law. Step 4, section 8(7): erasure, unless retention is necessary for compliance with any law in force. Section 6 is not in force: sub sections (1) to (8) and (10) fall in the 18 month group computed at 13 May 2027 and sub section (9) in the 1 year group computed at 13 November 2026, both interpretation until officially confirmed.

A drafting detail worth knowing if you read the Gazette yourself: section 6(6) describes the trigger as a withdrawal "under sub-section (5)", although the right to withdraw is conferred by sub section (4) and sub section (5) deals with consequences. This is the enacted wording rather than a print artefact, because the same cross reference appears in the bill as passed by both Houses, Bill No. 113-F of 2023. Sub section (5) itself refers back to "the withdrawal referred to in sub-section (4)", so reading the cessation duty as operating on any withdrawal of consent is the reading this site takes. That reading is ours, not the Act's, and no Board decision or judgment has addressed the point.

What the Act never says about consent

The proof burden is the design brief

"Where a consent given by the Data Principal is the basis of processing of personal data and a question arises in this regard in a proceeding, the Data Fiduciary shall be obliged to prove that a notice was given by her to the Data Principal and consent was given by such Data Principal to the Data Fiduciary in accordance with the provisions of this Act and the rules made thereunder."

2 facts have to be provable, not 1: that a notice was given, and that consent was taken as the Act requires. The moment of reckoning is "a proceeding", and that is a defined term: section 2(w) makes it "any action taken by the Board under the provisions of this Act". So the burden bites in action by the Data Protection Board rather than in litigation generally, and the record you can produce long afterwards is the record that counts.

As a recommendation, and not as a requirement of the Act, which prescribes no record format, that points at 5 things worth storing per consent event: the version of the notice text served, the version of the consent request wording, the timestamp, the language served, and the specific purposes agreed to. Version identifiers matter more than screenshots, because the question in a proceeding is what a named person saw on a named date, and a screenshot taken today cannot answer it.

What to do before this commences

Nothing in section 6 binds anyone as at 25 August 2026, and the order of the dates is the useful part. Consent Manager registration opens first, computed at 13 November 2026, and the substantive consent rules follow, computed at 13 May 2027, both interpretation until officially confirmed. That order matters if your plan assumes a registered Consent Manager will be available to hand you compliant consent on the first day the rules bite.

If the purpose is marketing, settle a prior question first: a separate regime already binds that activity while section 6 does not, and which rulebook your marketing consent comes from matters more before 2027 than after it.

3 steps, in the order they pay off. Settle whether a given purpose needs consent at all, because the section 7 legitimate uses and the section 3(c) carve outs take some processing off the consent path entirely. Then map each remaining purpose to the smallest set of personal data it needs, since that is the line section 6(1) draws, and the notice that has to precede the request is where the purpose gets stated. Then build the withdrawal path and the consent record together, because the consent record is what section 6(10) puts on you to produce, and both are hardest to retrofit.