Multilingual privacy notices: notifying users in Indian languages under DPDP

At a glance

The DPDP Act gives every person the right to read your privacy notice in English or any of the 22 languages in the Eighth Schedule to the Constitution — Hindi, Bengali, Tamil, Telugu, Marathi and the rest (Section 5(3)). You don’t have to translate everything into all 22 up front, but you must give people the option to access the notice in those languages. In practice: a language switcher on the notice, accurate translations of the languages your users actually use, and a route to request the others.

Educational resource only. This explains the language requirement for notices under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.

The situation

Your privacy notice is in English, and most of the compliance advice you’ve read assumes that’s fine. It isn’t quite — India’s law contains an explicit language provision that a lot of English-only notices miss. If a meaningful share of your users read a scheduled Indian language more comfortably than English, this isn’t a nicety; it’s a requirement with a specific statutory home, and one of the more concrete, checkable duties in the whole notice regime.

What Section 5(3) actually requires

The Act says the person gets to choose the language of the notice — English, or any Eighth Schedule language. Section 5(3) of the DPDP Act requires a data fiduciary to give the data principal the option to access the contents of the notice in English or any language specified in the Eighth Schedule to the Constitution. The Eighth Schedule lists 22 languages — Hindi, Bengali, Marathi, Telugu, Tamil, Gujarati, Kannada, Malayalam, Punjabi, Odia, Assamese, Urdu and others — so the right on paper is broad. It’s framed as an option to access, meaning the obligation is to make the notice available in the person’s language, not to guess their language and serve it automatically. This is one of the few notice requirements with a hard, external reference point: the list of qualifying languages isn’t a matter of interpretation, it’s a constitutional schedule.

“The option to access” — what that means in practice

“Option to access” is the reasonable middle between English-only and 22 full translations on day one. The law doesn’t demand that every notice ship in all 22 languages simultaneously, and reading it that way leads teams to either panic or ignore it. What it demands is that a person can get the notice in a scheduled language when they want it. The practical, defensible reading: translate into the languages your actual user base uses — a service with a heavy Tamil Nadu and Maharashtra footprint should have Tamil and Marathi ready, not just English — and provide a clear, working way to obtain the notice in the other scheduled languages on request. The more your product markets or operates in a specific language region, the weaker any excuse for not having that language’s notice ready in advance. An option that exists only in theory — “email us and we’ll get back to you” with no real process behind it — isn’t the option the Act has in mind.

What goes wrong with machine translation

A garbled auto-translation can defeat the whole point of the notice — an informed person — while looking like compliance. The obvious shortcut is to run the English notice through machine translation and publish 22 versions. The risk is that legal and data-protection language translates badly: “consent,” “purpose,” “retention,” “grievance,” “withdraw,” and “Data Protection Board of India” have precise meanings, and a literal machine rendering can produce text that’s confusing or subtly wrong in the target language. A notice that’s technically present in Bengali but doesn’t actually convey what you collect and why hasn’t made anyone informed — it’s failed the substance while passing the checkbox. Raw machine translation is a starting draft at best; the versions you publish, especially for the languages your users actually rely on, need a human who reads that language to check that the meaning survived. The stakes are highest exactly where the language matters most: the users depending on the translation are the ones least able to fall back on the English.

Step by step: offering the notice in Indian languages

Prioritise by your real user base, translate with care, make the rest reachable.

1. Find out which languages your users actually read. Region of signup, app-language settings, support-ticket language, marketing regions — you likely already have signals. This tells you which scheduled languages to have ready in advance versus on request.
2. Finalise the English notice first. Every translation derives from it, so translating before the source is stable means re-translating. Get the English right, then branch.
3. Translate the priority languages properly — human-reviewed, not raw machine output — checking that the load-bearing terms (consent, purpose, retention, rights, grievance, the Data Protection Board of India) carry their real meaning.
4. Add a visible language switcher on the notice itself, so the person can pick their language at the point they read it — not buried in a settings menu. The switch is the “option to access” made real.
5. Provide a working route for the remaining scheduled languages — a request mechanism that actually produces the notice in reasonable time, not a dead-end promise.
6. Keep the notices as a set. When the English notice changes, every published translation is now out of date until it’s updated too — build that into how you ship notice changes.

Use the template

DPDP notice template — a free, ready-to-fill notice covering every item Section 5 requires. Finalise your content in it first; it’s the English source your translations branch from.

Keeping translated notices in sync

The moment your English notice changes, every translation you haven’t updated is quietly wrong. Multilingual notices multiply a maintenance problem: a single change to what you collect or why now has to propagate across every language version, or you’re serving some users an accurate notice and others a stale one. The fix is to treat the language versions as one linked set with a single owner, so a change to the source triggers a translation update as part of shipping it — not a separate task that slips. This is the same discipline any notice needs, just multiplied; the answer is process, not heroics. Handled that way, the language requirement stops being a translation headache and becomes what it’s meant to be — the reason a Marathi- or Tamil-first user can actually understand what they’re agreeing to.

FAQ