When Consent Is Withdrawn: Revocation, Data Access and Customer Communication

A customer taps withdraw on a marketing consent toggle. From that moment, DPDPA Section 6 sets a specific standard for what your systems need to do next, and meeting it takes more engineering work than most compliance checklists suggest.

This article walks through what Section 6 actually requires, why the requirement is harder to satisfy than flipping a status flag, and how withdrawal ties into the deletion obligations under Section 8(7). If you manage consent for a Data Fiduciary handling meaningful customer volume, the gap between what the law asks for and what a typical tech stack delivers is worth understanding in detail.

What the Law Actually Asks For

Section 6(4) of the DPDPA gives every Data Principal, your customer, user, or subscriber, the right to withdraw consent at any time. No justification required. The same subsection requires the withdrawal procedure to be as easy as the one used to give consent in the first place.

Section 6(5) covers what happens next on the legal side: the consequences of withdrawal are borne by the Data Principal, and any processing that took place before the withdrawal stays legal. Section 6(6) is where the real obligation sits. It requires the Data Fiduciary, and any Data Processors working on its behalf, to stop processing within a reasonable time.

What "Reasonable Time" Means in Practice

The Act does not define reasonable time in hours or minutes, and that gap is where interpretation gets tested. A withdrawal that takes a week to work through your systems will struggle to pass as reasonable once regulators start comparing response times across similar organisations. Aim for as close to immediate as your architecture allows. Treat reasonable as a floor, not a target.

Picture the sequence that has to fire when a customer withdraws consent. The consent record updates in the system of record. The cache layer your live systems actually query gets invalidated. Every downstream system relying on consent status receives the updated state. Any operation already queued against the old consent gets pulled before it runs. Four steps, and each one has to complete quickly for the sequence to count as reasonable.

Why Consent Status Can Lag Behind a Withdrawal Request

Consent status for a large customer base rarely comes straight from a primary database. Most teams cache it, often in something like Redis, because querying the primary database for every permission check would slow the whole system down. That is sound engineering. It is also the one place a withdrawal can quietly fail to take effect on schedule.

Say a customer withdraws consent. The database updates correctly, but the cache entry does not get invalidated at the same moment. For a window of time, however short, the enforcement layer keeps handing out a stale yes. Your compliance dashboard can show the correct status while live systems are still acting on the old one. Closing that gap sits inside Section 6(6), not outside it as an optional extra.

How to Propagate a Consent Withdrawal Across Connected Systems

A single withdrawal event usually needs to reach several systems at once: marketing automation, SMS providers, personalisation engines, analytics tools, and any data warehouse feeding reports downstream. Each one needs to learn about the change close to the moment it happens, not at the next scheduled sync.

Event-driven architecture solves this reliably at scale. A consent change publishes to a message broker the instant it occurs, and every subscribed system reacts on its own, rather than waiting for a batch job to catch up. Building this takes more setup work upfront than a periodic sync. It is also the difference between a system that looks compliant on paper and one that behaves that way when a regulator checks. A real-time CRM consent sync approach follows the same principle for teams managing consent inside customer relationship platforms, and DPDPA opt-out management software applies the same logic when an opt-out has to reach every marketing channel at once.

Withdrawal Often Means Deletion Too

Withdrawing consent does not stop at halting future messages. Section 8(7) of the DPDPA requires a Data Fiduciary to erase personal data once consent is withdrawn, or once it is reasonable to assume the specified purpose is no longer being served, whichever comes first, unless retention is required under another law.

That puts a real decision in front of your team, not a formality. Someone has to check, category by category, whether any other lawful basis still covers that data before deletion gets scheduled. Skip that check, and deletion either happens too early, breaking a legitimate retention need, or too late, breaking Section 8(7).

The same infrastructure question comes up during breach preparedness: how quickly each system in your stack can respond once an event fires.

Our guide to data breach notification under DPDPA works through that question from the breach-response side.

What Should a Withdrawal Confirmation Tell the Customer?

Once withdrawal goes through, tell the customer, clearly and fast. A good confirmation covers four things: what they just withdrew, when it takes effect, what changes for them in practice, and how to re-grant consent if they change their mind later.

A silent withdrawal process leaves the customer wondering whether anything happened at all. A clear confirmation message costs almost nothing to build and turns the moment into a small deposit of trust instead of a black hole.

How Easy Must Consent Withdrawal Be Under DPDPA Section 6(4)?

The Act sets a specific comparability standard. If a customer can give consent with one tap, withdrawing it should take one tap too. A support ticket, a five-screen settings maze, or a form that gets emailed and processed by hand all fall short.

Run this audit yourself: open your own consent flow, then try to withdraw the same way a customer would. If the two journeys do not mirror each other step for step, that mismatch is usually the first thing worth fixing.

Building Withdrawal Into a DPDPA Compliance Programme

Cache invalidation, event propagation, deletion workflows, and clear customer communication need to work as one coordinated system, not as four separate checkboxes. Building that well takes real engineering time.

Teams that invest in it see fewer complaints, fewer escalations tied to data subject requests, and a customer base that notices when a company treats their choices with respect. Managing consent withdrawal well is more than updating a status field. A reliable consent management platform records withdrawals, keeps an auditable consent trail, and keeps every downstream system synchronised with what the customer actually chose.

Next Steps

OneConsent is built around DPDPA-focused consent management, helping you keep withdrawal, deletion, and communication workflows consistent across every connected system. Visit the OneConsent homepage to explore the platform, or book a DPDPA consultation to see how your current withdrawal process holds up against the Section 6(6) reasonable-time standard.