Consent as the Primary Lawful Ground
Section 6 of the DPDPA is the most operationally demanding provision in the entire Act. Consent is one of the two lawful grounds for processing personal data (alongside legitimate uses under Section 7), and for most commercial data processing activities, it is the only available ground. Unlike the GDPR's six lawful bases, the DPDPA's binary framework means that any processing activity not covered by Section 7's narrow legitimate uses must rely on Section 6 consent. This makes the quality of consent a make-or-break compliance issue. Defective consent - consent that fails to meet even one of the five statutory qualities - renders all downstream processing unlawful, exposing the organisation to penalties of up to two hundred and fifty crore rupees. This post examines each element of Section 6 in detail, provides guidance on designing compliant consent flows, explains the role of Consent Managers, and analyses the withdrawal provisions that give Data Principals ongoing control over their data.
The Five Qualities of Valid Consent
Section 6(1) requires that consent be free, specific, informed, unconditional, and unambiguous, and accompanied by a clear affirmative action. Each quality is a separate requirement - consent must satisfy all five simultaneously. 'Free' means the Data Principal must give consent voluntarily, without coercion, undue influence, or making access to goods or services contingent on consent for unnecessary data processing. An app that refuses to function unless the user consents to location tracking, when location is not essential to the core service, fails the 'free' requirement. 'Specific' means consent must relate to a particular, defined purpose - not a blanket authorisation covering all possible future uses. 'Informed' means the Data Principal must have received and understood the Section 5 notice before consenting. 'Unconditional' means consent cannot be bundled with unrelated terms or made subject to conditions not related to the data processing purpose. 'Unambiguous' means there must be no doubt about the Data Principal's intention to consent.
- Free - voluntary, without coercion or unnecessary conditionality
- Specific - tied to a particular, defined processing purpose
- Informed - preceded by a compliant Section 5 notice
- Unconditional - not bundled with unrelated terms or conditions
- Unambiguous - demonstrated through clear affirmative action, not silence or pre-ticked boxes
Clear Affirmative Action - What Counts and What Does Not
The requirement for a 'clear affirmative action' is the practical mechanism through which unambiguous consent is demonstrated. An affirmative action requires the Data Principal to do something - check an unchecked box, toggle a switch, click a clearly labelled button, type a confirmation, or provide a verbal agreement in a recorded interaction. What does not constitute a clear affirmative action includes pre-ticked checkboxes, continued browsing of a website after a cookie banner appears, silence or inaction, scrolling past a notice, or consent inferred from the Data Principal's failure to opt out. The affirmative action must correspond to the specific notice provided - a single 'I Agree' button that bundles consent for multiple distinct purposes may fail the specificity requirement unless each purpose has a separate consent mechanism. For granular consent, best practice is to use individual toggle switches or checkboxes for each processing purpose, with a master notice summarising all purposes and separate sub-notices for each. The design of the consent interface is not merely a UX decision - it is a legal compliance decision.
The Role of Consent Managers
Section 6(6) through 6(9) introduce Consent Managers - a concept unique to Indian data protection law. A Consent Manager is a person registered with the Data Protection Board who acts as a single point of contact through which a Data Principal may give, manage, review, and withdraw consent. Consent Managers must be registered with the Board, be accountable to the Data Principal, and act in the Data Principal's interest. They must be interoperable - meaning they must work across multiple Data Fiduciaries, not be locked to a single organisation. The Consent Manager framework is inspired by India's Account Aggregator model in financial services and represents a vision of consent as a managed, intermediated service rather than a bilateral interaction between each individual and each organisation. For Data Fiduciaries, integrating with Consent Managers means building APIs and interfaces that allow registered Consent Managers to submit consent, manage preferences, and process withdrawals on behalf of Data Principals. While the specific registration requirements and technical standards for Consent Managers will be prescribed by rules, organisations should begin planning their integration strategy now.
- Consent Managers are registered entities regulated by the Data Protection Board
- They enable Data Principals to manage consent across multiple Data Fiduciaries through a single interface
- Must be interoperable - cannot be locked to any single Data Fiduciary
- Data Fiduciaries must build integration capabilities to accept consent via Consent Managers
- Technical standards and registration requirements will be prescribed by rules under the Act
Withdrawal of Consent - The Right and Its Consequences
Section 6(4) grants every Data Principal the right to withdraw consent at any time. This right is absolute and unconditional - the Data Principal does not need to provide a reason for withdrawal. Section 6(5) imposes a critical operational requirement: the ease of withdrawing consent must be comparable to the ease of giving consent. If consent was given through a single click, withdrawal must also be achievable through a single click - not through a multi-step process involving email requests, phone calls, or in-person visits. This 'ease parity' requirement is designed to prevent organisations from making withdrawal deliberately difficult. Many organisations currently bury opt-out mechanisms in account settings several clicks deep while making opt-in prominent on the homepage - this asymmetry directly violates Section 6(5). Upon withdrawal, the Data Fiduciary must cease processing the Data Principal's personal data within a reasonable period. However, Section 6(7) clarifies that the consequences of withdrawal do not affect the lawfulness of processing carried out before the withdrawal - withdrawal operates prospectively, not retroactively.
Effect of Withdrawal on Services and Contracts
A critical practical question arises when consent withdrawal affects the Data Fiduciary's ability to provide a service. Section 6(7) states that the Data Fiduciary must inform the Data Principal of the consequences of withdrawing consent before the withdrawal takes effect. For example, if a user withdraws consent for an e-commerce platform to process their delivery address, the platform cannot fulfil orders - the Data Fiduciary must clearly communicate this consequence before finalising the withdrawal. However, the Data Fiduciary cannot use potential consequences as a coercion mechanism to discourage withdrawal. The notice of consequences must be factual and neutral, not designed to pressure the Data Principal into maintaining consent. After withdrawal, the Data Fiduciary must also ensure that personal data previously processed under the withdrawn consent is erased within such time as may be prescribed, unless retention is required under another legal obligation. The interplay between consent withdrawal, data erasure, and legal retention requirements creates complex compliance scenarios that require careful policy design.
- Data Fiduciary must inform Data Principal of withdrawal consequences before finalising
- Consequences must be communicated factually, not used as coercion to maintain consent
- Processing before withdrawal remains lawful - withdrawal operates prospectively only
- Data must be erased after withdrawal unless another legal retention obligation applies
- Service agreements should clearly specify which processing relies on consent versus legitimate uses
Designing a Compliant Consent Flow - Practical Guidance
Bringing all Section 6 requirements together, a compliant consent flow should follow this sequence. Step one: present the Section 5 notice with all required information - what data, what purpose, rights information, and complaint mechanism. Step two: provide granular consent mechanisms for each distinct processing purpose - separate toggles or checkboxes, not a single 'Accept All' button (though an 'Accept All' option may be provided alongside granular choices). Step three: ensure no pre-ticked boxes or default-on settings. Step four: make consent non-conditional - do not gate core service access behind consent for non-essential processing. Step five: record the consent with a timestamp, the version of the notice presented, the specific purposes consented to, and the method of affirmative action. Step six: provide an equally accessible mechanism for withdrawal, available through the same channel where consent was given. Step seven: implement automated workflows to cease processing and initiate erasure upon withdrawal. Each step should be documented in your processing register and be demonstrable to the Data Protection Board upon request.
- Present Section 5 notice before or alongside consent request
- Offer granular per-purpose consent mechanisms
- No pre-ticked boxes, no default-on, no bundled consent
- Do not gate core services behind non-essential consent
- Record consent with timestamp, notice version, purposes, and affirmative action method
- Provide withdrawal mechanism with ease parity to consent
- Automate data processing cessation and erasure upon withdrawal
Consent for Children's Data - Additional Requirements
While Section 9 governs children's data in detail, Section 6 interacts with it significantly. When the Data Principal is a child (under eighteen years), consent must be obtained from the parent or lawful guardian. This 'verifiable parental consent' requirement means organisations must implement age verification mechanisms at the consent stage and, when a child is identified, redirect the consent process to a verified parent or guardian. The methods for age verification and parental consent verification will be prescribed by rules, but organisations should begin planning for age gates, parental verification workflows, and restricted processing for minors now. The intersection of Section 6 consent requirements with Section 9 children's data protections creates particularly stringent compliance obligations for platforms that serve or may serve minors - including social media, gaming, edtech, and e-commerce platforms.
How Kraver.ai Helps
Kraver.ai's consent management platform is purpose-built for DPDPA Section 6 compliance. Our consent flow builder generates legally compliant consent interfaces with granular per-purpose consent mechanisms, no pre-ticked boxes, and built-in ease parity for withdrawal. The platform integrates with your web applications, mobile apps, and offline channels through SDKs and APIs, ensuring consistent consent capture across all touchpoints. Every consent event is recorded with a tamper-proof audit trail including the notice version, timestamp, specific purposes, and affirmative action method. Our withdrawal management module ensures that consent withdrawal is as easy as consent giving, automatically triggering data processing cessation and erasure workflows across your connected systems. For Consent Manager integration, Kraver.ai's open APIs are designed to support interoperability with registered Consent Managers as the ecosystem develops. The platform also handles children's consent workflows with configurable age verification and parental consent mechanisms. Start building compliant consent flows with Kraver.ai today.