
DPDPA Section 6: Valid Consent, Withdrawal, and Consent Manager Duties
Discover how your organization can effectively meet consent requirements under the new DPDP Act. Ensure compliance and build trust with your users today.
Written by
Priyanka Choudhury
Date
Read time
6 min

For a decade, consent was just a button you clicked to make a pop-up go away. DPDPA Section 6 changes that. It sets the operational standard for what valid consent actually looks like, how it must be sought, and what happens the moment a user changes their mind.
If your processing relies on consent, this is your playbook. The era of the pre-ticked box is over.
What DPDPA Section 6 Requires for Valid Consent
Under the DPDP Act consent requirements, permission must be free, specific, informed, unconditional, and unambiguous. It requires a clear affirmative action. More importantly, it must be tied to a specified purpose and limited strictly to the personal data necessary for that purpose.
In practice, this means:
- Free: No coercion or forced bundling. You cannot make unrelated permissions a condition for access.
- Specific: Identify the purpose and limit processing to it. If the purpose changes, your old consent is useless. Request fresh consent.
- Informed: The person must see the Section 5 notice before agreeing.
- Unconditional: No hidden terms or manipulative strings attached.
- Unambiguous: Explicit opt-in through a positive action. Silence, inaction, or pre-ticked boxes do not count.
- Affirmative action: An actual click, toggle, or signature that clearly indicates agreement.
The Act provides a clear illustration: A telemedicine app seeking access to a user’s contact list along with consent for telemedicine services cannot rely on that bundled consent. Contact access is not necessary to deliver a doctor’s consultation. Consent is limited to what is necessary for the stated purpose. Everything else is overreach.

The Partial Invalidity of Unlawful Terms
You cannot use a catch-all Terms of Service agreement to strip away statutory rights. Any part of a consent that infringes the Act, the rules, or any other law is invalid to that extent.
The Act illustrates this bluntly: A user consenting to policy issuance cannot waive her right to file a complaint with the Data Protection Board. Even if she explicitly agreed to it, that waiver is invalid.
Operational implications:
Strip out any waivers that attempt to limit rights under this law. Keep purpose-specific consents entirely separate from unrelated legal consents or contractual terms. A well-written lie in your policy will not save you.
How to Present Consent Requests
The days of burying data usage in a 40-page legal document are done. Every consent request must:
- Use clear and plain language.
- Be accessible in English or any language listed in the Eighth Schedule to the Constitution.
- Provide contact details of the Data Protection Officer (DPO), where applicable, or another authorized contact who can handle rights requests.
Do not bury the purpose and data uses. State them up front. Give a straightforward choice to accept or decline. Localize your consent screens,language access is mandatory, not optional. And display a working contact channel that responds to rights exercises, not a dead-end inbox.
Withdrawing Consent and What Follows
If processing is based on consent, the individual can withdraw it at any time. And here is the operational catch: the ease of withdrawal must be comparable to the ease of giving consent. If consent is a single click, withdrawal cannot be a PDF form mailed to a head office.
Two key consequences flow from withdrawal:
- The individual bears the business consequences of withdrawal. If consent is necessary to deliver a feature, that feature can be disabled.
- Withdrawal does not affect the legality of processing already done before the withdrawal.
The Act’s illustration: If a user withdraws consent after placing and paying for an order, the provider can prevent new orders, but must continue the processing necessary to fulfill the already placed order.
Operational obligations after withdrawal:
The Data Fiduciary must cease processing within a reasonable time. Crucially, you must also cause your Data Processors to cease processing. Processing may continue only if a provision of the Act, the rules, or another Indian law requires or authorizes it without consent.
Build for symmetry. Process the withdrawal in a comparable timeframe to how quickly you acted on consent. Confirm to the individual when processing has stopped and what will continue under a legal basis other than consent.

