Section 6 of the DPDP Act: Valid Consent Requirements

An India-facing product team redesigning a sign-up journey in August 2026 faces two different questions. It must identify what the law requires in the notified text, but it must also determine which requirements are legally operative today. Treating enactment, notification and commencement as interchangeable can produce an inaccurate compliance position.

Current status as of 29 August 2026: no subsection of Section 6 is yet in force. The Digital Personal Data Protection Act, 2023 was enacted on 11 August 2023, but the commencement notification G.S.R. 843(E), published on 13 November 2025, established a phased timetable for bringing different provisions into effect. The enacted wording is available for implementation planning, but that does not make every provision currently enforceable.^[1][2]

Under that timetable, Section 6(9), which concerns registration of Consent Managers with the Data Protection Board of India, is scheduled to commence on 13 November 2026. Rule 4 of the Digital Personal Data Protection Rules, 2025, which governs Consent Manager registration and obligations, is also scheduled to commence on that date. The substantive right to use a Consent Manager under Section 6(7), and the accountability requirements in Section 6(8), fall into the later commencement phase.

Sections 6(1)–(8) and 6(10) are scheduled to commence on 13 May 2027. Sections 5 and 8 commence on the same date, aligning Rule 3 on notices with Section 5 and Rule 6 on reasonable security safeguards with Section 8 under the commencement provisions in the DPDP Rules, 2025. These dates derive from the official commencement notification for the Act and Rule 1 of the Rules; implementation plans should be checked against any later notifications, corrigenda or amendments before reliance.^[2][3]

Section 6(1) treats consent as a defined system outcome rather than a signature or button click. Consent must be free, specific, informed, unconditional and unambiguous, and it must involve clear affirmative action. It must signify agreement to processing for a specified purpose and cover only the personal data necessary for that purpose. Each element should be tested independently; a prominent opt-in button does not cure an overbroad purpose or unnecessary data collection.^[1]

“Free” calls for a genuine choice rather than coercion or material obstruction, with particular scrutiny where there is a power imbalance. “Specific” requires the request to identify the purpose with enough precision to bound later use. “Informed” depends on the Data Principal receiving the required information before or with the request. “Unconditional” weighs against making access to a requested service depend on consent to unrelated processing. A necessary identity check may be integral to a service, while optional marketing or contact-list access ordinarily requires a separate justification and choice.

“Unambiguous” and “clear affirmative action” require conduct that objectively communicates agreement. An unticked box with a clear label is stronger evidence than inactivity, a pre-ticked box, continued browsing or a control designed to conceal refusal. Consent also cannot legitimise data beyond what is necessary for the specified purpose. A telemedicine service may need health and contact information to deliver a consultation, but access to the device’s full contacts list would require a distinct, supportable purpose rather than being folded into the consultation consent.

Common failures are usually visible in the relationship between wording and behaviour. A purpose-specific opt-in that leaves optional fields disabled is more consistent with Section 6 than one acceptance covering service delivery, advertising, profiling and partner sharing. Separate choices may be needed where purposes are materially distinct. Section 6(2) also makes any consent term invalid to the extent that it infringes the Act, its Rules or another law, so a contractual clause purporting to waive the right to complain to the Board would not become effective merely because the Data Principal clicked “agree”.^[1]

Notice and consent perform different legal functions. Section 5 and Rule 3 govern the information a Data Fiduciary provides; Section 6 governs whether the Data Principal’s agreement is valid. A complete privacy notice is not itself consent, and an affirmative click does not repair a notice that omitted the relevant data, purpose or rights information. Systems should therefore preserve separate evidence of notice delivery and the subsequent consent event.

Section 5 requires the consent request to be accompanied or preceded by a notice describing the personal data and proposed purpose. It must also explain how the Data Principal may withdraw consent, exercise the grievance right under Section 13 and complain to the Board. Section 6(3) separately requires the request for consent to use clear and plain language, offer access in English or any language in the Eighth Schedule to the Constitution, and provide contact details for the Data Protection Officer, where applicable, or another authorised contact.^[1]

Rule 3 adds presentation and content requirements. The notice must be clear, plain and independently understandable, and give a fair account of the information needed for specific and informed consent. This includes an itemised description of the personal data, the specified purpose and an account of the goods, services or uses enabled by the processing. It must provide an accessible link or comparable means for withdrawing consent, exercising rights and complaining to the Board. Legal and product reviewers should compare the displayed copy, interaction design and back-end purpose codes rather than approving the notice as a document in isolation.^[3]

Section 6(4) allows a Data Principal to withdraw consent at any time and requires the ease of withdrawal to be comparable to the ease of giving consent. A one-step opt-in followed by a support ticket, telephone call or hidden account path for withdrawal creates a material design concern. Comparable ease does not necessarily require an identical interface, but the withdrawal route should not introduce avoidable steps, delay or pressure.^[1]

The Data Principal bears the consequences of withdrawal under Section 6(5), and withdrawal does not affect the lawfulness of processing based on consent before it was withdrawn. That provision should not be read as permission to impose punitive friction. Product copy should describe genuine consequences, such as loss of a feature that objectively depends on the withdrawn processing, without implying that unrelated services will be removed.

