The Business Case for DPDP Act Compliance

Read Now

Get privacy insights in your inbox.

Compliance

DPDP Consent Management Requirements: A Practical Guide for Indian Enterprises

IQWorks ResearchSeptember 27, 202615 min read
Share
DPDP Consent Management Requirements: A Practical Guide for Indian Enterprises

Your website says a customer has agreed to receive marketing. But can you show which notice they saw, what they agreed to, when they agreed, and which systems are using that consent?

And if they withdraw it today, will the change reach your CRM, email platform, ad tools, and external processors, or only update one record?

These are the practical problems behind DPDP consent management. An EY survey found that 77% of organizations were not equipped to adopt privacy technologies such as consent management, data discovery, and rights-fulfilment tools.

For Indian enterprises, obtaining consent is just the first step. You also need to document it, use the data only for the stated purpose, and ensure that any withdrawal is applied everywhere the data is processed.

In this guide, I’ll break down the DPDP consent management requirements and show you how to implement them across your enterprise.

DPDP consent management means you need to manage consent through its full lifecycle, not just collect it.

For an enterprise, that means you need to:

  • Tell people what personal data you want to process and why before or when asking for consent.
  • Get consent through a clear affirmative action for a specific purpose.
  • Keep proof of the notice shown and the consent given.
  • Give people an easy way to withdraw consent.
  • Stop the processing that relied on that consent after it is withdrawn.
  • Make sure the withdrawal also reaches the processors using that data.
  • Keep consent, withdrawal, and related changes traceable across your systems.

The main challenge is connecting all of this. If consent is collected on your website but the data is later used in your CRM, marketing platform, or by an external processor, any change or withdrawal of that consent needs to reach the places where the data is being used.

Please note: The core DPDP consent provisions covered in this guide are scheduled to take effect on 13 May 2027.

DPDP consent management means collecting consent, recording it, and responding when someone changes or withdraws their choice.

For example, if a customer agrees to receive marketing emails, your business should be able to show what they agreed to, when they agreed, and which notice they saw. Their consent should remain tied to that specific purpose.

If they later withdraw consent, you must stop using their data for that purpose. You must also ensure that any processors relying on that consent stop processing the data.

In short, consent management keeps each person’s choice connected to how your business uses their data.

When your enterprise relies on consent under the DPDP Act, managing it goes beyond the moment someone clicks “agree.”

You need to show what the person was told, what they agreed to, the purpose of their consent, and what happens if they later withdraw it. You must also ensure their choice is respected across every system and processor handling the data.

Here’s what that involves:

Before asking someone for consent, your enterprise needs to be clear about what you want to use their personal data for.

Under the DPDP Act, consent must be specific and tied to a stated purpose. You should also collect only the personal data needed for that purpose. For example, if someone gives you their email address to receive a technical guide, that is one purpose. If you also want to send them product marketing or share their data with a partner, those are separate purposes and should not be bundled into the same consent.

For your enterprise, this means you should first map each purpose that relies on consent and the personal data needed for it. This gives you a clear base for the notice and consent request that come next.

Before someone agrees to the use of their personal data, they need to understand what they are agreeing to.

That is why the DPDP Act requires you to give a notice before or when you ask for consent. The notice should clearly explain what personal data you want to process and the specific reason you need it.

For example, if you ask a customer for their email address to send product updates, the notice should say that clearly. The customer should not have to guess why you need their email address or what you plan to do with it.

When Rule 3 takes effect on 13 May 2027, the notice must be clear and understandable on its own. It needs to tell the person:

  • An itemised description of the personal data being processed
  • The specific purpose or purposes for processing it
  • The goods, services, or uses that the processing will enable
  • A way to withdraw consent
  • A way to exercise rights under the DPDP Act
  • A way to make a complaint to the Data Protection Board

So, simply showing an “I agree” checkbox is not enough on its own. The required information needs to be presented before or when you ask for consent so the person can make an informed choice.

Once you have provided the required notice, the next step is to obtain valid consent. Under the DPDP Act, consent must be free, specific, informed, unconditional, and unambiguous. The person must actively and clearly choose to agree.

Silence, inactivity, or a pre-ticked box does not count as consent. You also cannot require someone to agree to an unrelated use of their data to access something they requested. The consent request must use clear, plain language and be available in English or any language listed in the Eighth Schedule to the Constitution.

For example, if someone provides their email address to download a guide, that does not mean they have agreed to receive marketing emails. They must separately and actively consent to that use.

If your enterprise relies on consent for a specific purpose, the person must understand the choice and actively agree to it.

If your enterprise relies on consent to process personal data, you need to be able to prove that the required notice was given and valid consent was obtained.

