DPDP is live. Can your systems keep the promise?

India's Digital Personal Data Protection Act is no longer a bill on the horizon - the rules are notified, the clock is running, and by late 2026 the Data Protection Board moves from gentle guidance to real supervision. Most D2C founders will hear "compliance" and reach for a privacy-policy template and a cookie banner. Those are the easy, visible ten percent. The hard ninety percent is a question your systems have to answer for every single customer: can you prove what you were allowed to do with their data, stop doing it the moment they say so, and delete them from everywhere when they ask? For a brand whose customer lives in six disconnected tools, the honest answer today is no - and closing that gap is an operations problem, not a legal one.

What DPDP actually asks a D2C brand to do

Strip away the legal language and the Act reduces to a handful of operational promises about the personal data you hold - names, phone numbers, emails, addresses, order history, behaviour. You have to collect consent for a specific, stated purpose, behind a notice written in clear and plain language that itemises what you are collecting and why. You have to use that data only for the purpose the customer agreed to, and no other. You have to make withdrawing consent as easy as giving it, and honour the withdrawal. You have to delete personal data when the customer asks, or when the reason you kept it has expired - and the rules set specific retention timelines for e-commerce entities. And you have to answer a customer who asks what data you hold about them, keep that data reasonably secure, and report a breach.

None of that is exotic. Read as a systems specification rather than a legal text, it is a short list of things your software has to be able to do on demand, per person, and prove it did. The trouble is that most D2C stacks were never built to do any of them.

The cookie-banner trap

The first move most brands make is to bolt a consent banner onto the storefront and swap in a longer privacy policy. That is necessary and nowhere near sufficient. A banner captures a "yes" at the front door; the law is about what happens to that person's data for the months and years afterwards, in the tools the banner has never heard of. Worse, a banner that records consent but whose "no" or "withdraw" never reaches your email platform is not a shield - it is evidence. You now hold a timestamped record saying a customer declined marketing, next to a campaign that mailed them anyway. Compliance is not the notice on the way in; it is the behaviour of every downstream system, and a banner changes none of it.

Why DPDP is a data problem, not a legal one

Here is the insight the privacy-policy framing hides. In a typical D2C business, a single customer does not exist once. She exists as a Shopify customer record, an Odoo contact, a subscriber profile in your email tool, a separate profile in your SMS and WhatsApp platform, a ticket requester in your helpdesk, a row in a warehouse or courier export, and a hashed entry in two or three ad-platform custom audiences. Those records were created independently, at different times, and most of them never learned they are the same person. Your marketing knows her as an email; your ERP knows her as a phone number; your COD courier knows her as an address on a manifest.

DPDP's obligations all assume the opposite - that "the customer" is one identifiable subject you can act on completely. Consent given once should govern all processing of her data. A withdrawal should stop every use of it. A delete request should remove every copy. But you cannot honour a promise about a person your systems cannot agree is one person. This is why compliance is not a document you write and file. It is a data foundation you either have or you do not - the same first-party data foundation that decides whether your marketing and AI tools work at all. That earlier problem was about owning your data; this one is about proving you had permission for it and being able to erase it. Same plumbing, higher stakes.

The three things your systems now have to do

Turn the Act's promises into engineering and three capabilities have to exist across your stack, not inside any one tool.

• Consent that travels, with its purpose attached. It is not enough to record that a customer said yes. You have to record what they said yes to - marketing emails, SMS, WhatsApp, personalisation, sharing with a partner - each as a separate, timestamped decision, and store it where every system that might act on it can read it before it acts. Consent living only in your storefront's cookie tool, invisible to your ERP and your email platform, is consent no downstream system can honour.
• Processing that respects the purpose, and a withdrawal that propagates. Purpose limitation means the phone number a customer gave you for delivery updates cannot quietly become a marketing list. When someone withdraws consent, that signal has to reach and change the behaviour of every tool - the email platform suppresses them, the WhatsApp sender stops, the ad audience drops them - not just the one where they clicked unsubscribe. A withdrawal that stops one channel and leaves three running is a breach with a paper trail.
• Erasure that can find every copy. A delete request is the hardest test, because it exposes exactly how fragmented you are. To honour it you have to locate that person in the store, the ERP, the marketing tools, the helpdesk, the exports, and the ad audiences, remove or irreversibly anonymise the personal data, and keep only what a separate law (tax, accounting) genuinely requires - and be able to show you did. If finding the person takes a week of manual database queries, you do not have a delete process; you have a delete aspiration.

Notice what all three need first: a way to resolve the scattered records into one customer, and one place where consent and identity are authoritative. Get that right and the three obligations become routine operations. Skip it and every request is a fire drill.

The India and D2C cut: WhatsApp, COD, and marketplaces

Three things about how Indian D2C actually operates make DPDP harder than a generic privacy checklist admits, and each one lands in the back office.

