DPDP Act 2023 and Rules 2025: Compliance Checklist for Apps

Under India’s Digital Personal Data Protection Act, 2023 (the DPDP Act) and the DPDP Rules, 2025, an app or website that collects personal data needs clear consent, a way for users to see, correct and erase their data, reasonable security safeguards, breach reporting, and limits on how long data is kept. Most of this has to be built into the product itself.

Most DPDP guides are written for lawyers and compliance teams. This one is for the people who build the product: what each requirement means in screens, tables, jobs and logs, with the section of the Act or the rule behind it. It is a practical summary, not legal advice. Read the Act and Rules as published in the Gazette, and involve a lawyer for decisions specific to your business.

What does the DPDP Act mean for apps and websites?

If your app or website collects personal data of people in India, such as names, phone numbers, email addresses, location or anything else that identifies a person, you are a Data Fiduciary under the Act. Any vendor that processes that data for you (hosting, email, analytics, a development agency) is a Data Processor, and you are responsible for what it does with the data (section 8(1) and 8(2)).

The Act covers digital personal data processed in India, and processing outside India when it is connected with offering goods or services to people in India (section 3). There is no size threshold.

The DPDP Rules, 2025 were notified in November 2025 and take effect in stages. Most of the obligations below apply from May 2027, eighteen months after notification. That sounds far away, but consent records, retention jobs and rights flows take time to build and retrofit. Start with a data map.

First step: map your data. For every form, screen, API and third-party SDK, list what personal data it collects, why, where it is stored, who can access it, which vendors receive it, and how long you keep it. Every item below depends on this list.

What must a consent screen include?

Consent must be “free, specific, informed, unconditional and unambiguous with a clear affirmative action” and limited to the data needed for the stated purpose (section 6(1)). Before asking, you must give a notice (section 5), and Rule 3 says what it must contain.

Build checklist for consent:

• A standalone notice, shown before or with the request, in clear and plain language, that lists the personal data you collect and the specific purpose for each item (section 5; Rule 3).
• Language choice: the notice and consent request available in English or any language in the Eighth Schedule to the Constitution, at the user’s option (sections 5(3) and 6(3)).
• Separate choices for separate purposes. “Deliver my order” and “send me offers” are different purposes; don’t bundle them into one checkbox.
• No pre-ticked boxes. Consent needs a clear affirmative action.
• Links in the notice to withdraw consent, exercise rights and complain to the Data Protection Board (Rule 3).
• Withdrawal as easy as giving consent (section 6(4)), for example a toggle in account settings, not an email to a hidden address.
• Stop processing after withdrawal within a reasonable time, and tell your processors to stop too (section 6(6)).
• A consent log. If a user disputes consent, you have to prove the notice was given and consent was received (section 6(10)). Store, for each user: the notice version shown, the purposes agreed to, the timestamp, the channel (app, web), and any withdrawal.

Children. The Act treats everyone under 18 as a child. Processing a child’s data needs verifiable consent from a parent or lawful guardian, and you must not track, behaviourally monitor or target advertising at children (section 9). Rule 10 describes how to check that the person consenting is an identifiable adult, for example using details you already hold or a virtual token such as one issued through DigiLocker. If children can use your product, plan the age check and parental flow early; it affects sign-up.

How do users exercise their rights?

Users (Data Principals) have the right to:

• access a summary of their personal data and how it is processed, and who it has been shared with (section 11)
• correct, complete, update and erase their data (section 12)
• grievance redressal from you before going to the Board (section 13)
• nominate someone to exercise their rights after death or incapacity (section 14)

Build checklist for rights:

