The Retention-vs-Erasure Playbook for DPDP

The question nobody in the room can answer

A customer writes in. She has withdrawn consent and wants her data deleted. The mail lands with the grievance officer, who forwards it to IT, who forwards it to the product owner, who asks legal whether deletion is permitted. Legal asks finance. Finance says keep everything, because the regulator might ask. Nobody has written back to the customer. Three weeks later she gets a holding reply, and the organisation has quietly failed an obligation it believed it had met because it had published a privacy policy.

This is not a legal problem. The law is not especially ambiguous: the Act requires you to stop processing and erase personal data when consent is withdrawn, except where retention is necessary to comply with another law in force. The problem is operational. In almost every organisation we assess, retention is a property of systems rather than of data elements. The loan origination system has a seven-year archive policy. The CRM has a ninety-day purge on closed tickets. The data lake has no policy at all. So when the question is asked about one named person, nobody knows, because the records about her sit in eleven systems whose retention rules were set by eleven people for eleven reasons, none of which was DPDP.

The fix is unglamorous and takes six to ten weeks for a mid-sized firm. Build a register at the level of the data element, attach a governing retention obligation to each element, define what withdrawal triggers for each one, and wire that into a request process with a clock on it. This paper describes the method in enough detail to start on it Monday morning without us.

Why system registers fail and element registers work

Most organisations already have something they call a data inventory. It usually lists systems: core banking, LOS, LMS, CRM, HRMS, the marketing automation tool, three S3 buckets and a BI warehouse. Against each system someone has written a data category ("customer data") and a retention period ("as per policy"). This artefact is useless for answering an erasure request, for three specific reasons.

• One system holds elements governed by completely different obligations. Your core system holds the PAN (governed by anti-money-laundering record rules), the marketing opt-in flag (governed by nothing but consent), and the last-login timestamp (governed by log retention expectations). A single retention period for the system is wrong for at least two of the three.
• The same element exists in several systems with different lifespans. A mobile number lives in the onboarding record, the OTP service, the SMS gateway logs, the collections dialler and two spreadsheets. Deleting it from the system of record does not delete it.
• System registers cannot express the clock. "Seven years" means nothing until you say seven years from what event. From account closure? Last transaction? Financial year end? Different sources start the clock differently, and that difference is the whole of the operational work.

An element register inverts this. The row is a data element; the system is an attribute of the row, and there can be several. It is a larger artefact — a mid-sized NBFC typically lands between 300 and 700 rows — but it is the only shape that answers the question actually asked of you.

Building the data-element register

Build it by walking collection points, not by exporting database schemas. Schema exports give you column names nobody recognises and miss everything collected on paper, over a call or in a chat window. Sit with the owner of each collection point (app onboarding, branch form, call centre, partner API, web forms, HR joining kit) and write down what is actually captured, including fields that exist only because a form template was copied.

These are the columns we use. Fewer and the register cannot answer a request. More and nobody maintains it.

Column	What goes in it	Why it is load-bearing
Element ID	Stable short code, e.g. CUST-ID-PAN	Lets policies, tickets and DPIAs reference an element without re-describing it
Element name	PAN number, not "tax identifier"	Front-line staff must recognise it or they will not maintain the row
Category	Identity, financial, contact, behavioural, biometric, health, children's data	Drives risk tiering and whether extra duties apply
Collection point(s)	Each channel where it enters	This is where notice and consent capture must be fixed
Stated purpose(s)	In the words used in the notice the person saw	Any processing beyond this is the gap that gets found
Lawful basis	Consent, or the specific legitimate use relied on	Determines whether withdrawal is even relevant to this element
System of record	The one authoritative store	Target for correction and for the erasure action
Downstream copies	Replicas, warehouses, logs, vendor systems, exports	The reason "we deleted it" is usually untrue
Retention obligation	Mandatory, discretionary, or none	Only "mandatory" survives a withdrawal
Source of obligation	Named instrument and the person who confirmed the reading	"Legal said so" is not evidence; a named source with a named reviewer is
Clock-start event	Account closure, transaction date, financial year end, consent withdrawal	Without this the period cannot be automated or audited
Retention period	Duration from the clock-start event	Feeds the deletion job
On withdrawal	Erase / ring-fence / continue, with one line of reasoning	This column is the playbook
Erasure method	Hard delete, crypto-shred, irreversible pseudonymisation, aggregate-and-drop	Different stores need different techniques; say which
Element owner	A named person in the business, not "IT"	Registers without owners go stale in one quarter
Last reviewed	Date and reviewer	The first thing an auditor looks at

Two practical notes. Keep the register somewhere that supports versioning and per-row ownership rather than in a shared spreadsheet, which will be the first thing an auditor finds and the last thing anyone updated. And do not try to complete it before using it: a register covering your top four collection points is worth more in week three than a perfect one in month nine.

Mapping each element to its governing obligation

This is the step that requires judgement and the step where organisations fabricate. The discipline is simple: every "mandatory" in the retention column must point at a named instrument, and a named person must have read it and signed off the reading. Where nobody can produce the instrument, the obligation is discretionary, and discretionary retention does not survive a withdrawal of consent. That sentence is uncomfortable, and it is the most useful one in this paper.

