DPDP consent notice: what every data fiduciary must include
Build a consent notice that satisfies DPDP Rules 2025 — eight required elements, common mistakes to avoid, and a before/after example.
Why your existing cookie banner or privacy policy is not enough
Most Indian organisations that started thinking about DPDP compliance reached for their existing privacy policy and assumed it would double as a consent notice. It will not. The Digital Personal Data Protection Act 2023 and the Rules notified in 2025 treat these as two distinct instruments, and conflating them is one of the most common compliance errors we see across SaaS, HRMS, and fintech companies.
A privacy policy is a broad, evergreen document that describes your overall data practices — how your organisation collects, uses, stores, and deletes personal data across all its products and operations. It typically runs several thousand words and lives on a dedicated URL.
A consent notice is different in purpose, timing, and scope. It is presented to the data principal at the point of — or immediately before — collection of their personal data for a specific purpose. It must be concise, purpose-specific, and written in language a lay person can understand. If you collect data for three separate purposes (say, processing a salary, sending a newsletter, and profiling for upsell), you may need three separate consent notices — or at minimum three clearly separated consent items within a single notice.
If you have not yet reviewed your privacy policy for DPDP alignment, our earlier guide on running a DPDP privacy policy check is a good starting point. This post focuses specifically on the consent notice, which is a separate and additional obligation.
The eight elements a DPDP consent notice must contain
The Rules are explicit about what a consent notice must include. Miss any element and the consent is not valid — meaning any processing based on that consent could be challenged or attract regulatory scrutiny. Here is each element with practical guidance.
1. Identity of the data fiduciary
State your company's full legal name, registered address, and — once assigned — your Data Fiduciary registration number. If you operate under a brand name different from your legal entity, include both. Do not use abbreviations or URLs alone.
2. Categories of personal data to be collected
Be specific. "Personal information" is not a category. "Name, mobile number, PAN, salary details, and bank account number" is. If you collect sensitive personal data (biometrics, health data, financial information), flag these explicitly. Data principals must know exactly what they are consenting to before they consent to it.
3. Specific purpose(s) of processing
This is where most notices fail. Phrases like "to improve our services," "for analytics purposes," or "to enhance your experience" are not purposes — they are marketing copy. The Rules require you to state the actual, discrete purpose for which each category of data will be processed. "To calculate and disburse your monthly salary via NEFT to your registered bank account" is a purpose. "To send you promotional communications about new payroll features via email and SMS" is a separate purpose and requires a separate consent item.
Bundled consent — where one tick box covers ten different uses — is explicitly non-compliant under DPDP. Consent must be granular: the data principal must be able to consent to some purposes and refuse others.
4. Whether data will be shared and with whom
If you share personal data with third parties — payroll processors, cloud providers, background verification firms, analytics tools — you must disclose this. You need not list every sub-processor by name in the notice itself (that level of detail belongs in your Data Processing Agreement), but you must clearly state that sharing occurs and describe the categories of recipients. A statement like "Your salary data will be shared with our payroll banking partner, [Bank Name], solely for NEFT disbursement" is compliant. "We may share your data with trusted partners" is not.
For a deeper look at managing data sharing obligations with vendors, see our post on drafting DPDP-compliant Data Processing Agreements.
5. Retention period
State how long the data will be retained. If different categories have different retention periods (for example, salary records must be kept for eight years under tax law, while marketing contact data may be kept for two years from last engagement), state these separately. Do not use vague language like "as long as necessary." Specify the period or the legal trigger for deletion (for example, "seven years from the date of last salary disbursement, as required under the Income Tax Act").
6. Right to withdraw consent and how to do it
This is non-negotiable. The notice must tell the data principal that their consent is not permanent, that they can withdraw it at any time, and precisely how to do so. The withdrawal mechanism must be as easy as the mechanism to give consent — you cannot make opt-in a single click and opt-out a six-step form. Include a direct link, email address, or in-app setting where withdrawal can be initiated.
7. Rights to access, correct, erase, and nominate
The DPDP Act grants data principals four core rights: to access a summary of their personal data and how it has been processed; to correct inaccurate data; to erase their data (subject to legal retention requirements); and to nominate another person to exercise these rights on their behalf in case of death or incapacity. Your consent notice must acknowledge these rights and direct the data principal to where they can exercise them — typically a DSAR (Data Subject Access Request) portal or a designated email.
8. Grievance Officer contact details
Every consent notice must include the name, designation, and contact information (email address at minimum) of your appointed Grievance Officer. If you have not yet appointed one or have not confirmed the appointment is still current, do this before finalising any consent notices. Once your notices are live, the Grievance Officer contact information must remain accurate — an incorrect email address in a published notice is a compliance defect.
Before and after: what compliant language looks like
Non-compliant (vague, bundled):
"By clicking Continue, you agree to our Privacy Policy and Terms of Service. We may use your data to improve our products and services and share it with our partners."
Compliant (specific, granular, actionable):
"Zeta HRMS Pvt. Ltd. (CIN: U72900MH2020PTC000001) is requesting your consent to collect and use the following personal data:
Data collected: Name, mobile number, PAN, Aadhaar number (masked), bank account number, salary details.
Purpose: To process and disburse your monthly salary via NEFT transfer to your registered bank account.
Sharing: Your bank account and salary data will be shared with HDFC Bank Ltd. solely for NEFT disbursement. No other third party will receive this data.
Retention: Seven years from the last salary disbursement, as required under the Income Tax Act 1961.
Withdraw consent: You may withdraw this consent at any time by writing to privacy@zetahrms.com. Withdrawal will not affect the lawfulness of processing before withdrawal.
Your rights: You have the right to access, correct, or request erasure of your data. Contact privacy@zetahrms.com.
Grievance Officer: Priya Mehta, Chief Privacy Officer — grievance@zetahrms.com."
The difference is stark. The compliant version takes slightly more space but is unambiguous, legally defensible, and genuinely informs the data principal.
Consent versus contractual necessity — know the difference
Not every data processing activity requires consent. DPDP recognises other lawful bases, including processing that is necessary to fulfil a contract with the data principal. If you are processing an employee's name and bank details to pay their salary, you may not need consent — you may be able to rely on contractual necessity. The distinction matters because consent-based processing is subject to the withdrawal mechanism, whereas contract-based processing is not.
Your consent notice should only cover processing activities that genuinely rely on consent as their lawful basis. Mixing consent-based and contract-based processing in a single notice — and asking the data principal to "consent" to something they have no real choice about — is a form of invalid consent.
If you are building out your full compliance documentation and want to understand how the consent notice fits into the broader compliance lifecycle, our guide on the DPDP readiness timeline maps every deliverable to a recommended completion date. Once your notices are live, your internal audit report should verify that notice text matches actual data flows.
Maintaining and updating your consent notices
A consent notice is not a one-time document. If your processing purposes change — you add a new product feature, onboard a new sub-processor, or change your retention period — you must update the relevant consent notices and, in most cases, seek fresh consent from data principals who were previously given the old notice. Build a review trigger into your change management process so that any product or vendor change automatically flags a consent notice review.
Build a compliant DPDP consent notice in minutes
Our Consent Notice Builder generates all eight required elements in plain language, correctly separated by purpose, with a withdrawal mechanism built in. Review it with your legal team and publish with confidence.
Build your consent notice — ₹1,499 →