Withdrawing consent should be as easy as giving it

The sign-up took one tap. Leaving requires a phone call during office hours, a printed form and repeated explanations to different staff. That imbalance is exactly the kind of friction a business should examine when preparing a consent-withdrawal process.

Section 6(4) of the DPDP Act provides for withdrawal at any time with ease comparable to giving consent. Section 6(6) addresses stopping processing by the fiduciary and its processors within a reasonable time, subject to processing required or authorised by law. As of 22 October 2026, these provisions are scheduled for the May 2027 phase under the commencement notification.

Measure the whole journey

Comparable ease is not just the number of clicks on the first screen. Examine whether the route is discoverable, whether the customer can use their usual channel, what verification is needed and whether the outcome is understandable. A prominent button that leads to an unmonitored inbox is an incomplete implementation.

Start with the route through which consent was obtained. If a customer chose an optional newsletter in an app, consider a clear preference control in that app and the communications they receive. If consent was collected at a counter, ensure staff can explain and receive withdrawal without sending the customer through an unrelated technical process.

The final notice rule requires particular links and other available means for withdrawal. Those routes should point to a functioning service, with an owner and an escalation path when the normal process fails.

Separate withdrawal from deleting an account

Imagine a hypothetical fitness studio. A member withdraws consent to promotional messages but wants to keep attending classes. The studio should identify the relevant purpose rather than close the entire membership by default.

The reverse also matters. Deleting an account may not automatically communicate withdrawal to every external campaign tool if the systems are poorly connected. The business needs to understand what each control actually triggers and describe it accurately.

Where withdrawal affects a service, explain the consequence in plain language. Section 6(5) recognises that consequences may follow and that earlier lawful processing is not retrospectively invalidated. That does not justify making unrelated services conditional on optional permission or using vague threats to discourage a change.

Build a purpose-level instruction

A useful internal event identifies the person, purpose, scope, time and source of the withdrawal. It should reach the systems and processors using the data for that purpose. The precise event format is a design choice, not a mandatory statutory schema.

For the studio, the event may update the main customer record, remove the member from a scheduled campaign and instruct the messaging provider. Someone should check whether a recent spreadsheet export remains in use. The task is not complete merely because the preference page displays “off”.

Record completion and exceptions. If a downstream provider fails to apply the instruction, the team needs a retry and escalation route. Silent failure is especially difficult to explain when the customer continues receiving the very messages they withdrew permission for.

Retention needs a separate explanation

Withdrawal does not necessarily require immediate destruction of every record. Legal retention requirements and the final Rules’ retention provisions need reconciliation with the erasure duties. Rule 8(3) includes at least one year of retention for Seventh Schedule purposes in the later framework.

The studio might retain a payment record for an applicable legal reason while removing the member from optional campaigns. The retained record should not continue to feed the withdrawn use merely because it remains stored. Restrict access and secondary use according to the documented reason for keeping it.

Explain this distinction without overwhelming the customer. Identify the category retained, the reason and the relevant period or trigger where known. Avoid a generic statement that the business “may keep anything required” when it can give a more useful answer.

Test withdrawal before promising it

Use a dummy member record and follow the process from the customer interface through scheduled exports and vendor confirmation. Repeat with an account that has changed its email address and with a request received by frontline staff. Those cases test whether the identity mapping and handoffs actually work.

Choose an internal completion target that supports the legal requirement and the operational risk. Do not invent a universal statutory twenty-four-hour withdrawal deadline when the Act uses a reasonable-time standard.

The strongest evidence is a completed journey: a discoverable route, a clear decision, instructions reaching the right systems and a checked result. That is what turns a withdrawal promise in a notice into a service the customer can use.