Storage Limitation
Keeping personal data only for as long as it is needed.
Storage limitation means you keep personal data only while you still need it for the purpose you collected it for. Once the need is over, the data should be erased unless a law says you must keep it.
Meaning of Storage Limitation
The Act requires erasure when consent is withdrawn or the specified purpose is no longer served, unless the law requires retention. Rule 8 adds a three-year retention rule for certain large classes of fiduciary and a one-year minimum for logs.
The Act expresses storage limitation mainly in Section 8(7). Unless retention is necessary for compliance with a law, a Data Fiduciary must erase personal data when the Data Principal withdraws consent or when the specified purpose is no longer being served, whichever is earlier, and must make its Data Processor erase any data it was given. The duty is automatic: no request from the person is needed. This is different from the Section 12 right to erasure, which a person triggers by asking.
Section 8(8) and Section 8(11) tell you how to decide that a purpose has lapsed. The purpose is treated as no longer served if the Data Principal has not approached the Fiduciary for the service and has not exercised any rights for a prescribed period, and that period may differ by class of Fiduciary and purpose. Rule 8 and the Third Schedule apply this to specified classes, including large e-commerce, online gaming and social media intermediaries above stated user thresholds: personal data is to be erased after three years from the person's last interaction, with a warning at least 48 hours beforehand.
The same rule carries an important counterweight. Rule 8 also requires that certain logs and traffic data be retained for at least one year, and Rule 6 pairs this with the security-log expectation. Other laws point the same way: tax and accounting law requires invoices to be kept, RBI and SEBI rules set record periods for KYC and trading data, and the CERT-In directions require logs to be kept in India for 180 days. Storage limitation therefore does not mean "delete quickly"; it means "keep only what is justified, for as long as it is justified".
Edge cases are common. Backups cannot always be edited record by record, so a sound approach is to put erased data beyond use and let it expire on the normal backup cycle. Data that has been truly anonymised, so that no person can be identified, is outside the Act. Pseudonymised data is still personal data. Research, archiving and statistical use may qualify for an exemption under Section 17(2) if the data is not used for decisions about a specific person and the prescribed standards are met.
Examples of Storage Limitation
A retailer deletes data of customers inactive for several years, after warning them.
A shopping platform that crosses the Third Schedule threshold tracks the last time each customer logged in or bought something. At two years and eleven months of inactivity it sends a warning, and 48 hours before the third anniversary it deletes profiles that remain inactive, keeping only invoices that tax law requires.
A company interviews 400 candidates for a hiring round. It keeps selected candidates' files as part of employment records but deletes the rest six months after the round closes, with a short line in the careers notice explaining that period.
A payments app keeps transaction records for the period set by its regulator but deletes marketing preferences, device fingerprints used only for onboarding and unused referral data after the purpose ends, and it records the logic in its retention schedule.
Why Storage Limitation matters
Old data is liability. Every extra year of stored records raises the amount exposed in a breach, and a breach of reasonable security safeguards can attract a penalty of up to ₹250 crore under the Schedule. A company that deleted inactive accounts after the stated period has less to notify, less to defend and less to lose.
Failing to erase is also a standalone breach of Section 8(7), which falls under the general head of up to ₹50 crore. Beyond penalties, over-retention makes rights requests harder, because the more systems hold a person's data, the harder it is to find and fix. Storage cost, discovery cost in disputes and operational clutter add to the bill.
How it works in practice
- 1Build a retention schedule that lists each record type, the shortest justified period, the law or business need behind it and the owner. Keep it short enough that people actually use it.
- 2Define the trigger event for every period, for example account closure, last login, end of employment or end of the loan. A period with no start point cannot be enforced.
- 3Automate deletion where you can, using database jobs, object-storage lifecycle rules and CRM purge routines, and keep a log of each run as evidence of compliance.
- 4For classes covered by the Third Schedule, build the inactivity tracker and the 48-hour warning message (email, SMS or in-app) and confirm that the person gets a chance to log in or ask for the data to be kept.
- 5Extend the schedule to processors, backups, test environments, email archives and shared drives, which are the places where forgotten copies usually live.
- 6Suspend deletion for records under a legal hold, document why, and resume once the hold lifts.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Keeping everything "in case we need it later". A vague future need is not a purpose, so decide a period and review it.
Deleting production records but leaving copies elsewhere. Analytics warehouses, email exports and vendor systems also count. Erasure must reach every copy you control or cause to be processed.
Treating the three-year rule in Rule 8 as a general standard for all businesses. It applies to specified classes; others need to set periods from purpose and law.
Deleting security logs to save space. This can conflict with the one-year minimum and with sectoral or CERT-In requirements.
Compliance tips
Treat the retention schedule as a living document and review it yearly, or when a new product or law changes the picture.
Ask legal and finance to confirm which statutory retention periods apply before you set a delete date, so you do not delete records you must keep.
Pseudonymise or anonymise data that you want for long-term trends, and test that re-identification is not reasonably possible.
Keep a deletion certificate or log from vendors, since your responsibility for their processing does not end with the contract.
Common questions about Storage Limitation
Is storage limitation required by the DPDP Act?
Yes. Section 8(7) obliges a Data Fiduciary to erase personal data once consent is withdrawn or the specified purpose is no longer served, unless the law requires retention. Rule 8 adds specific periods and warnings for certain classes of platforms.
How long can I keep customer data under DPDP?
The Act does not set one period for everyone. You may keep data while the purpose continues, or for as long as a law requires. Rule 8 sets a three-year inactivity limit for specified classes. Otherwise, set a reasonable period and be ready to justify it.
Do I have to delete backups immediately?
Not necessarily at the same moment. The practical approach is to restore no erased data, restrict backup access and let backups expire on a short, documented cycle. Check what your vendors and regulators expect and record your reasoning.
What is the difference between storage limitation and the right to erasure?
Storage limitation is your standing duty to delete when the purpose ends. The right to erasure under Section 12 is a person's request that you act now. Both end in deletion, but one is automatic and the other is triggered by the individual.