Key takeaways
- The DPDP Rules 2025 were notified on 13 November 2025 by MeitY. The Data Protection Board of India is now constituted. The substantive obligations come into force on 13 May 2027 — every Indian mobile app and every foreign app serving Indian users has 18 months to comply.
- The maximum penalty is ₹250 crore per violation for failure to maintain reasonable security safeguards, with no aggregate cap. A single mobile app breach can stack multiple findings.
- The Rules formalise breach notification to the Data Protection Board within 72 hours, alongside the existing CERT-In 6-hour incident reporting requirement. Mobile apps must engineer for both.
- This is a practitioner’s checklist — what to build, what to document, and what evidence the Board will look for when it starts adjudicating from May 2027.
The Digital Personal Data Protection Act, 2023 received Presidential assent on 11 August 2023. For 27 months after that, Indian product teams treated DPDP as a slow-moving regulatory abstraction. That ended on 13 November 2025, when the Ministry of Electronics and Information Technology (MeitY) published the final Digital Personal Data Protection Rules 2025 in the Official Gazette and triggered the enforcement clock.
The clock has three notches:
- 14 November 2025: procedural provisions effective immediately — definitions, constitution of the Data Protection Board of India (DPB), administrative provisions.
- 14 November 2026: Consent Manager regime activates — registration of Consent Managers with the DPB, oversight obligations.
- 14 May 2027: substantive operational obligations come into force — notices, security safeguards, breach reporting, data principal rights, retention, cross-border transfers, Significant Data Fiduciary duties.
By 13 May 2027 you need a working DPDP-compliant mobile app, not a roadmap. This article is the working checklist.
What every mobile app must do under DPDP
The Act is principles-based and applies very broadly. If your app processes the digital personal data of an individual located in India — whether you are headquartered in Bengaluru, Bahrain or Berlin — you are a Data Fiduciary, the user is a Data Principal, and the obligations attach.
The five product-level obligations that translate directly into mobile-app engineering work are:
- Notice and consent — every collection of personal data must be preceded by a clear, standalone, plain-language notice and an explicit consent for each specified purpose.
- Lawful processing — process only the personal data necessary for the specified purpose, only for as long as it is needed.
- Data Principal rights — the app must let users access, correct, erase, port, and nominate someone to exercise their rights.
- Reasonable security safeguards — the legal phrase carrying the ₹250 crore penalty. Translates in practice to encryption in transit and at rest, access controls, secure development, vulnerability management, breach detection.
- Breach notification — to the DPB and to affected Data Principals, in a defined format and timeframe.
The Rules layer additional obligations on Significant Data Fiduciaries (SDFs): organisations the Government may designate based on volume of data, risk to data principals, or impact on India’s sovereignty. SDFs must appoint a Data Protection Officer based in India, conduct Data Protection Impact Assessments, and submit to periodic audits.
The penalty schedule (and why ₹250 crore is the headline)
Schedule of penalties under the DPDP Act:
| Violation | Maximum penalty |
|---|---|
| Failure to maintain reasonable security safeguards | ₹250 crore per instance |
| Failure to notify the Board or affected Data Principals of a breach | ₹200 crore |
| Violation of obligations relating to children’s data | ₹200 crore |
| Violation of additional obligations of an SDF | ₹150 crore |
| Violation of duties of Data Principals | ₹10,000 |
| Violation of voluntary undertakings given to the Board | Up to amount of the undertaking |
| Any other contravention | ₹50 crore |
Two design choices in the Act sharpen the financial exposure for mobile apps specifically:
- No aggregate cap. Each violation can attract its maximum independently. A single breach involving inadequate security safeguards (₹250 cr) plus delayed notification (₹200 cr) plus children’s data exposure (₹200 cr) is ₹650 cr of theoretical exposure on one incident.
- Per-instance interpretation of “violation.” The Board has discretion in determining what counts as a discrete violation, but legal commentary on the final Rules is consistent that systemic failures affecting many Data Principals can be treated as multiple instances.
The Board determines actual penalty amounts after investigation, with guidance to consider the nature, gravity and duration of the violation, the type of data, the impact on Data Principals, repetition, mitigation, and the Data Fiduciary’s financial resources. This is a calibrated rather than tariff-style penalty regime — but the headline numbers are the headline numbers.
DPDP mobile compliance checklist (12 things to build before May 2027)
This is the working checklist we use with Indian fintech, healthtech and consumer-app clients. Each item maps to a Rule section and a discrete piece of engineering work.
1. Standalone consent notice screen (Rule 3)
A separate screen, shown at the point of data collection, written in plain language and offered in English plus the language(s) declared in the Eighth Schedule of the Constitution of India that your user base substantially uses. Must specify each category of personal data, each purpose, the rights of the Data Principal, and the contact for the Data Protection Officer or grievance officer. Implementation note: do not bundle this into your existing T&Cs flow — bundling is one of the most-cited violations under analogous regimes (GDPR), and the DPDP Rules explicitly require a standalone notice.
2. Per-purpose consent capture and audit log
Consent must be specific and granular. If your app uses personal data for service delivery, marketing, analytics and personalisation, that’s four consents. Each must be independently capturable, withdrawable, and auditable. Engineering pattern: model consent as a versioned object per purpose, not a global boolean. Store the consent UI version, the timestamp, the data principal identifier, and the IP / device context with each capture.
3. Consent withdrawal — symmetric with capture
Withdrawal must be as easy as granting consent (the legal text is “with the same ease”). On mobile, this means a settings screen with a per-purpose toggle, not a “send us an email to withdraw” link. Withdrawal must propagate to downstream processors within a reasonable time. Common bug: withdrawal is captured client-side but not pushed to analytics SDKs that continue collecting until the next app session.
4. Children’s consent flow (Section 9, Rule 10)
For a Data Principal who is a child (under 18), consent must come from a parent or lawful guardian, with verifiable parental consent. The Rules permit verification through reliable identity tokens, government-issued ID, or virtual tokens issued by an entity authorised by law. The Act prohibits behavioural tracking and targeted advertising directed at children, full stop. If your app does not actively serve children but might be downloaded by children, you still need an age-gate and a defensible age-determination methodology.
5. Data Principal rights workflow
Build a single in-app screen that lets users:
- request a summary of personal data being processed and the names of all processors with whom it has been shared
- request correction of inaccurate or incomplete data
- request erasure of data no longer required for the specified purpose
- nominate another person to exercise their rights in case of death or incapacity
- withdraw consent (covered above)
- file a grievance
The Rules expect responses within a reasonable period; industry guidance is converging on 30 days as the operational target, with 90 days as the statutory ceiling. Build in a Service Level Objective dashboard from day one.
6. Reasonable security safeguards (Rule 6) — the ₹250 crore control set
The Rules specify minimum safeguards every Data Fiduciary must implement:
- Encryption, obfuscation or masking of personal data in transit and at rest
- Access controls with appropriate identity verification
- Logs of personal data access and changes, retained for at least one year
- Backups for continued processing in case of a confidentiality, integrity or availability breach
- Reasonable measures for detection of unauthorised access and for confining and remediating breaches
- Contractual obligations on Data Processors to take corresponding safeguards
For mobile apps specifically, “reasonable” is now interpreted by emerging Indian privacy practice to include:
- Local storage encryption with platform-bound keys (Android Keystore / iOS Keychain)
- Certificate pinning for backend communication
- Tamper / root / jailbreak detection
- Obfuscation of binaries containing sensitive logic
- Secrets stored outside the binary (no hardcoded API keys)
- Vulnerability scanning of every release with documented remediation
This is the controlset HEXMobileSuite’s MPTL rule engine maps directly. See [link to /dpdp-compliance] for the per-control mapping.
7. Breach detection, classification and the 72-hour Board notification
Personal data breach in DPDP is defined broadly: “any unauthorised processing… or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access” that compromises confidentiality, integrity or availability. Notification has two clocks:
- To the Data Protection Board, in the prescribed form, within 72 hours of becoming aware (with ability to apply for extension).
- To affected Data Principals, without undue delay, in plain language, including the nature of the breach, the data involved, the consequences, the mitigation measures, and contact for further information.
This sits alongside the CERT-In 6-hour reporting requirement under the April 2022 Directions for cyber incidents. They are not substitutes for each other — for a personal-data-involving cyber incident in India, you have two parallel notification clocks.
Engineering implication: your incident response runbook needs a 6-hour CERT-In path (technical) and a 72-hour DPB path (legal/privacy), with a single source-of-truth incident timeline that both teams populate.
8. Data retention and erasure
The Rules require erasure when the specified purpose is no longer being served, with specific timelines for e-commerce, social media and online gaming entities above prescribed user thresholds. For most apps, this means: define a retention policy per data category, automate the erasure, log the erasure, and be able to evidence it on request. “We forgot to delete it” is a violation.
9. Cross-border data transfer controls
The Rules use a negative-list (blocklist) model: by default you can transfer personal data outside India. The Government may restrict transfers to specific countries or entities through notification. Sectoral regulators (RBI, SEBI, IRDAI) may impose stricter localisation for specific categories — payment data being the obvious example under the RBI’s 2018 directive. Practical pattern: maintain a Transfer Register (dataset → purpose → region → processor → legal basis) so you can respond to a localisation directive in days, not months.
10. Logging — the 12-month minimum
Every personal-data access and modification must be logged for at least one year. CERT-In separately requires all ICT system logs retained for at least 180 days within India. The pragmatic stance is the stricter superset: 12 months minimum, stored in India, with evidence of in-region storage.
11. Vendor / Data Processor contracts
Every third-party SDK that processes personal data is a Data Processor. Their contract must impose corresponding security obligations and a breach-cooperation clause. Mobile-specific risk: analytics SDKs, attribution SDKs, crash-reporting SDKs and ad SDKs frequently exfiltrate personal data without the publisher fully controlling what is sent. SBOM / SCA tooling is now a privacy control, not just a security control.
12. SDF-specific obligations (if you’re designated)
If the Government designates you a Significant Data Fiduciary:
- Appoint an India-based Data Protection Officer who reports to the Board of Directors or equivalent
- Conduct an annual Data Protection Impact Assessment
- Submit to periodic audits
- Verify that algorithmic systems do not pose risks to Data Principal rights
- Comply with any data-localisation requirements imposed by the constituted committee
Working assumption for fintech, healthtech, edtech and consumer apps with > 5 million Indian users: plan as if SDF designation is coming, even if you have not been notified. Designation will not be retroactive in scope but it will be immediate in obligation.
How DPDP intersects with the rest of the Indian regulatory stack
DPDP does not stand alone. Mobile app teams in India must already comply with:
- Information Technology Act, 2000 and the SPDI Rules, 2011 (still in force, not repealed by DPDP)
- CERT-In Directions, April 2022 — 6-hour incident reporting, 180-day log retention, NTP synchronisation, KYC retention
- RBI Master Direction on Information Technology Governance, November 2023 — for regulated entities
- RBI Cyber Security Framework for banks, NBFCs and payment system operators
- NPCI guidelines for UPI / IMPS / NACH connected apps
- Sector-specific directives from SEBI, IRDAI, MeitY on intermediary diligence
DPDP is a privacy overlay; it does not replace the security baseline imposed by these. The reverse is also true: complying with CERT-In and RBI does not give you DPDP compliance. You need both.
How HEXMobileSuite helps with DPDP for mobile apps
The control set in Rule 6 (reasonable security safeguards) is the part of DPDP most directly addressable by mobile application security testing. HEXMobileSuite’s MPTL rule engine ships with:
- 124 production rules covering the OWASP MASVS v2.1 control families
- A DPDP-specific mapping pack that links each rule finding to the relevant Rule 6 obligation
- DREAD risk scoring on every finding, suitable for the Board’s “nature, gravity and duration” assessment factors
- Signed, dated PDF reports per scan, with the artefact hash, scan rule version and DPDP mapping
- CI/CD integrations for GitHub Actions, GitLab CI, Bitbucket Pipelines and Azure DevOps — so DPDP evidence is generated automatically per release
- Continuous Play Store monitoring so SDK changes that introduce new privacy risk are detected without a fresh build
The SBOM output (CycloneDX format) doubles as your Data Processor inventory for vendor contract management.
What to do this quarter
The 13 May 2027 deadline sounds far away. It isn’t, given the scale of engineering work involved. The teams shipping cleanly in 2027 are starting now.
Q1 of your DPDP runway:
- Designate accountability. Appoint an interim DPO (formal role required only if you are designated SDF; informal accountability needed by everyone). Establish a privacy steering group.
- Inventory. Produce the authoritative list of mobile apps in scope, the data categories each collects, and the Data Processors (third-party SDKs) involved.
- Gap analysis. Run the 12-point checklist above against each app. Score green / amber / red.
- Prioritise the security baseline. The ₹250 crore penalty attaches to security safeguards specifically. Get scanning into CI for every mobile app in scope this quarter. [link to /free-scan] runs in 30 minutes.
- Schedule the legal work. Notice copy, consent UX, rights workflow, breach playbooks — these need legal sign-off and translation. Start the timelines now.
If you want a working session — bring one of your apps to a 30-minute call and we will scan it live, walk through the DPDP mapping, and build you the Q1 plan. [link to /book-demo].
The ₹250 crore number gets the headlines. The actual exposure for an Indian fintech in 2027 is the sum of the financial penalty, the operational shutdown risk, the reputational impact, and the cost of doing in a panic what you could have planned. The teams that ship clean DPDP compliance early will quietly turn it into a procurement advantage.
HEXMobileSuite is the mobile application security platform from Hiesen Cyber Security, with DPDP, NESA, SAMA and OWASP MASVS v2.1 mapping included on Pro and Enterprise tiers. Indian customers are billed via Razorpay in INR with UPI AutoPay support.