DPDP for e-commerce, marketplaces and D2C brands

E-commerce runs on personal data: accounts, addresses, order history, payment tokens, device data, reviews and marketing preferences. Most of it is collected for one reason, fulfilling an order, and then quietly reused for many others: retargeting, recommendations, lookalike audiences, sharing with brand partners, and credit offers at checkout. Under the DPDP Act, that reuse is where your risk sits.

This guide applies the Data Fiduciary playbook to online commerce.

Are you a Data Fiduciary, a processor, or both?

• D2C brand on its own site or app: you are the Data Fiduciary for your customers. Your platform provider (Shopify, a hosting company), payment gateway, courier and marketing tools are your Data Processors.
• Marketplace: you are a Data Fiduciary for buyers and for seller contacts. Sellers usually receive buyer names and addresses to ship orders. Spell out who is responsible for what in your seller terms. A seller who uses buyer data for its own marketing becomes a separate Data Fiduciary for that use, and needs its own ground.
• Seller on a marketplace: you are a Data Fiduciary for buyer data you receive and use. Use it only to fulfil the order unless the buyer separately agrees. The Third Schedule’s “e-commerce entity” excludes sellers on a marketplace, so the three-year rule applies to the marketplace, not to you.

The data you hold

Data category	Where it usually lives	Typical purpose	Sensitivity	Typical retention
Name, mobile, email, password hash	Account database, CRM	Account, login, order updates	Medium	While the account is active, then the inactivity rule
Delivery addresses, geolocation pins	Orders DB, logistics partner systems	Delivery	Medium to high (reveals home and routines)	Until delivery and returns close, plus legal minimums
Order history, cart, wishlist	Orders DB, data warehouse	Fulfilment, returns, invoices	Medium (can reveal health, religion, sexuality, finances)	Tax and accounting laws set minimums for invoices
Payment data	Payment gateway (tokens), refunds ledger	Payment, refunds	High	Keep card data with the gateway, not with you
KYC for COD limits, high-value orders or BNPL	Fintech partner, internal	Fraud, credit	High	Per the partner’s legal duties
Device IDs, IP address, cookies, ad IDs	Analytics, CDP, ad pixels, attribution SDKs	Analytics, attribution, retargeting	Medium to high in aggregate	Set short limits
Reviews, photos, Q&A	Content DB, CDN	Publishing reviews	Medium	As long as published; erase on request
Customer support chats and call recordings	Helpdesk, telephony vendor	Support, quality	Medium to high	6–12 months unless a dispute is open
Returns, damage photos, bank details for refunds	Returns system	Refunds	High (bank details)	Until the refund settles, plus legal minimums
Seller and partner contacts	Seller portal, CRM	Contract	Medium	During the contract and after, as accounting needs
Children’s accounts or orders (toys, school supplies)	Accounts DB	Varies	High	See section 9

Risk hotspots