The table below shows the shape of a completed mapping. Periods and triggers differ by entity type, product and the current text of the instrument, so treat it as a worked example of the structure rather than a schedule to adopt. Confirm each row with your counsel against the instrument as it stands today, and record who confirmed it.

Element	Typical governing obligation	Clock starts at	Effect of consent withdrawal
Identity document and verification record (PAN, Aadhaar-based verification result, passport)	Anti-money-laundering record-keeping and the sectoral KYC direction applicable to your entity	Typically end of the business relationship, not the date of collection	Ring-fence. Retention is required by law in force; stop every use not required by that law
Transaction records and statements	Anti-money-laundering transaction record rules; books-of-account obligations under tax and company law	Transaction date, or close of the relevant financial year	Ring-fence. Erasure refused with a documented exception
Marketing opt-in, channel preferences, behavioural segments, look-alike audiences	None	Not applicable	Erase, and propagate the suppression to every downstream marketing tool
Model training sets and derived scores built from customer data	None, unless the score itself forms part of a record you must keep	Not applicable	Remove from the training corpus; retire or retrain where the score is still in production use. Say honestly what cannot be unlearned
Call recordings and chat transcripts	Sectoral record-keeping expectations, plus evidentiary value in disputes	Call date, or resolution of the dispute	Usually ring-fence for the stated period, then delete. Quality-and-training use stops immediately
ICT system and application logs containing user identifiers or IP addresses	The CERT-In directions of 2022 require ICT system logs to be maintained for 180 days, within Indian jurisdiction	Event date	Retain for the log period, then purge on schedule. Do not mine the logs for anything else
CCTV footage at branches and offices	Usually internal policy, sometimes sectoral guidance	Capture date	Erase on the published schedule. If the schedule is "until the disk fills", you have a finding
Employee payroll, PF and tax records	Labour statutes, tax law and company-law books-of-account obligations	End of employment, or close of the financial year	Ring-fence. Employment data is also rarely held on consent in the first place
Grievance and rights-request history	Needed to evidence your own compliance	Closure of the request	Retain, minimised. Keep the fact of the request and the decision; you do not need the full payload forever

A note on the Rules. The DPDP Rules have been notified with a phased commencement, and different obligations bite at different points. Some classes of large consumer-facing fiduciary also attract a default erasure trigger after a defined period of user inactivity, with advance notice to the user. Whether your entity falls into that class, and which obligations are live for you on a given date, is a threshold question worth settling with counsel early rather than inferring from a vendor presentation. We will tell you where we think the answer is unsettled instead of guessing.

Designing the withdrawal SLA

Withdrawal is not one action. It is a fan-out, and each branch has its own realistic latency. Treating it as a single event is why organisations either over-promise ("deleted within 24 hours") or under-deliver ("we will revert in 30 days").

Split it into four tiers and publish the ones you can actually hit:

1. Stop (hours). Suppression set in the system of record and pushed to marketing automation, the dialler, push tooling and any partner you send audiences to. This is the branch customers judge you on, because it is the one they can observe. A promotional SMS after withdrawal undoes everything else you did.
2. Confirm (within your published window). A written reply naming which processing has stopped, which data is retained, the obligation requiring it, and the date the clock expires. Not a template saying "we have processed your request".
3. Erase (days to weeks). Unmandated elements removed from the system of record and from each downstream copy in the register. Scheduled, logged, verifiable.
4. Expire (months to years). Ring-fenced elements deleted automatically when the statutory clock runs out. This is a job, not an intention.

On the published number: the Rules require you to state the period within which you will respond, and you will be held to your own figure rather than to an industry norm. Pick one your weakest system can support in your busiest month, publish that, and beat it. We have yet to see an organisation penalised for a conservative window; we have seen several embarrassed by an ambitious one.

Partial erasure, ring-fencing and defensible exceptions

Full erasure of a customer record is rare in a regulated business and should not be what you design for. The common outcome is partial: some elements go, some are ring-fenced, and a few derived artefacts need a judgement call.

Ring-fencing has to be technically real rather than a label. At minimum: access restricted to a named role with a documented reason; the record excluded from analytics, BI, model training and any marketing or cross-sell selection; reads logged; and an automatic deletion date set from the clock-start event. If a ring-fenced record still appears in a cross-sell extract, it is not ring-fenced. It is flagged.

Situation	Can you erase now?	What you do instead	Artefact that proves it
Consent withdrawn; element has no mandatory retention source	Yes	Erase from system of record and all listed downstream copies	Deletion log entry with element IDs, systems and timestamp
Consent withdrawn; element governed by a named statutory retention period still running	No	Ring-fence, stop all non-mandated use, set the expiry date	Documented erasure exception plus the ring-fence configuration record
Consent withdrawn; retention period has already expired	Yes	Erase immediately, and investigate why the expiry job did not already do it	Deletion log plus a defect ticket against the expiry job
Processing was never on consent (statutory obligation, employment, legal claim)	Not on this ground	Reply explaining the basis in plain language; erasure right does not attach to withdrawal here	Register row showing the lawful basis, plus the response sent
Element sits in an immutable store (append-only ledger, WORM archive, blockchain-backed log)	Not by deletion	Crypto-shred the key, or irreversibly pseudonymise the identifying fields	Key-destruction record, or the pseudonymisation method and its review
Element is embedded in a trained model or an aggregate statistic	Partly	Remove from training corpus; assess whether retraining is proportionate; state plainly what is not reversible	Model data-provenance record and the documented decision
An active dispute, investigation or recovery proceeding involves the record	No	Legal hold with a named owner and a review date, not an open-ended freeze	Hold register entry with the matter reference and the review date

