If your business runs an app or a web portal that holds customer names, phone numbers or addresses, India's Digital Personal Data Protection regime now has a date attached. The Rules under the Act were notified in November 2025 and come into force in stages. The main duties of a business that holds personal data apply from May 2027. That is a long time for a policy document and a short time for software, because most of what the law asks for has to be built into the product.
We are a product engineering team at Infopark in Kochi. We build mobile apps and web applications that hold personal data for businesses in Kerala, across India and abroad. This guide translates the DPDP Act and Rules into the features an app needs. It is not legal advice. Have a lawyer confirm your obligations, then use this to plan the engineering.
The short answer
DPDP compliance for an app means five things in the product. A clear, separate notice before you collect personal data. Consent that is recorded and can be withdrawn as easily as it was given. A way for users to see, correct and erase their data, and to raise a complaint. Security controls with logs that are kept for at least a year. A breach process that can reach affected users quickly and the Data Protection Board within 72 hours. Apps used by children need verifiable parental consent as well. Start with an inventory of the personal data your app holds, because every other item depends on it.
The dates that matter
The Digital Personal Data Protection Act was passed in 2023. The Rules that make it work were notified on 13 November 2025, with an 18-month runway for most of the obligations.
| From | What comes into force |
|---|---|
| 13 November 2025 | Definitions, the Data Protection Board and the Government's rule-making powers. |
| 13 November 2026 | Registration and operation of consent managers, the platforms that let people give and withdraw consent across services. |
| 13 May 2027 | Consent, notice, security, breach reporting, user rights, children's data and the duties of significant data fiduciaries. |
Until May 2027 the older framework under section 43A of the IT Act continues to apply. Nobody should read the gap as permission to wait. Changing an app takes a design cycle, a build, testing and store review, and changes to data you already hold take longer still.
Who this applies to
The Act applies to personal data in digital form, or collected on paper and later digitised, that is processed in India. It also reaches processing outside India when it is connected with offering goods or services to people in India. A Dubai company selling to customers in Kerala is inside it. So is a Kochi clinic with a booking app, a Calicut retailer with a loyalty app and a Trivandrum school with a parent portal.
The law calls the business that decides why and how data is used a data fiduciary, and the person the data is about a data principal. The company that builds or hosts your app for you is a data processor. The duties sit with you, the fiduciary, even when the processor does the work. That point decides much of what follows.
What changes in the app itself
A notice that stands on its own
The Rules ask for a notice that can be understood independently of any other information, such as your terms and conditions. It must give an itemised description of the personal data you collect, the purpose for each item and the services that use it. It must say how a user can withdraw consent, exercise their rights and complain to the Board.
In product terms, a link to a long privacy policy at the bottom of the sign-up screen is not enough on its own. Plan a short, structured notice screen before data is collected, in plain language, with the full policy linked from it. The Act also lets a user ask for the notice in English or in any of the 22 languages in the Eighth Schedule of the Constitution. For an app serving Kerala, a Malayalam version is the obvious one to prepare. Have it translated properly, not by a machine.
Consent you can prove
Consent under the Act has to be free, specific, informed, unconditional and unambiguous, given by a clear action. Pre-ticked boxes and one checkbox covering five purposes do not meet that. Where you rely on consent, ask for it per purpose, and do not make an unrelated purpose a condition of using the service.
You also carry the burden of showing that consent was given. That means a consent record in the database: who agreed, to which version of the notice, for which purposes, when, and through which screen. If your app keeps no such record today, this is a back-end change, and it is the one we would build first.
Withdrawal as easy as consent
Withdrawing consent must be as simple as giving it. If consent took one tap at sign-up, withdrawal cannot require an email to a support address and a two-week wait. Put a privacy section in the app's settings with a toggle per purpose. When a user withdraws, the systems behind the app must stop the processing that depended on it, including the marketing tool, the analytics service and any partner you share data with.
User rights inside the product
Users have the right to a summary of their data and the processing, to correct and update it, to have it erased when it is no longer needed, to nominate someone to act for them in case of death or incapacity, and to raise a grievance. The Rules set a maximum of 90 days to resolve a grievance.
You can handle these by email, but at any volume a self-service screen is cheaper and easier to evidence. A profile page that allows correction, a request form for a data summary and an account deletion option cover most of it. Each request needs a ticket with a date, so you can show it was handled in time.
A named contact
Publish, on the website and in the app, the contact details of a person who can answer questions about how you process personal data. For most businesses this is a named role with a monitored email address. Significant data fiduciaries must appoint a data protection officer based in India.
What changes behind the app
Security safeguards
The Rules require reasonable security safeguards and give examples rather than a fixed standard: encryption, obfuscation or masking of data, or the use of virtual tokens in place of the data; access controls; monitoring and logging of access; backups and continuity measures; and contracts that hold your processors to the same care.
Encrypt data in transit and at rest, including backups and file storage, not only the main database.
Mask personal fields in admin panels and exports where staff do not need the full value.
Give each staff role access only to the data its work requires, and remove access when people leave.
Log who viewed, changed or exported personal data, and keep those logs for at least a year.
Keep personal data out of application logs, crash reports and analytics events, where it tends to leak unnoticed.
Retention and deletion
Personal data should be erased once the purpose it was collected for is served and consent is withdrawn, unless another law requires you to keep it. The Rules also require certain logs and traffic data to be kept for at least a year. Together these mean you need a retention schedule per kind of data and a scheduled job that deletes or anonymises records when their period ends.
Large e-commerce, gaming and social media platforms have a specific rule: erase the data of users inactive for three years, with 48 hours' notice before doing so. The thresholds run into millions of registered users, so most business apps will not meet them. The general duty to delete when the purpose is served still applies.
Breach reporting
When a personal data breach happens, affected users must be told without delay, through their account or registered contact. The Board must be told without delay, with a detailed report within 72 hours of the business becoming aware. Seventy-two hours is not long. You need monitoring that notices a breach, an agreed person who decides, and a way to message every affected user at once. Build the bulk notification and the user lookup before you need them.
Vendors and processors
A typical app sends personal data to a cloud host, an OTP provider, a payment gateway, a messaging service, analytics and crash reporting. You may use processors only under a valid contract, and their failures are your responsibility. List every service the app sends personal data to, what it receives and where it stores it. Remove the ones that receive data they do not need. Analytics tools that collect device identifiers by default are a common surprise.
Children's data
Under the Act a child is anyone under 18. Processing a child's personal data needs verifiable consent from a parent or lawful guardian, and the business must check that the person giving it is an identifiable adult. The Rules allow this through details you already hold, details the parent provides, or a virtual token from an authorised entity such as DigiLocker. Tracking, behavioural monitoring and targeted advertising aimed at children are prohibited, with some exemptions listed in the Rules.
This matters for school apps, tuition and learning platforms, gaming and any consumer app whose users may be teenagers. The age check and the parental consent flow change sign-up, so they belong in the design, not in a later patch. Check with your lawyer whether your category falls under an exemption.
A checklist for an existing app
If your app is already live, this is the order we would work in.
| Step | What to do | Who does it |
|---|---|---|
| 1. Inventory | List every personal data field, where it is stored, why it is collected and which services receive it. | Developers, with the business owner. |
| 2. Purposes | Decide the purpose of each field and whether you rely on consent or another lawful ground. Remove fields you do not need. | Business owner and lawyer. |
| 3. Notice | Write a standalone notice, have it checked, and translate it into the languages your users read. | Business owner and lawyer. |
| 4. Consent records | Add a consent table and per-purpose consent screens. | Developers. |
| 5. Settings and rights | Add withdrawal toggles, data correction, a summary request, account deletion and a grievance form. | Developers. |
| 6. Security | Encryption, masking, role-based access and access logs kept for a year. | Developers. |
| 7. Retention | Set periods per data type and schedule the deletion jobs. | Business owner sets them; developers build them. |
| 8. Breach plan | Name the decision-maker, write the steps and build the bulk user notification. | Business owner and developers. |
| 9. Vendors | Review contracts and data flows for every processor. | Business owner, with developer input. |
| 10. Existing data | Decide how data collected before the new notice will be handled, and plan any re-consent. | Business owner and lawyer. |
The same applies to the systems behind the app. A CRM or an admin portal that holds the same customer records needs the same access controls, logs and deletion jobs. Our general overview of data privacy and regulation covers the principles that the DPDP Act shares with Europe's GDPR.
If you are commissioning a new app
Building these features in from the start costs far less than retrofitting them. Put them in the brief and ask any developer how they will handle each one.
Where is consent recorded, and can you show me the record for one user?
How does a user withdraw consent, and what happens in the back end when they do?
How does a user delete their account, and which copies of their data are removed?
Which outside services receive personal data, and why?
Who can see personal data in the admin panel, and is that access logged?
How would we notify every affected user within hours if there were a breach?
A developer who has thought about these will answer quickly and specifically. Ask for the privacy features to be itemised in the estimate. Our guide to mobile app development cost in India explains how the rest of the quote is built.
Frequently asked questions
When does the DPDP Act apply to my app?
The consent, notice, security, breach and user rights obligations apply from 13 May 2027. Consent manager provisions start on 13 November 2026. Work on the app should start well before May 2027.
Does it apply to small businesses?
Yes. The core duties apply to any business processing digital personal data, whatever its size. The heavier duties, such as a data protection officer and independent audits, apply to businesses the Government designates as significant data fiduciaries.
Is a privacy policy enough?
No. A policy describes what you do. The Act also needs the app to do it: record consent, allow withdrawal, handle requests, protect and delete data and support breach notification.
What are the penalties?
The Act sets financial penalties by type of breach, with the highest at up to ₹250 crore. The Board decides the amount in each case.
Does my overseas customer base change anything?
It can add obligations. Customers in the European Union bring the GDPR, and customers in the UAE or Saudi Arabia bring their own data protection laws. An app built to the DPDP features above is a good base for the others, but each law has its own details.
Conclusion
DPDP compliance is mostly a product question. The Act asks for clear notice, provable consent, easy withdrawal, user rights, real security, timely deletion and a working breach process, and each of those is a feature that someone has to design, build and test. May 2027 gives enough time to do that calmly if the work starts now, and not much time if it starts in the spring.
If you have a live app or web portal and want to know what it would take to bring it in line, we can review it and give you an itemised list of changes. Tell us about your app and we will start from there.
Human. Digital. Future.
