Consent is the primary lawful basis under the DPDP Act, which means the humble consent form — and the system behind it — carries enormous weight. A consent flow that fails the Act's standard undermines the lawfulness of everything that follows, while a well-designed one provides a clean, defensible foundation for your processing.
Consent management is not just a one-time capture, either. It is an ongoing relationship: people must be able to see, manage and withdraw what they agreed to, and you must keep records that prove what happened.
This guide explains how to design a DPDP-compliant consent form, what consent records you need, how to handle withdrawal reliably, and how to prepare for the consent-manager ecosystem the Act envisages.
The sections below cover the standard for valid consent, how to design the form, the records to keep, reliable withdrawal, children's consent, and how to prepare for consent managers.
What valid consent requires
Under the Act, consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, and limited to the data necessary for the stated purpose. A consent form must be designed to meet every part of that standard.
This rules out pre-ticked boxes, bundled consent, and making a service conditional on agreeing to unrelated processing. The form must capture a genuine, deliberate choice.
Designing to this standard from the start is far easier than retrofitting a non-compliant flow once it is live and capturing thousands of consents.
Because consent underpins the lawfulness of so much processing, the consent form is one of the few places where a small design flaw can have outsized legal consequences, which is why it repays careful attention.
It helps to remember that the consent form is the visible front end of a larger system: the form captures the decision, but records, withdrawal handling and downstream propagation are what make that decision lawful and durable over time. Designing all of them together avoids a slick form backed by a broken process.
Designing the consent form
A compliant consent form presents a clear, itemised notice — what data, what purpose, how to withdraw, how to complain — and then captures agreement through an explicit action such as ticking an unchecked box or clicking a clear confirm button.
Granularity matters: where you process data for multiple purposes, offer separate consents rather than one sweeping permission, so people can agree to some uses and decline others.
Plain language and, where relevant, the user's own language make the consent genuinely informed, which is what the Act requires.
Testing the form with real users is worthwhile: if people cannot tell what they agreed to, or struggle to find how to withdraw, the flow has failed in spirit even if it is technically present.
Capturing consent records
Because the fiduciary must be able to demonstrate compliance, every consent should generate a record: what was agreed, when, on the basis of which notice version, and through what action. These records are your evidence if the Board ever asks.
Structured, timestamped consent logs — rather than transient form submissions — are what let you prove valid consent and reflect later withdrawals accurately.
Treat consent records as audit evidence to be retained and managed, not as throwaway data.
Treating consent records as durable audit evidence, stored and managed deliberately, is what separates a genuinely defensible consent practice from one that merely looks compliant on the surface.
Linking each stored consent to the exact version of the notice that was shown closes a subtle but important loop, because if your notice changes you can still prove precisely what each person saw and agreed to at the moment they consented.
Handling withdrawal
The Act requires that withdrawing consent be as easy as giving it. Your consent management must therefore offer a simple, accessible way to withdraw, and must propagate that withdrawal reliably through every system that processes the data.
On withdrawal, you must stop the relevant processing and cause your processors to do the same, unless another lawful basis applies. A withdrawal acknowledged but not actually enacted leaves you processing without a basis.
Engineering withdrawal as a system-wide event — not a manual flag — is what makes this reliable at scale.
Engineering withdrawal as a system-wide event — one that cascades to every downstream system and processor — is the single most overlooked requirement in consent management, and the one most likely to trip organisations up.
Consent for children
Where the data principal is a child, consent must come from a parent or guardian in a verifiable way, and your consent flow must incorporate age assurance and a verifiable-parental-consent path.
Because children's-data failures carry steep penalties, services likely to reach minors should build these protections in deliberately rather than assuming all users are adults.
A conservative default — routing users who cannot be established as adults into the protective path — is the safest design.
Because the penalties for mishandling children's data are among the Act's steepest, a conservative, protective default for any user whose adult status is uncertain is simply prudent risk management.
Age assurance need not be heavy-handed: combining declared age with contextual signals, and escalating to stronger verification only where the risk warrants, protects children without imposing friction on the adult users who make up most of your audience.
Free resource
Free DPDP Policy Templates
Privacy notice, consent and core DPDP policy documents you can adapt to your business.
Preparing for consent managers
The Act envisages registered consent managers that give individuals a single, interoperable way to manage consent across organisations. Designing your consent capture to produce clean, structured, interoperable records prepares you to integrate with that ecosystem.
Even before integration is widespread, building to this standard pays off: it makes your consent auditable, your withdrawals reliable, and your processing easier to justify.
Keeping consent architecture clean and modular means connecting to a consent manager later is a connection exercise, not a redesign.
Keeping consent architecture clean and standards-friendly now means that connecting to a registered consent manager later is a straightforward integration rather than a costly redesign of your whole consent stack.
Consent management as an ongoing system
Effective consent management treats consent as a living relationship: capture, record, surface, and allow withdrawal, continuously and reliably. It is a system, not a single form.
Preference centres that let people see and adjust what they have agreed to both satisfy the Act and improve the user experience, turning consent into something people feel they control.
Done well, strong consent management is not just compliant but a trust signal — visible evidence that you respect the choices people make about their data.
Visible, easy-to-use consent controls also send a quiet but powerful message: that the organisation treats people's choices about their data as something to respect rather than to work around — which is exactly the spirit that underpins credible dpdp compliance.
In the end, treating consent management as a continuous system rather than a one-off form is what keeps you lawful as people change their minds over months and years; a programme that captures consent beautifully but cannot reliably act on a withdrawal six months later has solved the easy half of the problem and ignored the hard one.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.