DPDP Act and mobile app security: a practical checklist for Indian startups

Every app collects data: a phone number, a name, a location, a photo, sometimes health or financial details. In India, how you collect, use and protect that data is now governed by the Digital Personal Data Protection Act, 2023 (DPDP Act). Alongside the law, users and app stores expect you to treat their information with care.

This is a practical, plain-language checklist for founders and product owners. It is not legal advice, and you should speak to a lawyer about your specific situation, but it will help you ask the right questions and build the basics correctly from day one.

The DPDP Act in simple terms

The DPDP Act sets rules for handling the personal data of people in India. Two terms matter:

• Data Principal: the person the data is about, your user.
• Data Fiduciary: the organisation that decides why and how the data is used, that is you, if you run the app.

In broad terms, the Act expects that you collect personal data only with clear consent for a specific purpose, collect no more than you need, keep it accurate and only as long as necessary, protect it with reasonable security safeguards, and give users ways to access, correct and delete their data and to complain. It also has special care around children's data and provisions for reporting data breaches. Penalties for failures can be heavy.

The Act and its rules are being put into practice in stages, so check the current requirements and timelines with a qualified adviser.

Part 1: Collect less, and say why

• List every piece of data your app collects and the reason you need each one. If you cannot explain why, do not collect it.
• Ask for permissions at the moment they are needed. Ask for camera access when the user taps "scan", not at install.
• Write a clear privacy notice in simple language, in English and, where relevant, in the languages your users speak.
• Get consent properly. It should be clear, specific and not bundled with unrelated things. Keep a record of when and what was agreed.
• Handle children with care. If your app may be used by minors, get verifiable parental consent as the law requires and avoid tracking and targeted advertising aimed at children.

Part 2: Protect data inside the app

• Do not store sensitive data on the phone unless you have to. If you must, use the platform's secure storage (Keychain on iOS, Keystore on Android).
• Never put secret keys inside the app. Anything inside the app can be extracted. Keep secrets on the server.
• Use HTTPS everywhere. No exceptions, including for images and analytics calls.
• Protect screens that show sensitive information from screenshots and screen recording where it makes sense.
• Clear data on logout and when the user deletes their account.
• Keep third-party SDKs to a minimum. Every analytics, advertising or social SDK can collect data too. Review what each one sends.

Part 3: Protect data on the server

• Check permissions on every request. Do not rely on the app to hide buttons. The server must decide who can see or change what.
• Validate all input and use safe database queries to prevent injection attacks.
• Hash passwords with a strong, modern algorithm. Never store them in plain text.
• Use short-lived sessions and secure tokens, with a way to revoke them.
• Add rate limits to logins, OTPs and forms to stop guessing and abuse.
• Encrypt sensitive fields and encrypt backups.
• Separate environments. Testing and production use different databases and keys, and developers do not casually work on live data.
• Keep software updated. Update libraries and servers regularly, since known weaknesses are widely exploited.

Part 4: Control who can access what

• Use roles. A support agent does not need the same access as an administrator.
• Give the minimum access needed and remove it when people change roles or leave.
• Protect the admin panel with strong passwords and a second step, and avoid exposing it to the open internet without protection.
• Keep audit logs of important actions so you can see who did what.

Part 5: Respect user rights

• Let users see and correct their data through the app or a clear request channel.
• Let users delete their account and data and really delete it, including from backups on a sensible schedule.
• Allow users to withdraw consent as easily as they gave it.
• Name a contact for privacy questions and complaints and respond within a reasonable time.

Part 6: Be ready when something goes wrong

• Have an incident plan. Who investigates, who decides, who informs users and the authorities, and in what time.
• Monitor for unusual activity such as many failed logins or large data downloads.
• Back up regularly and test that you can restore.
• Keep vendor contracts clear about who handles the data and how, because you remain responsible for it.

Part 7: Meet the store requirements

Both Apple and Google require privacy information in your listing. Apple asks for a privacy "nutrition label" and a privacy policy link. Google asks for a Data safety form and a privacy policy. Answer them truthfully and update them whenever your data practices change. Inaccurate answers can lead to rejection or removal. Our launch checklist covers the rest of the submission.

A one-page self-check

Question	Yes / No
Do we know every type of personal data we collect and why?
Do we have a clear privacy notice and recorded consent?
Is all traffic over HTTPS and are secrets kept on the server?
Are passwords hashed and logins rate-limited?
Does the server check permissions on every request?
Can users access, correct and delete their data?
Do we have backups and an incident plan?
Are store privacy forms accurate and current?

Common questions

Does the DPDP Act apply to a small startup?

It applies to organisations that process the personal data of people in India, regardless of size, though certain obligations are heavier for larger "significant" data fiduciaries. Ask your adviser how it applies to you.

Is using a cloud provider a problem?

No, but you remain responsible for the data you put there. Choose reputable providers, configure them securely and understand where data is stored.

Will this slow down development?

Building privacy and security in from the start costs little. Retrofitting it into a finished app costs much more.

Build it right from the start

Security is part of how we build every app and admin panel, not an extra at the end. If you want a second pair of eyes on a product you are planning or already running, talk to us, or see our mobile app development approach and what ongoing maintenance includes.