DPDP Act 2023 Compliance Masterclass for Indian WhatsApp Business

Under the DPDP Act 2023, marketing on WhatsApp rests on consent that is free, specific, informed and unambiguous. A pre-ticked box, a buried clause, or a number scraped from a directory does not clear that bar. Before a single broadcast goes out, you should be able to point to where, when and how each contact opted in — and to a notice that told them, in clear language, what you would use their data for.

In practice that means designing the consent moment deliberately: a checkbox that is unchecked by default, copy that names the purpose ("offers and product updates on WhatsApp"), and a timestamped audit log that stores the consent string, the channel, and the version of the notice shown. If you later change what you send, that is a new purpose and usually needs fresh consent.

Keep transactional consent and marketing consent conceptually separate. A customer who agreed to order updates has not necessarily agreed to promotional broadcasts. Blurring the two is one of the fastest ways to invalidate a whole opt-in base if a single complaint reaches the Data Protection Board.

Treat the audit log as the asset, not the message. When asked to demonstrate lawful basis, the log — not your intentions — is what you will rely on. Always verify the exact wording requirements against the current DPDP Rules and a qualified Indian lawyer before going live.

WhatsApp template categories (Utility, Authentication, Marketing) and your DPDP consent posture are linked. Utility templates serve a transaction or request the user initiated — order confirmations, shipping updates, appointment reminders, payment receipts. Marketing templates promote, cross-sell, or re-engage. The honest test is simple: did the user ask for this specific information, or are you nudging them toward a purchase?

The borderline cases are where teams get into trouble. An order-update that also says "customers also bought…" is no longer purely Utility. A "your appointment is tomorrow" reminder that bolts on a discount code has slipped into Marketing. When a message blends both, classify it by the part that drives the send — and if a promotion is doing any of that work, treat it as Marketing and require marketing consent.

A short decision flow helps: Was the message triggered by a user action or request? Does it contain any promotional offer or upsell? Could the user reasonably be surprised to receive it? If "triggered by the user" is yes and "promotional" is no, you are likely in Utility; otherwise lean Marketing.

Getting this right protects both compliance and deliverability — mis-categorised templates risk rejection and quality-rating damage. Meta's category definitions evolve, so re-validate your template library periodically rather than assuming a one-time mapping holds forever.

DPDP gives special protection to the personal data of children. Where your audience may include minors, the framework generally expects verifiable parental or guardian consent before processing, and restricts tracking, behavioural monitoring and targeted advertising directed at children. For EdTech, gaming, and any consumer brand with a young user base, this is not a footnote — it shapes onboarding.

Operationally, that means an age signal early in the flow and a real parental-consent step when a user falls under the threshold, not a throwaway "I am over 18" checkbox that everyone clicks past. The exact mechanics of what counts as "verifiable" are the kind of detail the DPDP Rules pin down, so confirm the current standard rather than relying on a generic OTP.

On WhatsApp specifically, avoid building marketing segments or lookalike-style targeting around users you know or suspect to be children. If your product genuinely serves minors, design the journey so the adult is the data principal you obtain consent from and communicate with.

Because enforcement here can be strict and the rules are still settling, this is a topic to walk through with a qualified Indian lawyer for your specific sector before you ship an age-gated flow.

A personal-data breach is not only a dramatic hack — it includes accidental exposure, unauthorised access, or loss of personal data. On WhatsApp stacks the realistic incidents are mundane: a phone-number export leaving the building, template content leaking PII, a misconfigured webhook, or a CRM seat handed to the wrong person. Recognising these as reportable events is half the battle.

DPDP expects notification to the Data Protection Board and affected individuals without undue delay. Many teams plan their incident response around a 72-hour window as a working target, but the precise timing, format and thresholds are governed by the DPDP Rules — verify the current requirement; do not treat 72 hours as a fixed legal guarantee.

Have the playbook written before you need it: who declares an incident, who assesses scope, what the notification contains (nature of the breach, likely consequences, mitigation taken), and how you reach affected users. Pre-drafted templates and a named decision-maker turn a panicked scramble into a process.

Finally, log everything during an incident — detection time, actions, decisions. The same audit discipline that proves consent also demonstrates that you responded responsibly, which materially affects how regulators view an event.

As a Data Fiduciary you must give people a way to raise grievances and exercise their rights — access, correction, erasure, and withdrawal of consent. That means publishing a Grievance Officer contact channel (not a private mobile number), committing to a response SLA, and having an escalation path when the first response does not resolve the issue.

Withdrawal must be as easy as giving consent. On WhatsApp, honour STOP / unsubscribe promptly and propagate it across your CRM so a withdrawn contact does not resurface in the next broadcast. Crucially, withdrawing marketing consent should not break legitimate transactional flows the user still expects — keep those consents separate so you can switch one off without the other.

For erasure and data-portability requests, define a workflow: how a request arrives, how you verify the requester, where the data lives, and how you confirm completion within a reasonable window. Even a small team can run a lightweight version — a shared inbox, a simple register, and a named owner beats an elaborate system no one maintains.

Document the SOP in one page: officer name/role, public contact, SLA, the rights you honour, and the steps for each request type. This is exactly the artefact an inspector or a serious customer will ask to see. As always, validate the specifics against the current DPDP Rules and a qualified Indian lawyer.