At a glance
A DPDP-ready consent flow asks for each purpose separately, in plain language, at the moment the data is needed — not as one bundled “I agree” wall at signup. Nothing is pre-ticked, each purpose can be accepted or declined on its own, the app still works if optional consents are refused, and withdrawing later is as easy as granting was. The visible screen is only half of it; a stored, timestamped record of what each user agreed to is what proves it.
Educational resource only. This explains how to design an in-app consent flow in line with India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.
The situation
Your app collects data for several reasons — the core service, analytics, marketing, maybe a third-party integration — and the easy thing is to roll them all into one “I agree to the Terms and Privacy Policy” checkbox at signup. That single checkbox is the most common consent-flow mistake in Indian apps. Designing this properly isn’t about legal wording; it’s an interaction-design problem, and the screens you build decide whether the consent you collect is worth anything.
Why the signup “I agree” wall fails
One checkbox covering everything gives you consent for nothing in particular. Section 6 of the DPDP Act requires consent to be free, specific, informed, unconditional and unambiguous, and given for a defined purpose. A bundled “I agree” fails “specific” by construction — the user can’t accept the core service while declining marketing, so the consent isn’t free either. It also fails “informed,” because a link to a policy nobody opens isn’t the same as telling someone what they’re agreeing to at the moment they agree. And because gating the whole app behind accepting optional processing makes the service conditional on that acceptance, the wall trips “unconditional” too. The design goal is the opposite of the wall: separate the asks, and let the necessary ones through without forcing the optional ones.
What a valid consent ask actually contains
Each consent ask is a tiny notice plus a genuine choice — both halves, or it doesn’t count. For every purpose you ask consent for, the screen has to carry, in plain language: what data you’re collecting, the specific purpose you’ll use it for, and a real way to say no — plus a pointer to how the person can withdraw later and reach your grievance contact. “To improve your experience” is not a purpose; “to send you order-status notifications on WhatsApp” is. The ask should sit as close as possible to the action it enables, so the person has the context to decide. A consent screen that states the purpose but offers no working decline, or offers a decline but hides the purpose behind a policy link, is only half-built.
Consent-screen patterns that work — and ones that don’t
The same flow can be compliant or not depending on small interaction choices — these are the ones that matter:
- Granular toggles, all off by default — one switch per purpose, each independently acceptable or refusable.
- Pre-ticked switches — a toggle already on isn’t an affirmative act, so it isn’t consent.
- Just-in-time prompts — ask for location when the map feature opens, contacts when the invite feature is used, not all upfront.
- Everything demanded at signup — front-loading every permission before the user has any context is the wall in a new outfit.
- Core service works if optional consents are declined — refusing marketing or analytics doesn’t lock the person out.
- “Accept all to continue” — making optional processing a condition of using the app fails the free/unconditional test.
- Withdraw is one reachable screen — a settings page where every consent can be turned back off.
- Withdrawal by email-only request — if turning it off is harder than turning it on, the consent wasn’t free to begin with.
Use the templateDPDP consent form template — a ready-to-adapt structure for the wording of each consent ask (data, purpose, choice). Adapt the field-level language into your screens rather than writing each prompt from scratch.
Step by step: designing the flow
Map the purposes, then design one honest ask per purpose.
- List every purpose your app processes personal data for — core service, analytics, marketing, personalisation, third-party sharing. This list is the skeleton of the flow; each item is a potential separate ask.
- Split the necessary from the optional. Data genuinely required to deliver what the user asked for can often rest on legitimate use or is inherent to the service; everything else needs its own opt-in. Be honest about which is which — “necessary” is not a label of convenience.
- Place each ask at its natural moment, just-in-time, not all at signup. The permission prompt appears when the feature that needs it is first used.
- Design each ask with all three parts — the data, the plain-language purpose, and a real accept/decline — plus the withdrawal and grievance pointers in reach.
- Default everything to off. No pre-ticked boxes, no toggles pre-switched-on. Consent starts from nothing and is added by the user’s action.
- Make the app degrade gracefully when an optional consent is declined — the feature that needed it is unavailable, but the rest of the app works.
- Build the withdrawal screen at the same time as the opt-in — a single settings surface listing every consent with a working off switch. Treating withdrawal as a later feature is how it never ships.
Proving and honouring consent after the tap
A consent flow isn’t finished at the screen — it’s finished when the choice is stored and the app acts on it. Every acceptance needs a record: which purpose, the exact consent text and version shown, and when. That record is what lets you demonstrate valid consent if you’re ever asked, and the burden of proving it sits with you. Just as important, the app has to actually behave according to the record — if someone declines marketing, the marketing pipeline must read that and stop, and a later withdrawal must propagate the same way. A beautiful consent screen wired to a backend that ignores the answer is worse than no screen at all, because it manufactures a record of consent the system then disregards.
FAQ
Can I ask for all permissions at signup to get them over with?
You can present them, but bundling them into one unavoidable “accept to continue” fails the specific and unconditional tests. Ask for each purpose separately, and ask for feature-specific permissions when the feature is first used, not upfront.
Is a link to my privacy policy enough to make consent “informed”?
No. A policy link is background reference; the consent ask itself has to state, in plain language and at the point of asking, what data is collected and why. Informed means informed at the moment of the decision.
Do necessary functions need a consent toggle?
Data that’s genuinely required to deliver the service the user requested often rests on legitimate use rather than a separate opt-in — but be strict about what counts as necessary. Analytics, marketing and third-party sharing are not necessary functions.
How do I handle withdrawal in the UI?
Build a settings screen that lists every consent the user has given with an off switch for each, and make sure flipping it off actually stops the downstream processing. Withdrawal has to be as easy as the original opt-in was.
What should I actually store when someone consents?
The purpose consented to, the exact consent wording and version they saw, and a timestamp — enough to reconstruct what the person agreed to and when, so you can prove valid consent and honour a later change.