Retention, Deletion and Logs: A Defensible DPDP Schedule

Executive summary

Most businesses will feel the Digital Personal Data Protection Act, 2023 (the DPDP Act) in their storage, not their privacy notice. The Act requires a data fiduciary (the business that decides why and how personal data is processed) to erase personal data once consent is withdrawn or the purpose is no longer served, and to make its data processors (vendors processing on its behalf) erase it too. The general escape is retention "necessary for compliance with any law for the time being in force".

That exception does most of the work. Tax, company, anti-money-laundering, securities, insurance, telecom and health laws already fix minimum periods, and the DPDP Rules, 2025 add two one-year floors. The goal is not "delete everything". It is to keep exactly what a law requires, for as long as it requires, and to delete the rest on a timetable you can prove.

This whitepaper covers:

• the statutory triggers for erasure, and the one bright-line period the Rules prescribe;
• a test for what counts as "law", consistent with Trayambic's hospitals study;
• how the one-year log floors in Rules 6 and 8(3) sit with CERT-In's 180 days;
• positions on backups, anonymisation, litigation holds and processor deletion;
• a cross-sector table of retention periods verified in Trayambic's impact studies; and
• a worked inventory for an AI software company, a checklist and a roadmap to 13 May 2027, when the erasure duties commence.

Background

Retention limits are not new. Since 2011, rule 5(4) of the IT Act's rules on sensitive personal data (the SPDI Rules) has said a body corporate "shall not retain that information for longer than is required" for its lawful purposes. Few businesses built deletion around it: it covered only sensitive data, had no regulator and was enforced only through compensation claims. Trayambic's Insight on the SPDI Rules explains what happens to them in May 2027.

The DPDP Act changes three things. The erasure duty covers all digital personal data. It is enforced by the Data Protection Board, with a maximum penalty of ₹50 crore under the Schedule's residual entry; where poor retention is really a security failure, the ₹250 crore maximum for safeguards is in play. And it reaches vendors through the fiduciary.

Over-retention also feeds breach exposure. Every stale record is one more record to notify after an incident, and one more reason to doubt that safeguards were reasonable. Trayambic's breach-notification whitepaper covers notification; this paper deals with what should not be there to lose.

Sections 8, 12 and 17 and Rules 6 and 8 commence on 13 May 2027. CERT-In's Directions and the sector retention laws apply now.

Legal framework

Three routes to erasure (ss.8(7)(a), 12(3)). A fiduciary must erase personal data when the data principal (the individual concerned) withdraws consent, or "as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier". It must also erase on her request under s.12(3). That right runs only against a fiduciary that relied on consent or s.7(a), as Trayambic's data principal rights article explains.

The exception for legal duties (ss.8(7), 12(3), 38). Section 8(7) applies "unless retention is necessary for compliance with any law for the time being in force". Section 12(3) adds retention "necessary for the specified purpose". Section 38 makes the Act additional to other laws and prevailing in a conflict, but because both erasure provisions defer to legally required retention, real conflicts are rare.

Vendors (s.8(7)(b)). The fiduciary must "cause its Data Processor to erase" any personal data it made available to that processor. Under s.8(1) it stays responsible "irrespective of any agreement to the contrary".

Minimum periods (Rules 6 and 8(3); CERT-In). Rule 6, which gives content to the security duty in s.8(5), requires backups for continuity and requires logs and related personal data to be kept for at least one year for detecting and investigating unauthorised access. Rule 8(3) separately requires a fiduciary, for processing done "by it or on its behalf", to keep the personal data, associated traffic data and logs for at least one year from the processing, for the purposes in the Seventh Schedule, and to erase them afterwards unless another law requires longer. Those purposes concern information the Centre may call for under s.36, such as for the security of the State or to assess designation as a Significant Data Fiduciary (SDF). Outside the DPDP framework, CERT-In's Directions, issued under s.70B(6) of the IT Act on 28 April 2022, require service providers, intermediaries, data centres, body corporates and government organisations to keep logs of all ICT systems for a "rolling period of 180 days" within India.

A fixed period for three platform classes (s.8(8); Rule 8; Third Schedule). A purpose is deemed no longer served if the person neither approaches the fiduciary for it nor exercises her rights for a prescribed period. The Rules prescribe one only here:

The period runs from the later of the person's last approach or exercise of rights and the commencement of the Rules. Access to the user account and to virtual tokens, such as wallet balances, is carved out. Rule 8(2) requires at least 48 hours' notice before erasure, and logging in or contacting the fiduciary stops it. On the reading in Trayambic's social media study, no account reaches three years before November 2028.

Exemptions (s.17). Section 17(1) lifts Chapter II, except ss.8(1) and 8(5), where processing is "necessary for enforcing any legal right or claim" (s.17(1)(a)), and for non-residents' data processed in India under a contract with a person abroad (s.17(1)(d)). Section 17(2)(b) covers research, archiving and statistics that inform no decision about an individual and follow the Second Schedule standards, which include a retention limit. No startup exemption under s.17(3) has been notified, and s.12(3) would survive one.

