Consent Under the DPDP Act: What Does It Actually Look Like in Practice?
Designing a consent screen can look deceptively simple.
Explain why personal data is required. Present the relevant information. Add a checkbox, toggle or button. Capture the individual's choice.
But when an organisation actually begins implementing consent, the difficult questions start appearing.
What exactly is the individual consenting to? Are different purposes sufficiently clear? Is consent actually required for every activity? Can optional processing be separated from the core service? What happens when consent is withdrawn? And can the organisation later demonstrate what the individual was told and what they agreed to?
This is where privacy moves from policy to practice.
Start With the Purpose, Not the Consent Button
A common implementation mistake is to begin with the user interface.
The better starting point is the processing itself.
Before deciding how consent should be presented, the organisation needs to understand:
What personal data is being collected?
Why is it required?
How will it be used?
Which systems and parties will process it?
How long will it be needed?
Does this particular processing activity require consent?
Only after answering these questions does it make sense to design the consent journey.
Otherwise, organisations risk creating a technically polished consent screen without first establishing what the consent actually represents.
One Consent Should Not Become Permission for Everything
Modern digital services rarely use personal data for just one purpose.
Consider a hypothetical financial platform.
It may need certain information to provide its primary service. The same organisation might also want to use information to provide personalised insights, improve algorithms, develop AI capabilities or introduce additional features.
These activities should not automatically be treated as one indistinguishable purpose simply because they occur within the same application.
The implementation exercise therefore needs to move from:
“We need the customer's consent.”
to:
“Consent to what, exactly?”
That small change in the question can expose significant differences in how personal data is being processed.
Notice and Consent Need to Work Together
A consent button by itself says very little.
The individual needs appropriate information to understand the choice being presented.
This is where the privacy notice and the consent mechanism need to work together.
The challenge is to provide enough information for an informed decision without turning the experience into pages of legal language that few people will realistically understand.
Good implementation therefore requires collaboration between privacy, legal, business, technology and user-experience teams.
The objective should not simply be to display information.
It should be to enable an understandable choice.
The Consent Screen Is Only the Front End
Perhaps the most important implementation lesson is that consent management does not end when somebody clicks a button.
That is actually where the operational requirement begins.
Behind the interface, the organisation may need to know things such as:
Who provided the consent?
What purpose did they consent to?
What information or notice was presented?
Which version was presented?
When was the consent provided?
Has the choice subsequently changed?
Has consent been withdrawn?
This means consent management potentially touches customer applications, identity systems, databases, marketing platforms, analytics systems, AI services and other downstream processes.
A beautifully designed consent screen therefore means little if the organisation cannot reliably translate the individual's choice into its processing environment.
Withdrawal Is a Workflow, Not Just a Link
Providing an option to withdraw consent is only the visible part of the requirement.
The harder question is:
What happens after the person withdraws it?
The organisation needs to understand which processing activities are affected, which systems need to receive the updated instruction and what should happen to personal data already held.
This becomes particularly challenging where information has travelled through multiple applications, processors or analytical systems.
A withdrawal mechanism therefore needs an operational workflow behind it.
The objective isn't simply to record “consent withdrawn.”
It is to ensure that the individual's changed choice is appropriately reflected in the processing that depended upon that consent.
Test the Journey From the Data Principal's Perspective
Privacy teams naturally examine consent through the requirements of the law.
There is another useful test: experience the process as the Data Principal.
Ask:
Do I understand what I am agreeing to?
Can I distinguish between different purposes?
Do I understand which choices are optional?
Can I change my decision later?
Is withdrawing my consent reasonably straightforward?
Then repeat the exercise from the organisation's perspective:
Can we demonstrate the choice that was made?
Can our systems actually honour it?
Those two perspectives need to meet.
From the Consultant's Desk
One of the most useful exercises during a privacy implementation is to stop looking at the consent journey as a compliance screen and start walking through it as the individual whose personal data is being collected.
The questions change quickly.
Instead of asking:
“Have we added consent?”
we start asking:
“Does the person understand what they are agreeing to, can our systems honour that choice, and can we demonstrate it later?”
That is the difference between displaying consent and operationalising consent.
Consent Is a Process, Not a Button
DPDP implementation will require organisations to translate legal and privacy requirements into processes that work across people, technology and business operations.
Consent is a good example of why that matters.
The visible screen may be where the individual makes the choice.
But effective consent management begins much earlier—with understanding the data and its purposes—and continues much later through records, downstream controls, withdrawal and governance.
The button captures the choice.The organisation still has to make that choice work.
