Short answer: Under the DPDP Act, every request for consent must come with, or be preceded by, a notice that lists the personal data, the purpose and how the user can withdraw, exercise rights and complain (s.5(1)). Rule 3 sets the detail: a standalone, plain-language notice with an itemised description of the data. Both take effect on 13 May 2027.
What is a DPDP notice?
A DPDP notice is the plain-language statement an app must give a user, before or alongside a consent request, setting out what personal data it wants, for what purpose, and how the user can withdraw consent, use her rights and complain to the Data Protection Board (s.5(1), Rule 3).
- Data Fiduciary: the person or company that decides the purpose and means of processing personal data (s.2(i)). An app that decides what user data to collect and why is a Data Fiduciary.
- Data Principal: the individual the personal data relates to, including a parent or lawful guardian in the case of a child (s.2(j)).
- Specified purpose: the purpose mentioned in the notice (s.2(za)). Consent, and later erasure, are tied to it.
The notice sits at the front of the consent model. If consent is the lawful basis, the app carries the burden of proving that notice was given and consent obtained in line with the Act and Rules (s.6(10)). Read the companion page on consent for the consent standard itself.
What must an app's notice include?
An app's notice must give an itemised description of the personal data, the specified purpose with a description of the goods, services or uses it enables, and a direct link in the app or website to withdraw consent, exercise rights and complain to the Board (Rule 3). It must be understandable on its own, without reference to other documents.
- Interpretation: because Rule 3(a) requires the notice to be understandable independently of other information, a bare link to a long privacy policy is unlikely to be enough on its own. This is a reading of the Rule, not an express statement in it.
Which languages must the notice be available in?
The user must be able to read the notice, at her option, in English or in any language listed in the Eighth Schedule to the Constitution (s.5(3)). The consent request itself carries the same language requirement (s.6(3)).
What about users who consented before the Act?
Where a user gave consent before commencement, the app must give her a notice "as soon as it is reasonably practicable" (s.5(2)). Processing can continue until she withdraws consent. The Act's illustration mentions sending the notice by email or in-app notification.
- The Act does not define how soon is reasonably practicable for large existing user bases, which our research lists as an open question.
Rule 3 at a glance
| Element | Source | What it means in an app |
|---|---|---|
| Standalone notice | Rule 3(a) | Understandable without other documents |
| Itemised personal data | s.5(1), Rule 3(b) | Each data item listed, not broad categories |
| Specified purpose and what it enables | s.5(1), Rule 3(b) | Each purpose, with the goods, services or uses it enables |
| Withdrawal link | s.5(1), Rule 3(c), s.6(4) | A working route, as easy as opting in |
| Rights and complaint routes | s.5(1), Rule 3(c) | Links to exercise rights and complain to the Board |
| Language choice | s.5(3) | English or an Eighth Schedule language |
What this means for your app
These are practical steps teams commonly consider. They are not a guarantee of compliance.
- Consider building a data inventory first: every field, event and identifier your app and its SDKs collect, mapped to a purpose. Rule 3 asks for an itemised list, so you need to know what the items are.
- A common approach is a short, layered in-app notice shown at the point of consent, with each data item and purpose on one screen, rather than a single link to a privacy policy.
- Consider listing data collected by third-party SDKs alongside your own. The page on processors and SDKs explains why the app stays responsible for them.
- Check that the withdrawal link in the notice leads somewhere that actually works, and that it takes no more steps than opting in did.
- Plan the s.5(2) notice to existing users: channel (email or in-app), timing and how you record that it was sent.
- Keep a versioned record of each notice shown, so you can prove what a given user saw (s.6(10)).
- Use the readiness checklist to track the notice items, and the timeline for the dates.