Super App Development Company, security and the DPDP Act: a compliance checklist
Is super app development company compliant with the DPDP Act?
No super app is compliant by default. Under India's DPDP Act the obligations fall on you as the data fiduciary, and a super app makes them harder because one login spans several purposes. Compliance is an architecture: per-purpose consent, scoped access between modules, retention per module and a complete audit trail.
No super app is compliant by default. Under India's Digital Personal Data Protection Act the obligations sit with you as the data fiduciary, and a super app makes them harder because one login spans several purposes. Super app development company security therefore has to deliver per-purpose consent, scoped access between modules, retention per module and a complete audit trail.
What follows is the checklist we work through on a super app build: each DPDP duty mapped to the architectural control that satisfies it and the artefact that proves it to an auditor. It also covers the two problems unique to super apps, cross-module data sharing and the shared wallet, and the point at which the honest answer is that a module should not launch yet.
What makes a super app harder than a single app under DPDP
The DPDP Act, passed in 2023 and administered by the Ministry of Electronics and Information Technology, requires that personal data be processed for a specified lawful purpose with the individual's consent, that the notice be clear and itemised, and that data be erased when the purpose is served. MeitY publishes the Act and its subsequent rules at meity.gov.in. The general obligations are covered in DPDP Act 2023 and AI: what Indian companies must do.
A single-purpose app can take one consent at signup. A super app cannot, because purpose limitation is per purpose, and grocery ordering, ride booking, lending and insurance are four purposes with four notices, four retention clocks and four erasure paths. Taking one blanket consent at signup for all of them is the single most common design error we are asked to fix.
The second structural problem is that a shell architecture encourages a shared customer profile, and a shared profile encourages modules to read fields they were never granted. If the ride module can read loan repayment history because both sit behind the same session, you have a purpose limitation breach that no amount of encryption fixes. See super app architecture: shell, modules and shared services for where those boundaries belong.
The third is the volume of third parties. A super app with payments, maps, messaging and partner merchants can easily have fifteen processors touching personal data, each of which needs a contract, a stated purpose and a region. Most teams discover this register does not exist the week a customer files an access request.
Obligation, control, evidence: the mapping
Compliance is easier to pass when each duty has one named control and one artefact. This is the table we put in the delivery plan.
| DPDP duty | Architectural control | Evidence artefact |
|---|---|---|
| Purpose limitation | One consent record per module purpose, enforced at the shell | Consent ledger with timestamp, version and purpose ID |
| Clear itemised notice | Notice rendered by the shell at first module entry, not at signup | Screenshots and notice version history per language |
| Consent withdrawal | Withdrawal disables the module and triggers its erasure job | Withdrawal log and downstream deletion receipts |
| Data minimisation | Module reads go through a field-scoped profile API | Access matrix mapping module to permitted fields |
| Retention and erasure | Separate retention clock and purge job per module | Retention policy document plus purge run logs |
| Accuracy and correction | Single write path per field with correction propagation | Correction audit entries showing propagation |
| Security safeguards | Encryption at rest and in transit, RBAC, key rotation, patch cadence | Access reviews, key rotation records, patch report |
| Breach notification | Detection alerting plus a rehearsed notification runbook | Incident log and a dated tabletop exercise record |
| Processor obligations | Contracts with every gateway, SMS and analytics vendor | Signed processor agreements and a sub-processor register |
Does the DPDP Act require data to stay in India?
Not universally. The Act permits transfer of personal data outside India except to countries the central government restricts by notification, which is a narrower rule than a blanket localisation mandate. Sector rules, however, may be stricter than DPDP: payment system data is subject to the Reserve Bank of India's storage directions, so any super app carrying a wallet or card rails inherits obligations the Act alone does not impose.
The practical answer for most Indian consumer platforms is to host in an Indian region, keep payment data in India as a matter of design, and treat any overseas processor, including analytics and crash reporting, as a deliberate decision with a signed agreement behind it. Data residency explains the terminology, and the wallets, UPI and payments in super apps post covers where payment data actually lands.
The controls we build in every super app
- A consent ledger in the shell. Immutable, versioned, queryable by user and purpose, and the source of truth every module checks before it processes anything.
- A field-scoped profile API. Modules request named fields and receive only those; no module gets a database connection or a whole profile object.
- Role-based access with real review. Separate roles for support, operations and engineering, quarterly access reviews, and no shared admin accounts. The pattern is set out in SSO, RBAC and audit logs.
- Per-module retention jobs. Each module owns a retention period and a purge job that runs on a schedule and writes a receipt.
- PII redaction in logs and analytics. Phone numbers, addresses and payment identifiers never reach observability tooling in plain form.
- A named patch cadence. Dependency and OS updates on a published schedule, not when something breaks, as argued in security patching cadence for production applications.
- A tested erasure path. Someone actually runs a deletion request end to end before launch and keeps the evidence.
- A sub-processor register. Every gateway, SMS provider, map service and analytics vendor listed, with its purpose and its region.
The two super app specific traps
Cross-module personalisation
The commercial appeal of a super app is using signals from one module to improve another. That is exactly what purpose limitation constrains. The workable route is an explicit, separately consented purpose for cross-service personalisation, with its own notice and its own withdrawal, and a profile layer that can serve modules without that consent from a reduced feature set. Building personalisation first and asking about consent later means rebuilding the feature store.
The shared wallet
A wallet sits across every module and accumulates a transaction history that reveals far more than any single service does. Treat the wallet as its own fiduciary boundary: its own retention clock, its own access matrix, and no module reading the ledger beyond the entries it created. Reconciliation and settlement access belongs to finance roles, not to product teams.
When the honest answer is not yet
We have told clients to delay a module, and it is usually one of three situations. The first is a lending or insurance vertical planned before anyone has read the sector rules that apply to it, where DPDP is the smaller problem. The second is a business that wants to migrate an existing customer base into a new super app without fresh notice, which is not a technical question and needs legal advice before any code is written.
The third is a team that has no named owner for data protection. Controls without an accountable person decay within two quarters: access reviews stop happening, the sub-processor register goes stale, and the purge job silently fails. If nobody in the organisation owns this, the compliant answer is to fix that before shipping module two, not to buy more tooling.
There is also an honest limit to what a vendor can promise. A super app development engagement can deliver the architecture, the artefacts and a tested erasure path. It cannot make you a compliant data fiduciary, because compliance includes decisions about purpose, retention period and business process that only you can take.
What this costs and who does it
The controls above are part of the build rather than an add-on. A super app programme with Eazyware starts at $63,000 or ₹41,60,000 and runs to $210,000 or ₹1.4 crore and above depending on module count, wallet complexity and partner onboarding; the bands are published on our pricing page. You own the code, the infrastructure and the documentation, which matters here because compliance evidence you cannot export is not evidence.
After launch, the recurring work is access reviews, patching, key rotation and breach-runbook rehearsals. Care Plans cover that from $1,000 or ₹68,000 a month at the Essential tier to $5,250 or ₹3,40,000 a month for 24x7 cover with a named engineer. A platform holding a wallet should assume the upper tier.
Pre-launch checklist
- One notice and one consent record per module purpose, in every language you ship
- Access matrix signed off showing which module may read which field
- Retention period agreed per module with a purge job and a run log
- A deletion request executed end to end, with receipts, before go-live
- Sub-processor register complete, with region and signed agreement per vendor
- Breach runbook rehearsed once, with the date recorded
- PII stripped from logs, crash reports and analytics events
- A named data protection owner with time allocated in their role
Related reading
AI audit trails: what regulators will ask to see covers the evidence side in more depth, sovereign AI in India explains the residency debate for enterprises, and merchant and partner onboarding as a product covers the processor relationships a multi-party super app inevitably creates.
Treat DPDP as an architecture requirement written down before the second module, and compliance becomes a set of artefacts you already have rather than a project you have to run.
Frequently asked questions
Does a super app need separate consent for each service?
▾
Yes. The DPDP Act ties lawful processing to a specified purpose, and grocery, ride, lending and insurance are separate purposes with separate notices, retention clocks and erasure paths. A single blanket consent taken at signup is the most common design error we are asked to fix in existing super apps.
Must super app data be stored in India?
▾
The DPDP Act permits transfers abroad except to countries restricted by government notification, so it is not a blanket localisation rule. Sector rules can be stricter: payment system data falls under Reserve Bank of India storage directions. Most Indian consumer platforms host in an Indian region and treat any overseas processor as a deliberate, documented decision.
Can one module in a super app use data collected by another?
▾
Only with an explicit, separately consented purpose for cross-service personalisation, carrying its own notice and its own withdrawal. Enforce it with a field-scoped profile API so a module receives named fields rather than a whole profile, and keep an access matrix showing which module may read which field.