DPDPA Compliance for E-commerce in India

Split the purposes. Section 7(a) covers personal data a customer voluntarily provides for a specified purpose without having indicated they object to its use — which reasonably covers taking the address, phone number and order details needed to fulfil and deliver that purchase, handle returns, and meet your invoicing and tax retention duties. It does not stretch beyond that purpose. Account creation, saved payment instruments, loyalty programmes, personalised recommendations, retargeting, newsletters, WhatsApp and SMS promotions, sharing with ad networks, and using order history to build audience segments are separate purposes needing Section 6 consent: itemised, plain language, in English or any Eighth Schedule language, by clear affirmative action, and as easy to withdraw as to give. The critical constraint is that consent must be unconditional — you cannot require someone to accept marketing in order to complete a purchase, and a pre-ticked box or a bundled "I agree to the terms and to receive offers" fails both the specificity and the affirmative-action tests. Practically: unbundle the checkout consent into separate toggles, default them off, and log which purpose each customer actually agreed to and when. Note also that DPDPA has no separate "sensitive personal data" tier — a home address, an order for a medical product and a phone number sit under one legal standard; the difference is the harm, not the rule.

Both, in different places, and you should map it deliberately rather than assume the platform terms settle it. You are a Data Fiduciary for everything you determine the purposes of: accounts, browsing and search behaviour, cart data, platform-wide recommendations, your own marketing, and the customer relationship generally. A seller who receives a customer's name, address and phone number to ship an order and then processes it for their own purposes — their own remarketing, their own CRM, their own retention — is a fiduciary in their own right for that processing, with their own notice and lawful-ground obligations. A seller or fulfilment partner acting strictly on your instructions under a written contract is a processor, and liability for their failure stays with you. The same analysis applies to your other partners: payment gateways typically process for their own regulated purposes and hold the card tokens under RBI's tokenisation framework rather than you, while your courier, warehouse operator, analytics provider, cloud host and customer-support tooling are usually processors needing a valid written contract specifying purpose, security obligations, sub-processing limits and deletion on exit. Two things platforms routinely get wrong: sending sellers and couriers far more customer data than the shipment requires, which is a purpose-limitation problem, and never contractually restricting a seller's or courier's independent re-use of the customer's phone number.

The erasure duty is real but qualified. On withdrawal of consent or once the purpose is served, you must erase the personal data and cause your processors to erase it — unless retention is necessary for compliance with any law. In practice that means your tax invoices, GST records and transaction documentation stay for their statutory retention period even after an account closure, and you should be able to point to the specific obligation rather than asserting a general business need. Two Rules floors matter for ecommerce specifically. Rule 8(3) sets a one-year minimum retention for personal data, traffic data and processing logs for the stated purposes (the Rules illustrate this with an e-book purchase). Separately, Third Schedule item 1 requires an e-commerce entity with not less than two crore registered users in India to erase personal data after three years from the Data Principal's last approach, for all purposes except enabling the Principal to access her account and stored virtual tokens — so large platforms cannot keep dormant marketing profiles forever even if they never receive a delete request. What cannot survive the request is the rest: marketing profiles and audience segments, recommendation and behavioural data, saved addresses beyond the retained order records, support-ticket transcripts past their purpose, and copies sitting in your CDP, email platform, analytics warehouse and ad-network custom audiences — that last one is the most commonly missed, because deletion in your primary database does not propagate to a third-party audience list you uploaded last quarter. Two design points: build erasure as a fan-out across every processor and partner rather than a single database flag, and apply the same discipline unprompted to data whose purpose has simply ended — guest checkout addresses from four years ago, abandoned carts, rejected COD attempts and dormant accounts. Customers also have access and correction rights, so you need a working mechanism to tell them what you hold and to fix it, not just to delete.

On breach: two clocks start at detection and both must be met; they are cumulative, not alternatives. CERT-In requires reporting of covered cyber incidents within 6 hours. Separately under DPDPA, you must intimate every affected customer without delay (Rule 7(1)), give the Board an initial description without delay (Rule 7(2)(a)), and file detailed particulars within 72 hours (Rule 7(2)(b)). Build one playbook with a named owner and pre-drafted templates, because a 6-hour clock does not survive an improvised escalation — and remember the breach may originate with a processor, so your courier, agency or plugin vendor contracts need an obligation to alert you immediately. Two scoping points ecommerce teams miss: a ransomware event with no confirmed exfiltration is still a personal data breach if it caused loss of access to the data, and a misconfigured storage bucket or an exposed API returning order details is a breach even with no attacker, because "nothing was stolen" is not an exemption from notification. Failure to maintain reasonable security safeguards attracts up to ₹250 crore, and failure to give the required breach intimation is assessed separately at up to ₹200 crore, with the Board setting quantum on the facts. On SDF status: it is conferred by Central Government notification, assessed against factors including the volume and sensitivity of personal data processed and the risk to Data Principals' rights, sovereignty, electoral democracy and public order — not triggered automatically by GMV, order volume or funding stage. A national-scale consumer platform is a more plausible candidate than most sectors, so it is worth building toward Rule 13 readiness — annual DPIA, independent data audit, algorithmic due diligence over your recommendation and pricing models, and an India-based Data Protection Officer — rather than assuming you fall outside it. Note also that Rule 15 transfer-restriction duties can apply to any Data Fiduciary transferring personal data outside India; Rule 13(4) localisation is the additional SDF-specific restriction — two different obligations. Until notified, you owe the baseline duties in full: valid consent, purpose limitation, accuracy, erasure, security safeguards, breach notification, and a published grievance channel with a named contact and a response timeline not exceeding ninety days under Rule 14(3). If you serve users under 18, Section 9 applies independently of all this: verifiable parental consent, and no behavioural tracking or targeted advertising directed at a child.