DPDP Act: consent flows an Indian app actually needs

What the Act is and why an app owner should care

The Digital Personal Data Protection Act, 2023 is India's first comprehensive law on the processing of digital personal data. If your app collects information about identifiable people in India, the Act applies to you, regardless of how small you are. It is not a law only for large technology companies. A neighbourhood business with an app that stores customer phone numbers is within its reach.

This page is a map, not legal advice. It explains the ideas, the vocabulary and the practical questions a product team should answer. It has not yet been verified line by line against the Gazette text by a lawyer, and the stamp at the top says so. Treat it as a way to ask better questions, and confirm every duty against the Act and the current Rules before you rely on it.

The vocabulary you need

The Act uses a few terms repeatedly. A Data Principal is the person the data is about, in practice your user or customer. A Data Fiduciary is the entity that decides why and how the data is processed, which is you if you run the app. A Data Processor is someone who processes data on the fiduciary's behalf, such as a cloud provider or an SMS vendor.

The distinction matters because the main duties fall on the fiduciary, and the fiduciary remains responsible when a processor is used. You cannot outsource responsibility by outsourcing the work. Your contracts with vendors need to reflect that.

Notice and consent: the heart of it

The Act's core idea is that personal data should be processed with the person's consent, for a stated purpose, after being told what is happening. Consent must be free, specific, informed, unconditional and unambiguous, and given through a clear affirmative action.

In product terms this rules out several common habits. Pre-ticked boxes are not a clear affirmative action. Bundling consent for unrelated purposes into a single tick is not specific. Making the app unusable unless a person agrees to something unnecessary is not free. Burying the request in a long legal page is not informed.

A good notice is short, in plain language, in a language the user understands, and tells them what data you collect, why, how to withdraw consent and how to complain. It appears when you ask, not hidden elsewhere. A good consent screen has a real choice and a button that means what it says.

Collecting only what you need

The Act ties processing to a purpose. You may collect and use personal data for the purpose you stated and that the person consented to. A form asking for date of birth, address and a photograph in order to send a receipt collects more than it needs.

The design discipline that follows is easy to state and takes effort to practise: for every field, be able to say what it is used for. If you cannot, remove it. Data you do not hold cannot leak, cannot be subpoenaed and cannot become a liability.

Children's data

The Act treats anyone under eighteen as a child, which is a higher age than many product teams assume. Processing a child's data requires verifiable consent from a parent or lawful guardian, and the Act restricts tracking, behavioural monitoring and targeted advertising directed at children.

If your app may be used by anyone under eighteen, which is the case for many education, gaming and social products, you need a plan: how you will establish age, how you will obtain and verify parental consent, and what you will switch off for those users. This is an area where the technical means of verification are still developing, and it deserves early attention.

Security safeguards and breaches

The fiduciary must keep reasonable security safeguards to prevent a personal data breach. 'Reasonable' is not defined by a checklist, but includes the ordinary measures: encrypting data in transit and at rest where appropriate, controlling who can access it, keeping software updated, and logging access.

If a breach does happen, the Act requires the fiduciary to inform the Data Protection Board and each affected person. That means having a process before it happens: knowing how you would detect a breach, who decides, and who writes to whom. Working that out in the middle of an incident is a poor way to do it.

The penalties in the Act's Schedule are large. They exist to make the point that protection of personal data is a board-level matter and not a task to hand to the newest developer.

People's rights and how you honour them

Data Principals have rights to obtain a summary of the personal data held and the processing done, to have inaccurate data corrected and incomplete data completed, to have data erased, and to have a grievance addressed. They may also nominate another person to exercise these rights if they die or become incapacitated.

For a product, this means building the plumbing: a way to receive a request, to verify who is asking, to find all the data about them across your systems, and to act. If the data is scattered through backups, analytics tools and a vendor's database, that is a project in itself, and it is far easier to design for than to retrofit.

Your vendors count

Most apps send personal data to others: SMS providers, analytics tools, crash reporting, cloud hosting, payment gateways. Each is a processor, and each is part of your compliance picture.

Keep a list of every service that touches personal data, what it receives and why. Make sure there is a contract that restricts their use of it. And be conscious that putting an analytics tool in an app, to see how it is used, can itself mean sending personal data to a third party.

Three small examples of getting it right

A neighbourhood salon app asks for a phone number to book an appointment. A compliant design asks for the number, says in one line that it is used to send the booking confirmation and reminders, and has a single clearly worded button. It does not also ask for a birth date or an address, which it does not need. It keeps the number only as long as it is needed for the booking relationship, and lets the customer ask for it to be removed.

A learning app has users of mixed ages. A compliant design asks for an age or date of birth at sign-up, and when the user is under eighteen, routes them to a flow in which a parent or guardian gives consent, with a means of verification suitable to the risk. It switches off behavioural tracking and targeted advertising for those accounts.

A shopping app wants to send promotional messages. A compliant design asks for that consent separately from the consent needed to process the order, with a clear choice, and makes it as easy to turn off as it was to turn on. Mixing the two, so that the customer cannot place an order without agreeing to marketing, is the pattern the Act is aimed at.

A practical way to start

1. List every piece of personal data you collect and what it is used for.
2. Remove anything you cannot justify.
3. Write a plain-language notice and a consent screen with a real choice.
4. Build a way to withdraw consent and to request access and erasure.
5. List your vendors and check the contracts.
6. Write down what you would do if there were a breach.

Then have a lawyer who knows data protection review what you have done. It is a bounded task, and it is far cheaper than the alternative. Commencement of provisions is phased and the Rules fill in the detail, so check which are in force when you build.