After withdrawal, Section 6(6) requires the Data Fiduciary, within a reasonable time, to cease processing and cause its Data Processors to cease unless continued processing is required or authorised by the Act, the Rules or another law. Engineering teams should map the event from the preference interface to data stores, campaign tools, analytics systems, processors and deletion or restriction workflows. Processor contracts should identify how withdrawal instructions are transmitted, acknowledged and applied, including treatment of backups and data retained under another legal obligation.

Section 2(g) defines a Consent Manager as a person registered with the Board who provides an accessible, transparent and interoperable platform through which a Data Principal may give, manage, review and withdraw consent. Sections 6(7) and 6(8) allow the Data Principal to use that pathway and make the Consent Manager accountable to, and acting on behalf of, the Data Principal. Section 6(9) supplies the registration requirement.^[1]

Rule 4 and the First Schedule set the eligibility, governance and operating framework for Consent Managers. Relevant controls include their corporate and financial standing, technical and operational capacity, conflict management, record handling, security, transparency and accountability. An organisation evaluating a Consent Manager should verify the Board registration, approved scope, governance disclosures, service terms, audit arrangements, security controls and ability to export an intelligible history of notices and consent events.^[3]

Using a Consent Manager is not mandatory for every Data Fiduciary, nor does it transfer the Data Fiduciary’s statutory obligations. An organisation may obtain consent directly, support a registered Consent Manager channel, or operate a hybrid journey where appropriate. Architecture reviews should determine how identities, purpose codes, notice versions, consent receipts and withdrawal events will be reconciled without assuming that a Consent Manager’s internal record automatically proves the Data Fiduciary’s complete compliance case.

Consent validity, notice quality and information security are distinct duty sets. Section 6 governs consent; Section 5 and Rule 3 govern notices; Section 8 and Rule 6 govern reasonable security safeguards. Strong encryption cannot make bundled consent specific, while valid consent does not excuse inadequate access controls or an avoidable security incident.^[1][3]

Rule 6 specifies a baseline that includes appropriate measures such as encryption, obfuscation, masking or virtual tokens; access controls; visibility over access through logs, monitoring and review; measures to detect, investigate, remediate and prevent unauthorised access; continuity arrangements such as backups; and technical and organisational controls. It also addresses contractual safeguards where processing is carried out by a Data Processor and retention of relevant logs and personal data for the specified period, subject to any longer requirement under other law.^[3]

Security reviewers should test whether controls follow the data after consent is recorded, including when data is transferred to processors or retained for a legally authorised purpose after withdrawal. Contract reviewers should verify security commitments, incident cooperation, audit evidence and instruction handling rather than assuming that a generic confidentiality clause satisfies Rule 6. Under the current timetable, Rule 6 and its corresponding Section 8 obligations are scheduled to commence on 13 May 2027.

Section 5(2) does not state that every consent obtained before commencement automatically becomes invalid. Once the provision commences, a Data Fiduciary that previously obtained consent must provide the prescribed notice as soon as reasonably practicable. Section 5(3) permits processing based on that consent to continue until the Data Principal withdraws it, subject to the rest of the Act and other applicable law.^[1]

The DPDP Act does not require consent for every processing activity. Section 7 establishes a defined set of “certain legitimate uses”, including specified situations involving personal data voluntarily provided for a purpose, State functions, legal disclosures, court or tribunal orders, medical emergencies, public-health events, disasters and employment-related purposes. This is a statutory list, not a general balancing test equivalent to similarly named grounds in some foreign privacy laws.^[1]

Where Section 7 is used, the processing record should identify the precise statutory limb, relevant facts, purpose, data categories, recipients, retention position and approving function. It is usually unhelpful to label the activity broadly as “legitimate use” without connecting the facts to the statutory wording. Notice, security, accuracy, retention and other duties may still apply even when consent is not the basis.

Employment and business contexts require particular care. Section 7 includes bounded employment-related purposes, but it does not convert every workforce use into a legitimate use. Nor does a B2B setting create a general exemption for identifiable business contacts. Legal reviewers should test the actual purpose and relationship, especially where refusing consent could affect employment, payment, system access or a commercial relationship.

Section 6(10) places the burden on the Data Fiduciary to prove that the required notice was given and that consent was obtained in accordance with the Act and Rules. A database flag reading “consent=true” rarely proves what the person saw, which purpose they accepted, what data was covered or whether the control required affirmative action.^[1]

A proportionate evidence pack ordinarily links the Data Principal or account to the notice and consent-request versions, language, purpose code, data categories, interface state, affirmative action and timestamp. It should also preserve changes in scope, withdrawals, processing cessation events, processor notifications and any continuing-processing rationale. Version-controlled screenshots or design records can substantiate the journey, while event logs establish what happened in an individual case. Retention should be governed rather than indefinite, taking account of Rule 6, evidentiary needs and other applicable requirements.^[3]

Regulatory obligations, contract risk and claim substantiation should be reviewed separately. The Act determines the Data Fiduciary’s duties; processor and partner contracts allocate instructions, cooperation and evidence responsibilities; public or customer-facing claims such as “DPDP-compliant consent” require their own support. A reviewer should verify that contracts match the actual data flow and that the evidence can be retrieved, interpreted and connected to the relevant processing rather than merely confirming that records exist.