DPDP Act Compliance: What Indian App Owners Must Change Before May 2027

DPDP Act compliance becomes enforceable on 13 May 2027, eighteen months after the Digital Personal Data Protection Rules were notified on 13 November 2025. Indian app owners must rewrite consent notices, add a breach reporting path to the Data Protection Board, build retention clocks with automatic erasure, and verify parental consent for every user under 18.

Most teams we speak to in Delhi NCR have read a summary of the law and filed it under “legal will handle it”. That is the wrong department. Almost every obligation in the notified Rules lands on a database schema, an API, a consent screen or a cron job. Legal can draft the privacy notice. Only engineering can make the app stop keeping data it is no longer allowed to keep.

This post walks through what the notified Rules actually require, what is already in force, what arrives next, and the nine things an Indian app owner has to change in the product itself.

The DPDP Act compliance timeline

The Digital Personal Data Protection Act was passed in 2023, but it sat without operative rules for two years. That changed with gazette notification G.S.R. 846(E), dated 13 November 2025, which brought the Digital Personal Data Protection Rules, 2025 into existence with a staggered commencement written into Rule 1.

The staggering matters, because it is the reason so many Indian app owners think they have nothing to do. Rule 1 splits the Rules into three groups.

So the honest position is this. Nothing in the operative compliance set binds your app today. All of it binds your app on 13 May 2027. Eighteen months sounds generous until you price the work, which is why DPDP Act compliance belongs on a 2026 roadmap rather than a 2027 one.

One caveat worth knowing. MeitY held consultations in January 2026 on cutting the eighteen-month window to twelve months, which would pull the operative date forward to 13 November 2026, and on bringing the cross-border transfer restrictions for Significant Data Fiduciaries into force immediately. Chambers and Partners reported that comments were sought by 4 February 2026. As far as we can establish at the time of writing, that change has not been notified, and 13 May 2027 remains the operative date. Build as though it could move.

Who the law covers

The Act applies to digital personal data processed in India. It also applies to processing outside India where that processing relates to offering goods or services to people in India. There is no revenue floor and no headcount floor. A two-person startup with a signup form is a Data Fiduciary in exactly the same way a listed company is.

What varies is the tier. Ordinary Data Fiduciaries carry the base obligations. Significant Data Fiduciaries, designated by the Central Government under section 10 on factors including volume and sensitivity of data, carry several more. Nobody is a Significant Data Fiduciary until notified as one, so an early-stage product should plan for the base tier and architect so that the upper tier is a configuration change rather than a rebuild.

Nine changes app owners must make

Here is the product work, in roughly the order we would sequence it on a build.

1. Separate the notice from the terms of service. Rule 3 requires a standalone notice, understandable on its own, listing the personal data collected in itemised form and the specific purpose of each item. A clause buried on page four of your T&C does not qualify.
2. Make consent granular and itemised. One checkbox covering analytics, marketing and core service delivery fails. Each purpose needs its own consent record, each with a timestamp and a version reference to the notice text the user actually saw.
3. Build withdrawal that is as easy as giving consent. If a user consented in two taps inside the app, withdrawal cannot require an email to support. It must be an in-product action, and withdrawal has to cascade to every processor you have shared the data with.
4. Version your consent notices. When you change a purpose you need to prove what the user agreed to and when. Store the notice text or its hash alongside each consent record. Most teams discover this is a schema migration, not a UI change.
5. Add age assurance before children’s data flows. Rule 10 requires verifiable parental consent for users under 18. That is not a date-of-birth field.
6. Instrument a breach detection and reporting path. You cannot report within 72 hours what you cannot detect in 72 hours. This is logging and alerting work, not paperwork.
7. Put a retention clock on every personal data table. Retention limits under Rule 8 only work if each record knows when its purpose was fulfilled and what the last interaction date was.
8. Build automated erasure, including at processors. Deletion has to propagate to backups, analytics warehouses, CRM, support desk and any vendor holding a copy. Erasure in the primary database alone is not erasure.
9. Ship Data Principal rights as product features. Access, correction, erasure, grievance redressal and nomination all need an interface and an SLA behind it, not an inbox.

If you are costing this for a product already in production, the heavy items are almost always four, seven and eight. Consent versioning and retention clocks touch the schema, and schema changes to live user tables are where the real estimate sits. Teams planning a new build from scratch have an advantage here, and it is worth folding these requirements into the architecture during initial product design rather than retrofitting them in year two.

Breach reporting and the 72-hour clock

Section 8(6) of the Act requires a Data Fiduciary to give both the Data Protection Board and every affected Data Principal intimation of a personal data breach. Rule 7 fills in the mechanics: an immediate notice to affected individuals describing the nature, extent and likely consequences of the breach along with mitigation measures, then a detailed submission to the Board. EY’s analysis of the notified Rules places that detailed submission at 72 hours.