Under the DPDP Act, if a question about consent comes up in a proceeding, the Data Fiduciary must be able to show that the person received the required notice and gave valid consent.

The Act does not tell you to use a specific system or record format. What matters is that you can produce enough evidence to show what the person was told and that they agreed to it.

For example, simply having “consent: yes” in your CRM may not show which notice was given or what the person actually agreed to.

So, for your enterprise, consent should not only be collected. You need to keep enough proof to show that the consent was valid if it is later questioned.

Giving consent does not mean the person is locked into that choice. Under the DPDP Act, they can withdraw their consent at any time.

The process for withdrawing consent must be as easy as giving consent. For example, if a customer can give marketing consent online in a few clicks, they should not have to call support or go through a difficult process just to withdraw it.

For your enterprise, this means the option to withdraw consent should be easy to find and easy to use. The person should be able to change their choice without facing unnecessary steps.

When consent is withdrawn, your enterprise must stop the processing that was based on that consent within a reasonable time.

This also applies when a Data Processor is handling the personal data on your behalf. You need to cause that processor to stop the affected processing as well.

For example, if a customer withdraws marketing consent, the change should not stop at your CRM. Any processor still using that data for the same marketing purpose also needs to stop.

The key requirement is to make sure a withdrawal is actually followed wherever that consent is being relied on.

7. Handle Erasure and Data Retention After Withdrawal

When someone withdraws consent, your enterprise needs to decide what happens to the personal data you already hold.

Under the DPDP Act, personal data must be erased when consent is withdrawn or when the purpose is no longer being served, whichever is earlier, unless keeping the data is necessary to comply with another law.

That means:

  • Erase the data when consent is withdrawn or the purpose is no longer being served.
  • Keep the data if another law requires you to retain it.
  • If the data was made available to a processor, cause that processor to erase it when erasure is required.

So, withdrawal does not always mean “delete everything.” Some data may still need to be kept because another law requires it.

DPDP consent management works as a step-by-step process for managing a person’s choice from the first request through withdrawal. Each stage needs to connect with the next so your enterprise knows what was agreed to and can act when that choice changes.

Here is how the process works:

  1. Define the purpose - Decide why you need the personal data and what data is necessary for that purpose.
  2. Give the notice - Tell the person what personal data you want to process and why before or when asking for consent.
  3. Collect valid consent - The person actively agrees to that specific use of their data.
  4. Keep proof - Keep enough evidence to show that the required notice was given and consent was obtained.
  5. Use the data for the agreed purpose - Process the personal data according to the purpose the person agreed to.
  6. Act on withdrawal - If the person withdraws consent, stop the processing that relied on it and cause the processors involved to stop as well.
  7. Handle the remaining data - Erase the personal data when required, while keeping any data that another law requires you to retain.

In practice, these steps may happen across several systems. The real test of DPDP consent management is not whether your enterprise can collect consent. It is whether you can apply that choice wherever the data is being used and act on it when the choice changes.

That is what turns consent from a one-time form action into something your business can actually manage across its systems and processors.

Once you know what the DPDP Act expects, the next step is to make it work across your business. You need to know where you rely on consent, whether you can prove it, and what happens across your systems when someone withdraws it.

Start by listing the purposes for which you rely on consent. Then follow the personal data from where you collect it to the systems and processors that use it.

This could include your website, CRM, marketing platform, analytics tools, cloud systems, and external vendors. Doing this shows you exactly where each consent choice needs to be followed.

Next, look at your existing consent records.

For each consent, check whether you can show what the person agreed to, which notice they received, and the purpose their consent covered. Pay particular attention to older customer records where this evidence may be incomplete.

If you cannot clearly prove a consent, you have found a gap that needs attention.

Now look at what happens when someone withdraws consent.

The change needs to reach the relevant systems and processors that are relying on that consent. Otherwise, you could record the withdrawal in one place while the same consent-based processing continues somewhere else.

So your withdrawal process needs to work across the full data flow, not just where the person originally gave consent.

Finally, test it from beginning to end.

Take a sample record and check whether you can find the consent evidence. Then withdraw the consent and confirm that the affected processing stops, the relevant processors receive the change, and erasure happens where required.

If you can trace what someone agreed to, where that consent is being used, and what happens when they withdraw it, you have a consent process that can actually work in practice.

If you are looking for a tool to manage DPDP consent, you may see both Consent Manager and consent management platform (CMP). They sound similar, but they mean different things.

Under the DPDP framework, a Consent Manager is a person registered with the Data Protection Board. It gives Data Principals a way to give, manage, review, and withdraw their consent. A CMP is software a business can use to manage consent across its own website, apps, and other systems. Here is the difference:

