The DPDP Act for app owners: a practical checklist

The words you need to know

You are responsible for what your processors do with your users' data. Choose vendors who can support your obligations, and have contracts that say so.

Notice and consent: the sign-up screens

Where consent is the basis for using someone's data, it must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action. In product terms:

• Show a clear notice before or when you ask for data: what you collect, why, and how the person can exercise their rights or complain.
• Make the notice available in English or in any of the languages listed in the Eighth Schedule of the Constitution. A Hindi, Tamil or Kannada app should have a notice in that language too. See our regional language guide.
• No pre-ticked boxes. Consent should be an action, like a tap on an unticked checkbox or a clear button.
• Ask only for what you need for that purpose. A food delivery app needs an address; it does not need the contact list.
• Keep separate consents separate. Agreeing to receive an order is not agreeing to marketing messages.
• Make withdrawing consent as easy as giving it — a settings toggle, not an email to a hidden address.
• Keep a record of what each person agreed to and when.

The Act also allows some processing without consent for certain legitimate uses, such as when someone voluntarily gives you data for a specific purpose. Your lawyer can tell you which of your flows fall there.

Purpose and retention: collect less, keep less

Personal data should be used for the purpose it was collected for, and erased when that purpose is served — unless a law requires you to keep it, such as tax or medical records.

• List every piece of personal data your app collects, why, where it is stored and who can see it. This data map is the foundation for everything else.
• Set retention periods for each kind of data, and build jobs that actually delete or anonymise it.
• Remove data you collect “just in case”. Every extra field is extra risk.
• Check analytics and crash tools. They often collect more than you think.

The Rules set specific retention and erasure expectations for some kinds of large platforms, and require some logs to be kept. Check which apply to you.

User rights: screens your app needs

People have rights over their data. Each one becomes a feature or a support process:

• Access: a way to see a summary of the data you hold and who you shared it with.
• Correction and updating: editable profile, addresses and preferences.
• Erasure: a delete-account option that actually deletes, with clear notes on anything you must keep by law. The app stores also require in-app account deletion — see our store launch guide.
• Grievance redressal: a named contact or in-app form, with a response within the time the Rules set.
• Nomination: a way for a person to nominate someone to exercise their rights if they die or become incapacitated.

Put these in one Privacy section in settings, rather than scattered across the app.

Children's data

Under the Act, a child is anyone under 18. Before processing a child's personal data, you need verifiable consent from a parent or lawful guardian. You must also not track or behaviourally monitor children, or target advertising at them, except where exemptions apply.

• If your app could be used by under-18s — edtech, school apps, gaming, fitness — plan an age check and a parental consent flow from the start.
• School and coaching apps should usually be designed with the parent as the account holder. Our school app guide and Chalkline show a parent-first model.
• Turn off personalised ads and behavioural analytics for child accounts.

Security and breach response

You must take reasonable security safeguards to prevent personal data breaches. In practice that means the basics done properly:

• Encryption in transit and at rest for personal data.
• Role-based access in your admin and ops dashboards. A support agent doesn't need to see full phone numbers.
• Masked phone numbers between customers and riders or pros.
• Access logs for who viewed or exported personal data.
• Backups, and a tested way to restore them.
• Contracts with processors that cover security and breach notification.

If a breach happens, you must inform the Data Protection Board and each affected person, in the form and within the time the Rules set. Write the breach plan now: who decides, who drafts the message, who sends it, and how you reach every affected user.

A one-page checklist

1. Data map: what, why, where, who, how long.
2. Notice in plain language, available in your app's languages.
3. Unticked, separate consents with a record of each.
4. Withdraw consent from settings in a few taps.
5. Access, correction, erasure and nomination in one Privacy section.
6. Grievance contact published in the app and on the website.
7. Age check and parental consent where children may use the app.
8. Retention periods with automatic deletion.
9. Security basics: encryption, role-based access, masking and logs.
10. Processor contracts reviewed.
11. Breach plan written and rehearsed.

We design these into the product from the first sprint — consent screens, privacy settings, masked contact and role-based dashboards — because retrofitting them is slower and costlier. See how on our process page, or send us your brief.

This guide is general information, not legal advice. The DPDP Act and Rules phase in obligations over time, and penalties for non-compliance can be large. Confirm what applies to your business, and when, with a qualified lawyer.

Questions people ask