28 Sept 20265 min read

Consent Withdrawal Under DPDP Act Website & App Guide

Learn DPDP consent withdrawal requirements for websites and apps, including easy withdrawal, purpose-based consent, lifecycle tracking and audit-ready records.

By Karan Kashyap5151

Back to blogs

Collecting consent is only the beginning of consent management.

A customer may agree today to receive promotional emails, personalized offers, product updates or another service. Later, that same customer may decide that they no longer want their personal data processed for that purpose.

Your website or mobile application therefore needs to answer an important question:

Under India's Digital Personal Data Protection Act, 2023, where processing is based on consent, the Data Principal has the right to withdraw that consent. The Act states that the ease of withdrawing consent should be comparable to the ease with which consent was given. India Code

For businesses working toward DPDP Compliance, this means consent withdrawal cannot be treated as an afterthought. It needs to become part of the website, app and backend compliance architecture.

One of the biggest mistakes businesses can make is treating consent as a permanent permission.

A user may give consent, change a preference and later withdraw it.

That creates a lifecycle:

Your systems need to be capable of managing these changes.

For example, suppose a customer signs up on an e-commerce website and separately agrees to receive promotional messages.

Three months later, the customer decides to stop promotional communication.

The company should have a mechanism through which that preference can be withdrawn and appropriately reflected in the relevant processing operations.

This is why modern Consent Management Platform architecture needs to manage the complete consent lifecycle rather than simply record a “Yes” once.

Section 6 of the DPDP Act provides that a Data Principal may withdraw consent at any time.

Importantly, the Act says that the ease of withdrawing consent should be comparable to the ease with which consent was given. India Code

This principle has major implications for website and app design.

If a user can give consent through a simple online interface, businesses should be careful about creating an unnecessarily difficult withdrawal process involving multiple emails, calls or offline steps.

The consent experience needs to consider both sides:

Giving consent and withdrawing consent.

The final Digital Personal Data Protection Rules, 2025 add an important operational detail.

Rule 3 provides that the notice should give a particular communication link for accessing the Data Fiduciary's website or app, along with a description of other available means through which the Data Principal may withdraw consent, exercise rights and make a complaint to the Board. The withdrawal mechanism must reflect the comparable-ease principle. Rule 3 is scheduled to commence 18 months after the Rules were published on 13 November 2025. MeitY

For website and app teams, this means withdrawal should be designed as part of the user journey rather than hidden deep inside legal documentation.

There is no requirement that every organisation use exactly the same interface.

The right mechanism will depend on the service and how consent was originally collected.

For example, a business could provide consent controls through a customer account, privacy dashboard, consent-preference page, website widget or another clearly accessible digital mechanism.

What matters is that the mechanism works in practice and does not create unnecessary friction compared with how consent was originally provided.

A good DPDP Consent Management Platform can centralize this experience instead of requiring every application to build an independent consent system.

Consider a customer named Rahul.

Rahul visits an online store and provides his mobile number to receive information relating to his order.

He also separately opts in to promotional communication.

Later, Rahul decides that he no longer wants promotional messages.

He opens the website's consent preference interface and switches promotional communication off.

At this point, simply changing the button on the website is not enough from an operational perspective.

The business may also need the new consent state to reach its CRM, SMS platform, marketing automation system or other relevant applications.

This is where consent withdrawal becomes a technology problem as well as a user-interface problem.

Withdrawal Should Reach Connected Systems

Modern businesses rarely process personal data in only one application.

A website may send customer information to:

CRM software, email marketing systems, SMS platforms, customer-support applications, internal databases and Data Processors.

Suppose your website records:

But your marketing platform still contains:

Now the organisation has conflicting consent states.

The website says one thing.

The marketing system says another.

A centralized DPDP Consent Management Platform can help businesses maintain a consistent consent state and communicate consent events to connected applications.

This is another area where businesses need to understand the Act carefully.

Withdrawal does not mean that everything previously done on the basis of valid consent suddenly becomes unlawful.

The Act states that withdrawal does not affect the legality of processing based on consent before its withdrawal. It also places responsibility on the Data Principal for consequences arising from withdrawal. India Code

After withdrawal, the Data Fiduciary must, within a reasonable time, cease processing the personal data on the basis of that consent and cause its Data Processors to cease such processing, unless processing without consent is required or authorised under the Act or another applicable law. India Code

This distinction is important.

Some information may still need to be processed or retained where another applicable legal requirement permits or requires it.

Businesses should not treat consent withdrawal and data erasure as identical actions.

A user may withdraw consent for promotional communication while the company still needs certain information for another valid reason.

For example, transaction information may need to be retained to satisfy another legal obligation.

Your compliance architecture should therefore distinguish between:

Consent withdrawal — stopping processing that depends on the withdrawn consent.

Erasure — deleting personal data where the applicable requirements for erasure are met.

A well-designed DPDP Compliance Software system should help organisations manage these workflows separately.

Don't Hide the Withdrawal Option

One of the practical mistakes businesses should avoid is making withdrawal unnecessarily difficult to locate.

Imagine this journey:

Giving consent takes one click.

Withdrawing consent requires searching through a privacy policy, finding an email address, writing a request, waiting for support and completing several additional steps.

That design raises obvious concerns against the comparable-ease principle in Section 6. India Code