1. Marketing bundled into checkout. A single “I agree to the Terms and Privacy Policy” checkbox at checkout cannot cover WhatsApp promotions, SMS offers, personalised ads or sharing with partners. Failure: every marketing message you send is processing without consent. Control: separate, unticked opt-ins per channel and purpose, shown after the order is safe, never as a condition of buying.
2. Pixels and SDKs that send data to ad platforms. Meta, Google and other tags, attribution SDKs and session recorders often send email hashes, phone numbers, purchase values and device IDs. Failure: sharing personal data with third parties without notice or consent, sometimes including what is in the cart. Control: a tag inventory, consent-gated loading, server-side tagging with field allow-lists, and no session recording on checkout or account pages.
3. Lookalike and custom audiences. Uploading customer lists to ad platforms is disclosure to another fiduciary. Control: only upload people who opted in to that purpose. Honour withdrawals by refreshing the lists.
4. Delivery partners and gig workers. Phone numbers and addresses are exposed to third-party couriers and riders. Failure: harassment, misuse, or data scraped from rider apps. Control: number masking, address shown only for active deliveries, short retention on the courier side, and contract clauses.
5. COD, BNPL and “pay later” partners. Checkout credit offers mean sharing data with lenders. Control: the lender collects consent in its own flow. You share only after the customer asks for the product. Never pre-qualify silently.
6. Customer support. Agents see everything. BPO vendors and chat tools store transcripts. Control: role-based views, masking of payment and address data, transcript retention limits, and BPO contracts that meet section 8(2).
7. Reviews and user content. Reviews can contain photos of people, health details (“this helped my diabetes”) and real names. Control: clear notice, pseudonymous display names, easy deletion, and moderation for third-party data.
8. Abandoned-cart and win-back campaigns. These email or message people who never consented to marketing. Control: an abandoned-cart reminder for an order the person started can rest on section 7(a) if your notice says so. Any promotional content in it needs consent.
9. Data sprawl into analytics and AI. The warehouse, CDP and recommendation models hold copies that erasure never reaches. Control: every copy is tracked in the inventory, erasure jobs run end to end, and training sets are reviewed when consent is withdrawn.
10. Account takeover and credential stuffing. These are a breach under DPDP if they expose addresses, orders or payment tokens. Control: OTP or passkey login, rate limits, anomaly detection, and the breach run-book.

Legal basis, purpose by purpose

Purpose	Basis	Notes
Creating an account, logging in	Consent (account creation) or 7(a) where the user voluntarily signs up for that purpose	Keep the data set minimal.
Processing and delivering an order	7(a): the customer voluntarily provided data to get the order	Section 6(5) illustration: after a withdrawal you may still deliver orders already placed and paid for.
Order and delivery updates (SMS, WhatsApp, email)	7(a)	Transactional only. No promotions in the same message without consent.
Invoices, GST and accounting records	7(d) / retention required by law	Keep the minimum the law requires; restrict access.
Fraud and abuse prevention	Section 17(1)(c) for preventing offences, otherwise consent	Document the use; do not reuse fraud signals for marketing. Relying on 17(1)(c) for private fraud checks is a common reading, not settled; confirm with counsel.
Returns and refunds	7(a)	Erase bank details once the refund settles.
Promotional SMS, WhatsApp, email and push	Consent, per channel	Also follow TRAI’s commercial-communication rules (TCCCPR) for SMS and calls.
Personalised recommendations on-site	Consent, unless strictly part of the service the user asked for	Offer a non-personalised option.
Retargeting, custom and lookalike audiences, data shared with ad platforms	Consent	The highest-risk purpose. Treat it as opt-in only.
Sharing with brand partners, co-marketing	Consent, naming the recipient category	Access rights include who you shared with (section 11(1)(b)).
Product reviews published with name or photo	Consent	Allow deletion.
Analytics for running the site (aggregate)	7(a) if strictly necessary for the service, otherwise consent	Prefer aggregated, pseudonymous analytics.
Credit or BNPL offers at checkout	Consent, collected by the lender	You may be a processor or a separate fiduciary; define it in the contract.

Notices and consent: getting the screens right

Channel	Do	Don’t
Sign-up	Show a short notice itemising the account data and why. Put marketing opt-ins as separate unticked toggles.	Hide marketing consent inside the Terms.
Checkout	Collect only what delivery and payment need. Offer guest checkout. Ask for marketing consent on the confirmation screen.	Make an order depend on accepting promotions or partner sharing.
App install	Ask for OS permissions (location, contacts, camera) only when the feature is used, explaining why.	Ask for contacts or SMS access at launch.
Website trackers	Load non-essential tags only after consent; keep a tracker register.	Fire pixels before the user has chosen.
WhatsApp and SMS	Record the opt-in source and timestamp. Put a one-tap “STOP” in every promotional message.	Message people from purchased lists.
Customer support	Read a short notice before call recording. Explain how to withdraw consent or make a request.	Use support transcripts to train models without a ground.
Existing customers	Send a section 5(2) notice by email or in-app with links to manage choices.	Assume old blanket consent covers new purposes.

