DPDP Customer Communications: Service Messages, Calls and Platforms
Short answer: DPDP customer communications covers every service message, transaction alert, support chat and recorded call you send or keep about a customer. The Digital Personal Data Protection Act, 2023 (DPDP Act) decides whether you may process the personal data involved. Meanwhile, TRAI’s telecom rules decide how commercial messages are classified and delivered. To comply with both, you need a lawful basis for each message type, clear retention rules for chats and recordings, and contracts with every messaging vendor.
This guide is about non-marketing communication. It covers order updates, OTPs, service alerts, contact-centre calls and the platforms that carry them. If you are looking for promotional consent on WhatsApp, SMS or email, read our separate guide to marketing consent on WhatsApp, SMS and email. Here, we explain how DPDP customer communications works in practice and how to evaluate platforms against it.
What does DPDP customer communications cover?
Any message that contains or relies on a customer’s personal data is in scope for DPDP customer communications. For example, that includes the phone number, name, order details, account balance, and the content of the conversation itself. In addition, it covers records you create, such as call recordings, chat transcripts and delivery logs.
Under the Act, therefore, your business is the Data Fiduciary. The customer is the Data Principal. Your CPaaS provider, contact-centre software, WhatsApp Business Solution Provider or email service is usually a Data Processor. Section 8(2) allows you to use a processor only under a valid contract.
How DPDP and TRAI rules divide the work
Two rulebooks shape DPDP customer communications in India, and they answer different questions.
First, the DPDP Act asks whether you may process the person’s data for this purpose at all. Second, TRAI’s Telecom Commercial Communications Customer Preference Regulations, as amended in 2025, govern how commercial SMS and calls are classified and delivered. Under the 2025 amendment, message headers carry a suffix: “-P” for promotional, “-S” for service, “-T” for transactional and “-G” for government messages.
The TRAI categories are useful, but they are not DPDP grounds. For example, a message can be a valid TRAI service message and still lack a DPDP basis. Therefore, map each message type to both rulebooks.
Which lawful basis applies to service and transactional messages?
For DPDP customer communications such as operational messages, Section 7(a) of the DPDP Act is the relevant ground. It allows processing for a specified purpose where the person voluntarily provided the data and has not said she does not consent. In fact, the Act’s own illustration fits customer messaging closely. A shopper gives a pharmacy her number and asks for a payment receipt by message. As a result, the pharmacy may use the number to send that receipt.
However, this ground is narrow. It covers the purpose the person had in mind, and nothing more. Consequently, a delivery update is usually fine, while a “you may also like” line added to the same message changes the picture. TRAI also treats any message that mixes promotional content as promotional.
Interpretation, not settled law: whether Section 7(a) covers a given message depends on the facts. Where in doubt, use consent under Section 6 and record it.
How DPDP customer communications works across your stack
In practice, DPDP customer communications pass through the same chain for every outbound message. First, a system of record, such as a CRM or order system, holds the customer’s data. Next, a trigger decides to send a message. Then a vendor delivers it by SMS, WhatsApp, email or voice. Finally, records of the message, and any reply, are stored.
DPDP checks belong at three points in that chain:
- Before sending: check that the message type has a basis, and that the customer has not withdrawn consent where consent applies.
- At the vendor: make sure the contract limits use, requires safeguards and covers breach notice.
- After delivery: apply retention rules to logs, transcripts and recordings.
Our guide to CRM compliance under DPDP covers the system-of-record side in more depth.
A practical example
A mid-sized insurer sends policy renewal reminders by SMS and WhatsApp. In addition, it runs a contact centre that records calls. The insurer maps renewal reminders as service messages linked to the policy the customer bought. Moreover, it keeps them free of cross-sell content. For calls, the IVR plays a short notice that the call is recorded and why. The insurer then sets a retention period for recordings based on its sector rules. It deletes recordings when that period ends and tells its contact-centre vendor to do the same.
Call recordings, chat transcripts and support tickets
In DPDP customer communications, recordings and transcripts often hold more personal data than the original message. For instance, a caller may share health, financial or family details to resolve a query. So treat these records as personal data with their own purpose and retention clock.
We recommend four steps. First, give notice at the start of the call or chat. Second, define why you keep recordings, such as quality review or dispute resolution. Third, restrict who can access them. Finally, set a deletion date. Also, where a customer asks to see or erase her data, include recordings in your search. Our guide to data principal rights explains how those requests work.
Logs, retention and breaches at messaging vendors
DPDP customer communications generate large volumes of logs. Rule 6 of the DPDP Rules, 2025 requires reasonable security safeguards, including logging, and retention of logs and personal data for at least one year. Therefore, agree with each vendor which logs they keep, for how long, and how you can access them.
Vendor breaches are a real risk for DPDP customer communications. Under Section 8(5), you remain responsible for safeguards even when a processor handles the data. Rule 7 requires you to inform affected people without delay and to send a detailed report to the Data Protection Board within 72 hours of becoming aware of a breach. For this reason, your vendor contract should require the vendor to tell you fast enough to meet that clock. Our guide to the 72-hour breach report covers the steps.
Comparing platforms for DPDP customer communications
Many buyers ask which communication platforms support DPDP requirements. We do not rank vendors, because features change quickly and claims need testing. Instead, compare platforms on capabilities.
| Capability | What to ask for |
|---|---|
| Message typing | Tags for service, transactional and promotional content |
| Consent lookup | A real-time check before sending |
| Language support | Notices in the customer’s chosen language |
| Retention controls | Configurable deletion for logs, chats and recordings |
| Processor terms | DPDP-aligned contract, breach notice and erasure on request |
In short, the platform delivers the message, but your consent and records system decides whether it should be sent. For that reason, many teams pair a delivery platform with a separate consent layer.
Pros and cons of a central consent layer for DPDP customer communications
Pros:
- Every channel checks the same consent and withdrawal records.
- Changing a messaging vendor does not break your consent evidence.
- Retention rules and processor records sit in one place.
Cons:
- Each channel needs an integration, which takes time.
- Message templates still need human review to keep service content free of promotion.
- A tool cannot decide your lawful basis. That remains a legal judgement.
Common mistakes
These DPDP customer communications mistakes come up most often:
- Treating TRAI registration as DPDP compliance. A registered template is not a lawful basis.
- Adding offers to service messages. The message becomes promotional and needs marketing consent.
- Keeping recordings forever. No clock, no owner and no deletion.
- Ignoring vendor copies. The business deletes data, but the vendor keeps logs and transcripts.
- No breach clause. The vendor has no duty to report incidents quickly.
How we measure success
These are the DPDP customer communications indicators we suggest tracking. We do not publish benchmark figures for them.
- Mapping coverage: the share of message templates mapped to a DPDP basis and a TRAI category.
- Pre-send checks: the share of outbound messages that pass a consent or basis check.
- Retention coverage: the share of recordings and transcripts with a set deletion date.
- Vendor contracts: the share of messaging vendors with DPDP-aligned terms.
- Breach readiness: the time from a vendor incident alert to your internal escalation.
Frequently asked questions
Do OTPs and order updates need DPDP consent?
Often they do not. Section 7(a) can cover data the customer gave you for that purpose. However, this depends on the facts, and the message must stay within that purpose.
Is a TRAI service message the same as a DPDP legitimate use?
No. Instead, TRAI categories control delivery and headers. The DPDP Act controls whether you may process the data. Therefore, you need to satisfy both.
Do we need to tell callers that calls are recorded?
If you keep recordings, they contain personal data. A short notice at the start of the call is the clearest way to inform people. We recommend it for every recorded line.
Who is responsible if a messaging vendor has a breach?
You remain responsible as the Data Fiduciary. Section 8(5) covers processing done on your behalf. Therefore, your contract must make the vendor report incidents quickly.
How long should we keep chat transcripts?
Keep them only as long as the purpose needs, subject to any law that requires longer. Rule 6 sets a minimum of one year for security logs.
When do these duties apply?
The core DPDP obligations, including the notice, security and breach rules, commence on 13 May 2027. TRAI’s rules already apply.
Summary and next step
In summary, DPDP customer communications needs three things. You need a mapped basis for every message type, a retention clock for every record, and a DPDP-aligned contract with every vendor. Above all, keep service messages clean of promotion, and keep marketing consent separate.
ProtectComply provides the consent, withdrawal, RoPA and vendor-catalogue layer that sits beside your messaging platforms. It does not send messages itself. See how the consent and RoPA features work, review the product modules, or book a walkthrough of your communication stack.
Published by Jupinder Singh Bedi, CEO and Co-Founder, ProtectComply. SEO: Yatin Chaudhary. Legal references: Digital Personal Data Protection Act, 2023, Sections 6, 7, 8; Digital Personal Data Protection Rules, 2025, Rules 6 and 7; TRAI Telecom Commercial Communications Customer Preference (Amendment) Regulations, 2025. This article is general information, not legal advice.