Short answer: Section 7 of the DPDP Act lists the only situations in which personal data can be processed without consent, and the list is closed. For most apps the relevant item is s.7(a), data the user voluntarily provided for a specified purpose. These provisions take effect on 13 May 2027.
What is a legitimate use under the DPDP Act?
A legitimate use is one of nine situations listed in s.7 of the DPDP Act in which a Data Fiduciary may process personal data for a lawful purpose without the Data Principal's consent (s.4, s.7).
- Lawful grounds: personal data may be processed only for a lawful purpose and either with consent or for a legitimate use (s.4).
- Closed list: s.7 sets out the legitimate uses on its face as an exhaustive list. There is no general legitimate interests ground and no contractual necessity ground of the kind found in some other data protection laws.
What are the nine legitimate uses?
The nine legitimate uses cover voluntary provision for a specified purpose, State benefits and functions, legal obligations, court orders, medical and public-health emergencies, disasters and employment (s.7(a) to (i)). Only the first is likely to matter for most consumer apps.
| Clause | Legitimate use | Relevance to a typical app |
|---|---|---|
| s.7(a) | Specified purpose for which the user voluntarily provided her data and has not indicated she does not consent | High: for example sending a receipt for a purchase |
| s.7(b) | State subsidies, benefits, services or licences | Low, unless the app delivers State services |
| s.7(c) | Performance of State functions, sovereignty, security | Low for private apps |
| s.7(d) | Legal obligation to disclose information to the State | Possible, for disclosures required by law |
| s.7(e) | Compliance with a judgment or order | Possible, when served with an order |
| s.7(f) | Medical emergency | Health and safety apps |
| s.7(g) | Epidemic or other threat to public health | Health apps in a public-health event |
| s.7(h) | Disaster or breakdown of public order | Safety and emergency apps |
| s.7(i) | Employment purposes | Workforce and HR apps, for employee data |
How does s.7(a) work for an app?
Section 7(a) covers processing for the specified purpose for which the user voluntarily provided her personal data, where she has not indicated that she does not consent to its use. The Act's illustration is a pharmacy that sends a payment receipt by SMS to the phone number a customer gave when buying medicine.
- The data must have been provided voluntarily by the user.
- Use is limited to the purpose for which she provided it.
- If she indicates she does not consent, s.7(a) no longer applies to that use.
- The access right in s.11 expressly applies to data processed under s.7(a), so users can still ask what you hold. See data principal rights.
Can an app rely on s.7(a) for analytics or marketing?
This is untested. Whether data voluntarily provided includes passively collected telemetry, such as in-app events, device details or SDK signals, is an open question in our research.
- Interpretation: because there is no legitimate interests ground, analytics, attribution and marketing processing that does not fit within s.7(a) would generally need consent under s.6. This reading is reported from law firm commentary (AMLEGALS); no Board or court decision exists yet.
- Interpretation: commentators read the closed s.7 list as making consent the default basis for most commercial app processing.
- The attribution page sets out how this affects measurement SDKs.
Are there wider exemptions?
Separately from s.7, s.17 contains exemptions. Two are relevant to apps:
- Startups: the Central Government may notify classes of Data Fiduciaries, "including startups", as exempt from s.5 (notice), s.8(3) and (7) (accuracy and erasure), s.10 and s.11 (s.17(3)). No such notification was found as of 21 October 2026.
- Non-residents under foreign contracts: processing by a person in India of non-residents' personal data under a contract with a person outside India is exempt from most of Chapter II except s.8(1) and (5), from Chapter III and from s.16 (s.17(1)(d)).
What this means for your app
These are practical steps teams commonly consider. They are not a guarantee of compliance.
- Consider mapping each processing purpose to either consent or a specific s.7 clause, and writing down why.
- A common approach is to rely on s.7(a) only for narrow, user-initiated purposes, such as fulfilling an order or sending a requested receipt.
- Treat analytics, personalisation, attribution and marketing as consent-based unless legal advice supports another view.
- Consider honouring any user signal that she does not consent to a s.7(a) use, since that ends the legitimate use.
- Keep s.7 uses within reach of your access and grievance processes, because rights still apply.
- Watch for a s.17(3) startup exemption notification on the timeline before planning around one.