Chapter 14 — Retention, Deletion, Backups and Legal Holds

1. The data that refuses to leave

There is a quiet asymmetry at the heart of every data-driven enterprise: collecting personal data is easy, but forgetting it is hard. Systems accumulate copies — production databases, backups, caches, logs, analytics stores, derived models, an archive server in a corner that nobody remembers is still holding customer records. The law that governs this material has a stern counterweight to all that accumulation: personal data is not yours to keep indefinitely. When the purpose for which it was collected has been served, and no lawful basis for keeping it remains, DPDP requires that data to be erased — and it extends that erasure obligation across the entire estate, including the copies that were made and given to others.

The engineering reality behind the legal rule deserves a moment of respect, because it is why this chapter exists as an engineering chapter rather than a paragraph in a policy manual. In a real estate, “delete the customer” touches a dozen systems owned by a dozen teams, some of which receive the customer’s data indirectly (the marketing automation platform that got the email from the CRM sync, the feature store that derived the propensity score from the order history). Each hop is a place the deletion can silently stop. The recommended engineering response is a deletion journal, propagation acknowledgements and restore tests. These artifacts help demonstrate execution; the Act does not prescribe these named mechanisms. The chapter’s machinery is built around distinguishing a legal decision from an attempted operation and from verified disposal.

This chapter is about that erasure control plane, and it begins with an idea the whole book depends on:

The idea. Use a trigger-and-authority decision, not one universal minimum/maximum pair. Purpose completion or withdrawal triggers assessment; applicable retention duties can require restricted holding, but do not restore the withdrawn commercial purpose. Disposal eligibility and successful physical disposal are separate states. ACT:351–375; RULES:1153–1166.[1][5]

2. The statutory frame, read carefully

2.1 The erasure duty (Section 8(7)(a))

A Data Fiduciary must, unless retention is necessary for compliance with any law, erase personal data:

• upon the Data Principal withdrawing her consent, or
• as soon as it is reasonable to assume the specified purpose is no longer being served, whichever is earlier.

The “whichever is earlier” is the key phrase: the earlier of withdrawal or purpose-completion triggers the analysis. And the carve-out for lawful retention is narrow and specific — it is “necessary for compliance with any law,” not “we’d rather keep it.” Note what the duty is not: it is not “erase when the principal asks” (that is Section 12(3), §2.4) and it is not “erase when a retention policy expires” (that is the schedule’s operationalisation of this duty). Section 8(7)(a) is the automatic erasure duty — it runs on the fiduciary’s own trigger, with or without any principal action.

The trigger’s timing is where the engineering weight sits. “As soon as it is reasonable to assume” is not a licence for indolence; it is a reasonableness standard that the retention schedule must pre-compute. For each dataset, the schedule states when purpose-completion is deemed to occur (the Section 8(8)/Rule 8 mechanism below supplies a prescribed rule for covered classes and purposes), and the planner assesses disposal on that event against the scoped retention duties, rather than presuming every event causes immediate physical erasure. The un-scheduled version — “we’ll judge reasonableness case by case” — is the failure mode this chapter’s design exists to prevent, because an unowned queue can miss relevant events. A schedule should support exceptions and review, not pretend every judgment is reducible to a date.

2.2 The processor copy (Section 8(7)(b))

And the fiduciary must cause its Data Processor to erase any personal data that was made available to the processor. This is the clause that ties erasure to the processor-control chapter (Ch.17) — erasure does not stop at the fiduciary’s own database; it must propagate to the processor’s copy too, with evidence.

The word “cause” deserves the engineer’s attention: the duty is not merely to request the processor’s erasure but to make it happen and to hold the evidence. In practice this means the recommended Chapter 17 contract operationalises erasure with a scoped acknowledgement artifact — and the recommended receipt records whether processor evidence has arrived and what it actually establishes. An acknowledgement alone does not prove complete physical erasure. A processor that does not acknowledge is a Chapter 17 escalation (the non-ack flow), not a footnote.

2.3 Three separate clocks in Rule 8

The Third Schedule is not a payment-versus-edtech table. It covers e-commerce entities with at least two crore registered users in India, online gaming intermediaries with at least fifty lakh, and social-media intermediaries with at least two crore. Each row uses three years and excludes enabling access to the user account and the specified virtual-token access purpose. The anchor is the principal’s last approach for the specified purpose or exercise of rights, or commencement of the Rules, whichever is latest. The definitions and the specific purpose exclusions must be read with the threshold, not after classification. RULES:1598–1680.[5]

