The DPDP Act's One-Time Notice: What Indian SMEs Must Do About the Data They Already Hold

The DPDP Act's One-Time Notice: What Indian SMEs Must Do About the Data They Already Hold

Most of the DPDP conversation is about new data: the consent screen you'll add to your signup form, the notice the next customer will see. But there's a quieter obligation in the law that applies to something already sitting in your database right now, the emails, phone numbers, and profiles you collected months or years before the rules landed. This is the DPDP Act one-time notice, and for a lot of Indian SMEs it's the single largest compliance job nobody has put on the calendar yet.

Here's the setup. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025. The substantive obligations, notice, consent, and data-principal rights, become fully enforceable on 13 May 2027. That gives you a fixed runway to deal not only with future collection but with every record you are already processing today.

What Section 5(2) actually says

Section 5(2) of the DPDP Act, 2023 covers personal data collected before the Act came into force. Where you process such data on the basis of consent given earlier, you may keep processing it, but you must, in the words of the section, "as soon as it is reasonably practicable," give that person a notice. The notice has to tell them what personal data you hold and the purpose of processing, how they can exercise their rights, and how they can complain to the Data Protection Board of India.

Two consequences follow. First, you don't have to go back and re-collect consent for old data. If a customer agreed to your terms in 2023, that consent still stands. Second, you do have to tell them, once, in plain language, that you hold their data and what you do with it. From the moment they receive that notice, they can withdraw consent, and then you have to stop processing.

That's the trade the law offers: continuity in exchange for transparency. You keep using the data your business runs on, provided you're straight with people about holding it.

Why this is bigger than it sounds

The new-signup notice is a build-once problem. You wire it into the registration flow and it fires for every future user. The one-time notice is a back-catalogue problem, and back catalogues are messy.

Think about where customer data actually lives in a five-year-old company. A CRM. An old billing system. Three marketing tools. A spreadsheet a former employee kept. Support tickets. A newsletter list imported from a platform you no longer use. Section 5(2) doesn't care how scattered it is. If you're still processing that data, each of those people is owed a notice.

So the real work isn't writing the notice. It's answering a harder question first: whose data do we actually have, where is it, and why are we still keeping it? A company that has never mapped its data will find that the one-time notice forces the mapping. That is not a bad thing. It's the same inventory you'd need for a privacy impact assessment or a breach response, so the effort pays off in more than one place.

What to put in the notice, and how to send it

The notice should be short and specific. Vague reassurance isn't compliance. A workable version tells the person, in itemised terms: the categories of personal data you hold about them, the purposes you use it for, how they can withdraw consent, how they can access or correct their data, and how they can raise a grievance or complain to the Board.

Two details trip people up. It has to be available in English and the languages listed in the Eighth Schedule to the Constitution, so a customer can ask for it in their own language. And it has to reach people through channels they actually use. Email works for some lists. For others, SMS, WhatsApp, or an in-app message will land better. If half your notices bounce off dead email addresses, you haven't really given notice.

One thing you can drop from your worry list: you are not asking permission again. This is an informational notice, not a fresh consent request. Framing it as "click here to keep your account" creates confusion and can look like manufactured consent. Tell people what's happening and give them a clear route to say no.

The withdrawal you have to plan for

The part teams underestimate is what happens after the notice goes out. Some people will withdraw. The Act says you must make withdrawal as easy as giving consent was, and once someone withdraws, you stop processing and, unless another legal ground applies, delete their data within a reasonable period.

That means the notice can't be a broadcast you fire and forget. It needs a working back end: a way to receive a withdrawal, route it to whoever controls each system the data lives in, and confirm the deletion actually happened across all of them. If a customer withdraws and their record quietly survives in your email tool, you're now processing data you were told to stop processing, which is exactly the kind of failure the penalty regime, up to ₹250 crore per instance, is built to catch. This connects directly to your retention and deletion practices, and to the grievance process you should already be standing up.

Where to start now

You have until 13 May 2027, and that sounds comfortable until you count the systems. A sensible sequence for an SME looks like this.

Start with a data inventory: list every place personal data lives and every third-party tool it flows to. For each store, decide whether you still have a reason to process the data, because anything you can't justify keeping is better deleted before you notify people about it. Draft one clear notice template and get it translated. Pick delivery channels by list, not one channel for everyone. And build the withdrawal handling before you send a single notice, not after, because the requests start arriving the day it goes out.

None of this needs a large legal team. It needs someone to own the map and a few weeks of unglamorous cleanup. Companies that treat the one-time notice as a data-hygiene project rather than a legal chore tend to end up with a smaller, cleaner, cheaper-to-defend database.

If you want a structured way to begin, our DPDP compliance checklist walks through the inventory and notice steps in order, and the DPDP Act compliance overview sets out how Section 5(2) fits the wider timeline. When you're ready to scope the work for your own systems, get in touch.

This article is general guidance for Indian businesses and not legal advice. Obligations depend on your specific data, systems, and circumstances. For a plan tailored to your business, start with our compliance checklist or contact us.