DPDPA Consent Withdrawal: How Propagation Must Work End-to-End

Section 6(4) of the Digital Personal Data Protection Act 2023 gives Data Principals the right to withdraw consent "at any time" and requires that withdrawal be "as easy" as giving consent. Section 6(5) addresses the consequences: withdrawal does not affect the lawfulness of processing that occurred before withdrawal, but processing must cease on withdrawal.

These two provisions together define a complete withdrawal obligation: a mechanism that is accessible and simple (not buried in settings); cessation of processing for the withdrawn purpose from the point of withdrawal; and propagation to downstream processors who were processing on the basis of that consent.

The withdrawal obligation in DPDPA is more operationally demanding than the equivalent right in many global privacy laws because of two factors: the "as easy as" standard creates a UX requirement, not just a legal one; and the downstream propagation to processors is explicit, not implied. Both of these require architectural decisions, not just policy decisions.

The "as easy" standard is a functional test, not a checkbox. If consent was given via a single tap on a mobile app consent screen, withdrawal must be achievable in a comparable number of steps from a comparably accessible location. If consent was given via a website pop-up, withdrawal must be available via an equally prominent mechanism.

Common withdrawal implementations that fail this standard:

• Requiring the user to send an email to a support address — consent was one click, withdrawal requires composing an email
• Placing the withdrawal option three screens deep in account settings — accessible in theory, but not "as easy" as the consent collection flow
• Requiring a phone call to withdraw — practically inaccessible for users who don't speak the support agent's language
• Withdrawal forms that require additional verification steps beyond what consent collection required — creating friction asymmetry

The test to apply is: if a regulator looked at the withdrawal mechanism alongside the consent collection mechanism, would they describe them as comparable in ease of access? If not, the withdrawal mechanism needs to be redesigned.

When a Data Principal withdraws consent for a specific purpose, the Data Fiduciary must cease all processing of personal data for that purpose. Critically, "cease" does not mean "stop collecting new data" — it means stop all processing: stop using existing data for that purpose, stop sharing it with processors for that purpose, and stop any derived processing that builds on the now-withdrawn consent.

The scope of cessation depends on the granularity of the consent architecture. If consent was collected at the purpose level — separate consent records for "marketing communications," "product personalisation," and "analytics" — then a withdrawal of the "marketing communications" consent stops only marketing processing, while product personalisation and analytics continue.

If consent was collected as a single bundled consent covering all purposes, a withdrawal of that consent stops all processing — which is why purpose-specific consent architecture is both a DPDPA requirement and a business risk management consideration. Bundled consents that get withdrawn take down all processing purposes simultaneously.

One important clarification: withdrawal does not require erasure. The Fiduciary may retain the personal data if there is another legal basis for retention (a legal obligation, a contractual relationship, another valid deemed consent basis). But they cannot process it for the withdrawn purpose.

The hardest part of withdrawal compliance is not the withdrawal mechanism itself — it's the downstream propagation. Every Data Processor who received personal data on the basis of the withdrawn consent must also cease processing. This requires a real-time, auditable propagation system.

The technical components of downstream propagation:

• A processor registry linked to consent purposes: For each consent purpose, a record of which processors receive data under that purpose, including their API endpoints for withdrawal notification
• Webhook or API integration with each processor: On withdrawal, a machine-readable withdrawal event must be sent to each processor in the registry for that purpose
• Delivery confirmation and retry logic: The propagation system must confirm that each processor received the withdrawal signal, with retry on failure and escalation if delivery cannot be confirmed
• Propagation audit trail: For each withdrawal, a logged record of which processors were notified, at what time, and what their confirmation response was

Manual propagation — a human emailing vendor contacts when a withdrawal is received — does not scale and does not create the audit trail the Data Protection Board might require. Automated, API-driven propagation is the only viable approach for organisations processing consent at any meaningful volume.

DPDPA does not specify a maximum time for withdrawal to take effect. The Act says processing must cease "consequent to" withdrawal — implying promptness but not specifying a deadline. The DPDP Rules 2025 also do not set a specific withdrawal propagation timeline.

In the absence of a specified deadline, best practice from comparable jurisdictions applies. GDPR does not specify a timeline either, but supervisory authority guidance generally treats "without undue delay" as meaning within 24–72 hours for the first-party cessation and within a reasonable period (typically 1–2 weeks) for downstream processor propagation, accounting for the practicalities of notification and system updates.

For India, a reasonable target that would withstand Data Protection Board scrutiny:

• First-party processing cessation: immediate or within 24 hours of withdrawal
• Processor notification: within 24–48 hours of withdrawal
• Processor confirmation of cessation: within 7 days of notification

Any withdrawal that takes longer than this — or that has no audit trail showing when it was propagated — creates enforcement exposure if a Data Principal complains to the Board that their withdrawal was not honoured.

End-to-end withdrawal infrastructure has three layers: the user-facing withdrawal mechanism (the "as easy as" layer), the consent management system that records the withdrawal and triggers propagation (the orchestration layer), and the processor notification system with delivery confirmation (the propagation layer).

Consentica by OpenBlockAI is built around exactly this three-layer architecture. The user-facing withdrawal can be embedded in any channel — app, web, IVR, SMS — matching the form factor of the original consent collection. The Consentica consent management system records the withdrawal with timestamp and scope, immediately triggers the propagation workflow to all registered processors for the withdrawn purpose, and logs delivery confirmations to the immutable audit trail. If a processor fails to confirm receipt, the system escalates automatically rather than silently failing.

For organisations with complex processor chains — dozens of SaaS vendors, multiple downstream data recipients — this automation is what makes compliance at scale operationally viable. Without it, withdrawal compliance depends on manual processes that break down precisely when volumes are highest.