Summary
A commerce platform is a hard DPDP case. Each seller decides why it collects its shoppers' data, so the seller is the Data Fiduciary and the platform is its processor. For the sellers themselves (their accounts, KYC documents, bank details and billing) the platform is the fiduciary. Each role brings different duties, and a single bug could expose data across every store on the platform.
We ran the readiness assessment in November 2026, mapped 29 controls to the Act and the Rules, and published the status of each one below. Nineteen are live in production today. The rest are scheduled in two waves, with the target of every control live before the core obligations apply.
The platform
| What it is | An operations platform for Indian direct-to-consumer brands (orders, COD, delivery, GST billing) and a self-serve store builder |
|---|---|
| Customers | 1,000+ businesses, from first-time sellers on a free plan to established brands on paid plans |
| Personal data held as fiduciary | Seller accounts (name, mobile, email), sign-in records, KYC documents (PAN, GST certificate), bank details for payouts and verification, billing and invoices, consents and declarations |
| Personal data processed for sellers | Shoppers' names, phone numbers, email addresses, delivery addresses, orders, returns, reviews and support messages on each store |
| Hosting | Primary servers in Germany; warm standby and archive in Mumbai, India |
| Service providers | Payment gateways (on each seller's own keys), a shipping aggregator, an SMS provider for one-time codes, a social sign-in provider, a KYC verification API, a bot-check service and an email provider |
Who is responsible for what
Everything else follows from this table. It decides who gives notice, who answers a rights request, and who has to be told first after a breach. The basis column is our reading of the Act for each flow.
| Data flow | Platform role | Basis | What it means for the platform |
|---|---|---|---|
| Seller sign-up, sign-in, billing | Fiduciary | Provided by the seller for the service (s.7(a)) and contract | Its own notice, rights handling and retention |
| Seller KYC and bank verification | Fiduciary | Provided for verification, with a recorded consent | Encrypted bank numbers, private document storage, team-only access |
| Shopper orders, addresses, phone numbers | Processor | The seller's purpose | Act on the seller's instructions; give sellers the tools to meet their duties |
| Phone codes that confirm COD orders | Processor | The seller's purpose (fraud-free delivery) | Store only a one-way hash of the code |
| Platform-wide delivery-risk signals | Fiduciary | Being confirmed: DPDP has no general fraud-prevention ground, so consent or a section 7 use is being settled with counsel | Share counts only, never which shop or what was bought |
| Abuse protection (IP scores, blocks) | Fiduciary | Being confirmed: DPDP has no general security ground; the Rules do require safeguards and logs, and the basis is being settled with counsel | Short-lived scores; blocks expire automatically |
What the assessment found
We assessed the platform with our standard method: data map first, then each obligation against the Act and the Rules. Security came out strongest, because the platform had already been through two security audits and server hardening in late 2026. The gaps sat where DPDP asks for something specific that general good practice doesn't.
Logs were retained for CERT-In purposes. Rule 6(1)(e) and Rule 8(3) ask for one year of logs and processing records. Fixed: both servers now keep a year.
The incident response plan already met CERT-In's six-hour reporting. It needed the Rule 7 notices: the Board, without delay and then within 72 hours, and every affected person, including support for each affected seller to notify its own shoppers.
Sellers are the fiduciaries for their shoppers, but they had no in-product way to receive, verify and close a shopper's access or erasure request against a deadline.
Each store had a privacy policy template. Rule 3 asks for an itemised notice with specific purposes and the links to withdraw, exercise rights and complain.
Bank account numbers were encrypted and KYC documents kept privately. Database and backup encryption with managed keys was the next step.
Delivery-risk signals across stores and automated abuse protection are the platform's own purposes. DPDP has no "legitimate interests" ground, so the basis for each (consent at sign-up or a specific section 7 use) is being confirmed with counsel.
The Act allows transfers unless the government restricts a country, and none is restricted so far. The platform now documents where data sits, and is adding an India-primary option.
The control board
Every control we mapped, with its source in the Act or the Rules and its status on 13 November 2026. Live means running in production. Building means in development now. Planned means scheduled, with a target month before the core obligations apply.
| Control | Source | Status |
|---|---|---|
| Every consent and declaration recorded with its text's hash, IP address, browser and time | s.6(10) | Live |
| Versioned terms and privacy pages; sellers re-asked at most once in 30 days | s.5, s.6 | Live |
| Privacy policy explains DPDP rights and how to use them | s.11–13 | Live |
| Bank account numbers encrypted; KYC documents in private storage | Rule 6(1)(a) | Live |
| One-time codes stored only as a one-way hash | Rule 6(1)(a) | Live |
| Two-factor sign-in for the operator console; per-account sign-in limits | Rule 6(1)(b) | Live |
| Store-to-store isolation tests; old sessions and links refused after an account is replaced | Rule 6(1)(b) | Live |
| Abuse shield, automatic IP blocking and bot checks on sign-up and sign-in | Rule 6(1)(c) | Live |
| Daily vulnerability watch; operating-system security updates applied automatically | Rule 6(1)(g) | Live |
| Warm standby in Mumbai, copied every 2 minutes, with a written failover procedure | Rule 6(1)(d) | Live |
| Complete store export in one file, with secrets left out | s.11 | Live |
| Self-service account deletion that purges sessions, devices, codes and 25+ tables | s.8(7), s.12 | Live |
| No marketing email from the platform at all | s.6(1) (data minimisation) | Live |
| Delivery-risk signals shared as counts only, never shop names | s.6(1) (data minimisation) | Live |
| Incident response with CERT-In six-hour reporting and synchronised clocks | CERT-In directions | Live |
| DPDP-referenced privacy policy templates for every store | s.5 | Live |
| Tamper-evident evidence ledger, sealed daily and copied off the server | s.6(10), Rule 6(1)(c) | Live |
| Logs and processing records kept for one year, write-once | Rule 6(1)(e), Rule 8(3) | Live |
| Breach console: Board intimation, per-store shopper notices, 72-hour clock | s.8(6), Rule 7 | Building · Jan 2027 |
| Shopper Privacy Centre on every store, routed to the seller with a deadline timer | s.11–13, Rule 14 | Building · Feb 2027 |
| Grievance contact published on the platform and on every store | s.8(9), Rule 9 | Live |
| Itemised notice builder for sellers, in English and the Eighth Schedule languages | s.5, Rule 3 | Building · Feb 2027 |
| Database and backup encryption with managed keys | Rule 6(1)(a) | Building · Jan 2027 |
| Data processing terms for every seller, and a public list of sub-processors | s.8(2), Rule 6(1)(f) | Planned · Mar 2027 |
| One-click DPDP evidence pack for each store | s.6(10), s.8 | Planned · Mar 2027 |
| Shopper retention settings per store, with automatic purge of inactive shoppers | s.8(7), s.8(8) | Planned · Apr 2027 |
| India-primary hosting option for paid plans | s.16 (readiness) | Planned · Apr 2027 |
| Children's data guard for stores in child-focused categories | s.9, Rule 10 | Planned · Apr 2027 |
| Breach tabletop drill against the 72-hour clock, then yearly | Rule 7 | Planned · Apr 2027 |
What is already live
Consent you can prove
Section 6(10) puts the burden of proving notice and consent on the fiduciary. Every consent and declaration a seller gives on the platform is recorded with the exact text they agreed to (as a hash), the time, their IP address and their browser. That covers the terms, verification consent, GST declaration and compliance declaration. When the terms change, sellers are asked again, but at most once in 30 days, so the record stays meaningful rather than click-through.
Less data, by design
The cheapest personal data to protect is data you never hold. The platform sends no marketing email of its own, so there is no marketing consent to manage. One-time codes are never stored, only a one-way hash of them. The delivery-risk check that warns sellers about repeated refused COD orders shares counts across the platform, never which store or what was bought. Store exports leave out payment and shipping credentials.
Security safeguards under Rule 6
- Protect the data itself: bank account numbers are encrypted; KYC documents sit in private storage that is never served publicly; uploads are type-checked, renamed and re-encoded.
- Access control: two-factor sign-in for the operator console, per-account sign-in limits with owner alerts, and isolation tests that check one store cannot see another's data.
- Visibility: an abuse shield scores and blocks hostile traffic, an error log captures failures across the app and the browser, the evidence ledger records every significant action, and logs are kept for a year.
- Continuity: a warm standby in Mumbai receives a copy every two minutes, with a written failover procedure.
- Keeping it working: a daily vulnerability watch checks every package the servers run, and operating-system security updates apply automatically.
Rights you can exercise in one click
A seller can download everything their store holds in one file: products, orders, customers, reviews, pages and settings. A seller with no open obligations can delete their account themselves. The purge removes sessions, trusted devices, sign-in codes and more than 25 tables of store data, and leaves a single anonymous record that the deletion happened.
The evidence ledger
Live
When the Board asks what happened, "we think" is not an answer. The platform keeps one append-only record of what each account did, agreed to and was told, and what the operations team did to it. Each entry carries a hash of its own content and of the entry before it, so editing, removing or reordering any entry breaks every hash after it.
The ledger is designed to answer the questions a DPDP inquiry is likely to ask: when did this seller consent, to which text, from where; who on the operations team touched this account, and why; which grievances came in and how they were closed. It also records takedown orders, government requests and security incidents logged by the team.
What ships next
Shopper Privacy Centre, on every store
The plan is for every store to get a privacy page where a shopper can see what the store holds about them, correct it, ask for erasure or raise a grievance, after confirming their phone with a one-time code. Because the seller is the fiduciary, each request lands in the seller's admin with a deadline timer and suggested actions, and the platform carries out the erasure across orders, addresses, reviews and messages once the seller approves. When it ships, over 1,000 stores get the same workflow on the same day.
Breach console
Designed as one screen that turns an incident into the notices Rule 7 requires. It drafts the Board intimation from the incident record. It works out which stores and which shoppers are affected, prepares a plain-language notice for each, and runs a 72-hour clock against the detailed report. CERT-In's six-hour report sits on the same timeline. The aim is for each affected seller to see a notice in their admin within hours, so each one can meet its own duty as a fiduciary.
A DPDP kit for every seller
- Notice builder: an itemised notice generated from what the store actually collects (checkout fields, apps switched on), with each purpose spelled out, in English and Eighth Schedule languages.
- Retention settings: how long the store keeps inactive shoppers, with automatic purge and the platform's one-year log floor built in.
- Processing terms: data processing terms every seller accepts in the admin, and a public list of sub-processors that updates from the same register the engineers use.
- Evidence pack: one download per store with its notices, consent records, rights requests and their outcomes, ready for a customer, an auditor or the Board.
Stronger safeguards
Database and backup encryption with managed keys. An India-primary hosting option for paid plans, for sellers whose customers ask for data in India. A guard for stores in child-focused categories that switches off tracking and asks for verifiable parental consent where section 9 applies.
The plan to May 2027
The order follows exposure. Log retention, the grievance contact and the evidence ledger shipped first, in November. The breach console and encryption sit under the two highest penalty ceilings, so they come next. The seller-facing kit follows, with the drill last, run against the finished system.
What 1,000+ customers inherit
A seller on the platform is the Data Fiduciary for its shoppers, and many sellers have no privacy team. Every control above is built once, at platform level, and every store gets it the day it ships.
What the platform carries
- Security safeguards and encryption
- Logs, backups and the evidence ledger
- Breach detection and the notice drafts
- Erasure across every table
- Isolation between stores
What each seller decides
- What it collects and why (the notice builder helps)
- How long it keeps inactive shoppers
- Approving rights requests from its shoppers
- Telling its own shoppers after a breach
- Its grievance contact
That split is what we build for SaaS clients too. The platform owns everything that should work the same for every tenant. Each tenant gets the decisions that are genuinely theirs, with the tools to make them quickly. See DPDP for SaaS companies and fiduciary vs processor.
Lessons for any platform
Security work is not DPDP work, but it is most of the foundation
Two security audits had already covered most of Rule 6. The DPDP-specific gaps were narrower: one-year logs, Board-format breach notices, rights workflows and notices.
Record consent with its text, not just a tick
A ticked box proves little a year later. A record with the exact text's hash, time, IP and browser does.
Delete is a feature you test
The deletion purge has its own test suite, because a missed table is a breach of section 8(7) waiting to happen.
Build once for every tenant
On a multi-tenant platform, the right control at platform level covers every customer at once. That is the cheapest compliance you will ever buy.
Want the same for your platform?
In a 30-minute scoping call we'll walk through your likely gaps against the Act and how we would build your own control board.
Status as of 13 November 2026 (updated the same day as the evidence ledger, one-year logs and grievance contact went live). Live controls are in production on the platform. Building and Planned items are scheduled work with target months, not live features; this page is updated as each one ships. Statutory references are to the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 as notified on 13 November 2025.