Rule 8(2) requires informing the principal at least forty-eight hours before completion of the period for erasure under the rule: erasure follows unless she logs in, initiates the relevant contact or exercises relevant rights. Capture warning preparation and delivery separately, and do not treat an unrelated background system job as the principal approaching the fiduciary. ACT:369–385; RULES:1142–1152.[1][5]

The staggered Rules commencement makes the Third Schedule anchor an interpretation question (QL-002), not a missing period. The three-year computation is a deemed-purpose clock, not permission to keep data until that date despite an earlier purpose-end/withdrawal or the separate Rule 8(3) disposal analysis. RETENTION-001’s marketplace counterfactual computes the clock and warning only, not a final lawful-retention date. This teaching design provisionally uses the core effective date, 2027-05-13, and records that choice. An actual eligible entity needs a reviewed anchor and transition rule before its scheduler disposes of data. The Company is an NBFC, not one of those classes by assumption, and its customer volume establishes neither that classification nor SDF designation. An edtech cohort cannot inherit a statutory three-year clock solely because it has learner accounts.

Rule 8(3) is distinct and not limited to those thresholds. For any processing by the fiduciary or on its behalf, it requires the personal data, associated traffic data and other processing logs to be retained for a minimum of one year from the date of such processing for Seventh Schedule purposes, followed by erasure unless further retention is required by other law or notified by Government. The e-book illustration requires retention even after account deletion; the cloud illustration requires the fiduciary to ensure its processor also retains the data and associated logs. RULES:1153–1166.[5]

The Seventh Schedule concerns specified State-use and SDF-assessment purposes and authorised persons; it is neither a nomination schedule nor authority for a renewed marketing campaign. Rule 6(1)(e) separately requires one-year retention of such logs and personal data for detection, investigation, remediation and continuity, unless law requires otherwise. Model these as PUR-009 and PUR-008 respectively, even where a controlled repository safely serves both approved scopes. RULES:1101–1106,1894–1921.[5]

The minimum does not justify collecting unnecessary fields initially or keeping every duplicate forever. Nor does a convenient “minimised archive” label establish that destroying a particular processor copy before the minimum is lawful. QL-001 leaves the copy, ongoing-storage and reset interpretation explicit: record class, processing-event history, necessary copies, retained fields, permitted use and disposal review. Do not invent an endless reset on every storage tick, or promise a definitive erasure date without resolving the interaction. The specimens conservatively preserve required material in restricted stores and remove marketing access without claiming physical deletion during the minimum.

2.4 Erasure on a principal’s request (Section 12(3))

On a request for erasure, the fiduciary shall erase unless retention is necessary for the specified purpose or for compliance with any law. This is the rights-service companion to the auto-erasure duty: the request has its own specified-purpose or law exception. It cannot be used to resurrect consent already withdrawn; read Section 6(6), Section 8(7) and the Rules together. ACT:245–249,351–359,473–476.[1]

The illustration the Act itself gives is instructive. A bank that must, under banking law, maintain identity records for a fixed period beyond account closure is required to keep them for that period — lawful retention — but it does not keep them forever, and it does not keep the data whose purpose is genuinely served on the excuse that it once was a customer’s.

A recommended partial response explains which class is retained, its authority, permitted use, owner and next review; it does not replace the real law with “[banking law]”. Chapter 12 owns the communication case. Here DEC-006 links RIGHTS-001 to RETENTION-001: the response can close after its components are addressed while the independent retention/disposal obligation remains tracked. A refusal is not evidence of physical retention correctness, and a promised future review is not a deletion receipt.

3. The tension: hoarding versus premature deletion

Retention design has to resist two opposing instincts.

The hoarding instinct. “Keep everything, just in case” — the belief that the safest posture is never to delete. The audit-flagged version of this is the myth that “strictest means longest” — that the most defensible retention is the maximum of all applicable periods. This is wrong twice over: it conflicts with the minimization and erasure the Act requires (Section 8(7)), and it maximizes exposure — the more data an organisation holds, the more it stands to lose in a breach (Chapter 16) and the more of it is outside any lawful basis for keeping it.

The premature-deletion instinct. Erase at the earliest possible moment — the mirror image. Deleting a scoped identity or transaction record during an actually applicable statutory period, because “we must minimize,” destroys a record the entity is legally obliged to hold. That is not compliance; it is a different failure — and in the sectors with statutory retention duties, the error can matter under that sector regime independently of DPDP.

The reconciliation is an explicit decision tree. A cessation decision removes the relevant use permission; a retention decision determines whether the material must still exist; a disposal planner determines the targets and evidence required. Combining all three into a “delete by” date hides the reason a retained row cannot be marketed and the reason a no-longer-marketed row may not yet be destroyed.

4. The populated retention decision