WhatsApp and SMS marketing need demonstrable opt-in. A brand running WhatsApp marketing through Odoo or an SMS blast is processing personal data for a specific purpose, and the law expects you to show the customer agreed to it. That means the opt-in has to be recorded against the customer with a timestamp and a purpose, and a "stop" has to reach the sender immediately. The discipline is the same one behind pruning your marketing list for deliverability - keep only the contacts who genuinely want the message - except here it is a legal duty, not just an inbox-placement tactic.

COD checkout collects data without an account. A large share of Indian D2C orders are cash-on-delivery, placed by first-time buyers who never create an account. You still capture a name, phone, and address - personal data - at the moment of purchase. Where is the consent, what purpose does it cover, and can that guest buyer later ask you to delete them? If your COD orders live only as rows in a courier manifest and an ERP with no link back to a consent record, you are processing personal data you cannot govern.

Marketplace and imported data carries obligations you did not originate. Selling on marketplaces, or importing a list you acquired, means you hold personal data you did not collect directly through your own notice. You are still responsible for it. When that data flows into your Odoo ERP and your marketing tools, it inherits the same consent and erasure duties as data a customer typed into your checkout - and "we got it from the marketplace" is not an answer to a delete request. Every inbound source has to land against the one customer record, tagged with where it came from and what you are allowed to do with it.

Where to start without boiling the ocean

You do not need a data-protection platform and a compliance department by next week. You need to make five moves in order, and most of the value is in the first three.

First, draw a data map: list every system that holds customer personal data - store, ERP, email, SMS, WhatsApp, helpdesk, analytics, ad accounts, courier exports - and for each one write down what it holds and how you would delete a person from it today. The map alone usually shows the problem: the same customer in eight places, deletable from two. Second, make one customer record the source of truth. For most D2C brands the clean spine is the Shopify and Odoo link, with the ERP contact as the master and other tools resolving to it. Third, treat consent as a field on that record, not a setting in a banner - captured per purpose, timestamped, and read by systems before they process. Fourth, write an erasure runbook: the actual step-by-step for finding and removing a person across every system on the map, tested on a real request, so a "delete me" is a checklist and not a panic. Fifth, start where the exposure is highest and the volume is largest - marketing consent and your top two or three systems - and extend to the long tail after. Do those and you have covered most of the real risk with a fraction of the effort, and you are ready for the sharper supervision that arrives later in 2026 rather than scrambling after it.

This is squarely the work an AI-powered Odoo back office is built for, and it sits alongside the broader compliance and risk posture a growing brand needs. If you want the multi-regulation view, our compliance checklist across GDPR, DPDP, and the EU AI Act maps the overlapping obligations; this post is the focused D2C build underneath the DPDP row of it. And it is the same readiness that should precede any AI - the data hygiene you fix for a delete request is the hygiene you need before an AI marketing agent runs your store or an AI support agent reads customer data on your behalf.

Frequently asked questions

Does DPDP apply to a small D2C brand?

Yes. The Act applies to the processing of digital personal data of individuals in India, and there is no blanket small-seller carve-out for the core obligations - consent, purpose limitation, and the duty to honour withdrawal and erasure. Some heavier obligations scale up for large-volume "significant" data fiduciaries, but a small D2C brand collecting customer names, phones, and addresses is processing personal data and is responsible for it. Size changes the intensity of some duties, not whether you have them.

Is a cookie consent banner enough to comply?

No. A banner and an updated privacy policy are a starting point for how you collect consent, but compliance is decided by what happens to the data afterwards - whether you use it only for the consented purpose, whether a withdrawal actually stops processing in every tool, and whether you can delete a person on request. All of that lives in your systems downstream of the banner, so a banner alone leaves the hardest ninety percent of the obligation unmet.

What about customer data we get from marketplaces or bought as a list?

You are responsible for it once you hold and process it, even though you did not collect it through your own notice. Data flowing in from a marketplace or an acquired list carries the same consent and erasure duties as data a customer entered at your checkout. In practice that means every inbound source should land against your single customer record, tagged with its origin and the purposes you are permitted, so that a withdrawal or a delete request reaches it too.

When does enforcement actually bite?

The rules are notified and the Act is enforceable, with an initial soft-enforcement period widely expected to run through late 2026 while the Data Protection Board builds up and the consent-manager framework comes online. After that window, supervision moves from guidance toward active enforcement. The practical read for a D2C founder: the penalties are real and the direction is fixed, so the low-cost time to build the data foundation is now, before a request or an audit forces it.

India's DPDP Act is one more 2026 rule that looks like a legal task and is really a data one. The privacy policy takes an afternoon; keeping its promises takes a stack that agrees on who the customer is and can act on her data completely - consent honoured, purpose respected, deletion done. Build that foundation - one customer record, consent that travels, and an erasure process that reaches every tool, inside the ERP and Shopify integration you already run - and DPDP becomes a set of routine operations instead of a scramble per request. If you want it built, our team does exactly this. Book a free call and we will map where your customer data and consent actually live, and show you honestly where a withdrawal or a delete request would fall through the cracks today - and how to close it.