Each notice must be readable on its own, itemise data and purposes, and link to withdrawal, rights and complaints to the Board (rule 3). It must also be available in English and the Eighth Schedule languages. Start with Hindi and the languages of your top delivery regions.

Other laws you must line up with

• Consumer Protection (E-Commerce) Rules, 2020: duties to display seller details and run grievance handling. Align your DPDP grievance process with your consumer grievance officer, but keep them distinct.
• Consumer Protection Act, 2019 and the guidelines on dark patterns: pre-ticked boxes, forced action and “confirm-shaming” can breach both consumer law and DPDP section 6.
• IT Act, 2000 and CERT-In Directions (2022): cyber incidents may need to be reported to CERT-In on a much shorter clock than the DPDP 72 hours. Confirm the current requirement with counsel.
• GST and income-tax law: retention of invoices and accounting records overrides erasure requests for those records only.
• RBI rules on payment aggregators and card tokenisation: do not store card data. Rely on gateway tokens.
• TRAI TCCCPR: consent and registration for commercial SMS and calls.
• Legal Metrology (Packaged Commodities) Rules: product and seller disclosures, not personal data, but often mixed into the same seller database.

Retention and erasure

1. When the purpose ends: order delivered and the return window closed, a refund settled, or an account closed. Stop using the data, and erase it after the one-year log minimum in rule 8(3), unless a law requires longer (for example tax records).
2. When consent is withdrawn: stop marketing and sharing at once, and remove the person from ad audiences and partner feeds. Keep order records you must hold by law.
3. The Third Schedule three-year rule: if you are an e-commerce entity with 2 crore or more registered users in India, you must erase a user’s data three years after they last engaged with you. The clock runs from the last time they used the service for its purpose or exercised a right, or from the Rules’ commencement if that is later. Two kinds of data are excluded: data needed to access the account, and data needed to access virtual tokens such as wallet balances, gift cards or loyalty points. At least 48 hours before erasure, tell the user it will happen unless they log in or get in touch (rule 8(2)).
4. Processors: make your CRM, CDP, email and messaging tools, and your couriers, erase too. Get confirmation.
5. Backups: document how long backups keep data and make sure restored backups replay erasures.

Rights requests and grievances

• Channels: an in-app “Privacy” section, a web form, the support chat, and an email address. Publish them along with the identifier you need, usually the registered mobile or email.
• Identity: use an OTP to the registered contact. Do not ask for ID documents you do not already hold.
• Access (section 11): give a summary of profile data, order history, marketing preferences and devices. List the other fiduciaries and processors you shared data with: couriers, payment providers, ad platforms (if consented), partners.
• Erasure (section 12(3)): erase the account, addresses, preferences and audience memberships. Keep invoices and data under a legal hold, and tell the person what you kept and why.
• Grievances: acknowledge quickly. Publish a resolution period well inside the 90-day ceiling (rule 14(3)); 15–30 days is good practice.
• Nomination (section 14): let users nominate someone, which matters for accounts holding wallet balances or gift cards.

Breach readiness

Likely scenarios:

• a leaked export of orders or addresses from a seller or courier portal
• account takeover at scale
• a misconfigured storage bucket of invoices or return photos
• a compromised marketing tool
• a support agent copying data

Run-book:

1. Contain within hours: revoke keys, disable accounts, take exposed buckets offline.
2. Assess: which data, how many people, and which consequences (fraud, scams, physical safety for addresses).
3. Notify affected people without delay through their account or registered contact, covering every point in rule 7(1): what happened, the consequences for them, what you are doing, what they should do (for example, beware of fake “delivery” calls), and a contact.
4. Notify the Board without delay, then send the detailed report within 72 hours (rule 7(2)).
5. Report to CERT-In where its directions apply, and inform payment partners if tokens or payment data may be involved.
6. Learn: find the root cause, fix it, and update contracts if a processor caused the breach.

