Picture the email landing in your support inbox. “I closed my account back in 2021, please delete everything you have on me.” Fine, easy, a ticket. Then somebody goes looking and finds her details in the production database, last quarter’s analytics export, a CSV someone parked in their Drive, the CRM, a vendor’s ticketing tool and (because of course) Tuesday night’s backup. Which of those do you wipe? Which are you allowed to keep? And, the part nobody likes, who made that call?
That’s data retention under the DPDP Act, more or less. I’d guess most companies still don’t have a tidy answer.
Dates, quickly. The real duties start on 13 May 2027, which is when the retention schedule needs to be live, not in November 2026. If you get retention wrong you’re probably in the catch-all penalty tier, up to ₹50 crore, though that’s my reading, not gospel. What worries me more is breaches. Security failures go up to ₹250 crore, and every record you should’ve deleted but didn’t is one more record sitting in the blast radius.
What the Act says, which isn’t much
Section 8(7) is where it starts. A Data Fiduciary has to erase personal data when the person withdraws consent, or as soon as it’s reasonable to assume the purpose is no longer being served, whichever’s earlier, unless some law says you’ve got to keep it. Your processors have to erase it as well. The Act’s own example is a marketplace where someone sells a used car. Once the sale’s done, the marketplace shouldn’t be hanging on to her data.
Around that you’ve got two other bits. Section 8(8) considers the purpose of data collection finished if the person either doesn’t reach out to you about it or don’t exercise any rights they have, for a certain amount of time. And then there’s Section 12(3) which lets her ask for her data to be completely wiped out and deleted - which you have to do unless retaining that data is needed for a specific reason or in order to meet a law.
That makes three triggers: withdrawal, purpose served (the inactivity clock lives in here), and a straight request. Most retention policies I’d expect to see squash all three into one number. Mistake number one.
Figure 1. Keep or erase? The decision path for a record once a trigger fires.
Rule 8 pulls in two directions
The Rules add a twist. Rule 8 asks for two opposite things: an erasure duty that’s narrow, and a retention duty that applies to everybody. Take them one at a time.
The three-year rule isn’t general
You’ll hear people say DPDP means deleting everything after three years. It doesn’t. The Third Schedule lists only three classes: e-commerce entities with at least two crore registered users, online gaming intermediaries with at least fifty lakh, and social media intermediaries with at least two crore. Those three delete after three years of inactivity. Everyone else? Three years isn’t a universal retention period.
If you are one of the three that do this - though you’d hope to avoid being in that situation - it’s best to give the person a heads up early on. You have to let them know at least 48 hours before you intend to delete their data, and because the clock starts from the later of when they last contacted you or when these new rules came in - then a login inside that period will effectively cancel the erasure plan. I think (it’s worth checking with a lawyer to confirm) that the first batch of automatic erasures due to inactivity will kick in roughly 3 years after the rules come in - which would put them around 2030, depending on how you count the start date.
One year of logs, underneath it all
Rule 8(3) pulls the other way. You’ve got to keep personal data, associated traffic data and processing logs for a minimum of one year from the date of processing, for the purposes in the Seventh Schedule, then erase unless another law wants longer. It’s a floor for specific purposes. It isn’t a reason to keep everything for a year, and a blanket “retain it all for a year” policy is the wrong takeaway.
There’s an older clock under it as well. CERT-In wants ICT logs kept for a rolling 180 days, stored in India. So the DPDP floor is longer. If your logs are set to 180 days because that’s the number your security team remembered, well, that’s a gap.
When some other law says keep it
Most real-world retention periods come from other laws, because Section 8(7) steps aside for them. RBI’s KYC rules, for instance, want identity records preserved for at least five years after the relationship ends. The Act’s own bank example says ten years, but that’s there to show the principle, so don’t copy it as a number. Litigation’s another one. Section 17(1)(a) switches off most of Chapter II when processing is necessary for enforcing a legal right or claim, although Sections 8(1) and 8(5) stay on. A legal hold is fine, then, so long as it’s real and scoped to what the claim needs.
Stacked up, the clocks look like this.
| Data | Who sets the clock | What it means |
|---|---|---|
| Customer data for a finished service | Section 8(7) | Delete once the purpose is served |
| KYC identity records | RBI KYC rules | At least five years after the relationship ends |
| Processing logs | Rule 8(3) and CERT-In | One year under DPDP, 180 days under CERT-In |
| Inactive users of large platforms | Third Schedule | Three years, plus a 48-hour notice |
| Data under a legal hold | Section 17(1)(a) | Keep what the claim needs, restrict the rest |
Illustrative summary, not legal advice. Confirm periods for your sector.
Figure 2. How long the clocks run, side by side.
Where deletion falls over
Writing the policy is the easy bit. The plumbing’s harder. Backups, warehouses, analytics copies and old exports are where erasure stops being a policy exercise. Each one needs either a lineage link back to the person or a rebuild-from-source schedule short enough that deletions flow through. Vendors count too, since Section 8(7)(b) says you must cause your Data Processor to erase it as well, and the place that instruction lives is the contract (so go and read a few).
A CRM that deletes the record while the warehouse keeps its copy hasn’t erased anything. It’s moved it.
Writing a data retention policy DPDP auditors will accept
A data retention policy DPDP auditors will accept has a few boring features, and boring is the point.
First, a schedule, broken down into its own little sections to keep things straight - data categories, purposes, and the three retention rules. What is it? why do we hold onto it? how long do we need to keep it? is there a law that makes us keep it? who technically owns the data? how does it get deleted - that’s the kind of stuff you should know. Also keep in mind that if we just combine all three triggers into one big retention period, we might end up holding onto data for too long - which means we’d get in trouble over here - or worse yet, not holding onto it long enough to meet some other law.
Anything we keep on hand after its original purpose is up gets a formal justification, so it doesn’t just get repurposed as a marketing tool one day. And we better have a paper trail for when data gets deleted - we need to record what got erased, when it got zapped, and from where - without keeping the actual personal data in the record. If you’re one of those companies that’s Third Schedule, we’ll need to send a 48-hour heads up on the deletion and make sure the whole job shares state info. This retention schedule should also get pushed down to the processors and any backups we’ve got going on - and we should be reviewing the whole thing at least once a year, or any time we launch a new thing.
The next 30 days
You don’t need all of this running by Friday. Over the next month I’d list every system that holds customer or employee data (vendors included), then take your ten biggest data categories and write down the purpose and the clock for each. Go hunting for the law behind every “we keep that for years” habit, and if nobody can name it, flag it for review. Check your log retention against both the 180-day and the one-year figures. And pull five vendor contracts at random to see whether they say anything at all about erasure. (I’d bet a few say nothing.)
Who owns this
Not legal alone. Product decides what gets collected, engineering where it sits, security the logs, procurement the vendor clauses. Somebody senior has to sign off every exception, legal holds especially, because that’s where “temporary” quietly becomes permanent.
Seven months is enough to build the schedule if you start with a data map. It isn’t if you wait to see what the Board does first. Whatever your data retention policy DPDP version ends up looking like, a new joiner should be able to read it in ten minutes.
If you want to go deeper, Consiva’s posts on why erasure doesn’t mean delete and the 48-hour pre-erasure notice cover the two sharpest edges. And if you’d like to see how a platform maps retention rules to your data, talk to the team.
Frequently Asked Questions
Basically, until the reason you collected it runs out, unless some law tells you to hang on to it for longer. Once that purpose is over or the person withdraws consent, it should be deleted. There are two extra rules too. Very large platforms must delete data of users inactive for three years, and log data has to be kept for at least one year.
No, it only covers the big players. That means e-commerce and social media platforms with more than two crore users in India, and online gaming platforms with more than 50 lakh users. Everyone else follows the normal rule. Delete data once its job is done or consent is withdrawn, unless another law, like RBI’s KYC rules, says to keep it.
They can ask, but if a law says you must keep the data, you can say no. The same applies if you still need it for the purpose it was collected for. Keep in mind that deletion isn’t only about requests. Even if nobody asks, the data has to go once consent is pulled or its job is done. And if you do turn someone down, point them to the actual law that’s stopping you.
Honestly, a table does most of the work. List each kind of data you hold, why you’ve got it and how long it stays. Add a column for any law that forces you to keep it longer, a name for whoever deletes it, and a note on how copies in backups and vendor systems get wiped. If a new hire can’t make sense of it in ten minutes, it’s too complicated.
The main rules start on 13 May 2027, and that’s when penalties kick in too. CERT-In’s log retention rules already apply today, so some of this work can’t wait. Use the months you have to map your data, set a retention period for each category and test that deletion actually works, including at your vendors and in your backups.
Yes, if you’re one of the large platforms covered by the three-year inactivity rule. The DPDP Rules say you must warn the person at least 48 hours before erasing their data. The message should tell them their data will be deleted unless they log in or get in touch. Other companies don’t have this exact duty, but a short heads-up is still a kind thing to do.
Yes. When you have to erase data, the Act says your vendors that process it for you must erase it too. That covers their systems, shared folders and any copies you’ve sent out. Backups aren’t exempt either. The easiest fix is to keep backup cycles short so deleted data falls away on its own, and to make sure old backups never bring it back.