retention-decisions.json carries RETENTION-001 and the following recommended decision order. Every date is a hypothetical event or calculated review date, not a universal sector period.

1. Identify the subject, data class, purpose, system, processor and relevant processing events. Determine scope/exemptions first; do not propagate an exemption from one activity to the entire customer row.
2. Select the earlier relevant withdrawal/purpose-end event for the automatic Section 8(7) assessment, or record the separate Section 12 request. Apply qualified cessation under Section 6(6), without rejecting withdrawal. ACT:245–249,351–359,473–476.[1]
3. Determine Rule 8(1) class/threshold/purpose eligibility and any warning/clock independently. Record not_applicable with facts for the Company, not period_unknown.
4. Resolve Rule 8(3), Rule 6(1)(e), other-law duties and a scoped hold. Separate facts already established from counsel questions. Unknown authority is not an indefinite retention licence or automatic permission to delete.
5. Return a permitted-use decision and target status. When expiry becomes eligible, issue idempotent commands; complete only targets actually evidenced. Recalculate on hold release or a genuinely relevant new processing event.

HOLD-001’s specimen is not an invented court order. It assumes a documented dispute over one loan transaction and a necessity assessment for enforcing that claim under Section 17(1)(a). That exemption removes Chapter II except Section 8(1)/(5), Chapter III and Section 16 for qualifying processing; it is not a generic statutory minimum or authority to retain the whole marketing profile. The hold record flags real counsel approval and sector instrument mapping as unavailable and blocks treating the teaching record as a production instruction. ACT:523–526.[1]

Hold administration is an author recommendation: Legal requests scope, the custodian identifies exact records, a distinct reviewer checks necessity, and the scheduler records next review and release approval. On a synthetic release after ordinary eligibility, DS-002 returns to the disposal assessment; expiry is not restarted merely because a hold existed. If ordinary minima or another valid basis remain, keep the relevant restricted class. If not, queue deletion and track any failed target. A “hold released” event is neither a grant to use the data nor proof it is gone.

The bank illustration in Section 8(7) stipulates ten years; it does not establish a current universal RBI period. Identification, transaction, tax and marketing data require distinct sector mappings and starting events. No banking/PMI placeholder or remembered eight/ten-year number is supplied as operative law here. ACT:365–368.[1]

5. Erasure as a control plane, not a statement

“Deletion” in DPDP is not a DELETE FROM statement against the primary database. It is a control plane that must reach every copy:

• the source of record — the system of truth;
• processors — cause the processor to erase and collect the acknowledgement (Section 8(7)(b); Chapter 17);
• system copies — caches, indexes, logs that contain personal data;
• derived material — identifiable features, embeddings and outputs; model weights require a separate identifiability and feasible-remediation assessment, not an assumed per-person delete operation (QL-009; Chapter 21);
• backups — the classic leak, addressed below;
• a deletion receipt — a record of what was erased, when, and by whom;
• external residuals — identify the recipient, role, attempts and restriction/remediation options; inability to recall a disclosure is a recorded limit, not relief from duties. Escalate suspected breaches and do not call an external copy erased merely because a request was sent.

The deletion receipt is the evidence that moves this from a statement to a control (Chapter 22): it is the artifact an audit or inquiry can inspect.

The architecture of the plane deserves one more observation: it is idempotent and replayable. A deletion that half-completes (the primary store clean, the feature store timed out) must be resumable without re-running the completed steps, and the receipt’s per-store status is what makes it so. The plane is therefore less like a DELETE and more like a durable workflow with per-target journaling than an atomic distributed transaction. It cannot roll back an irreversible erasure. Use stable operation IDs, authenticated callbacks, duplicate detection and explicit uncertain results; a new retry key must not hide an unresolved old operation.

6. Backups, failed replicas and restoration barriers

A backup creates a temporal problem: the snapshot may be lawful when captured, yet contain authority that has since been withdrawn or data later eligible for erasure. Restoring it directly into production would restore both bytes and obsolete permissions. Neither “backups cannot be deleted” nor “all backups were scrubbed” is a safe universal statement. Service/version/lock mechanics differ. The architecture specifies target enumeration and quarantine; actual cloud-adapter behaviour is not tested in this packet.

The journal uses restricted_retention, blocked_by_hold, failed, deferred_backup_expiry, completed_verified and unknown. A successful API response or a metadata tombstone is not physical erasure. A failed replica stays failed even when the primary query returns no row; a missing processor acknowledgement remains missing. If an immutable cohort must age out, record cohort, locks, retained fields, reason, owner, expiry mechanism and evidence due. Deferred expiry is an operational residual, not an exemption from an applicable legal deadline. If that residual is unacceptable, restrict the service and change the storage design rather than certify it away.

