DPDP Act compliance checklist for apps and websites

If your app or website collects personal data from people in India, the DPDP Act expects it to do five things by 13 May 2027: show a clear, itemised consent notice, let users withdraw consent as easily as they gave it, protect the data with encryption and access logs, report breaches within 72 hours, and answer requests to see, correct or delete data. The consent manager framework switches on earlier, on 13 November 2026. Most of this is product and engineering work, which is why it takes longer than founders expect.

This is an engineering checklist written by people who build apps, not legal advice. Have a lawyer review your notices and contracts. But the lawyer can't add a consent log to your database, and that's the part that eats the calendar.

The dates that matter

The Digital Personal Data Protection Act was passed in 2023. The Rules that make it work were notified in November 2025 with an 18-month runway, split into phases:

• November 2025: the Data Protection Board of India was set up.

• 13 November 2026: the rules for consent managers take effect. These are registered companies that let a person give, review and withdraw consent across many apps from one place.

• 13 May 2027: everything else. Notices, consent, security safeguards, breach reporting and user rights all become enforceable.

The penalties are large enough to get a board's attention. Failing to take reasonable security safeguards can cost up to 250 crore rupees per instance. Missing a breach notification or mishandling children's data can cost up to 200 crore rupees.

The Act also reaches beyond India. If a company abroad offers goods or services to people in India and processes their data, it's covered too.

The checklist, step by step

Step 1: map the data you actually hold

You can't write an honest notice until you know what you collect. Most teams we talk to find data they forgot about: old signup fields, a support tool that stores chat transcripts, a spreadsheet export someone emailed in 2024.

List every place personal data lives:

• Signup and profile fields in your database

• Payment, delivery and invoice records

• Analytics, crash reporting and session tools

• Support desks, CRMs and email platforms

• Backups and file storage

• Every vendor that receives data from you, which the Act calls a data processor

For each one, write down why you collect it and when you stop needing it. That purpose list becomes your consent notice, and the "when you stop needing it" column becomes your deletion rules.

Step 2: rebuild consent as a feature

Under the Rules, a consent notice has to stand on its own, be written in plain language, and list the data and the purpose item by item. A checkbox under a 9,000-word privacy policy doesn't qualify. Users also need to be able to read the notice in English or in any of the 22 languages in the Eighth Schedule of the Constitution.

In practice, the build work looks like this:

• A consent screen that names each purpose separately, so a user can agree to order updates and refuse marketing.

• A consent record in your database: who agreed, to which notice version, for which purposes, and when.

• A withdraw button that is as easy to find as the agree button was. Once someone withdraws, your systems have to stop processing that data for that purpose within a reasonable time, including at your vendors.

• Versioned notices, so when you change your wording you know who agreed to what.

Consent managers matter here too. From 13 November 2026, a user may manage their consent to your app through a registered consent manager. Plan for your consent records to be updated from outside your own screens.

Step 3: children need verifiable parental consent

The Act treats anyone under 18 as a child. If your product can be used by children, you need verifiable consent from a parent or guardian before processing their data, and you can't do tracking, behavioural monitoring or targeted advertising aimed at them.

This hits edtech hardest. When we built EduVerse for a student community, age and consent questions came up in the first scoping call, because they shape the signup flow. Decide early how you'll check age and how a parent confirms. Retrofitting it after launch means rebuilding onboarding.

Step 4: security, logs and breach reporting

The Rules list the safeguards they expect: encryption or masking of personal data, access controls, logs of who accessed what, backups, and contracts that bind your vendors to the same standards. Access logs should be kept for at least one year so a breach can be investigated.

Breach reporting has two clocks. You tell affected users without delay, in plain language, with what happened and what they should do. You tell the Data Protection Board without delay and send a detailed report within 72 hours.

72 hours is short. Teams that meet it have three things ready before anything goes wrong:

• Alerts on unusual access or bulk exports

• A written incident runbook with named owners

• Email and in-app templates for user notices, already approved by legal

Step 5: user rights and deletion

People can ask for a summary of their data, ask you to correct it, ask you to erase it, and nominate someone to act for them if they die or can't act themselves. You need a grievance process that answers within 90 days.

Build these as proper flows, even if a human handles each request at first. A simple admin screen that finds every record linked to an email and exports or deletes it will save your team hours per request.

Deletion also works the other way round. When a purpose is done, the data should go. The Rules set a specific clock for large e-commerce, gaming and social media platforms: erase data after three years of inactivity, with a warning to the user 48 hours before. Smaller businesses still need retention rules. They just set their own periods based on purpose and other laws, such as tax record rules.

How long the engineering work takes

For a typical small app with one database and a handful of vendors, the consent, rights and logging work is usually a few weeks of focused engineering. Larger platforms with years of data spread across tools take longer, mostly because of the mapping in step 1.

The expensive route is waiting until April 2027 and doing it in a panic. The cheap route is folding it into the work you're already doing: add the consent log when you next touch signup, add the admin export when you next touch the dashboard.

If you're building something new, bake it in from the first sprint. We scope DPDP requirements into every custom software build and web or mobile app for Indian users, so there is nothing to retrofit later.

Questions about DPDP compliance

Does the DPDP Act apply to small businesses?

Yes. There is no general size exemption for businesses that process personal data digitally. The government can notify exemptions for certain classes of startups, but you shouldn't plan around one until it exists in writing.

Do I need a consent manager?

No. Consent managers are optional services for users. You need to be able to work with them if a user chooses one, which means your consent records must be accurate and updatable.

Is a privacy policy enough for DPDP compliance?

No. A policy explains your practices, but the Act needs working features: itemised consent, easy withdrawal, rights requests, breach handling and deletion. Those live in your product, not in a document.

What happens if my app was built by an agency that no longer supports it?

You're still responsible as the data fiduciary. Start with the data map and a code review of how signup, storage and deletion work today. That tells you whether small changes will do or whether parts need rebuilding.

Where to start this week

Do the data map in step 1 before anything else. It takes a day or two and makes every later step cheaper. If you'd like a second pair of eyes on it, book a free call with us and we'll tell you honestly how much work your app needs before May 2027.