Consent under the DPDP Act: what a WhatsApp opt-in record should contain

Compliance review required before publishing. This article is not legal advice.

India's Digital Personal Data Protection Act, 2023 (the DPDP Act) makes consent a central basis for processing personal data. For a business that messages customers on WhatsApp, that raises a simple question with a demanding answer: if someone asks, can you show that this person agreed to hear from you, about this, and has not changed their mind?

This guide reads the relevant parts of the Act and turns them into a list of fields a WhatsApp consent record should contain. It is not legal advice. Your counsel should confirm how the Act and the rules made under it apply to you.

What the Act asks of consent

Section 6(1) of the Act says consent must be free, specific, informed, unconditional and unambiguous, given with a clear affirmative action, and limited to the personal data necessary for the specified purpose.

Three other provisions shape what you need to record:

• Notice (section 5). When you ask for consent, you must give a notice that sets out the personal data and the purpose, how the person can withdraw consent and exercise their rights, and how to complain to the Data Protection Board.
• Withdrawal (section 6(4)). A person can withdraw consent at any time, and withdrawing must be as easy as giving it.
• Proof (section 6(10)). Where consent is the basis for processing, the data fiduciary must be able to prove that notice was given and consent was obtained.

The last point is what turns consent from a checkbox into a record. "We have a field that says opted_in = true" does not prove notice, purpose or timing.

Who is the data fiduciary?

The Act calls the organisation that decides why and how personal data is processed the data fiduciary, and an organisation that processes data on its behalf a data processor.

When a lender uses a WhatsApp platform to message its customers, the lender is normally the data fiduciary for those customers' data, and the platform provider is a data processor. Section 8(1) keeps the fiduciary responsible for compliance even when a processor does the processing. In practice: your platform should give you the record, but the obligation to hold it is yours.

The fields a WhatsApp consent record should contain

Here is a practical list, with the reason for each field.

1. Who. The person's WhatsApp number in a consistent format (for example E.164), and a link to your customer record. Without a stable identifier, you cannot match an opt-out to an earlier opt-in.

2. What they agreed to. The purpose, as specific as your notice was. "Payment reminders for loan ending 4821" and "offers on new loan products" are different purposes. A single "WhatsApp: yes" cannot show the consent was specific.

3. The channel. That the consent covers WhatsApp. WhatsApp's own policy also expects people to have agreed to be contacted on WhatsApp in particular.

4. Where it happened. The source: an application form, a mobile app screen, a website form, a branch form or a WhatsApp conversation the customer started. Include a reference to the specific form or screen.

5. What they saw. The version of the notice and consent text shown at the time. Notices change; you need to know which one this person accepted.

6. The affirmative action. What the person did: ticked an unticked box, tapped "Yes", typed "START". Section 6(1) requires a clear affirmative action, so a pre-ticked box is weak evidence.

7. When. The date and time, with the time zone. This is what lets you show consent came before the first message.

8. Evidence. A pointer to proof: the form submission ID, the app event, the message ID of the customer's "Yes" reply, or a stored copy of a signed form.

9. Who captured it. The system, import or staff member that recorded the consent. If a batch of consents arrived through a file import, record which import and who ran it.

10. Withdrawal. When a person withdraws consent, record it as a new entry: the time, how they withdrew (for example a "STOP" or "band karo" reply, a call to your contact centre, or Meta's own marketing opt-out), and which purposes it covers.

11. Current status, derived. The current status for each purpose should be calculated from the history, not stored as a single field that can be overwritten.

Why an append-only ledger works better

The simplest design that meets the proof requirement is a ledger: every opt-in and opt-out is a new row, and rows are never edited or deleted during the retention period. The current status is worked out from the latest relevant entry.

A ledger answers the questions an auditor or the Data Protection Board is likely to ask: what did this person agree to, when, and has that changed? It also protects against a common failure: a later file import silently overwriting a customer's opt-out with an old opt-in.

Making withdrawal as easy as giving consent

On WhatsApp, the easiest way for a customer to withdraw is to reply. Section 6(4) asks that withdrawal be comparably easy to giving consent, so your process should:

• Recognise common opt-out replies in the languages your customers use, including Hindi and Hinglish phrases such as "band karo" or "मत भेजो".
• Act on them straight away, and confirm to the customer.
• Check the latest status immediately before every send, not only when a campaign is planned.

Section 6(6) adds that once consent is withdrawn, the fiduciary must, within a reasonable time, cause its processors to stop processing for that purpose. For WhatsApp, that means the platform must stop the messages, not only your CRM.

After withdrawal and deletion

Section 8(7) requires a fiduciary to erase personal data when the purpose is no longer served or consent is withdrawn, unless the law requires it to be kept. That creates a tension: if you delete everything about a person, how do you remember not to message them again?

One approach is to keep a minimal, anonymised record of the opt-out, such as a one-way hash of the phone number with the purpose, source and date, so that an opt-out keeps being honoured without keeping the person's details. Discuss this with your counsel.

A checklist for your consent records

• [ ] Every contact has consent entries per purpose, not one flag.
• [ ] Each entry has source, notice version, action, time with time zone and evidence.
• [ ] Imports carry a consent source and are attributed to the person who ran them.
• [ ] Opt-outs by reply are recognised in English, Hindi and Hinglish.
• [ ] Status is derived from history, and history cannot be edited.
• [ ] Consent is checked again immediately before each message is sent.
• [ ] An anonymised opt-out record survives deletion.

How Senderr helps

Senderr keeps an append-only consent ledger for every contact, with source and proof for each entry. Imports carry a consent source. STOP and Hindi and Hinglish opt-out replies, and Meta's marketing opt-out, are recorded automatically. Consent and suppression are checked again before each message is sent. Contact profiles let you export or delete everything held about one person, with each request logged and given a due date, and anonymised opt-out proof is kept so an opt-out is honoured after deletion.

Request access to see the consent ledger with your own data model.