RESTORE-001 follows the Q01 chronology: SNAP-001 precedes WITHDRAW-001; restoration follows both. Load into SYS-014 with production identities and egress denied. Fetch the current authority ledger and the complete post-snapshot restriction/tombstone frontier, including events received after capture. Replay withdrawals before marketing access; replay eligible erasures and hold decisions before releasing any material. Required retained data remains restricted, even where it cannot yet be physically erased. Record the frontier and integrity check; if the ledger is unavailable or ordering is uncertain, quarantine remains latched.

The old test looked only for receipts predating the snapshot. The central test must instead exercise snapshot first, withdrawal/deletion second, restore third. The local fixture results compare a deliberately unsafe restore branch with the restricted replay branch. They inspect a toy in-memory dataset, not a cloud snapshot or production backup. A second branch models already-eligible erasure after a stipulated minimum review, a failed replica, and deferred backup expiry. No branch is labelled proof of physical media sanitisation.

The production acceptance specification adds checks this fixture cannot perform: enumerate snapshot versions and cross-region replicas; reconcile the inventory against actual provider listings; verify deletion permissions and locks; collect provider attestations with their scope; query restored search/index/cache paths; and attempt access through administrative and break-glass routes. A cryptographic key’s deletion is relevant only after all usable key copies, wrapped keys and alternate plaintext paths have been assessed. The chapter does not recommend it as a generic erasure shortcut.

7. Counterexamples that expose a bad schedule

Purpose ends first: a synthetic marketing projection’s purpose ends on 2027-06-01 and consent is withdrawn on 2027-06-02. The assessment trigger is the former, not a minimum defined by the latter. The one-year layer still needs its own processing-date analysis. This counterexample demonstrates why the replaced min/max row could contradict itself.

Withdrawal during the minimum: SUB-001’s withdrawal immediately blocks the Company’s recommended marketing gate, while required restricted records remain. The SYS-003 acknowledgement target at 10:05 is missed. The aggregate result is partial/unresolved, not “cessation complete” or “erased”; procurement owns escalation in Chapter 17 and the rights service communicates the actual limit in Chapter 12.

A non-covered educational app: a learning subscription expires, but no facts establish a qualifying Third Schedule class and threshold. The record is not_applicable for that prescribed class clock, while ordinary purpose-end assessment and the one-year layer remain relevant. An internal non-use review may be useful, but it must not be labelled a statutory edtech period.

Release of a narrow hold: after the stipulated normal eligibility review, Legal releases the DS-002 claim hold. The planner checks remaining bases, commands the eligible target, and records a replica timeout. The release must not extend to unrelated DS-003, and a failed replica must not be relabelled complete to close a case. The synthetic journal preserves that failure; the separate cache/restore retests do not clear the failed replica.

These are populated in RETENTION-001 with owner, source IDs, exception facts, processing date, warning applicability, permitted uses, hold state and review status. Their value is not that each succeeds: it is that an operator can tell why a target remains restricted, what evidence is missing and who must act.

8. Acceptance and remaining boundaries

Chapter 10 owns withdrawal acceptance and orchestration; this chapter owns storage/disposal/restore; Chapter 17 owns contractual propagation; Chapter 12 owns the response case. Keep their shared event/subject/purpose identities, but do not make one team’s ticket closure the other’s completion condition. EVT-025 is explicitly a disposal eligibility review on 2028-06-03, not a promise that every minimum has expired.

QL-001 and QL-002 remain interpretation/application questions requiring real deployment advice. Sector record periods, actual legal-claim necessity, vendor disposal mechanics and model identifiability remain explicitly unproved, with safe restriction or no-go rather than fabricated dates. The known one-year, three-year and forty-eight-hour provisions are no longer deferred to an unread Gazette. A real implementation must settle the open authority/adapter questions and test all supported targets before claiming complete erasure.

For the reader exercise, add a late processing event to a retained class and an unavailable ledger to the restore scenario. Explain which review date needs reassessment and why production access still cannot open. Then release the hold with one failed replica outstanding. An answer that returns a single green customer-level “deleted” flag has lost the mechanism this chapter is meant to teach.

The question that hands the book its next chapter

Because erasure and lawful retention require scoped decisions rather than a single customer-level flag, the organisation must also be able to protect the data it is legitimately holding — encryption, access control, and safeguards — so that the data it is entitled to keep is not leaked or mishandled. That is the subject of Chapter 15, Security Safeguards and Access Control — Section 8(4)/(5) and Rule 6, the technical and organisational controls that underpin the whole retention-and-erasure discipline.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index