Rule 8(3) of the Digital Personal Data Protection Rules, 2025 requires a Data Fiduciary to retain personal data, associated traffic data and processing logs for a minimum of one year — even where the individual has deleted their account. Section 12 of the Act separately gives a right to erasure. A system that satisfies an erasure request by hard-deleting the record breaches the retention obligation while satisfying the erasure right.
That is not a technicality. It is the difference between a system that produces defensible evidence and one that destroys it.
What does the DPDP Act say about erasure?
There are two erasure obligations, and they work differently.
Erasure on request — section 12. A Data Principal is entitled to erasure of personal data for the processing of which they previously gave consent. On receiving the request you must erase — unless retention is necessary for the specified purpose or for compliance with any law in force.
Erasure on purpose completion — section 8(7). Independently of any request, you must erase personal data on withdrawal of consent, or as soon as it is reasonable to assume the specified purpose is no longer being served, whichever is earlier. You must also cause your Data Processor to erase.
Section 8(7) is the one almost nobody has planned for, because it needs no trigger from the individual. It requires you to notice, unprompted, that a purpose has been served.
What is the minimum retention period under the DPDP Rules?
One year. Rule 8(3) requires a Data Fiduciary to retain — in respect of any processing undertaken by it or on its behalf by a Data Processor — the personal data, associated traffic data and other logs of the processing, for a minimum of one year from the date of processing, for the purposes in the Seventh Schedule. Only after that may it erase, and only if no other law requires longer.
The Rules illustrate this directly, and the illustration settles the argument:
A person buys an e-book on a platform. Delivery completes, so the specified purpose is served. The platform must nonetheless retain the order details, personal data and processing logs — order confirmation, payment, delivery events — for at least a year from the transaction, even if the customer deletes their account.
A second illustration extends it down the chain: a company using a cloud provider as its Data Processor must ensure the provider also retains the data and logs for at least a year.
So account deletion cannot mean data deletion. And your processor's deletion policy is now your compliance problem.
Where the two obligations collide
| Scenario | Erasure says | Retention says | Correct action |
|---|---|---|---|
| Customer deletes account 2 months after a purchase | s. 12 / 8(7): erase | Rule 8(3): retain 1 year | Suppress from active processing; retain the transaction record and logs; document why |
| Customer asks a bank to erase KYC data | s. 12: erase | RBI and PMLA mandates apply | Refuse for the mandated data; explain the basis; erase everything outside it |
| Marketing consent withdrawn | s. 6(4) / 8(7): cease and erase | Nothing mandates keeping a marketing profile | Erase the profile; keep a suppression record, or you will contact them again |
| Dormant e-commerce account, 3 years inactive, wallet balance present | Rule 8(1): erase | Third Schedule carve-out for virtual tokens | Erase for other purposes; preserve account access and the token |
| Employee leaves | s. 8(7): purpose served | Employment and tax retention periods | Retain per mandate; restrict access; erase discretionary data |
The pattern in every row is the same. Erasure is purpose-scoped, not record-scoped. The correct unit is "this data, for this purpose" — never "this person's row."
The suppression record trap
The marketing-consent row above conceals the mistake that catches sophisticated teams. If someone withdraws marketing consent and you erase the record completely, you have destroyed the only evidence they opted out. The next time their email arrives through an import, a partner list or a re-engagement campaign, you will contact them again — with no record of why you shouldn't have.
The answer is a suppression record: the minimum data needed to honour the withdrawal — a hashed identifier and the withdrawal date — retained for that purpose alone, never enriched, never used for anything else. It looks like retention and functions as erasure.
Getting this wrong in either direction is a breach. Over-retain and you have kept a marketing profile you were told to delete. Under-retain and you will re-contact someone who withdrew.
Which Indian laws override the erasure right?
Section 12 defers expressly to other law, and Indian regulation is dense with retention mandates.
| Source | Broadly requires retention of |
|---|---|
| RBI Master Directions on KYC | Customer identification and transaction records |
| Prevention of Money-Laundering Act and rules | Client identity and transaction records |
| Income-tax Act and rules | Books of account and supporting documents |
| Companies Act, 2013 | Books of account and statutory registers |
| IRDAI regulations | Policyholder, proposal and claims records |
| SEBI regulations | Client and transaction records for intermediaries |
| TRAI and telecom licence conditions | Subscriber verification and call detail records |
Periods vary by instrument and are amended periodically — confirm from the source instrument rather than a summary, and take advice where two instruments conflict.
Retention conflicts don't resolve themselves
Consiva's retention module flags a conflicting mandate at the point of an erasure request, holds each rule with its source instrument, and writes the closure record automatically.
Start Free on Consiva.ai — No Credit Card →What a compliant erasure actually does
Six steps. Fewer than six is not erasure.
- Resolve the request to purposes, not records. Some purposes will be erasable; others will not.
- Check every retention mandate in scope — statutory retention, the Rule 8(3) one-year floor, and any live legal claim.
- Erase what is clear. Delete data for purposes with no retention basis.
- Suppress and restrict what must be retained. Retained data must leave active processing for the erased purposes. Retention is not permission to keep using it.
- Cascade to processors. Section 8(7) requires you to cause your Processor to erase; Rule 8(3) requires you to ensure it retains the minimum. Your processor instructions must be able to express "erase this, retain that."
- Produce the artefact. What was requested, what was erased, what was retained, the legal basis, when, by whom.
Step six has direct financial value. Section 33(2) requires the Board to consider mitigation and its timeliness when setting a penalty — a dated closure record is evidence in your favour.
What this means for your systems
Five capabilities, none of which a policy document provides: a retention register mapping category and purpose to a rule and its source; purpose-scoped erasure rather than record deletion; a conflict detector that surfaces a mandate blocking an erasure instead of silently resolving it; scheduled clocks with pre-erasure notification; and artefacts at every step.
Consiva's retention module flags the conflict at the point of request, holds each retention rule with its source instrument, and writes the closure record. Which mandate applies to your business remains your determination — and where a period is contested, that is a question for counsel.
Frequently Asked Questions
One year. Rule 8(3) requires retention of personal data, associated traffic data and processing logs for at least one year from the date of processing, for Seventh Schedule purposes, unless another law requires longer.
Yes, where retention is necessary for the specified purpose or for compliance with any law. Section 12 makes the erasure right expressly subject to that. Data outside any mandate must still be erased, and the refusal should be explained.
Not entirely, and not immediately. The Rules illustrate a platform retaining transaction records and processing logs for at least a year after a customer deletes their account. Data outside a retention mandate should be erased.
Yes, in effect. Rule 8(3) applies to processing undertaken by a Data Processor on the Fiduciary's behalf, and the Rules illustrate it with a cloud provider hosting customer records.
Rule 8 and section 12 commence on 13 May 2027, together with the rest of the substantive obligations and the penalty regime.
Get Retention and Erasure Right — Free
Consiva runs your retention register, flags conflicts before erasure, and writes the closure record automatically. One domain, 1,000 cookie consents a month, no card.