The checklist

Phase 1: discover (days 0–30)

• [DPO] Appoint a DPDP owner and a working group (product, engineering, marketing, CX, legal, security).
• [Product] Map every collection point: sign-up, checkout, app permissions, reviews, support, returns, campaigns, social commerce.
• [Eng] Inventory all systems: orders DB, CRM/CDP, warehouse, analytics, helpdesk, logs, backups.
• [Marketing] List every pixel, tag and SDK on the web and in the app, with what each sends and to whom.
• [Legal] List all processors (gateway, couriers, messaging, email, support BPO, cloud, analytics) and collect their contracts.
• [DPO] Count registered users in India to check the Third Schedule threshold (2 crore or more).
• [Product] Check whether children order or hold accounts (toys, school supplies, games).
• [Marketing] Find every customer list uploaded to ad platforms and every partner data feed.

Phase 2: design and build (days 31–90)

• [Legal] Assign a legal basis to each purpose (use the table above), and stop purposes without one.
• [Legal] Write itemised notices for sign-up, checkout, app permissions, support and marketing.
• [Product] Translate the notices into Hindi and the top regional languages; make all 22 available on request.
• [Product] Rebuild sign-up and checkout: guest checkout, minimal fields, separate unticked marketing opt-ins per channel.
• [Eng] Load non-essential tags only after consent; move to server-side tagging with field allow-lists.
• [Eng] Stop session recording on checkout, payment and account pages.
• [Eng] Check consent before every marketing send, audience upload and partner share.
• [Eng] Feed withdrawals in real time to the CRM, CDP, messaging tools and ad-audience sync.
• [Product] Add one-tap withdrawal in app settings and “STOP” in every promotional message.
• [Ops] Mask customer phone numbers for couriers and riders; show addresses only while a delivery is active.
• [Legal] Add DPDP clauses to processor contracts: security, breach notice to you, erasure on instruction, one-year logs, sub-processors, audit.
• [Legal] Update seller terms: buyer data only for fulfilment, no marketing, erasure after returns close, breach notice.
• [Legal] Make BNPL and credit partners collect consent in their own flow, and write down who is the fiduciary.
• [Eng] Encrypt addresses and phone numbers at rest; tokenise payments through the gateway; never store card data.
• [Security] Add MFA for admin, seller and support consoles, and rate limits and bot protection on login.
• [Eng] Keep access logs for at least one year.
• [Eng] Build retention jobs: erase return bank details after settlement, close dormant accounts, apply legal holds for invoices.
• [Eng] If you are in the Third Schedule, build the three-year inactivity erasure with the 48-hour warning, excluding account access and wallet, gift card and loyalty tokens.
• [Product] Publish the privacy page: contact person, rights request channels, identifier needed, grievance timeline.
• [Ops] Set up the rights and grievance workflow with OTP verification, owners and deadlines.
• [Product] Send the section 5(2) notice to existing customers with a link to manage choices.
• [Product] For child customers, add an age gate and verifiable parental consent, and switch off personalised ads and tracking.

Phase 3: operate (ongoing)

• [DPO] Review new campaigns, partners, SDKs and features before launch.
• [Marketing] Re-scan the site and app tags every month; remove tags nobody owns.
• [Marketing] Refresh ad audiences at least weekly so withdrawals take effect.
• [Security] Run a penetration test every year on the site, app, seller portal and APIs.
• [Security] Run a breach tabletop drill every year (for example, a seller-portal export leak) against the 72-hour clock.
• [Ops] Review rights and grievance timelines every month; investigate overdue cases.
• [Legal] Review processor and seller contracts and renewal dates every quarter.
• [DPO] Keep evidence: consent records, withdrawal handling, erasure confirmations, training records.
• [Leadership] Re-assess the likelihood of SDF status as the user base grows.

Where myconsentapp comes in