Analysis

What counts as "law"

The Act defines neither "law" nor "erase". In our view, retention is "necessary for compliance with any law" when three conditions hold.

1. 1.The instrument binds the business. Statutes, rules and regulations qualify, as do directions issued under a statutory power, such as RBI's KYC Directions (made under ss.45JA, 45K and 45L of the RBI Act, 1934) and CERT-In's Directions (under s.70B(6)). Court orders also bind.
2. 2.It requires keeping, not merely permits it. A limitation period within which someone may sue is not a duty to retain. That situation belongs under s.17(1)(a), below.
3. 3.The retained set matches the duty. Section 128(5) of the Companies Act, 2013 requires books of account and vouchers for eight financial years. It does not require the customer profile, marketing preferences or support chats behind an invoice.

Guidelines, industry standards, contracts and internal policies do not qualify on their own; they qualify when a law makes them binding. Standards on Auditing are the clearest case: s.143(9) of the Companies Act requires auditors to comply with them, so SA 230's seven-year period for audit files is, in our view, a legal requirement, as Trayambic's CA and tax study explains.

The Electronic Health Record Standards, 2016 are the hard case. Trayambic's hospitals study noted that they recommend preserving records during the patient's lifetime, that rule 9(iv) of the Clinical Establishments (Central Government) Rules, 2012 ties registered establishments to record formats the government determines, and that whether the lifetime recommendation is "law" is unsettled. We keep that position. In our view the Standards alone are guidance; an establishment bound by rule 9(iv) has a reasonable but untested argument. A provider relying on them should record that basis, restrict access to older records, and apply it only to clinical records, never to call recordings, campaign lists or CCTV.

Two more points. Some laws set ceilings, not floors: RBI's Credit Information Companies Directions, 2025 let "non-specified users" (businesses outside the lenders and others RBI names) keep a credit report for at most six months without fresh consent, and RBI's tokenisation circulars bar merchants from storing card data. And where several laws reach one record, keep it for the longest period, but only the fields each law names.

When does a purpose end?

Outside the Third Schedule, nobody prescribes when a purpose ends. Section 8(7)(a) asks when it is "reasonable to assume" so. In our view a period that will stand up to questioning has three parts: a trigger event (order delivered, account closed, contract ended, last login), a buffer tied to a real need (refunds, chargebacks, warranty), and a written reason. For a one-off purchase relied on under s.7(a), the purpose ends when delivery, returns and refunds are complete. The Third Schedule's three years is a sensible benchmark for dormant consumer accounts, but it is a ceiling for three classes, not a safe harbour for everyone else.

Logs: three rules, one policy

Rule 6 asks for one year of logs for security; Rule 8(3) asks for one year of processing records for State purposes; CERT-In asks for 180 days in India. One policy meets all three: keep security and processing logs for at least twelve months, hold at least the most recent 180 days in India, restrict access to security and legal staff, and erase at the end.

Rule 8(3) needs care. Read literally, it reaches the personal data itself, not just the logs. A person who withdraws consent a week after signing up therefore cannot have every trace erased at once. In our view a rule made under the Act is "law" for s.8(7), so the fiduciary should stop all use for the original purpose, move the Rule 8(3) set to a restricted store, use it for nothing else, and erase it when the year ends. Because the rule covers processing "on its behalf", the fiduciary must also decide whether each processor keeps that set or hands it over.

Backups and archives

Rule 6 demands backups and s.8(7) demands erasure, with no carve-out for copies. Restoring every backup to remove one person is impractical, so the two have to be reconciled by design. In our view the key control is a deletion ledger: a record of every erasure, re-applied automatically before restored data re-enters any live system. Around it, the backup's own life should be short and fixed, so that erased records disappear when the copy expires, and backups should serve recovery only, never analytics or model training. Where each customer's data sits under its own encryption key, destroying the key at contract end erases the tenant everywhere at once. Books of account need their own regime: the Companies (Accounts) Rules, 2014 require a daily back-up on servers in India, and s.128(5) keeps the books for eight years.

An archive is not a backup. It is a separate store for records a law requires, holding only the required fields, with its own access log. Calling a commercial data warehouse an "archive" does not bring it within s.17(2)(b), which needs research, archiving or statistical purposes, no decisions about individuals and compliance with the Second Schedule standards.

Anonymisation instead of erasure

Personal data is data about an individual "who is identifiable by or in relation to such data" (s.2(t)). Data that identifies no one is outside the Act. Trayambic's AI training article sets the practical test: if records can be re-linked using information the business holds or could readily obtain, they are not anonymous. Hashing, masking and tokens are security measures under Rule 6, not anonymisation, as our ad-tech study explains.

