How to Build a DPDPA-Compliant Consent Notice in 2026 (With Real Examples)

Your signup form has a checkbox that says 'I agree to the Terms of Service and Privacy Policy.' If your consent infrastructure starts and ends there, every record in your user database is legally unverifiable under the Digital Personal Data Protection Act 2023.

This guide walks through exactly what a DPDPA-compliant consent notice requires — what to include, what's prohibited, what counts as valid consent, and how to build it operationally so you have proof when the Board asks.

What DPDPA Requires: The Legal Foundation

Section 5 of the DPDPA places the notice obligation on the Data Fiduciary: before or at the time of seeking consent, you must give the Data Principal a notice containing specific information. This is not the same as a privacy policy. It is a specific, purpose-tied notice that accompanies each consent request.

Rule 3 of the Digital Personal Data Protection Rules 2025 operationalises S.5. It specifies that the notice must:

1. 1Be presented before or at the time of seeking consent
2. 2Be in clear and plain language — not legalese
3. 3Be available in English and in any language specified in the Eighth Schedule to the Constitution if the Data Principal requests it
4. 4State: the personal data to be processed and the purpose of processing
5. 5State: the manner in which the Data Principal can exercise rights under S.11–14
6. 6State: the manner in which the Data Principal can make a complaint to the Board
7. 7State: the contact details of the Data Protection Officer (if applicable) or the person designated to handle Data Principal queries

Section 6 adds the consent standard itself. Consent must be free, specific, informed, unconditional, and unambiguous — with a clear affirmative action. Silence, pre-ticked boxes, and bundled consent for multiple purposes are explicitly invalid.

The 5 Elements Every Consent Notice Must Have

1. Identity of the Data Fiduciary

The user must know who they are giving consent to. Your company's legal name, not just a brand name. If you're Acme Technologies Private Limited operating as 'QuickPay,' the notice should name the legal entity and can reference the brand.

2. Personal Data Being Collected — Itemised by Category

You cannot say 'we collect information to provide our services.' You must itemise: what specific categories of personal data you are collecting for each specific purpose. Name. Mobile number. Email address. Location data. Purchase history. Device identifier. Each category, stated explicitly.

3. Purpose of Processing — One Purpose Per Consent

Each purpose must be consented to separately. You cannot bundle 'providing our service, improving our product, and sending you marketing emails' into a single consent. These are three separate purposes. Each needs its own consent item, its own checkbox, and its own timestamp.

S.6(1) is explicit: consent 'shall signify an agreement to the processing of her personal data for the specified purpose.' Singular. Purpose limitation means each consent is tied to exactly one purpose — and you need fresh consent for every new purpose.

4. How to Withdraw Consent

The notice must explain how the Data Principal can withdraw consent. This must be as easy as giving consent. If consent was given by ticking a checkbox in an app, withdrawal must be achievable by a similar action — not by emailing a DPO and waiting 7 business days.

5. Contact Details for Queries and Complaints

The notice must include the DPO's contact details (if you have one) or the details of a person who can answer questions about data processing. It must also include how to file a complaint with the Data Protection Board. The Board's complaint mechanism is online — you must link to or reference it.

What Is Explicitly Prohibited

S.6(4) lists dark patterns and invalid consent mechanisms that the Act prohibits. Understanding what's banned is as important as knowing what's required:

• Pre-ticked boxes — any checkbox that is checked by default is invalid consent
• Bundled consent — asking for consent to multiple purposes in a single request without separating them
• Consent as a condition of service — you cannot make using your core service conditional on consent to unrelated data processing (e.g., you can collect data necessary to provide the service, but you cannot require consent to marketing as a condition of account creation)
• Vague purpose statements — 'to improve user experience' or 'for analytics purposes' are not specific enough. You must state exactly what processing will occur
• Implied consent — no action or silence counts as consent. It must be an affirmative act

Valid vs Invalid: Real Examples

Example 1: The Bundled Consent (Invalid)

☐ I agree to the Terms of Service and Privacy Policy and consent to
receive marketing communications and allow my data to be used for
product improvement and shared with our partners.

This is invalid for four reasons: it bundles consent to Terms (a contract) with consent to marketing (a separate purpose) and data sharing (another separate purpose). It does not itemise data collected. It does not state specific purposes. It does not explain how to withdraw.

Example 2: The Purpose-Separated Consent (Valid)

We collect your name and email address to create your account 
and send you transactional emails related to your account activity.
[Legal basis: S.6 consent]