• A clear way to make a request, published on your website or app (Rule 14). An in-app form or an account settings page works better than an email address.
• Identity verification before acting on a request, so that you don’t hand one person’s data to another.
• An export of the user’s data and the list of processors it was shared with.
• Edit screens for data users can correct themselves.
• An erasure job that deletes or anonymises the user’s data across your database, file storage, search indexes, analytics and processors, unless you must keep it by law (section 12(3)). Decide how deleted data ages out of backups.
• A request tracker with deadlines. Rule 14 caps the time to respond to grievances at 90 days; aim to be much faster.
• Contact details of your Data Protection Officer or a person who can answer questions, shown prominently on the website or app and in responses to users (section 8(9); Rule 9).

What security safeguards are expected?

Section 8(5) requires “reasonable security safeguards” to prevent a personal data breach. Rule 6 sets the minimum, and the build work follows from it.

Build checklist for security (Rule 6):

• Encryption, obfuscation, masking or tokens for personal data, in transit (HTTPS everywhere) and at rest.
• Access control: least-privilege roles for staff and services; no shared admin accounts.
• Visibility of access: logs of who accessed personal data, with monitoring and regular review.
• Log retention: keep those logs, and the related personal data needed to investigate, for at least one year, unless another law says otherwise.
• Backups so that processing can continue after an incident, and tested restores.
• Contracts with processors that require them to take the same safeguards.
• Secure development basics: dependency updates, secret management, code review and testing before release.

What happens if there is a data breach?

Any personal data breach must be reported to the Data Protection Board and to each affected user (section 8(6)). Rule 7 sets how:

• Tell affected users without delay, in plain language: what happened, the likely consequences, what you are doing about it, what they can do to protect themselves, and who to contact.
• Tell the Board without delay, then send a detailed report within 72 hours of becoming aware of the breach (or longer if the Board allows): the facts, cause, mitigation, any findings about the person responsible, and the notifications sent to users.

Build checklist for breaches:

• A breach runbook that names who decides, who writes the notices, and who contacts the Board. The 72-hour clock leaves no time to work this out during an incident.
• Alerts on unusual access, bulk exports and failed logins, so you actually learn about breaches.
• A way to contact every affected user (email, SMS or in-app) at short notice.
• An incident log that records what happened and when.

How long can you keep personal data?

You must erase personal data once the user withdraws consent or the purpose is no longer being served, unless a law requires you to keep it, and have your processors erase it too (section 8(7)).

Rule 8 and the Third Schedule set a fixed period for large platforms: e-commerce entities and social media intermediaries with at least two crore registered users in India, and online gaming intermediaries with at least fifty lakh, must erase data three years after the user’s last interaction, and warn the user 48 hours before erasing it. Separately, Rule 8 requires personal data and related logs to be kept for at least one year for the purposes listed in the Rules.

Build checklist for retention:

• A retention schedule: for each data type in your map, how long it is kept and why (for example, invoices for the period tax law requires).
• Scheduled jobs that delete or anonymise data when its period ends, with logs showing they ran.
• Last-activity tracking per user, if an inactivity period applies to you.
• Advance notice before erasure where the Rules require it.
• Processor deletion: confirm your vendors delete data when you do.

Does it apply to AI features and third-party tools?

Yes. Personal data used to run or train an AI feature, sent to an analytics tool, or passed to a marketing platform is still processing under the Act. Name those purposes in the notice, send only the data each tool needs, and check where each vendor stores and processes it. Cross-border transfers are allowed except to countries the government restricts by notification (section 16), but sector rules, such as the RBI’s requirement to store payment data in India, still apply.

If you build AI features into your product, treat the data flowing into prompts, logs and training sets as part of your data map from day one.

Where to start

A realistic order for most teams:

1. Map the data across screens, APIs, databases and vendors.
2. Rewrite the notice and consent screens, and start logging consent.
3. Build the rights flows: access, correction, erasure and grievances.
4. Set the retention schedule and automate deletion.
5. Close the security gaps against Rule 6 and write the breach runbook.

Most of this is ordinary good engineering; the Act mainly makes it compulsory and provable. If you need help building consent, rights and retention into an existing product, our custom software development and mobile app development teams do this work. Talk to us about where your app stands today.