You will refuse erasure, and that is lawful where another law in force requires retention. What determines whether the refusal holds up is the quality of the record you make at the time, because reconstructing it eighteen months later in front of a regulator does not work. A defensible exception has six parts and fits on one screen:

• The specific elements being retained, by element ID, rather than "the customer record".
• The named instrument requiring retention, and the reading of it that you are relying on.
• The person who confirmed that reading, with a date. Internal counsel is fine. "Legal advised" with no name is not.
• The clock-start event and the resulting expiry date, as a date, not a duration.
• What processing has stopped, explicitly listed, so the exception is visibly narrow.
• The plain-language explanation given to the data principal, as actually sent.

The test we apply when reviewing an exception: if the regulator read only this record and nothing else, would it conclude the organisation retained the minimum the law required, or the maximum it could argue for? Exceptions written to the second standard are the ones that fail.

Keep exceptions as structured records, not as prose in a ticket. You want to be able to answer "show me every erasure you refused in the last year and the grounds" in one query. That question is coming.

Backups, archives and the copies you forgot

Backups are where honest retention policies go to die, and where dishonest ones get exposed. The sequence we recommend, and the reasoning behind it:

Do not restore a backup to delete one person's record. It introduces more risk than it removes. Instead, document the position: backups are held for a defined period, they are not used for any processing other than restoration, erasure is applied to the live estate immediately, and any restore is followed by re-application of the erasure and suppression log before the system returns to service. That last clause is usually the missing one, and it is what makes the position hold. It means keeping an erasure journal that outlives the backup window — a small engineering task and a large compliance difference.

Then shorten the backup window to what your recovery objectives actually require. Most organisations we assess hold backups far longer than any stated RPO, usually because the setting was never revisited after a storage migration. Archives are different: an archive is a processing store, not a recovery store, so erasure applies to it in full. If your "archive" is a cold data lake that analytics still queries, it is live data with a cheaper storage class.

Three categories get missed in almost every engagement: ad-hoc exports in mail attachments and shared drives; vendor-side copies held by processors whose contracts have no deletion trigger; and test and staging environments seeded with production data, which in several assessments turned out to be the largest unmanaged store of personal data in the organisation.

Answering a request without a manual scramble

The register and the policy only pay off if a request routes itself. The target is that a standard erasure request is handled by one person following a script, with escalation only for genuine exceptions. The handoffs below are what that requires.

Step	Responsible	Accountable	Consulted	Target
Intake and logging	Rights-request desk	DPO / grievance officer	—	Same business day
Identity verification	Rights-request desk	DPO	Fraud / ops, where the claim is doubtful	2 business days
Suppression of marketing and non-mandated processing	Marketing ops and product owner	DPO	—	Same day as verification
Register lookup and classification	Rights-request desk	DPO	Element owners for non-standard elements	2 business days
Erasure execution across systems and downstream copies	System owners / platform engineering	CTO or IT head	DPO	Within the published window
Exception drafting and approval	Compliance analyst	Legal / counsel	Business owner	Before the response goes out
Response to the data principal	Rights-request desk	DPO	Legal, for refusals	Within the published window
Expiry-job verification	Platform engineering	DPO	Internal audit	Monthly sample

Where to start, and what we are not telling you

If you have eight weeks and one analyst, do this in order. Weeks one and two: list collection points and build the register for the top four. Weeks three and four: map obligations with counsel, demoting unsourced claims to discretionary. Week five: write the withdrawal decision table and the exception template. Week six: fix suppression propagation, the highest-visibility failure and usually the cheapest to close. Weeks seven and eight: stand up the request desk with the RACI above and run two live rehearsals, including one refusal.

What this paper does not give you. No section numbers, penalty figures or deadlines, deliberately. Those move, they differ by entity type, and a paper that gets one wrong does more damage to its reader than one that stays general. It does not tell you whether a specific retention period applies to your products, because that depends on your licence, your entity type and the current text of instruments we have not read on your behalf. And it does not resolve the open question, which is how a sectoral regulator and the Data Protection Board will each view a ring-fenced record. Our position, and it is a position rather than settled law, is that a narrow, documented, time-bounded exception is defensible to both and a blanket "we keep everything" is defensible to neither.

If what you need is a legal opinion on a retention instrument, that sits with your counsel and we will say so on the call. What we do is build the register, the decision table, the exception format and the request desk, then prove it works by running real requests through it while we are still in the room. We do not publish invented case studies or success percentages for this work.