Three engineering consequences follow.

• You need to know which users were affected. That means logs that tie records to individuals, retained long enough to reconstruct an incident.
• You need a notification channel that reaches users who may no longer be active. Email on file is usually the only one that works.
• You need an on-call path that treats a data breach as a P1 at 2am on a Sunday, because the clock does not pause for weekends.

Note the asymmetry in the penalty schedule: failing to secure data properly carries a higher maximum than failing to report. Reporting a breach promptly is always the cheaper decision.

Retention, erasure and the 48-hour notice

This is the obligation most likely to break an existing product, because almost no Indian consumer app deletes anything today.

The general rule is that personal data must be erased once its purpose is fulfilled and no law requires its retention. On top of that, the Third Schedule sets fixed retention limits for three classes of large platform: 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 registered users. For those classes, personal data may be retained for three years from the user’s last interaction, after which it must go.

Rule 8 adds a requirement that catches teams by surprise: the Data Fiduciary must tell the user at least 48 hours before the retention period expires that their data is about to be erased, unless the user logs in or otherwise makes contact in the meantime. That is a scheduled job, a notification template, and a reset-the-clock rule on login. It is small work if you design for it and awkward work if you bolt it on.

Children’s data and parental consent

Under the Act, anyone under 18 is a child. Rule 10 requires verifiable parental consent before processing their data, with the parent’s identity and age checked against reliable identity details or a virtual token mapped to them. The Act separately prohibits tracking, behavioural monitoring and targeted advertising directed at children, with exemptions set out in the Fourth Schedule for certain classes such as healthcare and education providers.

For an Indian consumer app, the practical questions are whether you can plausibly claim no users under 18, and if not, what your age assurance flow looks like. Edtech products have no escape route here at all. Neither do most gaming and social products.

The Significant Data Fiduciary tier

If the Central Government designates you a Significant Data Fiduciary under section 10, four more obligations attach: a Data Protection Officer based in India who reports to the board and serves as the grievance contact, an independent data auditor, periodic Data Protection Impact Assessments and audits, and under Rule 13 due diligence on algorithmic software to verify it does not pose a risk to Data Principals’ rights. Rule 15 adds restrictions on transferring personal data outside India, as specified by the Central Government.

India Briefing’s compliance timeline expects the first Significant Data Fiduciary audit cycle to begin in early 2027. If you run a platform at the scale where designation is plausible, the DPIA and audit trail work should start considerably sooner than that.

What a breach actually costs

The Schedule to the Act, read with section 33, sets the maximum financial penalties the Data Protection Board can impose.

These are ceilings, not tariffs. The Board weighs the nature and gravity of the breach, the data affected, repetition, mitigation and the gain or loss involved. A small app will not be fined Rs 250 crore. But the residual Rs 50 crore head covers almost everything else in the Rules, and it is the one most Indian app owners will be exposed to, because it catches notice and consent failures.

A DPDP Act compliance plan you can run

DPDP Act compliance is not a document exercise with an engineering appendix. It is an engineering project with a document appendix. The sequence we would recommend to any Indian app owner starting from zero:

1. Data map first. Every personal data field, where it is stored, which processor touches it, which purpose justifies it. Most teams find fields nobody can justify. Those get deleted, which is the cheapest compliance win available.
2. Purge what you cannot justify. Data you do not hold cannot be breached, reported, retained or erased.
3. Schema work. Consent records with versions and timestamps, retention and last-interaction columns, erasure flags.
4. Notice and consent UI. Standalone, itemised, withdrawable in-product.
5. Rights endpoints. Access, correction, erasure, grievance, nomination.
6. Erasure and notice jobs. The retention cron, the 48-hour warning, processor propagation.
7. Breach runbook. Detection, classification, the 72-hour submission, the user notification template.
8. Vendor contracts. Every processor needs a contract under section 8(2). Analytics SDKs count.

Compliance tooling is a product problem as much as a legal one. When we built the Fact Flow compliance portal, the hard parts were never the regulatory definitions. They were deduplication across record sets, permissioning, and keeping an audit trail that survived scrutiny. The same is true of DPDP Act compliance work: the obligations are readable in an afternoon, and implementing them properly is a quarter of engineering time.

If you are budgeting this alongside other roadmap work, our breakdowns of mobile app development cost in India and CRM development cost in India give a sense of what comparable engineering blocks run to, and our 12-point checklist for choosing a software development company in Delhi NCR covers what to ask a partner before handing them your user database.

Planning your DPDP Act compliance work before the May 2027 deadline? We run data mapping and consent architecture reviews for Indian app owners, and we build the schema, erasure jobs and rights endpoints that follow. Talk to our custom software development team about scoping it for your product.