E-commerce Is Named In The Rules Themselves.
Most sectors have to reason by analogy from a general statute. E-commerce does not: it is one of three classes the Third Schedule names outright, and the Act uses online marketplaces in three of its own illustrations.
Covers: online stores, marketplaces, D2C brands, quick commerce, retail chains.
Why this sector is treated differently
The Digital Personal Data Protection Act, 2023 is drafted to be sector-neutral. It defines a Data Fiduciary by what it does with personal data, not by what industry it is in, and almost every obligation applies identically to a hospital, a bank and a bookshop. That is deliberate, and it is why most "DPDP for your industry" material is the same checklist with a different heading.
E-commerce is one of the genuine exceptions. The Third Schedule to the Digital Personal Data Protection Rules, 2025 names "e-commerce entity" as a class with its own erasure clock, triggered at two crore registered users in India. And the Act's drafters reached for an online marketplace three separate times when they needed an illustration - for pre-commencement consent under section 5, for withdrawal under section 6(6), and for erasure under section 8(7). Those illustrations are part of the Act. They are the closest thing you have to the legislature telling you how it expects your sector to behave.
The practical consequence is that an e-commerce compliance programme is mostly about two things the rest of the Act treats as edge cases: what happens when a customer withdraws consent in the middle of a transaction, and when a dormant account has to be erased.
What you actually process
One row per activity, not per data type. Lawful basis and erasure attach to a purpose, so the same phone number can sit in three rows below with three different answers.
| Activity | Lawful basis | When it must go |
|---|---|---|
| Fulfil an orderName, Delivery address, Phone, Payment reference, Order contents | § 6Consent for the specified purpose. Section 6(6) then does unusual work here: withdrawal stops future processing but does not stop the supply of goods already ordered and paid for. | § 8(7)Erase when the purpose is served, unless another law requires retention. Tax and company law do impose invoice retention; those periods come from statutes outside this Act, so confirm them against those statutes rather than assuming a number. |
| Market to past customersEmail, Phone, Purchase history, Browsing and click behaviour | § 6A separate consent from the one that supports fulfilment. Consent must be free, specific and informed, so bundling marketing into checkout does not produce it. | § 8(7)On withdrawal, cease and cause processors to cease, then erase. There is no marketing-specific carve-out. |
| Hold a dormant accountProfile, Saved addresses, Order history, Saved payment tokens | § 8(7)Once the specified purpose is no longer being served there is no basis to keep holding it, whatever the user count. The Third Schedule adds a hard clock on top for large e-commerce entities. | Third ScheduleThree years after the Data Principal last approached you or exercised a right, or three years from the rule's commencement, whichever is latest, at two crore or more registered users in India. |
| Answer a rights requestWhatever the Data Principal asks about, across every system | § 11The right to access information about processing, with correction and erasure under section 12 and grievance redressal under section 13. | § 8(7)The request record is its own processing activity. Keep what proves you complied, and no more. |
The data flow, and where it breaks
Each lane follows one activity through the actors and systems that touch the data. The failure mode sits on the hop where it happens, rather than in a list somewhere else on the page.
Fulfil an order
Complete the purchase the customer has already paid for
- Checkout formCollects the delivery and contact details§ 5Fails when: Notice bundled into terms of service rather than given at the point of collection
- Order serviceHolds the order and its state transitions§ 8(1)Fails when: Withdrawal wired as a global stop, cancelling deliveries the customer paid for
- CourierReceives name, address and phone to deliver§ 8(2)Fails when: Onboarded on a commercial contract with no processing terms at all
- Payment gatewayProcesses the transaction and returns a reference§ 8(2)Fails when: Treated as a peer rather than a processor, so no instruction trail exists
Market to past customers
Promote further purchases to someone who has bought before
- Order serviceExports the customer list and purchase historyFails when: Purchase data reused for marketing on the consent given for fulfilment
- Marketing platformSegments and schedules campaigns§ 8(2)Fails when: Segments built from behavioural data nobody consented to being profiled on
- Email and SMS vendorDelivers the message§ 8(2)Fails when: Suppression list not propagated, so withdrawal is honoured in one channel only
Hold a dormant account
None, once the customer stops returning. This is exactly the case the Third Schedule was written for.
- Account storeRetains the profile indefinitely by defaultThird ScheduleFails when: No last-approached timestamp, so the erasure date cannot be computed at all
- Erasure jobComputes the due date and erasesrule 8(1)Fails when: Runs on account creation date instead of last approach, erasing active customers
- Notice jobWarns the Data Principal before the period completesrule 8(2)Fails when: Fires late, or does not cancel when the customer returns
Answer a rights request
Discharge the duties Chapter III places on you
- Published contactReceives the request§ 8(9)Fails when: No published contact, so requests arrive through support and are never recognised as rights requests
- Identity checkConfirms the requester is the Data PrincipalFails when: Either too weak to be safe, or so heavy it becomes a barrier to the right
- Systems sweepFinds the data across order, marketing and analytics stores§ 11Fails when: Analytics and warehouse copies missed, so the summary given is incomplete
The provisions that apply
Three years, at two crore users
Rule 8(1) requires an e-commerce entity with two crore or more registered users in India to erase personal data three years after the Data Principal last approached it for the specified purpose or last exercised a right - or three years from the rule's commencement, whichever is latest. Retention required by another law survives this. Below the threshold the class rule does not bite, but section 8(7) still does.
Forty-eight hours' warning
Before that period completes, the Data Principal must be told - at least forty-eight hours in advance - unless she comes back or exercises a right in the meantime, which resets the clock. This is an outbound notification duty with a hard deadline, so it is a system to build, not a policy to write.
Withdrawal does not cancel the order
The Act's own illustration: X consents, places an order and pays. If X withdraws consent, Y may stop letting her use the app to place orders - but may not stop processing for the supply of goods already ordered and paid for. Withdrawal is not a kill switch on an in-flight transaction, and building it as one would break the contract you owe the customer.
Purpose served means erase
Illustration (I) to section 8(7): X registers on a marketplace to sell her used car, the sale concludes, and Y shall no longer retain her personal data. This bites regardless of user count and regardless of the Third Schedule. Purpose exhaustion is the general rule; the Schedule is a backstop for accounts that never formally end.
What to do about it
Find out whether you cross two crore
"Registered users in India" is a number your growth team already reports. Establish who owns it, how it is counted, and what happens the quarter it crosses - the obligation arrives with the threshold, not with a notification.
Instrument "last approached"
The three-year clock runs from the Data Principal's last approach or exercise of a right. If your systems record only account-creation and last-login, you cannot compute the date the rule turns on. Add the event, then backfill what you can.
Separate consent withdrawal from order fulfilment
Model them as two different states. Withdrawal stops future processing for the consented purpose; it does not stop you shipping what has been paid for, and section 6(6) says so explicitly. Most consent tooling gets this wrong by treating withdrawal as a global stop.
Build the forty-eight-hour notice as a job, not a policy
It has to fire before a computed date, per Data Principal, and be cancellable when she returns. That is a scheduled pipeline with a suppression rule - the kind of thing that is trivial to specify and easy to leave until an audit asks for evidence it ran.
Sequence the work
The same controls as above, in the order they are worth doing. Each names the evidence you would put in front of an auditor, because a control you cannot evidence is a control you cannot prove you had.
Build the foundation
Get the lawful basis and the roles right. Everything else assumes these are settled.
- Fulfil an orderModel withdrawal and fulfilment as two independent states. Withdrawal closes future ordering; it must not cancel an in-flight delivery.Evidence: Per-purpose consent records tied to the order, plus the order state transitions showing what continued after withdrawal and why.
- Market to past customersA distinct opt-in for marketing, and withdrawal that is as easy as giving it was. Section 6(4) makes that comparability explicit rather than aspirational.Evidence: Consent records showing purpose, timestamp and the exact wording shown, plus suppression propagating to every channel within a stated window.
Operationalise it
Turn the basis into systems that run without anyone remembering to run them.
- Hold a dormant accountRecord last approach and last exercise of a right as first-class events, then drive a scheduled erasure and a forty-eight-hour notice from them.Evidence: Erasure job logs showing the computed date per Data Principal, the notice sent, and any reset caused by the customer returning.
Keep it honest
Prove it still works, and answer the people whose data it is.
- Answer a rights requestOne intake channel that is published, and a documented sweep list naming every store that can hold personal data.Evidence: A request log with received, identified, answered timestamps, and the sweep list itself under version control.
Section and Schedule references above point at the statute itself. Read them in context in the full text of the Act, or against the MeitY publication. This is an educational summary, not legal advice for your organisation.
E-commerce & retail: common questions
Does the three-year rule apply if we have fewer than two crore users?
The Third Schedule class obligation does not. Section 8(7) still does: you must erase when the Data Principal withdraws consent or when it is reasonable to assume the specified purpose is no longer being served, whichever is earlier, unless a law requires retention. In practice the general rule is often the stricter one, because it has no waiting period.
Can we keep order history for accounting after erasure is due?
Section 8(7) opens with "unless retention is necessary for compliance with any law for the time being in force". Tax and company law retention requirements sit inside that carve-out. The discipline is to retain the records the law names, for the period it names, and not to treat one statutory retention duty as a licence to keep the whole customer profile.
Are marketplace sellers Data Fiduciaries too?
It depends on who determines the purpose and means of processing, which is the test in the definition of Data Fiduciary. A seller who receives buyer data and decides for itself what to do with it is making that determination. A seller who only processes on the marketplace's instructions looks like a Data Processor, and section 8(2) then requires a valid contract between them.
Know this well enough to prove it
The certification is a free, graded 15-question exam covering the Act end to end, not just this sector. Pass mark is 70%.
DPDP Academy Editorial: Legal education and implementation guidance. DPDP Academy Source Review: Primary-source verification against Gazette and MeitY publications; last checked 9 August 2026 against E-commerce & retail implementation guide. Educational information, not legal advice.