DPDP Act27 May 2026 8 min read

DPDP Act Consent Withdrawal: How to Handle Opt-Outs

How the DPDP Act 2023 consent withdrawal right works, how to build a compliant opt-out mechanism, and what happens to data after consent is withdrawn.

Key Takeaways

Section 6(4) gives Data Principals the right to withdraw consent at any time, with withdrawal being as easy as giving consent.
After consent is withdrawn, processing must cease — unless another lawful basis (Section 7) applies.
Withdrawal of consent does not make prior processing unlawful — only processing after withdrawal is affected.
For products that rely on consent as the sole lawful basis, consent withdrawal effectively triggers an erasure obligation.
A consent management dashboard that allows granular withdrawal (per purpose) is best practice and likely what the Rules will require.

In this guide

The Consent Withdrawal Right Under Section 6(4)
Withdrawal Must Be as Easy as Giving Consent
What Happens After Consent Is Withdrawn
Building a Consent Management Interface
Granular Consent and Partial Withdrawal
Service Continuity After Opt-Out
Consent Withdrawal Record-Keeping

Section 6(4) of the DPDP Act 2023 provides that a Data Principal shall have the right to withdraw consent at any time. This is a fundamental right — consent given to a Data Fiduciary is not irrevocable. Just as a Data Principal can choose to provide their personal data for processing, they can choose to withdraw that permission at any point during the relationship.

The withdrawal right matters because it gives individuals ongoing control over their personal data. It is not sufficient to obtain consent once at registration and then process indefinitely on that basis — the consent is always contingent on the Data Principal not withdrawing it. Companies that rely heavily on consent as their lawful basis for processing must build the infrastructure to honour withdrawal requests promptly.

Withdrawal of consent does not affect the lawfulness of processing conducted before the withdrawal. Processing that occurred while consent was validly in place is not retrospectively unlawful. However, all processing that relies on the withdrawn consent must cease from the moment of withdrawal. If the company has no other lawful basis (such as a Section 7 exemption) for continuing to process the data, it must stop processing and delete the data.

Withdrawal Must Be as Easy as Giving Consent

Section 6(4) explicitly states that withdrawal of consent shall be as easy as giving consent. This is a direct prohibition on dark patterns that make it difficult to opt out — long multi-step processes, buried privacy settings, confirmation requirements that do not apply to the original consent, or customer service queues for a process that was completed with a single click at registration.

If a user consented with a checkbox during a 2-minute registration flow, they must be able to withdraw consent in an equivalent or shorter process. This has direct implications for product design: the consent withdrawal mechanism must be as prominent and accessible as the consent capture mechanism. Hiding opt-out in the 15th item of a settings menu accessible only via a help article is a violation of this requirement.

The "ease of withdrawal" requirement also applies to timing. If consent was given instantly (real-time), withdrawal should be processed promptly — not in 14-30 days via a customer service ticket. Build withdrawal into the product experience as a self-service function, not a support process.

What Happens After Consent Is Withdrawn

When a Data Principal withdraws consent, the Data Fiduciary must immediately cease any processing that was based solely on that consent. If there is an alternative lawful basis under Section 7 — for example, the processing is required to perform a contract with the Data Principal, or is required by law — processing may continue on that basis even after consent withdrawal. But the company must have actually established and documented that alternative basis, not claim it retroactively.

For most Indian consumer-facing applications, consent is the primary lawful basis, and withdrawal effectively means the end of the data relationship. The company must: stop all processing of the withdrawn-consent data, delete data for which there is no continuing legal basis for retention, cease sharing the data with third parties, and send the Data Principal a confirmation of withdrawal and the actions taken.

The DPDP Act does not specify a timeframe for "ceasing processing" after withdrawal — the Rules will. In practice, immediate cessation of active processing (marketing sends, analytics enrichment) and deletion within 30 days is a reasonable target. Document the precise sequence and timing of actions taken after a withdrawal to demonstrate compliance.

Building a Consent Management Interface

A consent management interface — sometimes called a privacy centre or privacy dashboard — allows Data Principals to view the consents they have given, understand what each consent covers, and withdraw specific consents individually. This is both a Section 6(4) requirement and a best practice for building user trust.

The minimum viable consent management interface should show: (1) a list of purposes for which consent has been given; (2) the current status of each consent (active or withdrawn); (3) a toggle or button to withdraw each consent; (4) an explanation of what will happen if consent is withdrawn (e.g., "You will no longer receive marketing emails. Your account will remain active."). Provide immediate confirmation when a consent is withdrawn.