AreaDPDP Consent ManagerConsent Management Platform (CMP)
What it isA person registered with the Data Protection BoardSoftware used by a business
Who uses itData PrincipalsBusinesses managing customer consent
What it doesLets people give, manage, review, and withdraw consentHelps businesses collect consent, keep records, manage preferences, and update connected systems
RegistrationMust be registered with the Data Protection BoardUsing a CMP does not make it a registered DPDP Consent Manager

If your business needs help collecting consent, keeping proof, managing preferences, and updating other systems when consent changes, a CMP can help with that work.

But not every CMP is a registered DPDP Consent Manager. So, before choosing a consent solution, be clear about whether you need software to manage consent inside your business or the services of a registered DPDP Consent Manager.

Under the DPDP Act, your enterprise must prove that consent was valid, allow people to withdraw it, and apply those changes where that consent is being relied on. The challenge is doing this across multiple systems while keeping all the evidence in one place.

A consent management platform can help you handle that work in one process. ConsentIQ by IQWorks, for example, is an end-to-end consent management platform that supports the consent lifecycle from collection through enforcement.

Consent analytics example by ConsentIQ
Consent analytics example by ConsentIQ

With ConsentIQ, you can:

  • Collect and manage consent through customizable banners and preference centers. 
  • Keep proof of consent showing when it was given, what the person agreed to, and how it was collected.
  • Let people change or withdraw consent through the preference center.
  • Pass consent changes to connected systems, including HubSpot, Salesforce, Zoho, Dynamics 365, Marketo, and LeadSquared.
  • Send consent signals to tools such as GTM, GA4, and Meta Pixel, so those systems can act on the current consent status.
    Vendor integration available on ConsentIQ
    Vendor integration available on ConsentIQ

So the DPDP Act sets the consent obligations, while a platform like ConsentIQ helps you run and track those consent processes across your systems.

Before you consider your consent process ready, check whether it works from the moment you ask for consent to the point where someone changes or withdraws it.

Use this checklist to spot any gaps: 

  • Purpose: Is each consent tied to a clear and specific purpose?
  • Notice: Can you show what notice the person received?
  • Consent: Can you show that they actively agreed to that purpose?
  • Proof: Can you prove what they agreed to and when?
  • Withdrawal: Can they withdraw consent as easily as they gave it?
  • Systems: Does a consent change reach every relevant system?
  • Processors: Can you make sure processors act on a withdrawal?
  • Erasure: Can you erase the data when required while keeping anything another law requires you to retain?
  • Testing: Can you trace a consent from collection through withdrawal?

If you cannot answer yes to any of these questions, you have found a gap in your consent process. 

Conclusion

For Indian enterprises, the harder part of DPDP consent management is not understanding the rulebook. It is making sure those rules still hold when consent moves through real business systems, teams, and vendors.

That is why the strongest setup is one where consent is not treated as a one-time record, but as an active instruction that can be checked, changed, and carried through the systems that depend on it.

ConsentIQ is built for that kind of setup, with consent records, preference management, CRM sync, and downstream consent signals in one platform.

If your goal is to turn DPDP consent requirements into a process your team can actually run day to day, ConsentIQ is worth a closer look.

Frequently Asked Questions

What is DPDP consent management?

DPDP consent management is the process of managing a person’s consent throughout its lifecycle. It covers how consent is requested, recorded, used, changed, withdrawn, and acted on across your systems and processors.

What makes consent valid under the DPDP Act?

Consent must be free, specific, informed, unconditional, and unambiguous, and it must be given through a clear affirmative action. The person should understand what they are agreeing to and for what purpose.

Do enterprises need to keep proof of consent under the DPDP Act?

If consent is questioned in a proceeding, the Data Fiduciary must be able to prove that the required notice was given and valid consent was obtained. The Act does not require a specific type of consent ledger or software for keeping this evidence.

Can a person withdraw consent under the DPDP Act?

Yes. A person can withdraw consent at any time, and withdrawing it should be as easy as giving it. Once consent is withdrawn, processing that depended on that consent must stop within a reasonable time, unless another legal basis requires or allows it to continue.

What is the difference between a DPDP Consent Manager and a consent management platform?

A DPDP Consent Manager is a person registered with the Data Protection Board that enables Data Principals to give, manage, review, and withdraw consent. A consent management platform is software an enterprise can use to manage consent within its own systems. Using a CMP does not make it a registered DPDP Consent Manager.

Free DPDP Implementation Workshop

A 90-minute session for your team, on-site or remote: the DPDP Act applied to your organization, a 90-day roadmap, and the top five actions per department.

Book the workshop

Related Articles