Chatbots and India's DPDP Act: consent, storage and deletion in plain language

Updated 2026-09-19 · 4 min read · By the Convo360 team

This is information, not legal advice

The Digital Personal Data Protection Act, 2023 (DPDP Act) is India's data protection law, and its rules and rollout continue to evolve through rules and notifications. What follows is a plain-language overview of concepts relevant to running a chatbot. It is not a compliance checklist you can rely on without your own legal counsel, and specific obligations depend on your business, the data you handle, and the current state of the rules. Where anything below sounds like it applies directly to your situation, that is exactly the point at which to bring in a lawyer rather than proceed on this article alone.

The core ideas behind DPDP

• Consent. Personal data generally should be collected with clear, informed consent for a specific purpose, rather than assumed or bundled into unrelated terms.
• Purpose limitation. Data collected for one purpose (say, booking an appointment) should not be silently repurposed for something unrelated (say, unsolicited marketing) without fresh consent.
• Data minimisation. Collect what you need for the stated purpose, not everything you could possibly ask for.
• Rights of the data principal. The person whose data it is generally has rights including the ability to request access to, correction of, or deletion of their data.

These are the underlying ideas most privacy frameworks share, and a chatbot, because it collects names, phone numbers, sometimes addresses and preferences, directly in conversation, sits right at the point where these principles matter operationally, not just as a policy document nobody reads.

Consent capture inside a chatbot flow

A well-designed flow treats consent as a deliberate step rather than an assumption. Practical patterns include:

• An explicit opt-in message before a Marketing-category broadcast, distinct from a transactional Utility message a customer would already expect.
• A clear statement of purpose when collecting sensitive fields ('We're asking for your address to schedule the delivery, it won't be used for anything else').
• Recording the consent event itself (timestamp, what was agreed to) rather than only recording the data collected.
• Honouring opt-out or 'STOP' keywords immediately and reliably.

Building consent capture into a flow, block by block

In practical no-code terms, consent capture is usually three ordinary flow blocks used deliberately, not a special feature:

1. Ask a Question to present the consent statement in plain language and wait for a yes/no or button response, rather than assuming silence means agreement.
2. Set Variable to record the response (and ideally a timestamp) against that contact, so the consent event itself is stored, not just the data collected afterwards.
3. Save CRM lead or a custom field update to reflect the consent status on the contact's record, so anyone looking at that contact later, whether support, marketing or an auditor, can see what was agreed to and when.

The same three-block pattern works whether the consent is for a Marketing broadcast, sharing an address for delivery, or recording a voice call.

Storage, retention and handling a deletion request

Keep only what the bot's purpose requires, and have a defined retention approach rather than storing every conversation indefinitely by default. When someone requests deletion of their data, you need an actual mechanism to locate and remove their records, including contacts, conversation logs and CRM entries, not just a promise. Build this into your operational process, and confirm with your platform how contact deletion works in practice.

A workable process usually looks like this.

1. Log the request itself (who asked, when, through which channel) before acting on it.
2. Locate the contact record and search conversation logs and CRM entries tied to that phone number or contact ID.
3. Remove or anonymise the records according to your own retention policy, keeping only what you are required to retain for another reason (such as a financial record).
4. Confirm back to the person in writing that the request has been actioned.
5. If anything about the request is ambiguous, such as a partial deletion, a legal hold or a dispute, pause and check with your legal advisor before proceeding.

Sub-processors: who else touches the data

On a BYOK platform, a customer's message may pass through several parties: the WhatsApp/Meta infrastructure, your chosen AI provider (OpenAI, Claude or Gemini) for generating a reply, your telephony provider for voice calls, and the chatbot platform itself for orchestration and storage. Each of these is effectively a sub-processor of personal data. Review each provider's own privacy and data-handling terms. A chatbot platform choosing a well-known, established provider for each layer is a reasonable starting point, but the responsibility to check remains yours as the data controller for your customers' information.

How Convo360 supports this operationally

Convo360 lets you capture consent as an explicit flow step using Ask a Question, Set Variable and Save CRM lead blocks before any Marketing send, stores API keys and credentials encrypted at rest, and supports contact-level management so records tied to a specific person can be located and removed on request. Because it is BYOK, your sub-processors for AI and telephony are the providers you directly chose and hold accounts with, not an opaque third party the platform picked for you. None of this replaces your own legal review. See the compliance documentation as a starting point, and consult a qualified professional for your specific obligations.

Step by step

1. Add a consent step before any Marketing sendUse an Ask a Question block to present the consent statement and wait for an explicit response.
2. Record the consent event, not just the dataUse Set Variable to capture the response and timestamp against the contact.
3. Reflect consent status on the contact recordUpdate a custom field or CRM stage so anyone reviewing the contact later can see it.
4. Define a retention approachDecide how long conversation logs and CRM entries are kept, and apply it consistently rather than storing everything indefinitely.
5. Build a deletion-request processDocument the steps to locate, remove or anonymise a person's records, and confirm back to them once done.

Example conversation

Frequently asked questions

Related reading

Available across India — see WhatsApp & AI calling automation by state and city.