☐ I consent to processing of my name and email for account creation 
and transactional communications.

You can withdraw this consent by visiting Settings > Privacy > 
Manage Consents at any time.

---

[Optional — separate checkbox]
☐ I consent to my name and email being used to send me product 
updates and promotional offers from DPDPA Shield.

You can withdraw this consent by clicking 'Unsubscribe' in any 
marketing email or via Settings > Privacy > Manage Consents.

This is valid: two separate consents for two separate purposes, each with its own checkbox, each with a withdrawal mechanism stated, each specifying exactly what data is used and why.

The Version Control Problem

Your consent notice will change. You'll add new features that process data differently. You'll onboard a new analytics vendor. You'll change your marketing strategy. Every material change to processing purposes requires a new version of your consent notice — and fresh consent from users for the new or changed purposes.

This creates a version control requirement. You need to know: which version of your consent notice each user saw when they consented, and whether any users need to be re-consented because their original consent predates a material change.

The Legacy Consent Problem

If your app was collecting user data before DPDPA enforcement — which most Indian businesses were — your legacy consents are almost certainly invalid under the Act. A checkbox from 2022 that said 'I agree to the Privacy Policy' does not meet the DPDPA standard of free, specific, informed, unconditional, and unambiguous consent with itemised purposes.

S.5(2) addresses this: where consent was given before the Act commenced, the Data Fiduciary must give the Data Principal a notice as soon as practicable, informing them of the personal data processed and the purpose, and the manner in which they can exercise their rights. The Data Fiduciary may continue to process until the Data Principal withdraws consent.

The practical implication: you do not need to delete all pre-Act data immediately. But you do need to send a retroactive notice to all affected users, and you need to stop using that data for purposes they did not specifically consent to.

The Language Requirement

Both the Act and Rule 3 require that the consent notice be available in English and in any of the 22 languages listed in the Eighth Schedule to the Constitution if the Data Principal requests it. For most SMEs, this practically means: your default notice should be in English (or the language you operate in), but you must have a mechanism to provide the notice in other scheduled languages on request.

The 22 scheduled languages include Hindi, Bengali, Telugu, Marathi, Tamil, Urdu, Gujarati, Kannada, Malayalam, Odia, Punjabi, Assamese, Maithili, Santali, Kashmiri, Nepali, Konkani, Dogri, Sindhi, Manipuri, Bodo, and Sanskrit.

The Proof Requirement

Consent is only as good as your proof of it. If the Board or a Data Principal asks 'did User #4821 consent to processing for Purpose X?' — you need to be able to produce evidence. Not just 'yes, we had a checkbox.' Evidence: which version of the notice they saw, the timestamp of their consent action, the identifier linking the consent to the user record, and the specific purposes they consented to.

This means your consent must be captured and stored, not just displayed. Every consent event needs a record: notice version, timestamp, user identifier, purposes consented to, and the action taken (checkbox, button click, etc.). This record must be immutable — it cannot be edited after the fact.

The Consent Notice Checklist

Before publishing your consent notice, verify each of these:

1. 1Legal name of your company is stated
2. 2Every category of personal data collected is itemised
3. 3Each purpose of processing is stated separately — not bundled
4. 4Each purpose has its own consent checkbox — not shared
5. 5The method for withdrawing consent is clearly explained
6. 6DPO contact details (or designated contact) are included
7. 7Information on how to file a Board complaint is included
8. 8Notice is in plain language — no legalese
9. 9No pre-ticked boxes anywhere in the consent flow
10. 10Core service is not made conditional on optional data processing
11. 11Notice version is tracked — you know which version each user saw
12. 12Consent events are stored with timestamp and user identifier
13. 13Legacy consents have been identified and a re-notification plan exists

What DPDPA Shield Automates

Building a compliant consent notice manually and maintaining it across notice versions, user segments, and data category changes is a full-time operational task. DPDPA Shield's Consent Management module handles the full lifecycle:

• WYSIWYG notice builder with purpose-by-purpose configuration — each purpose is a separate consent item with its own checkbox
• Version control with full history — every notice change is tracked, and users are automatically identified for re-consent if affected
• 22-language support — notices can be served in any scheduled language
• SDK widget (< 12KB) that captures consent events with cryptographic timestamps and stores them as immutable proof records
• Withdrawal mechanism built in — users can withdraw any individual consent from their account settings
• Re-consent campaign manager — identifies affected users when a notice changes and sends re-consent requests automatically