Businesses should instead design consent controls with the withdrawal journey in mind from the beginning.

Record the Withdrawal Event

A withdrawal mechanism should not simply change what the user sees on screen.

The backend should maintain appropriate evidence of the event.

Depending on the system design, useful consent history may include:

Consent ID, purpose, previous consent state, new consent state, timestamp, applicable notice or consent version, and downstream processing status.

This creates a traceable consent lifecycle.

If the organisation later needs to investigate a complaint or demonstrate how a consent preference was handled, this history becomes valuable.

What If a Downstream System Fails?

This is where basic consent tools can create a hidden compliance gap.

Imagine this sequence:

A customer withdraws consent.

Your Consent Management Platform records the withdrawal.

A webhook is sent to the marketing platform.

The marketing platform returns an error.

What happens now?

If nobody notices the failure, promotional processing could potentially continue.

A stronger compliance architecture should therefore consider:

Delivery tracking, retry mechanisms, acknowledgement, failure monitoring and escalation.

Recording the withdrawal is important.

Making sure the relevant systems act on it is the next challenge.

One Withdrawal May Affect Multiple Systems

A single consent withdrawal can trigger multiple actions.

For example:

A customer withdraws consent for promotional communication.

Your CRM may need an updated preference.

Your SMS system may need to stop campaigns.

Your email platform may need to remove the customer from the relevant marketing workflow.

An external Data Processor may need an instruction.

Your audit system should record what happened.

This is why consent management becomes increasingly complex as an organisation grows.

Suppose a customer has consented to three different purposes:

Product updates

Promotional SMS

Personalized offers

The customer may want to withdraw only promotional SMS consent.

A system that offers only:

Accept Everything / Withdraw Everything

may be too simplistic for a purpose-specific consent architecture.

Where consent is obtained for distinct specified purposes, businesses should be able to manage the relevant consent states appropriately.

Purpose-based consent management gives both the organisation and the Data Principal better control over the consent lifecycle.

Website and Mobile App Teams Need Backend Support

A beautiful consent-preference screen does not automatically create a complete compliance system.

The front end may allow the user to click:

But the backend needs to know:

Which user?

Which consent?

Which purpose?

Which systems are affected?

Which Data Processors are affected?

Was the event delivered?

Was the downstream action completed?

What evidence should be retained?

This is why DPDP Compliance requires coordination between legal, product, IT and compliance teams.

This is where Consent Server provides a structured solution.

Consent Server is a comprehensive DPDP Consent Management Platform designed to manage the complete consent lifecycle rather than only consent collection.

A website or mobile application can integrate Consent Server into the customer consent journey and maintain centralized consent records.

When a Data Principal withdraws consent, Consent Server can record the change and maintain the consent history.

Consent Server supports purpose-based consent.

Instead of treating consent as one generic approval, organisations can configure different purposes and allow consent states to be managed accordingly.

For example:

A customer could continue receiving service-related communication while withdrawing a separate consent used for promotional communication, depending on the applicable processing basis and configuration.

This provides a much more structured approach to consent management.

Consent Server provides APIs and webhooks for integration with websites, applications, CRM systems, marketing platforms and other enterprise systems.

When consent is withdrawn, the relevant event can be sent to configured downstream systems.

Consent Server's event framework can also support tracking of delivery, acknowledgement, retry, escalation and completion evidence where the integration supports those workflows.

This gives businesses greater visibility into what happened after the customer clicked Withdraw Consent.

Consent Server can maintain consent lifecycle information covering events such as:

Consent granted

Consent updated

Consent withdrawn

Consent renewed

Consent expired

Instead of overwriting the previous value, businesses can maintain a history of consent events.

This is particularly useful for audit readiness and investigating customer complaints.

Consent withdrawal is only one part of DPDP Compliance.

Consent Server also supports broader operational capabilities including Data Principal request workflows, grievance management, notice/version management, audit-ready records, role-based access control, reporting, APIs and webhooks, tamper detection and self-hosted/on-premise deployment.

This makes Consent Server a comprehensive option for businesses evaluating a Consent Management Platform, DPDP Consent Management Platform or DPDP Compliance Software in India.

Businesses often spend significant effort optimizing how customers give consent.

The withdrawal journey deserves the same attention.

A strong consent architecture should make it possible to:

Collect consent clearly.

Maintain purpose-specific consent states.

Allow consent to be updated or withdrawn.

Record the complete consent history.

Communicate changes to relevant connected systems.

Identify failures.

Maintain audit-ready evidence.

That is the difference between a simple consent checkbox and a complete consent-management architecture.

The DPDP framework makes consent withdrawal an important part of the consent lifecycle.

Businesses should therefore review their websites and mobile applications now.

Ask a simple question:

If a customer gives consent today and wants to withdraw it tomorrow, can our systems handle the entire process correctly?

If the answer involves emails, spreadsheets, manual database changes and disconnected applications, your consent architecture may need improvement.

Consent Server brings purpose-based consent, withdrawal management, complete consent lifecycle tracking, APIs and webhooks, downstream event visibility, Data Principal workflows and audit-ready records into one centralized platform.

For Indian businesses building structured DPDP Compliance, Consent Server provides a strong technology solution for managing consent from the moment it is given through updates, withdrawal, renewal and expiry.

Back to blogs

Consent Withdrawal Under DPDP Act Website & App Guide