Turning off a marketing flag is the easy part. A withdrawal is only really handled when the affected purpose has stopped across every system and processor that touched it, retained data is justified, and you can prove the whole thing was done.
When a Data Principal withdraws consent under Section 6 of India’s Digital Personal Data Protection Act, 2023, the Data Fiduciary must, within a reasonable time, stop the affected consent-based processing and cause its Data Processors to stop. Withdrawal must be as easy as giving consent. Earlier processing does not become retrospectively unlawful, and limited processing may continue only where it independently remains required or authorised without consent under the Act, the Rules or another Indian law.
The operational question this guide answers is narrow and practical: once someone withdraws consent, what does your organisation actually have to do, and how do you know it is finished? The legal test lives in Section 6. The hard part lives in your systems.
Most teams treat consent withdrawal as a single field change. A user unticks a box, a CRM flag flips from “opted in” to “opted out”, and the ticket is closed. Under the DPDP Act, that is rarely the whole obligation.
A consent withdrawal is not complete merely because a CRM field changes from “opted in” to “opted out.” The duty in Section 6(6) is to cease the affected processing, including by your processors. A flag is evidence of intent, not proof that processing stopped.
To act on a withdrawal properly, the organisation has to identify six things and then follow them through to completion:
Withdrawal is governed by Section 6 of the DPDP Act. The table below separates the statutory rule from its operational meaning. The left two columns are the law. The right column is how we read it in practice, and is interpretation, not statute.
| Provision | Statutory rule Law | Operational meaning Practice |
|---|---|---|
| 6(4) | Where consent is the basis of processing, the Data Principal may withdraw it at any time, with an ease comparable to the ease with which it was given. | You must offer a real withdrawal path, and it cannot be materially harder than the path you used to collect consent. |
| 6(5) | The consequences of withdrawal are borne by the Data Principal, and withdrawal does not affect the legality of processing done before it. | Withdrawal is forward-looking. You do not have to treat past, lawful processing as if it never happened, but you cannot keep processing for the withdrawn purpose going forward. |
| 6(6) | On withdrawal, the Data Fiduciary shall, within a reasonable time, cease processing, and cause its Data Processors to cease processing, unless required or authorised by law. | This is the core operational duty. You stop internally and you make your vendors stop. The only carve-out is processing that independently stands without consent. |
| 6(7)–6(9) | The Data Principal may give, manage, review or withdraw consent through a Consent Manager, which is accountable to the Data Principal and must register with the Board as prescribed. | A statutory Consent Manager is a specific registered entity. It is not the same as a cookie banner, a consent-management platform or a CRM preference field. |
| 6(10) | Where consent is the basis of processing, the Data Fiduciary bears the burden to prove that notice was given and valid consent was obtained. | If you cannot prove consent, you cannot safely rely on it. The same evidentiary discipline is what lets you prove a withdrawal was honoured. |
The core Section 6 consent duties are notified but scheduled to commence on 13 May 2027. Consent Manager registration under 6(9) is separately scheduled for 13 November 2026. Building withdrawal handling now is preparation for a duty that is coming, not a duty already in force.
You cannot rescue withdrawn processing by relabelling it as a “legitimate use” after the person objects. If a purpose genuinely qualifies as a certain legitimate use under Section 7, it should have been on that basis from the start. Reclassifying on withdrawal, to keep doing the same thing, is the kind of move a regulator reads as bad faith.
For the full text and illustrations of Section 6, see the Section 6 reference page. For what makes the underlying consent valid in the first place, see Valid Consent Under Section 6.
Section 6(4) sets a relative standard, not an absolute one. Withdrawal must be comparably easy to how consent was given. It does not, on its face, mandate a single universal one-click button for every channel.
The person may withdraw “with an ease comparable to the ease with which it was given.” The comparison is to your own collection journey, so if you collected consent in two taps, a five-step, identity-heavy withdrawal maze is hard to defend.
Offer withdrawal on the same primary channels you used to collect consent, and make it discoverable. A prominent in-product control plus an always-available route (such as a preference centre or a clearly published request path) is a defensible reading of “comparable ease.” A universal one-click control is good practice, but treat it as a recommendation, not a stated statutory command.
| Channel | How consent is typically given | Comparable withdrawal route |
|---|---|---|
| Website | Checkbox or toggle at sign-up or in a form | Equivalent toggle in a visible preference centre or account settings |
| App | In-app permission prompt or settings toggle | In-app settings toggle in the same area, not buried three levels deep |
| Opt-in link or subscription confirmation | Working unsubscribe or manage-preferences link in every message | |
| SMS | Reply keyword or opt-in link | Reply STOP keyword, or the equivalent published route |
| Call centre | Verbal consent captured by an agent | Verbal withdrawal an agent can action, with the same identity check as collection |
| Physical form | Signature on a paper or PDF form | A published request path of comparable effort, not a notarised letter |
| Consent Manager | Consent given through a registered Consent Manager | Withdrawal through the same Consent Manager, once that regime is live |
When consent for a purpose is withdrawn, every activity that depended on that consent must stop going forward. The examples below are the common ones. If consent was the basis, the activity ends when consent ends.
| Activity | What stops on withdrawal |
|---|---|
| Promotional email | The person is removed from consent-based marketing sends for that purpose. |
| SMS / WhatsApp | Consent-based promotional messaging on these channels stops, not just email. |
| Personalised recommendations | Recommendation engines stop using their data for the withdrawn purpose. |
| Behavioural advertising | Audience and retargeting activity built on that consent is switched off and suppressed. |
| Partner sharing | Sharing to partners for the withdrawn purpose ceases, and partners are told. |
| Optional analytics | Analytics that relied on consent (rather than a separate lawful basis) stops for that person. |
| Research | Consent-based research use ends, unless it stands on an independent footing. |
| Optional product features | Features the person opted into, which are not core to the service, are wound down. |
| AI training / evaluation | Where consent was the basis, feeding the person’s data into training or evaluation stops. |
Maintain a mapping from each consent purpose to the systems and jobs that act on it. Without that map, teams stop the visible channel (email) and miss the quiet ones (a warehouse export, an ad-audience refresh, an AI feature pipeline).
Withdrawing consent for one purpose does not delete the account or end the relationship. A person can stop marketing while remaining a paying customer. The account stays; the withdrawn purposes stop.
The person keeps using the service. Withdrawal narrows what you may do, it does not end the relationship.
The right-hand column continues only where that processing independently remains required or authorised without consent. “They still have an account” is not, by itself, a lawful basis to keep marketing to them.
Section 6(6) lets processing continue where it is “required or authorised by law” independently of consent. That is a narrow door, not a general exception. Each item below must stand on its own footing, tied to a specific legal requirement or authorisation, not a vague business preference.
| Retained processing | Why it can stand without consent |
|---|---|
| Tax / accounting | Statutory record-keeping obligations under Indian tax and company law. |
| KYC / AML | Customer-diligence and record duties under RBI, PMLA and sectoral rules. |
| Payment records | Transaction and dispute records required by payment and sectoral regulation. |
| Fraud / security | Processing genuinely needed to detect, prevent or investigate fraud and to keep systems secure. |
| Legal claims | Data needed to establish, exercise or defend a legal claim. |
| Regulatory investigation | Data a regulator or law requires you to preserve or produce. |
| Suppression lists | A minimal record kept specifically so you do not re-market to the person. |
| Active-service administration | Processing needed to run a service the person is still using. |
Each retained activity needs its own justification and should be scoped to what the law actually requires. The following are not valid reasons to keep processing a withdrawn purpose:
Withdrawal, cessation, erasure, retention, restriction and suppression are related but distinct. Conflating them is the single most common source of both over-deletion and under-deletion. This is a summary; erasure has its own dedicated guide.
| Concept | Meaning | Typical outcome |
|---|---|---|
| Withdrawal | Permission revoked | Consent-based processing stops |
| Cessation | Processing activity stops | Systems and processors stop acting |
| Erasure | Data deleted | Removed where deletion is required |
| Retention | Limited data remains | Keep only justified records |
| Restriction | Ordinary use blocked | Narrow the retained use |
| Suppression | Minimal identifier retained | Prevent renewed marketing |
You need reasonable assurance that the person asking to withdraw is the person whose consent it is. But verification should be proportionate. Demanding heavy proof for a simple marketing opt-out can itself undermine the “comparable ease” standard.
The DPDP Act does not prescribe one universal identity-verification workflow for withdrawal. Proportionality is an implementation judgement, not a fixed statutory procedure.
| Scenario | Sensitivity | Proportionate check |
|---|---|---|
| Logged-in user toggles a preference | Low | The active session is usually sufficient |
| Unsubscribe link in a message | Low | The signed link itself carries assurance |
| Email or call to support to withdraw marketing | Low to medium | Match against known account contact details |
| Withdrawal that triggers erasure of sensitive records | Higher | Stronger verification proportionate to the impact |
Set a proportionate verification standard per channel and impact, and document it. The goal is to avoid two failure modes at once: actioning a request from the wrong person, and turning a simple opt-out into an obstacle course.
This is a practical operating model for handling a withdrawal from intake to closure, grouped into six phases. It is an implementation recommendation. The Act sets the duty in Section 6(6); it does not prescribe these exact steps, owners or tooling.
The same twelve steps, in order, for reference:
Steps 6 and 7 carry the express Section 6(6) duty: cease internally and cause your processors to cease. The surrounding steps (identity method, evidence capture, monitoring) are sound controls that support that duty; they are recommendations, not separately stated statutory requirements.
Withdrawal handling fails when no one owns the whole chain. The matrix below is one way to assign responsibility across the twelve steps. It is an implementation recommendation, not a statutory RACI requirement. Adapt roles to how your organisation is actually structured.
| Phase | Primary owner | Supporting roles | Oversight |
|---|---|---|---|
| Intake | Customer support (R) | Identity team (S) | Privacy operations (O) |
| Decide | Privacy operations (R) | Product, CRM owner (S) | DPO (O) |
| Enforce | System owners (R) | CRM owner, product (S) | Privacy operations (O) |
| Propagate | Procurement / vendor management (R) | Security, system owners (S) | DPO (O) |
| Resolve | Records management (R) | Legal (S) | DPO (O) |
| Prove | Privacy operations (R) | Audit (S) | Executive escalation (O) |
The reason “change one CRM field” is inadequate is that consent-based data spreads. A withdrawal has to reach every system that stores, moves or acts on that purpose. The map below shows the usual surface area.
Practically, that means checking, at minimum: identity and authentication, the consent ledger or preference store, CRM, marketing automation, email, SMS and WhatsApp, the CDP, the data warehouse or lake, the product application, analytics, ad-tech, support and helpdesk, AI and ML pipelines, every relevant Data Processor, and backup environments. Backups matter because a careless restore can quietly reinstate an old consent state.
Section 6(6) is explicit that you must cause your Data Processors to cease processing. Everything beyond that basic duty (registers, APIs, acknowledgements) is good operational practice that helps you meet and evidence the duty. It is important not to present the tooling as if the Act named it.
On withdrawal, the Data Fiduciary must cause its Data Processors to cease processing the affected personal data, within a reasonable time, unless that processing is independently required or authorised by law. Section 8(2) separately requires processors to act under a valid contract.
To meet and prove that duty at scale, organisations commonly maintain: a processor register, a purpose-to-processor map, subprocessor visibility, withdrawal-event notifications or APIs, contract clauses covering cessation, an acknowledgement step, an escalation path, periodic testing, and audit evidence. These are recommended controls, not separately mandated statutory mechanisms.
Section 6(6) requires cessation “within a reasonable time.” The Act does not specify a universal 24-hour, 48-hour, 72-hour, 7-day or 30-day withdrawal deadline. Reasonableness depends on the processing and the systems involved.
Because there is no fixed statutory clock, organisations set internal service levels so “reasonable” does not drift into “eventually.” The targets below are recommended internal SLAs, not legal deadlines.
| Action | Suggested internal target |
|---|---|
| Update the authoritative consent state | Near-immediate, ideally automated |
| Suppress the person from active campaigns | Same working day |
| Notify affected Data Processors | Within a small number of days |
| Obtain processor cessation confirmation | Within the notice period agreed in contract |
| Close and evidence the request | Once all downstream actions are confirmed |
An internal 72-hour target is a governance choice. Publishing it as though the DPDP Act imposed it is inaccurate, and it can box you into a commitment the statute does not require.
You cannot prove “within a reasonable time” without measuring it. A lightweight set of operational metrics keeps the process honest and surfaces backlogs before they become breaches of the duty.
Track these as operational metrics, not a public dashboard. The point is internal assurance and early warning, not a scoreboard.
The Act allows a person to give, manage, review and withdraw consent through a Consent Manager: a specific entity that is accountable to the Data Principal and must register with the Data Protection Board. It is a defined statutory role, not a marketing tool.
Consent Manager registration under Section 6(9) is separately scheduled to commence on 13 November 2026. Until the regime is operational, withdrawal handling runs through your own channels.
| This | Is not this |
|---|---|
| DPDP Consent Manager (registered, accountable to the individual) | A cookie banner |
| DPDP Consent Manager | A consent-management platform (CMP) |
| DPDP Consent Manager | A CRM preference field |
Most withdrawal failures are not refusals. They are partial completions: the visible channel stops, something quiet keeps running. Each row pairs a failure with why it matters and a control that prevents it.
| Failure | Why it matters | Control |
|---|---|---|
| CRM updated, retargeting continues | Ad audiences still hold the person; processing did not actually stop | Purpose-to-system map that includes ad-tech |
| Email stops, SMS / WhatsApp continues | Cessation was channel-specific, not purpose-specific | Suppress across all channels for the purpose |
| Primary processor stops, downstream provider continues | Subprocessor never received the signal | Subprocessor visibility and propagation |
| Withdrawal treated as full account deletion | Over-deletion removes data the person still needs | Distinguish withdrawal from erasure at intake |
| Active account used to deny withdrawal | “You still have an account” is not a lawful basis to keep marketing | Purpose-specific handling, not all-or-nothing |
| Excessive identity verification | Heavy checks undercut the comparable-ease standard | Proportionate, documented verification |
| Consent state lost during migration | A platform move silently resets preferences | Consent state as a first-class migration item |
| Backup restores old consent state | A restore reinstates a withdrawn opt-in | Reapply withdrawals after any restore |
| Warehouse exports withdrawn users | Downstream jobs keep shipping the person’s data | Consent-aware filtering on exports |
| AI pipeline keeps receiving data | Consent-based training or evaluation continues | Gate AI feeds on current consent state |
| Processor provides no completion evidence | You cannot prove cessation if asked | Require confirmation as a contract term |
A customer of a retail mobile app keeps her account active but withdraws consent for promotional marketing and personalised recommendations. Here is what a complete response looks like, traced through the stack.
Concretely, the app and consent record update first; the CRM flag flips; email, SMS and WhatsApp suppress; the CDP stops feeding marketing and ad-tech audiences; the recommendation engine and analytics or warehouse jobs stop using her data for the withdrawn purposes; AI and ML pipelines drop her from consent-based feeds; transaction and tax records remain because they stand on their own legal footing; she goes onto the suppression list so she is not re-marketed; Data Processors are told to stop and confirm; and the whole thing is evidenced.
What continues in the middle column depends on each item genuinely having an independent basis. The example shows the shape of a good response, not a fixed legal conclusion for every business.
Telling the person what happened is good practice and reinforces the “comparable ease” posture. Keep it plain and specific about what stopped and what, if anything, is retained and why.
“We’ve processed your request to withdraw consent for marketing and personalised recommendations. You’ll no longer receive promotional messages or personalised suggestions, and we’ve asked our service providers to stop the related processing. Your account stays active, and we keep a limited set of records (such as order and tax records) only where the law requires it. If you have questions, you can reach us at [contact].”
This is example language to adapt, not text prescribed by MeitY or the Act.
Use this to pressure-test your own withdrawal handling. Grouped by phase so different owners can take different sections.
See where consent and withdrawal handling sits across your organisation.
Start the DPDP Readiness AssessmentA dedicated DPDP Consent Withdrawal Runbook is coming soon.
Under Section 6(6), the Data Fiduciary must, within a reasonable time, stop the affected consent-based processing and cause its Data Processors to stop, unless that processing independently remains required or authorised by law. Withdrawal must be as easy as giving consent was.
Not automatically. Withdrawal stops consent-based processing going forward. Whether data is then erased, restricted, suppressed or retained depends on whether it independently needs to be kept, for example for tax, KYC or an active service.
No fixed universal deadline. The Act says “within a reasonable time.” Businesses commonly set internal service levels, but those are governance targets, not statutory time limits.
No. An active account is not a lawful basis to keep processing a withdrawn purpose. Withdrawal is purpose-specific: the account can remain while marketing, personalisation and similar purposes stop.
Yes, where they process the affected data on your behalf. Section 6(6) requires you to cause your Data Processors to cease. Registers, notifications and acknowledgements are recommended controls that help you do and prove this.
No. Section 6(5) states that withdrawal does not affect the legality of processing done before it. The duty is forward-looking.
No. A statutory Consent Manager under Section 6(7) to 6(9) is a registered entity accountable to the individual. A cookie banner, CMP or CRM field is not the same thing. That registration regime is separately scheduled to commence on 13 November 2026.
The core Section 6 consent duties are notified but scheduled to commence on 13 May 2027. The Act and Rules are already notified, so 2026 is the window to build and test withdrawal handling.
This guide is general information about the DPDP framework, not legal advice. Confirm application to your organisation with a qualified Indian privacy-law adviser.