In our view, irreversible anonymisation achieves what s.8(7) protects, and can replace erasure for statistics or model evaluation. It should be tested before reliance, documented, and repeated when new datasets could make re-linking easier. Where a person has asked for erasure under s.12(3), say in the reply that her records were anonymised and how.

Litigation holds under s.17(1)(a)

Section 17(1)(a) disapplies s.8(7) and s.12 for processing "necessary for enforcing any legal right or claim". Trayambic's earlier studies read it narrowly: it covers papers needed for a live or reasonably anticipated dispute, but not keeping every record in case someone sues. We treat a hold as a matter, not a status. Open it on a trigger (a legal notice, a complaint, a regulator's inquiry, a credible threat), scope it to named people, systems and dates, review it monthly, and release it in writing when the matter ends. Security and accountability still apply, because ss.8(1) and 8(5) survive the exemption.

Some statutes build holds in. Section 36 of the CGST Act extends retention while an appeal or proceeding is pending; the PCPNDT Act's s.29 keeps records until proceedings end; s.128(5) of the Companies Act lets the Centre direct longer retention during an investigation.

Processors: deletion down the chain

Section 8(7)(b) puts the processor's deletion on the fiduciary's account. The contract, which Rule 6 requires to carry security provisions, should therefore fix:

• deletion or return at contract end and on instruction, with a time limit;
• the processor's own legal retention (its tax records, its CERT-In logs), listed and limited;
• who holds the Rule 8(3) one-year set;
• flow-down to sub-processors, and backups covered by rotation;
• a deletion certificate naming systems, date and method.

No law requires a certificate, but it is the fiduciary's evidence if the Board asks. CERT-In's audit policy guidelines of July 2025 already expect auditee data to be wiped with a certificate, a useful model.

Cross-sector retention table

The minimum periods below were verified against primary sources in Trayambic's impact studies. A period is a floor unless stated, and it covers only the records the provision names.

Worked example: an AI document-intelligence company

All figures are illustrative.

A 180-person Bengaluru company sells a platform that reads loan files and insurance claim papers for Indian lenders and insurers, and a self-serve tier used by about 9,000 chartered accountants. It hosts in an Indian cloud region. After its legal map, its inventory reads:

Three decisions took the most time.

• The one-year set against 30-day deletion. Its lenders and insurers are fiduciaries and must keep a year of processing records under Rule 8(3). The company's agreement now lets each client choose: the client exports the set weekly, or the company keeps it in a restricted store for a year. Documents themselves still go at 30 days unless the client asks otherwise.
• Training. It does not train on client documents. Evaluation sets come only from clients who opt in, with names, PAN, account numbers, addresses and signatures removed and a re-linking test run against its own client data. Trayambic's startup budget whitepaper covers the contract terms.
• A hold. One insurer disputed a quarter's invoices. Legal opened a hold under s.17(1)(a) on that quarter's job logs and billing records only. The documents were deleted on schedule because the dispute concerned volumes, not content. The hold was closed when the settlement was signed.

Compliance framework

Roadmap to 13 May 2027

1. 1.Now to December 2026. Inventory, roles and a first legal map. Freeze new long-retention uses.
2. 2.January to March 2027. Legal sign-off; log policy, backup ledger, hold procedure and anonymisation standard built and tested.
3. 3.April to 13 May 2027. Processor amendments signed; deletion jobs dry-run, then switched on; erasure workflow tested end to end.
4. 4.After 13 May 2027. First purge cycle with evidence; quarterly review of holds; annual review of the schedule.

Recommendations

1. 1.Start from laws, not systems. Every long period should cite a provision, and legal should sign off what counts as "law".
2. 2.Keep the record the law names, not the account around it. Move long-retained fields into a minimal store.
3. 3.Run one log policy that satisfies Rule 6, Rule 8(3) and CERT-In, and decide who holds the one-year set for each processor.
4. 4.Make deletion provable: job logs, a backup ledger and processor certificates.
5. 5.Treat each litigation hold as a matter with an owner, a scope and an end date.
6. 6.Anonymise only after testing; otherwise erase.
7. 7.Re-run the schedule whenever a law changes, starting with the SPDI Rules in May 2027.

Key takeaways

• Erase personal data when consent is withdrawn or the purpose ends; the main exception is retention a binding law requires, and only the fields it names.
• In our view 'law' means statutes, rules, regulations, statutory directions and court orders; guidelines and standards count only when a law makes them binding, and the EHR Standards' lifetime recommendation remains unsettled.
• Rule 6, Rule 8(3) and CERT-In can be met by one policy: twelve months of logs, at least 180 days in India, restricted access.
• Backups, anonymisation, litigation holds and processor deletion each need a written method; the Act says little about how any of them should work.
• Only large e-commerce, gaming and social media platforms get a prescribed inactivity period; everyone else must set and justify their own.