You need to	With myconsentapp	You still own
Ask for consent per purpose and per channel	Define purposes (orders, WhatsApp offers, email offers, personalised ads, partner sharing) once. The hosted consent page or widget shows each as a separate toggle, off by default, after checkout.	Choosing the moment in your journey.
Prove consent if a customer complains	Every choice is signed and hash-chained against the exact notice version. The customer gets a receipt, and you can download an evidence pack.
Check consent before every campaign	Call the verify API before sending or uploading an audience; it returns not permitted immediately after a withdrawal.	Wiring it into your campaign tools.
Spread withdrawals everywhere	Signed webhooks tell your systems the moment a customer withdraws. Acknowledgement deadlines flag anything not handled.	Removing the person from audiences in your ad accounts.
Make vendors stop too	A processor registry links each vendor to purposes. Vendors confirm withdrawals and erasures, and erasure stays open until they do. Contract expiry dates are flagged.	Signing the contracts.
Re-notify existing customers	Send customers to the hosted page to record fresh, itemised choices under the new notice.	Sending the email or in-app message.
Offer notices in Indian languages	Notices in English and the 22 Eighth Schedule languages, with machine-translation drafts marked for review.	Reviewing the translations.
Run retention	Set retention per purpose; the retention job ends access and alerts you and your linked processors; erase-on-withdrawal opens erasure automatically.	Deleting rows in your own databases.
Handle access, erasure and grievances	A rights inbox with SLA timers; the customer sees status in their app; erasure closes with a structured proof.	The answers.
Handle children	An age gate with guardian verification through DigiLocker; tracking and ad purposes can never be marked child-safe.	Deciding where children may be present.
Manage a breach	A breach register with the 72-hour clock, Rule 7 notices to affected customers, and Board report documents.	Detecting and investigating.

Not included today: a website cookie-banner scanner or tag manager. Use your tag manager to gate tags, and use myconsentapp’s consent status as the source of truth.

Common mistakes

• Treating “I agree to the Terms and Privacy Policy” as consent for marketing.
• Pre-ticked “Send me offers on WhatsApp” boxes.
• Uploading the whole customer list to ad platforms “for exclusion only”, which is still a disclosure.
• Leaving couriers with full customer phone numbers and addresses for months.
• Removing a customer from the CRM but not from the warehouse, the CDP and ad audiences.
• Asking for an Aadhaar copy to verify a rights request.
• Building the three-year erasure without the 48-hour warning, or erasing wallet balances the user still holds.
• Forgetting the Instagram or WhatsApp storefront, where orders are taken in DMs and spreadsheets.

Frequently asked questions

Do I need consent to deliver an order? Usually not. Section 7(a) covers data a customer voluntarily gives for a purpose, here delivering what they bought, as long as they have not objected. The section 5 notice is tied to consent requests, but telling people plainly what you use their data for is still good practice, and their rights under sections 11 and 12 still apply.

Can I send an abandoned-cart reminder? A plain reminder about an order the person started can rest on 7(a) if your notice explains it. Adding promotions, discounts for other products or cross-sell turns it into marketing, which needs consent.

If a customer withdraws consent, must I cancel their order? No. The Act’s own illustration says you may stop them placing new orders but may not stop processing for goods already ordered and paid for (section 6(5)).

Are we covered by the three-year rule? Only if you are an e-commerce entity with 2 crore or more registered users in India. Sellers on a marketplace are excluded. Everyone else must still erase data when the purpose is over.

Is a hashed email “anonymous” when we send it to an ad platform? No. A hashed email can be matched back to a person; that is the whole point of sending it. Treat it as personal data that needs consent.

Our courier is a separate company. Who is responsible if they leak addresses? You are responsible for processing done on your behalf (section 8(1)). Make sure the contract requires security, breach notice and erasure, and limit what you share.

Do I need a Data Protection Officer? Only Significant Data Fiduciaries must appoint one. Every fiduciary must publish a contact person who can answer questions (section 8(9), rule 9). Large marketplaces should prepare for SDF status.