DPDP / Consent Withdrawal

Consent Withdrawal Workflow

CA Nikhil Gupta·May 2026·3 min readDPDP / Consent Withdrawal

Build a consent-withdrawal process that stops optional processing, updates vendors, preserves legal records, confirms closure and prevents future re-enrolment.

Consent is incomplete until the user can withdraw it through a practical, traceable and comparable process.

Quick View

Decision

Connect the withdrawal request to every system, campaign, processor and retention exception before closing the case.

First action

Create a single withdrawal request channel.

Core evidence

Consent event and notice version.

Main warning

Withdrawal hidden in account deletion.

Why It Matters

The Digital Personal Data Protection Act, 2023 and the final Rules notified in November 2025 follow phased commencement. As of 25 June 2026, organisations should separate duties already operative from consent, grievance, rights, children, Significant Data Fiduciary and other operational provisions scheduled for later commencement, while continuing to comply with the IT Act, CERT-In directions and sector-specific rules already in force.

Section 6 of the DPDP Act states that withdrawal should be as easy as giving consent and that the Data Fiduciary must cause processors to stop consent-based processing within a reasonable time, unless another law authorises continued processing.

Withdrawal does not make earlier lawful processing unlawful, and it does not automatically require deletion of records that must be retained for tax, fraud, contract, insurance, banking or other legal reasons.

Control Framework

AreaWhat to establishOperating rule
IntakeUser, channel, purpose and consent record.Open one traceable case.
ScopeProcessing based on consent versus another lawful route.Separate before stopping.
PropagationCRM, analytics, marketing and processors.Send and verify stop instructions.
ClosureUser confirmation, suppression and retained exceptions.Keep evidence.

Action Checklist

  1. Create a single withdrawal request channel.
  2. Verify the requester proportionately.
  3. Locate the original consent purpose and version.
  4. Stop future consent-based processing.
  5. Notify processors and campaign tools.
  6. Confirm closure and record lawful retention exceptions.

Practical Example

A user withdraws marketing consent in the mobile app, but the CRM exports the same contact to a messaging vendor the next morning because the suppression list is not synchronised.

Evidence to Keep

  • Consent event and notice version.
  • Withdrawal request ticket.
  • System and vendor stop logs.
  • Suppression-list update.
  • Retention exception memo.
  • Closure communication.

Warning Signs

  • Withdrawal hidden in account deletion.
  • Stopping one channel only.
  • No processor confirmation.
  • Deleting legally required records.
  • Re-importing suppressed users.

Detailed Review

A reliable control should connect the individual, data field, purpose, notice or sector disclosure, system, employee access, vendor access, retention rule and closure evidence. A policy statement that cannot be traced through this chain is difficult to operate.

Maintain a legal-timing matrix. Record the DPDP provision, phased commencement status, current IT Act or sectoral duty, business owner, system dependency and implementation deadline. Avoid one blanket label such as compliant or not compliant.

Build controls into technology and workflow. A written instruction cannot stop an SDK from collecting contacts, a campaign tool from re-importing suppressed users or an agent from downloading medical records unless the system enforces the decision.

Use proportionate verification. Weak checks can expose another person’s information; excessive checks create more Aadhaar, health, payroll or bank data that must be protected and deleted later.

Generate evidence during ordinary operations: versioned screens, event logs, access approvals, vendor tickets, complaint chronology, deletion reports, test recordings and management decisions.

Run a negative-path test: refusal, withdrawal, account closure, vendor breach, employee exit or child-user flow. The control should continue to protect data outside the happy path.

Management reporting should show overdue actions, repeat complaints, failed tests and residual risk rather than only the publication of policies.

Control Test

Select one real user or transaction journey and trace it from collection through sharing, access, retention, withdrawal, complaint or closure. Capture the evidence at each stage.

Test the control on production-like systems rather than screenshots alone. Review network traffic, event logs, suppression status, vendor responses, role access and deletion output.

Run an adverse scenario: the vendor is breached, the user is a child, the borrower alleges harassment, the employee leaves or the app permission is revoked. Record the response and gaps.

Compare public wording with actual behaviour. Product forms, call scripts, privacy notices, contracts, SDKs and support tools should tell the same story.

Assign a named owner, funded action and closure date to each gap. Retain the reason when management accepts residual risk or chooses a less intrusive alternative.

Escalation Route

Start with the privacy, security, product or regulated-business owner and preserve system evidence before changing configuration or deleting records. Separate current sector and CERT-In obligations from future DPDP readiness.

For serious complaints, children’s data, financial harassment, medical exposure or suspected cybercrime, involve qualified legal, privacy, cyber, banking, insurance or healthcare specialists and use the applicable official channel.

Frequently Asked Questions

Must withdrawal be as easy as consent? â–¼
The Act requires comparable ease when the relevant provision commences.
Does withdrawal require immediate deletion of everything? â–¼
No. Processing should stop where consent was the basis, subject to lawful retention or another permitted basis.
Who must stop processing? â–¼
The Data Fiduciary and processors acting on its behalf.
How should closure be proved? â–¼
Through ticket, system logs, vendor confirmation, suppression status and user response.