For complex products with many processing purposes, invest in a proper Consent Management Platform (CMP) — either a specialist tool or a custom-built module. The CMP should: store timestamped records of every consent given and withdrawn, propagate withdrawal events to all downstream processing systems, and provide an API for other systems to check consent status before processing.

Section 6(2) requires that consent be "specific" — meaning consent must be given and can be withdrawn at the level of individual processing purposes. A user should be able to withdraw consent to marketing emails without withdrawing consent to transactional communications. They should be able to opt out of analytics data collection without deleting their account.

Implement granular consent management that tracks consent at the purpose level. Each processing purpose (marketing, analytics, product improvement, personalisation, third-party sharing, etc.) should have its own consent flag, independently settable and withdrawable. This granularity ensures that withdrawal of one consent does not inadvertently affect processing the user still wants to enable.

When a user withdraws consent for a specific purpose, the downstream effect should be surgical: stop only the processing activities that rely on that consent. If they withdraw marketing consent, pause marketing sends and remove them from marketing segmentation lists — but continue sending transactional emails and retain account data needed to provide the service they are still subscribed to.

Service Continuity After Opt-Out

One of the most important DPDP Act requirements is that the withdrawal of consent must not be conditional on the Data Principal accepting reduced service quality for processing that is necessary to provide the service. In other words, you cannot punish users for withdrawing marketing consent by degrading their product experience. Service provided under contractual necessity is not dependent on the marketing consent.

Communicate clearly to users what will and will not be affected by withdrawal. Use simple language: "If you withdraw your marketing consent, you will no longer receive our newsletters and promotional offers. Your account will continue to work normally and we will still send you important account notifications." Clarity prevents misunderstanding and reduces the number of support tickets following opt-out.

However, if a user withdraws consent for processing that is actually necessary to provide the core service — for example, withdrawing consent for sharing data with a payment processor in a marketplace application — the consequence may be that the specific service feature cannot be provided. Be transparent about these dependencies at the consent stage, not only at the withdrawal stage.

Consent Withdrawal Record-Keeping

Maintain records of all consent withdrawals: the Data Principal's identity, the specific consents withdrawn, the timestamp of withdrawal, and the actions taken in response. These records are critical evidence if a Data Principal later claims they withdrew consent and you continued processing — your records either vindicate or inculpate you.

Consent records (both grants and withdrawals) should be retained for a sufficient period to cover potential Board investigations. A retention period of 3 years for consent logs is a reasonable baseline — long enough to cover the investigation and penalty assessment timeline while not being excessively long. The logs themselves are a compliance record, not personal data used for operational purposes.

Integrate consent status into your data processing pipelines. Before any system processes personal data for a consent-based purpose, it should check the current consent status. This "consent check at point of use" prevents stale consent records from being relied upon. Architectures that cache consent status must ensure the cache is invalidated promptly when consent is withdrawn.

Frequently Asked Questions

If a user withdraws marketing consent but keeps their account, can we still use their data for product analytics?

Only if product analytics is a separately consented purpose that the user has not withdrawn, or if analytics falls under a different lawful basis (such as the Fiduciary's legitimate use to improve the service, if Section 7 applies). Do not conflate different processing purposes — withdrawal of marketing consent should only affect marketing processing.

Can we require users to go through customer support to withdraw consent?

No. Section 6(4) requires withdrawal to be as easy as giving consent. If consent was given digitally in-product, the withdrawal mechanism must also be digital and in-product. Routing withdrawals through customer support — which introduces delay, friction, and human bottlenecks — violates the ease-of-withdrawal requirement.

What if a user withdraws consent and then re-consents two months later? Do we need to restart data collection?

After withdrawal, you must delete data that has no other retention basis. If the user re-consents two months later, you are starting a new consent relationship and will collect data from that point forward. You cannot simply "reactivate" historical data that was deleted following withdrawal. This reinforces why granular withdrawal (per purpose rather than full account deletion) is better for both parties.

Does withdrawing consent give rise to an immediate erasure obligation?

If consent is the only lawful basis for holding the data, withdrawal means the purpose is no longer being served and the data must be erased under Section 8(7). If another lawful basis applies (legal obligation, legitimate use under Section 7), the data may be retained on that basis. The key question after withdrawal is: is there any remaining lawful basis for retention?

How do we handle consent withdrawal for a B2B account where consent was given by the organisation, not individuals?

In B2B contexts, the individual employees or users whose data is processed are the Data Principals, not the organisation as a whole. Even if consent was obtained at the organisational level, individuals retain their right to withdraw. Build individual-level consent management in B2B products, and ensure your enterprise contracts address how individual consent withdrawal will be handled operationally.