How to Build a DPDPA-Compliant Consent Notice: Language, Clarity and Opt-In Design

Your consent notice is not paperwork. It is the legal foundation of your entire relationship with a customer's personal data. When a notice contains vague wording, buried checkboxes, or a decline option hidden in grey font, every piece of consent collected on top of that notice is invalid. Not "risky." Invalid.

Under the DPDPA, a poorly designed notice does not merely annoy users or invite a complaint. It can unravel an organisation's entire consent record retroactively. Getting this right is worth the effort.

It Is Not a Disclaimer. It Is a Conversation.

The instinct, especially for legal and compliance teams, is to treat a consent notice like a disclaimer. Dense and defensive, written to survive an audit rather than to be read by a human being. That instinct is exactly backwards under DPDPA.

A compliant notice is a piece of communication. Its job is to help an individual make an informed choice about their own personal data. The Act and its Rules do lay out specific requirements, but meeting those requirements is not the finish line. The real test is whether an ordinary person, glancing at a notice on their phone between other tasks, actually understands what is happening to their information.

What Section 5 Actually Requires

Stripping away the legal phrasing, Section 5 of the DPDPA asks for five fairly simple things in every notice:

1. What personal data you are collecting

2. Why you are collecting it

3. How the person can access, correct, erase, or withdraw consent for their data

4. How to raise a grievance, and who the Grievance Officer is

5. How to contact you, the Data Fiduciary

The DPDP Rules, 2025 add one more layer that trips up many organisations: this information must be available in the languages your Data Principal actually understands. Not just English. Not just the language your legal team drafted it in.

"Clear and Plain Language" Is Not a Suggestion

The Act says content must use "clear and plain language," and it means that literally. Legal boilerplate copied from a template into a footer does not meet that standard, no matter how solid it sounds to a lawyer.

Here is a useful gut-check: imagine someone with a secondary-school education, scrolling quickly on their phone, half-distracted. Can they read your notice and immediately understand what data you are taking and why? If you hesitate even slightly, that is your answer. Rewrite it.

Why Layered Notices Work Better

The best-designed notices do not try to say everything at once. They use a layered structure:

• A short, plain-language summary at the top, covering what data, why, and for how long

• A link to the full, detailed notice for anyone who wants the complete legal picture

• A separate, unambiguous opt-in action for each purpose for which you are asking consent

That top layer should be something a person can read in under a minute. If it takes longer, you have probably tried to cram too much into the first screen, and people will simply stop reading. That defeats the entire point of asking.

Stop Bundling Consents Together

This is one of the most common mistakes, and one of the easiest to fix: treating consent as one big yes-or-no decision instead of several smaller ones.

If your form asks someone to agree to "marketing communications, personalisation, analytics, and sharing with partners" under a single checkbox, you have bundled four separate purposes into one tick. Under DPDPA, that does not work. Each purpose needs its own toggle, its own checkbox, its own independently revocable consent. Someone should be able to say yes to a newsletter and no to sharing their data with a marketing partner, without those two choices being welded together.

Yes, this means more UI elements. It also means the consent you collect is actually meaningful and far less likely to be challenged later.

Dark Patterns Are on the Board's Radar

The DPDP Rules explicitly call out manipulative interface design, and the Data Protection Board will scrutinise it. A few patterns worth removing from your product today if they are still present:

• Consent boxes that are pre-ticked before the user does anything

• A "decline" or "reject" option that is visually harder to find than "accept"

• Colour, size, or placement used to nudge people toward accepting and away from refusing

• Language that frames refusal in alarming terms to pressure someone into saying yes

None of these are subtle to a regulator reviewing your flow. If your design team's first instinct was to make "accept" the big green button and "decline" a tiny grey link, it is worth revisiting that choice now rather than after a complaint lands.

The Real Payoff

Designing a consent notice properly is two jobs at once: it is a legal document, and it is a piece of UX. Treat it as only the first, and you will end up compliant on paper but confusing in practice. Treat it as only the second, and you will miss requirements that get you in trouble.

Organisations that put real effort into both walk away with something valuable beyond compliance. Consent records that actually hold up, and fewer people withdrawing consent later because they felt misled the first time. In a regulatory environment built around trust and transparency, that is not a small advantage. It is the whole game.

OneConsent generates DPDPA-compliant, multilingual consent notices with per-purpose granularity across web and mobile channels. The platform is built specifically for India's regulatory environment, helping organisations deliver consent notices that are both legally compliant and genuinely understandable to their customers.

OneConsent takes care of the technicalities of notice versioning, language localization and audit trail generation so your team can focus on establishing confidence with customers, rather than wrestling with regulatory requirements.