This article is not legal advice. It describes the product-side and technical changes that the Digital Personal Data Protection Act 2023 and the DPDP Rules (notified in the Gazette on 13 November 2025) require of apps and websites that process personal data of Indian users. For compliance decisions specific to your business, consult a legal practitioner.
India's DPDP Rules are rolling out in stages. Under Rule 1, the Rules on the Data Protection Board and definitions took effect on publication. The Consent Manager registration rule (Rule 4) comes into force one year after publication, which is 13 November 2026. That rule is for companies that want to register as Consent Managers; it is not a duty on ordinary apps. The obligations that matter to most apps and websites - the consent notice (Rule 3), security safeguards (Rule 6), breach intimation (Rule 7), erasure and log retention (Rule 8), the published contact (Rule 9), and the rights of Data Principals (Rule 14) - come into force eighteen months after publication, which is 13 May 2027. The government's own summary describes this as an 18-month phased compliance period. If you run an app or website that collects personal data from Indian users, you have roughly six months to get the product-side work done.
Who This Applies To
The DPDP Act applies to any "Data Fiduciary" - a person or entity that determines the purpose and means of processing personal data of Indian residents. That includes a SaaS app collecting email addresses, a mobile app collecting location, an e-commerce site collecting payment and shipping details, and an analytics tool collecting behavioural data. The Act does not contain a blanket small-business exemption. Section 17(3) lets the Central Government notify certain Data Fiduciaries or classes of them, including startups, to whom some provisions (notice, parts of section 8, and sections 10 and 11) will not apply, and the government has said the framework includes simplified compliance for start-ups and certain data fiduciaries. Do not assume your business is covered until a notification names a class that fits you.
"Significant Data Fiduciaries" (those processing data at high volume or in sensitive categories) face additional obligations, including a Data Protection Impact Assessment and an audit once every twelve months under Rule 13. Significant status is decided by the government by notification, so a small app should not assume either way. This article covers the obligations that apply to all Data Fiduciaries.
The Product Checklist: What Needs to Change
1. Consent: Specific, Informed, and Separate
Under section 6 of the DPDP Act, consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action, and limited to the personal data necessary for the specified purpose. In practice, this means:
- No pre-ticked boxes or default opt-ins for non-essential processing
- Each purpose of processing described separately - analytics consent is distinct from marketing consent
- The consent request must clearly state what data is collected, for what purpose, and for how long
- The consent notice must be understandable on its own, independent of other information, as Rule 3 requires, so do not bury it inside terms of service
- The user must be able to withdraw consent as easily as they gave it
On the product side, this means a consent management interface - not a cookie banner that dismisses with one click, but a screen or modal that presents each processing purpose and captures a positive action for each. If you use Google Analytics 4, consent mode lets your tags adjust their behaviour to the visitor's consent state, but it does not provide the banner itself. If you use third-party tools (advertising pixels, CRM enrichment), each one requires its own consent disclosure.
2. Notice: What You Must Tell Users Before You Collect
- The categories of personal data being collected
- The purpose for which the data is processed
- The identity and contact details of the Data Fiduciary (your business name and a contact for privacy queries)
- How users can access, correct, or erase their data
- How long the data will be retained
- Whether data is shared with third parties, and who those parties are
A privacy policy page is necessary but not sufficient. The notice must be provided at or before the point of collection, in plain language, and in a form the user can retain. For a mobile app, this typically means a consent flow at first launch before any data is collected. For a web app, this means the consent interface appears before analytics or tracking fires.
3. Data Principal Rights: The Technical Plumbing
The Act and the government's summary of the Rules give users (called "Data Principals") the right to access, correct, update and erase their personal data, and to nominate someone to exercise these rights on their behalf. Rule 14 requires you to publish on your website or app how to make such a request. Implementing these rights on the product side means:
- A way for users to ask for a summary of the personal data you process and who you share it with, which is what section 11 of the Act provides for (a downloadable export is good practice, though the Act does not name a machine-readable format)
- A way for users to correct inaccurate data held about them
- A way for users to request deletion of their account and associated data - including cascading deletes from any third-party services you pass data to
- A grievance process that resolves requests within a reasonable period not exceeding ninety days, as Rule 14(3) requires, with that period published on your site or app
- A published business contact for privacy queries, which Rule 9 requires (a Data Protection Officer is only mandatory for Significant Data Fiduciaries)
On the engineering side, this means your database schema and application logic must support deletion in a way that actually removes the data, not just marks it as inactive. Soft-delete patterns that keep personal data indefinitely are a risk, because section 8(7) requires erasure once consent is withdrawn or the purpose is no longer served. The exception is data you must keep by law: Rule 8(3) also requires you to retain personal data, traffic data and logs of processing for at least one year for the Seventh Schedule purposes, so plan erasure around both.
4. Breach Reporting: The 72-Hour Clock
Under Rule 7, when you become aware of a personal data breach you must tell each affected Data Principal without delay, and tell the Data Protection Board without delay with a description of the breach. Within seventy-two hours of becoming aware of it (or a longer period the Board allows on a written request) you must send the Board updated and detailed information: the facts and reasons, mitigation, any findings about who caused it, remedial measures, and a report on the notices sent to users. The clock runs from when you become aware, not from when your investigation finishes.
This 72-hour window requires you to have a breach response plan before a breach happens. The minimum elements are: a definition of what constitutes a reportable breach for your system, an escalation path (who is notified internally, in what order), a template for the Board notification, and a template for user notification. For more detail on building this plan, see our post on the DPDP 72-hour breach response.
5. Data Minimisation and Retention
- Collect only the personal data necessary for the stated purpose - no speculative collection for future features
- Do not retain data beyond what the purpose needs, subject to the one-year minimum log retention in Rule 8(3) and any other law
- Implement automated deletion or anonymisation for data past its retention period
- If you store logs that contain personal data (IP addresses, user identifiers), set a defined retention period on them; Rule 6 expects logs to be kept for detecting unauthorised access, for one year unless another law requires otherwise
6. Third-Party and AI Tool Data Flows
If you use third-party tools that process personal data - analytics platforms, email providers, CRMs, AI APIs - you are responsible for ensuring those processors comply with the Act or operate under an appropriate contractual obligation. This includes AI tools you use in your product: if a user's query goes to an external LLM API, that data flow needs to be disclosed in your notice and covered by your contracts.
The practical implication is an audit of your data flows: every external service your app calls, every API you pass user data to, and every third-party script on your frontend. Tools like Google Analytics, Intercom, Hotjar, HubSpot, and similar all receive personal data and need to be disclosed. If you do not know what scripts are loading on your pages, that is the first thing to check.
What to Do in the Next Six Months
- Map your data flows: document what personal data you collect, where it goes, and which third parties receive it
- Audit your consent UI: does it meet the specific, separate, and withdrawable standard?
- Add data export, correction, and deletion functionality if it does not exist
- Write a breach response plan before you need one
- Set retention limits on logs and inactive account data
- Review contracts with third-party processors to ensure they carry appropriate data processing obligations
- Appoint a contact for privacy queries and publish that contact in your notice
The product-side work here is real but not exceptional. An app built on a modern stack with proper user account management already has most of the data structures in place. What is usually missing is the consent interface, the deletion logic that actually removes data from all the right places, and the breach response plan.
Where to Start on the Technical Side
If you are not sure what personal data your app collects or where it goes, a technical review is the right first step - not a legal review. The legal advice comes after you have a map of what the product does. Run the free app health check to get an inventory of what scripts are loading on your site, what headers your server sends, and what third-party calls are visible in the response. Then bring that output to your legal adviser alongside the gazette text of the DPDP Rules to determine what specifically applies to your business category and processing volume.
Common questions
When do the main DPDP Rules obligations start for apps?
The obligations most apps care about, including the consent notice (Rule 3), security safeguards (Rule 6), breach intimation (Rule 7), erasure and log retention (Rule 8) and Data Principal rights (Rule 14), come into force eighteen months after the 13 November 2025 gazette date, which is 13 May 2027. This is not legal advice.
Does the DPDP Act exempt small businesses and startups?
The Act has no blanket small-business exemption. Section 17(3) lets the Central Government notify certain Data Fiduciaries, including startups, to whom some provisions will not apply. Do not assume you are covered until a notification names a class that fits you.
When should I get a technical review before DPDP applies?
If you are unsure what personal data your app collects or where it goes, a technical review is the first step, before legal advice. Zovintra's free app health check inventories scripts, headers and third-party calls you can bring to your legal adviser.
Sources
- The Digital Personal Data Protection Rules, 2025 (Gazette of India, 13 Nov 2025) - Ministry of Electronics and Information Technology, published 13 November 2025
- The Digital Personal Data Protection Act, 2023 - Ministry of Electronics and Information Technology, published 11 August 2023
- Government notifies DPDP Rules to empower citizens and protect privacy - Press Information Bureau, published 14 November 2025
- Simplified compliance framework for start-ups and certain data fiduciaries under DPDP Act and Rules - Press Information Bureau, published 3 December 2025
- Consent mode on websites and mobile apps - Google Analytics Help, accessed 19 Oct 2026
