Topics: Custom software & SaaS, Mobile apps
Want this done for your business? Get a fixed quote or book a free 30-minute call.
Quick answer: India's DPDP Rules were notified in November 2025. Consent manager provisions apply from November 2026 and most obligations from May 2027. Before then, an app serving Indian users needs an itemised consent notice, one-tap withdrawal, an audited list of SDKs, in-app deletion and access requests, verifiable parental consent for under-18s, a 72-hour breach process and a retention period for every type of data.
Eighteen months sounded generous when the Rules were notified. Counted in two-week sprints, the time left in December 2026 is about ten releases, and some of the work, such as re-plumbing how analytics SDKs start up, touches every screen. This checklist translates the Rules into app screens, SDK settings and back-office processes. For how India's law compares with Australia's, read our overview of the DPDP Act and Australia's Privacy Act. This is general information, not legal advice; have a lawyer confirm how it applies to you.
When do the DPDP Rules apply to your app?
The Rules switch on in three stages, per the notification published by MeitY in the Gazette of India.
| When | What applies |
|---|---|
| November 2025 | Rules notified; provisions setting up the Data Protection Board took effect immediately |
| November 2026 | Registration and obligations of consent managers |
| May 2027 | Notice, consent, security safeguards, breach reporting, children's data, retention and user rights |
The Act covers digital personal data processed in India, and also processing outside India when it is connected with offering goods or services to people in India. So a Dubai-based developer of an app aimed at Indian customers is in scope.
In DPDP terms, your business is the data fiduciary: you decide why and how data is processed. Your hosting company, analytics provider and the developer agency are data processors, acting for you under contract. Responsibility stays with you.
What must your in-app notice and consent screen say?
A clear, standalone notice that itemises the personal data you collect and the specific purpose for each item, shown before or at the point of collection. It must also explain how users can withdraw consent, exercise their rights and complain to the Data Protection Board. The Act requires that users can read notices in English or any language listed in the Eighth Schedule of the Constitution.
Consent itself must be free, specific, informed, unconditional and given by a clear action. Withdrawing it must be as easy as giving it.
Screen checklist:
- [ ] Notice shown at sign-up or first collection, not hidden in a long privacy policy
- [ ] Separate choices for separate purposes: running the service, marketing messages, personalised ads, sharing with partners
- [ ] No pre-ticked boxes, and no blocking the core service because someone declined marketing
- [ ] Plain-language description of each data item (phone number, location, contacts, photos)
- [ ] Link to the full privacy policy and a named grievance contact
- [ ] A consent record for every user: notice version, purposes accepted, time and channel
Operating-system permission prompts for location, camera or contacts are not DPDP consent. Show your own short explanation of why you need the permission first, then trigger the system prompt.
How do you audit SDKs and third-party data flows?
List every SDK in the app, record what it collects by default and switch off anything your notice does not cover. Default settings in analytics, advertising and crash-reporting libraries often collect more than the privacy policy admits.
| SDK type | What it often collects by default | What to check |
|---|---|---|
| Analytics | Device IDs, IP address, screen views, events | Disable IP storage and automatic screen tracking you do not need |
| Advertising and attribution | Advertising ID, install source, in-app events | Start only after consent; never for children's accounts |
| Crash reporting | Device details, logs that may contain user data | Scrub names, phone numbers and tokens from logs |
| Push notifications | Device tokens, user IDs | Map tokens to purposes; delete them on account deletion |
| Chat and support widgets | Messages, attachments, contact details | Check where data is stored and for how long |
| Payments | Contact details, transaction data | Confirm the provider's role and contract |
The audit in five steps:
- Pull the dependency list from the build files (Gradle, CocoaPods or Swift Package Manager, pubspec or package.json).
- For each SDK, document data collected, purpose, where it is sent and retention.
- Reconfigure or remove anything without a clear purpose.
- Change start-up order so non-essential SDKs initialise only after consent.
- Confirm a contract exists with each processor, and update the Google Play Data safety form and Apple's privacy details to match.
Our guide to app security basics covers encryption, token storage and API protection, which sit alongside this audit.
How should users withdraw consent or delete their account?
Give users a privacy centre inside the app, not an email address and a hope. It should include:
- Per-purpose toggles that take effect promptly, including at your processors
- Account deletion inside the app. Apple and Google already require this for apps that let users create accounts, and Google also asks for a web link
- Requests to access, correct or erase data, plus the right under the Act to nominate someone to act if the user dies or is incapacitated
- A tracked process with an owner and deadlines, published so users know the response timeline
Verify identity before acting. A deletion or data-export request from someone who has merely got hold of a user's phone number is a breach in waiting. Strong sessions, re-authentication for sensitive actions and admin roles that limit who can see personal data all help; our explainer on user authentication and roles covers the patterns.
Erasure has limits. Invoices and records you must keep under tax or other laws stay, but only those records, and only for as long as that law requires.
What changes if children use your app?
Under the DPDP Act, anyone under 18 is a child, and you need verifiable consent from a parent or lawful guardian before processing their data. There is no lower threshold like the 13-year age line common in other countries, so teenagers are covered.
The Rules describe checking that the person consenting is an identifiable adult, using reliable identity details you already hold or a token from an authorised provider such as a DigiLocker-based service. The Act also prohibits tracking, behavioural monitoring and targeted advertising directed at children. The Rules exempt some classes of organisation, such as healthcare providers and educational institutions, for specific purposes.
For an app team, this means:
- An age question at sign-up, with a separate parental consent flow for under-18s
- Ad and attribution SDKs switched off for children's accounts
- Personalisation based on behaviour switched off for those accounts
- Extra care in edtech, gaming, fitness and social apps, where teenagers are core users
What does a breach response look like under DPDP?
Tell affected users without delay, tell the Data Protection Board without delay, and send the Board a detailed report within 72 hours of becoming aware of the breach, unless the Board allows longer. Separately, CERT-In's 2022 directions require many cyber incidents to be reported within six hours, so the clocks overlap.
A simple runbook:
- Detect and contain. Revoke leaked keys, close the hole, preserve logs.
- Assess. What data, how many users, since when, likely consequences.
- Notify early. Initial intimation to the Board and CERT-In where required.
- Tell users. What happened, likely impact, what you have done and what they should do, with a contact.
- Report in detail within 72 hours. Facts, cause, mitigation and steps to prevent a repeat.
- Review. Fix the root cause and update the runbook.
Name the people responsible for each step now. During an incident nobody has time to work out who signs the Board notification.
How long can you keep user data?
Only as long as the purpose needs it or the law requires, then erase it. The Rules add specific inactivity-based erasure for large e-commerce, gaming and social media platforms, and require logs of processing to be kept for at least a year for security purposes.
| Data type | Purpose | Example retention rule |
|---|---|---|
| Account profile | Providing the service | Until account deletion, plus a short recovery window |
| Orders and invoices | Tax and accounting law | As long as the relevant law requires |
| Support conversations | Resolving issues | A fixed period you set and publish |
| Access and processing logs | Security and investigation | At least one year, per the Rules |
| Consent records | Proving consent | As long as you rely on that consent, plus a buffer |
| Marketing lists | Promotions | Until withdrawal or a set period of inactivity |
Automate the deletion with scheduled jobs. Manual clean-ups are the first thing forgotten, and retention becomes part of ongoing app maintenance rather than a one-off.
The stakes are real. Under the Act's Schedule, failing to take reasonable security safeguards can attract a penalty of up to ₹250 crore, and failures on breach notification or children's data up to ₹200 crore. Build these checks into the sprint plan now rather than in the final quarter.
Frequently asked questions
When does the DPDP Act start applying to apps?
Most obligations, including notice, consent, security, breach reporting, children's data and user rights, apply from May 2027, 18 months after the Rules were notified in November 2025. Consent manager provisions apply from November 2026.
Does my app need to work with a consent manager?
Consent managers are registered intermediaries through which users can give, manage and withdraw consent, with registration opening from November 2026. If a user chooses to manage consent that way, you will need to honour it. Store consent as structured records with clear purposes so connecting a consent manager later is straightforward.
Do Indian apps need parental consent for teenagers?
Yes. The Act defines a child as anyone under 18, so a 16-year-old's data needs verifiable consent from a parent or lawful guardian, subject to narrow exemptions in the Rules. Tracking, behavioural monitoring and targeted ads aimed at children are prohibited.
What are the penalties under the DPDP Act?
The Act's Schedule sets penalties of up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to notify breaches or meet obligations on children's data. The Data Protection Board decides the amount based on factors such as severity and duration.
Does DPDP apply to apps run from outside India?
Yes, if the app processes personal data in connection with offering goods or services to people in India. Where the company is registered does not change that.
Get your app ready before May 2027
We build and maintain apps for Indian businesses and can map these checks onto your screens, SDKs and back end, then fix the gaps. You can ask us for a DPDP review of your app, or book a free call to talk through your timeline.