The Role of a Consent Manager Under the DPDP Act
The Act introduces a new operational layer: individuals can give, manage, review, or withdraw consent through a Consent Manager.
A Consent Manager is accountable to the individual and acts on her behalf in the prescribed manner. Every Consent Manager must be registered with the Board and meet prescribed technical, operational, financial, and other conditions, as set out in DPDP Rules 2025, Rule 4.
If you offer or integrate a Consent Manager, you must validate their registration status with the Board. Ensure technical and operational controls align with the prescribed conditions, and maintain an auditable trail of instructions received and actions taken via the Consent Manager.
The Burden of Proof Sits With the Data Fiduciary
If a dispute arises in a proceeding about consent, the burden does not fall on the user. The Data Fiduciary must prove that the Section 5 notice was given, and that consent was obtained in accordance with the Act and rules.
This is not a paperwork formality. It is an evidentiary requirement.
You need practical evidence. Retain the exact version of the notice shown, including the language used. Keep timestamped logs of the affirmative action taken by the individual, alongside the purpose-specific scope captured at the time of consent. Maintain records of withdrawals, cessation timelines, processor instructions, and copies of support interactions related to consent.
Practical Controls to Implement
Purpose Design
Map each processing purpose and the minimum data needed. Do not request or process data that is not necessary for the specified purpose.
Consent Design
Separate consents by purpose. No bundling of unrelated data access. Require explicit, affirmative actions. Make decline paths visible and equal in prominence to accept paths.
Language and Contact
Provide the consent request in English and any Eighth Schedule language requested by the user. Display DPO or authorized contact details clearly.
Withdrawal
Build one-click or simple in-product withdrawal. Ensure cessation within a reasonable time and mirror the speed of activation. Instruct processors to stop processing and verify compliance.
Processor Governance
Include contractual clauses requiring processors to cease processing upon instruction following withdrawal. Maintain logs of instructions to processors and acknowledgments received.
Documentation and Audit
Capture consent artifacts and associate them with the individual and purpose. Keep retention aligned with legal defense needs and storage limitation principles. Prepare to produce records quickly during an inquiry or proceeding.
Interface Integrity
Avoid designs that obscure decline options or overemphasize accept options. Ensure that consent screens do not contain hidden conditions. Manipulative patterns undermine validity and invite scrutiny.
What This Changes in Practice
Consent is no longer a blanket permission. It is a tightly scoped authorization tied to a defined purpose and necessary data. Your systems must enforce that scope at both the collection and use stages.
Withdrawal is not a support ticket. It is a rights action that requires timely cessation across your systems and your processors.
Finally, your proof is only as good as your records. If you cannot show notice and affirmative consent for the specific purpose, you have a gap.
Getting this right requires coordinated work across product, engineering, legal, and operations. Most teams struggle not because they disagree with the rules, but because they lack a structured way to manage them across systems, versions, and vendors.
At Regodit, we help teams operationalize these requirements. We replace scattered spreadsheets with clear workflows, evidence capture, and accountability. If you need a practical way to implement Section 6 requirements across products and vendors, we can walk through your current consent flows, documentation, and processor management, and map a path to compliance that actually stands up in practice and in proceedings.
Disclaimer: The views and explanations shared in this blog are based on our team's understanding of the relevant compliance frameworks. While every effort has been made to ensure accuracy, readers are encouraged to refer to the original legal provisions and official notifications for authoritative guidance. Please reach out to us at connect@solsphere.ai.
Keep reading
All blogs →DPDPA Rule 23: Government Requests for Information from Data Fiduciaries and Intermediaries
Handling a notice under DPDP Act Rule 23 requires strict confidentiality. Discover how to respond to government data requests and ensure full compliance.
DPDPA Rule 22: Appeals to the Appellate Tribunal
Lost at the Data Protection Board? DPDPA Rule 22 governs the digital-first appeals process. Read our complete guide to filing an appeal with the Tribunal.
DPDPA Rule 21: The Machinery Behind the Data Protection Board of India
Ensure your business meets DPDP Act compliance requirements. Discover key obligations for data fiduciaries, penalty risks, and steps to protect user privacy.
