The short answer
The Digital Personal Data Protection Act treats your chat logs, phone numbers and order histories as protected personal data, and it applies to a two-person store as much as to a bank. For most small businesses compliance is less about lawyers than about choosing tools that can actually locate, export and delete a specific customer's data on request.
The Digital Personal Data Protection Act is the first Indian law that treats your customer chat logs, phone numbers, and order histories as legally protected personal data - and it applies to a two-person Shopify store just as much as to a bank. The good news: for most SMBs, compliance is less about lawyers and more about choosing tools that were built correctly.
What follows is a plain-language orientation, not legal advice. If you handle sensitive categories of data or operate at scale, talk to someone qualified. If you run a small business wondering whether any of this touches you, it does, and the practical version is shorter than you fear.
What counts as personal data in a support inbox
Most small businesses underestimate this, because they picture a customer database and conclude they do not have one. You do. It is your inbox.
Names and phone numbers, obviously. Delivery addresses. Email addresses. Order histories. But also the things that do not feel like data: the chat transcript where a customer explained why they wanted to return something, the recording or summary of a call, the screenshot they sent of a damaged item, the WhatsApp thread on your business number. All of it is personal data about an identifiable person, and all of it sits in tools you chose.
| What you hold | Where it usually lives | Can you delete just one customer's? |
|---|---|---|
| Name and phone number | Order system, chat tool | Usually yes |
| Chat transcripts | Support tool or a shared mailbox | Often not, in a mailbox |
| Call recordings or summaries | Phone provider | Depends entirely on the provider |
| Uploaded photos and screenshots | Wherever the thread lives | Rarely, without doing it by hand |
| WhatsApp threads | The WhatsApp tool | Ask the vendor before you need to |
The right-hand column is the whole exercise. An obligation you cannot technically perform is not a policy problem - it is a procurement problem you already made.
The obligations that touch your support stack
Four matter in practice for a support setup.
Notice and purpose. You tell people what you are collecting and why, in language they can read, and you use it for that. Data collected to answer a support query is not a marketing list.
Purpose limitation. The support transcript that helped you resolve a delivery complaint should not quietly become training data, a lead list, or an input to something the customer never agreed to.
Security safeguards. You are expected to take reasonable measures - encryption, access control, not leaving credentials in a shared spreadsheet - proportionate to what you hold.
Erasure. When data is no longer needed for the purpose, or a customer asks, you must be able to actually delete it. Not archive it. Not hide it from a view.
Compliance isn't a document you write. It's a property of the tools you chose.
Why this lands on procurement, not policy
Every one of those four is a capability question about your software rather than a question about your intentions. You can write an excellent privacy policy and still be unable to honour it.
Try the test on your current setup. A customer emails asking you to delete everything you hold about them. Can you find their chat transcripts across every channel - website, WhatsApp, phone? Can you delete them without deleting anyone else's? Can you confirm the deletion propagated to backups and any analytics copy? For most small businesses running support out of a shared mailbox plus two SaaS tools, the honest answer to at least one of those is no.
That is fixable, and the fix is boring: consolidate where customer conversations live, and pick tools that expose export and deletion as actual features rather than as a support ticket you file with the vendor.
Questions to ask any support vendor
Six questions. A vendor who has done the work answers them crisply; one who forwards you to a generic trust page has not.
- Where is my data physically stored, and is it isolated from other customers at the database level rather than by a filter in application code?
- Is it encrypted at rest as well as in transit?
- Can I export or delete one specific customer's conversations, on my own, without raising a ticket?
- Is my data used to train any model - yours or a third party's?
- Which sub-processors touch this data, and where are they?
- What happens to my data when I cancel, and how long until it is actually gone?
Question one deserves the most weight with AI tools specifically. Your documents and transcripts are what the system reads to produce answers, so isolation is not an abstract database concern - it is the mechanism that makes it impossible for your price list to inform someone else's chatbot. Our security page answers all six, and the DPA is the contractual version.
Retention: the setting nobody changes
Most tools default to keeping everything forever, because storage is cheap and deletion is a support burden. That default is directly at odds with holding data only as long as the purpose requires.
The practical fix is to decide a retention period on purpose rather than by inertia. Support transcripts that are more than a year old are almost never useful operationally - they are a liability sitting in a database waiting for a breach to make them interesting. Pick a window, set it where the tool allows, and write it down in your privacy notice so the notice describes what actually happens.
The same applies to what you collect in the first place. Every field you ask for at escalation is a field you now hold, protect and eventually delete. Name and contact is enough; an eleven-field form is a compliance cost as well as a conversion cost.
The upside nobody mentions
Indian customers are increasingly wary of where their data goes, and increasingly willing to ask. Being able to answer - your chats are encrypted, stored with tenant isolation, retained for a fixed window and deletable on request - is not legal overhead. It is a trust signal most of your competitors cannot make, because they have not done the procurement work.
The DPDP Act sets a floor. Treat it as a floor you are comfortably above, and it becomes a sentence you can put on your own website. The privacy page is where ours lives, and the security page covers tenant isolation and the rest in plain language.
Frequently asked questions
Does the DPDP Act apply to a small business?
Yes. The obligations attach to what you do with personal data, not to your size. A two-person store holding customer names, phone numbers and chat transcripts is processing personal data in the same way a bank is, even though the scrutiny is different.
What counts as personal data in a support context?
Names, phone numbers, email addresses, delivery addresses, order histories and the chat or call transcripts themselves - transcripts are the one most businesses forget, because they do not feel like a database.
What should I ask a support vendor about compliance?
Where the data is stored and whether it is isolated per customer; whether it is encrypted at rest as well as in transit; whether you can export or delete one specific customer's conversations; whether your data is used to train models; and how long they retain data after you cancel.
Why does tenant isolation matter for AI tools?
Because your uploaded documents and transcripts are what the AI reads. Without isolation at the data layer, there is a path - however unlikely - by which your price list informs another business's answers. Isolation makes that structurally impossible rather than merely against policy.
