A DPDPA consent notice missing even one of the six mandatory elements is invalid — and the consent collected under it cannot be relied upon. Here is exactly what the Act requires.
What Makes a DPDPA Consent Notice Legally Valid
Under the Digital Personal Data Protection Act 2023, consent is only valid if it was collected after giving a proper notice. An invalid notice means invalid consent. And invalid consent means every downstream processing activity built on that consent is itself unlawful — regardless of how sophisticated your data infrastructure is.
Section 5 of the Act sets out what a consent notice must contain. The DPDP Rules 2025 elaborate on format and delivery. Together, they create a specific checklist — not a general principle of "tell people what you're doing," but a defined set of elements, each of which must be present for the notice to be legally effective.
Missing one element doesn't make the notice incomplete. It makes the consent invalid.
Mandatory Element 1: Identity of the Data Fiduciary
The consent notice must clearly identify who is collecting and processing the personal data. This means the full legal name of the Data Fiduciary — not a brand name, not a product name, not a website name if it differs from the legal entity.
This matters more than it sounds. Many consumer-facing organisations operate under brand names that are distinct from their legal entity. A fintech branded "FastPay" whose legal entity is "Acme Financial Technologies Pvt Ltd" must use the legal entity name in the consent notice. Using the brand name alone creates a notice defect.
The notice must also include contact details for the Data Fiduciary — typically an email address or a grievance officer's contact — so the Data Principal has a way to reach the organisation before exercising formal rights.
Mandatory Elements 2–4: Purpose, Data Description, and Processor Disclosure
Element 2 — Specific Purpose: The notice must state, in plain language, the specific purpose for which personal data is being collected. "We collect your data to improve our services" is not a specific purpose under DPDPA. "We collect your mobile number to send you OTP-based authentication codes for login" is. Each processing purpose requires its own purpose statement — bundled multi-purpose consents that were common under pre-DPDPA practice create notice defects.
Element 3 — Description of Personal Data: The notice must describe what categories of personal data will be collected. Vague descriptions like "personal information" are insufficient. The notice must specify the data categories — name, phone number, Aadhaar number (if applicable), location data, financial data — for each stated purpose.
Element 4 — Data Processor Disclosure: If the Data Fiduciary uses Data Processors who will have access to the personal data, the notice must disclose this. The level of disclosure required is not a named list of every vendor, but a clear statement that processors are used and a description of the categories of processing they perform on behalf of the Fiduciary.
Mandatory Elements 5–6: Rights Summary and Withdrawal Mechanism
Element 5 — Rights Summary: The consent notice must inform the Data Principal of their rights under DPDPA. This doesn't require quoting the Act, but it requires a plain-language summary that tells individuals they have the right to access their data, correct it, request erasure, and withdraw consent. A notice that collects consent without informing the Data Principal that they can withdraw it is defective.
Element 6 — How to Withdraw Consent: The notice must tell the Data Principal how to withdraw consent — not just that they can, but the specific mechanism for doing so. If consent withdrawal is handled via an email to a specific address, the notice must state that address. If it's via a self-service portal, the notice must provide the URL. The withdrawal mechanism must be as easy to access as the consent collection mechanism itself.
This last point catches many organisations off guard. If you collected consent via a one-click button on a mobile app, your withdrawal mechanism must be equally accessible — not buried in a settings menu behind three screens.
Language Requirements: The 22 Indian Languages Obligation
Section 5(2) of the DPDPA requires that the consent notice be available in English or any other language specified in the Eighth Schedule of the Constitution. The Eighth Schedule currently lists 22 languages including Hindi, Bengali, Tamil, Telugu, Marathi, Gujarati, Kannada, Malayalam, and others.
The obligation is not to translate into all 22 languages — it is to make the notice available in the language the Data Principal prefers. In practice, this means your consent notice system must be able to serve the notice in the Data Principal's preferred language, which requires either detecting the preferred language from device settings or offering a language selector before consent is sought.
For organisations using IVR-based consent collection — common in banking, insurance, and telecom — this means the IVR consent journey must be available in the Data Principal's preferred language. A Hindi-speaking consumer receiving an English-only IVR consent prompt may not have given informed consent, which is a notice defect with direct enforcement implications.
Common Notice Defects That Create Enforcement Exposure
Based on how DPDPA's requirements translate to real-world notice implementations, these are the most common defect patterns:
- Omnibus purpose statements: "We may use your data for various business purposes" — fails the specificity test
- Static notices on dynamic processing: The notice was written once at launch; processing purposes have since expanded without notice updates or fresh consent
- Missing withdrawal instructions: The notice says "you may withdraw consent" but doesn't explain how
- Language mismatch: The notice is only available in English for a service used primarily by vernacular-language speakers
- Brand name instead of legal entity name: The notice identifies the collector by brand, not legal name
- No processor disclosure: The notice makes no mention of third-party processors who process the data on the Fiduciary's behalf
Each of these defects, if discovered during a Data Protection Board inquiry, can result in the invalidation of consent records and penalties under Section 66 of the Act.
Automating Compliant Notice Delivery at Scale
For organisations collecting consent at high volume — thousands of new users daily, consent collection across multiple channels, multilingual user bases — manually maintaining compliant notices is not operationally realistic. The notice must be versioned (updated when processing purposes change), the version that applied at the time of each consent collection must be auditable, and the correct language version must be served to each individual.
Consentica by OpenBlockAI handles consent notice versioning, multilingual delivery, and per-consent notice version audit trailing natively. Each consent record in Consentica is linked to the exact notice version shown to the Data Principal at the time of collection — satisfying the evidentiary requirement if a consent record is ever challenged before the Data Protection Board. Language detection and Eighth Schedule language support are built into the consent collection flow, including IVR journeys for phone-based consent in 22+ Indian languages.