The Digital Personal Data Protection Act 2023 places consent at the heart of personal data processing. Unlike older compliance cultures where a long privacy policy page was considered sufficient, the DPDP Act requires consent to be a deliberate, documented, and reversible act. This guide walks through what valid consent means under Section 6, the anatomy of a compliant flow, and the consent log structure that surfaces when the Data Protection Board asks for evidence.
For the wider compliance programme this fits into, see our 90-day DPDP roadmap. The consent mechanism is Step 5 of that programme.
1. What Valid Consent Means Under Section 6
Section 6 of the DPDP Act defines valid consent with five attributes. All five must be present; missing any one invalidates the consent.
Free
Not coerced or conditional on a service the user is otherwise entitled to. Consent extorted from a user to access a public service is not free.
Specific
Tied to a clearly stated purpose, not blanket collection. "For business purposes" is not specific.
Informed
The data principal must have seen and understood the notice. Notice must accompany the consent ask, not sit behind an unread link.
Unconditional
No bundled consent. Cannot bundle multiple unrelated purposes into one tick. Each purpose needs its own affirmative action.
Unambiguous
An active affirmative action -not a pre-ticked box, not silence, not continued site usage.
+ Withdrawable
Withdrawal must be as easy as giving consent. Implied in Section 6 and required by Section 7.
Free, Specific, Informed, Unconditional, Unambiguous -and Withdrawable on the same effort budget. If your withdrawal flow takes 5 minutes when consent took 5 seconds, you have a Section 7 failure.
2. The Anatomy of a Compliant Consent Flow
Show the notice before collecting data
The consent request must be accompanied by a privacy notice -written in clear, plain language. The notice tells the user what data is being collected, why (specific purpose), who you will share it with, and how they can exercise their rights. Do not show only a general privacy policy link; show the specific notice relevant to the action the user is about to take. See our privacy notice template for the structure.
Present a clear affirmative action
The user must take a deliberate action to signal consent.
Acceptable
- Unchecked checkbox the user checks
- Labelled button: "I Agree" or "Give Consent"
- Toggle switch defaulted to OFF
- Three-button cookie banner (Accept / Reject / Customise)
Not Acceptable
- Continued use = consent
- Pre-ticked checkbox
- Consent buried in T&Cs
- "By scrolling you agree…"
Record and store the consent
Every consent event must be logged. See the consent log structure in the next section.
Provide an easy withdrawal path
The Act requires withdrawal to be as easy as giving consent. Build a dedicated "Manage My Consent" or "Privacy Settings" page where users can see active consents, withdraw specific consents, and request deletion of data tied to a withdrawn purpose. When consent is withdrawn, stop processing for that purpose immediately and trigger your data deletion or anonymisation workflow.
3. The Consent Log -What to Record
Every consent event must be persisted with enough detail to reproduce, on demand, exactly what the user agreed to. The minimum fields:
- User identifier -the persistent ID linking back to the data principal. Email or account ID, not just an IP.
- Timestamp -ISO 8601, UTC. Captured at consent grant time, not at form submission time.
- Notice version -the exact version of the privacy notice shown at the time of consent. When the notice changes, the version increments and a re-consent prompt may be required.
- Channel -web, mobile app, email reply, in-person. Identifies which UI produced the consent.
- Specific purpose(s) consented to -listed individually, not bundled. Functional, analytics, marketing each captured as separate flags.
- Locale / language -the language the notice was presented in. The DPDP Act allows the data principal to choose any Eighth Schedule language; you must serve the requested language and log which language they consented under.
This consent log is your audit trail. The Data Protection Board may ask for it. The log should be tamper-resistant -append-only at minimum, ideally with cryptographic integrity if you operate at scale.
If a user consented to v1.2 of your notice and you later updated to v1.5 with new purposes added, the consent on file is for v1.2 -not v1.5. Re-prompting is required when the purposes change. Without notice versioning in the log, you cannot tell whose consent is current and whose is stale.
4. The Withdrawal Path
Section 7 requires withdrawal to be as easy as giving consent. In practice this means a single durable surface where every consent the user has ever given is listed, with per-purpose toggles.
- Persistent access. Either a footer link ("Privacy Settings" or "Cookie Preferences") or an account-level setting page. Users should not have to hunt for it.
- Per-purpose granularity. Withdraw marketing without withdrawing functional. Withdraw analytics without withdrawing email notifications.
- Immediate effect. Withdrawal stops processing for that purpose at the moment of click. If marketing consent is withdrawn, the next marketing send must not include that user -even if the campaign was queued before the withdrawal.
- Downstream deletion. Withdrawal often triggers deletion of data tied to the withdrawn purpose. See our erasure workflow guide for the handoff.
- Withdrawal confirmation. Show the user a clear confirmation that the withdrawal has been recorded, and log the withdrawal event itself with the same fields as the original consent.
5. Third-Party SDKs and Tags
If your site loads third-party scripts -Google Analytics, Meta Pixel, HubSpot, Hotjar, LinkedIn Insight -these must not fire until the user has consented to the corresponding category.
- Block by default. No third-party script loads on first page load until consent is recorded. The HTML page should not contain script tags that auto-execute; tags load via the tag manager only after consent.
- Consent Mode v2 (for Google tags). If you use Google Tag Manager, configure Consent Mode v2 with analytics-storage and ad-storage signals tied to your CMP state. Without consent, tags run in "cookieless" mode and do not set identifiers.
- Granular firing. Functional tags (error monitoring, session security) can fire on the basis of legitimate interest if your notice covers it. Analytics fires only on analytics consent. Marketing/ad tags fire only on marketing consent.
- Tag inventory. Maintain a list of every third-party tag, the purpose it serves, the data it collects, and the consent flag that gates it. This list goes in your privacy notice (or is linked from it) so users know exactly what gets loaded.
6. Re-Consenting Existing Users
If you have not collected valid consent from existing users -either because the original consent was bundled, or because no consent was collected, or because the notice has materially changed -you need a re-consent campaign.
Send a notice explaining the update and require users to actively re-consent to continue data processing for non-essential purposes. For functional purposes (such as keeping their account active), processing can typically continue under "necessary for performance of contract" while consent for marketing or analytics is collected separately.
7. Common Mistakes to Avoid
- Bundling marketing and functional consent into one checkbox
- Not recording the version of the notice at consent time
- Treating "scroll past the banner" as consent
- Failing to update consent records when the privacy notice changes
- Not providing granular withdrawal (withdraw all vs. withdraw per purpose)
- Loading analytics or marketing tags before consent is recorded
- Storing only "consented: yes" -without notice version, channel, or timestamp, the record is unprovable
Need to ship a compliant consent flow?
SecComply builds DPDP-compliant consent management -UI, log structure, withdrawal path, third-party tag gating, re-consent campaigns. End-to-end implementation on web and mobile.
Book a consent build call →FAQ
The banner should appear when the user first lands on your site and any time you collect data for a new purpose not previously consented to. Once consent is recorded, you do not need to show the banner again on every page. A persistent Cookie Preferences or Privacy Settings link in the footer satisfies the ongoing access requirement.
No. Section 6 of the DPDP Act requires an unambiguous affirmative action. Scrolling, dwelling on a page, or clicking unrelated links does not constitute consent. The user must take a deliberate action -checking a box, clicking an explicit consent button, or toggling a switch.
For at least as long as you process the data the consent authorised, plus the limitation period for any legal claims that might arise. Three to seven years is the common range in Indian practice, but you should set the retention period through your records-retention policy and document the justification. The Data Protection Board may ask for evidence of consent for any specific data subject, so the records need to be retrievable on demand.
Granular per purpose is required. Section 6 explicitly prohibits bundled consent -a single tickbox covering multiple unrelated purposes. Functional consent (needed to deliver the core service) is one purpose; marketing consent is another; analytics is another. Each needs its own affirmative action and can be withdrawn independently.
Third-party scripts that process personal data must not load until the user consents to that category. This typically means using a tag manager or consent management platform that blocks scripts by default and only loads them when the corresponding consent flag is set. Google Tag Manager with Consent Mode v2 is one common approach; dedicated CMPs are another.