Data Retention and Erasure Mapping Under the DPDP Act

The basics

What are data retention and erasure? Plain definitions for a DPDP Act programme

Retention is the decision to keep personal data for a stated reason and for a stated time. Erasure is the act of removing it, including from every copy and from every Data Processor that holds it. Mapping means writing both decisions down for each kind of data, so that deletion happens on purpose and not by accident.

These terms are not defined separately in the Act, so this guide uses them in their everyday sense. Section 2 of the Act does list “erasure” among the operations that count as processing, and it defines a “specified purpose” as the purpose mentioned in the notice given to the Data Principal. That second definition matters most, because the erasure duty in Section 8(7) is tied to it.

The basics

The 7-link chain: from purpose to deletion proof

Every retention rule should follow one chain: purpose or requirement, retention trigger, retention period, system or location, deletion trigger, deletion mechanism, evidence. If a link is empty, the rule cannot be run. The most common empty links are the trigger and the evidence.

The basics

Why map retention and erasure? Five problems it prevents

Mapping turns “we delete when we can” into rules that people can run, check and explain. It is not an express requirement of the Act. It is practical compliance infrastructure that helps you meet the erasure duties the Act does contain.

There is also a plain security benefit. Data you no longer hold cannot be leaked. The Act itself does not make this argument, but it is the reason many security teams push for tidy retention.

The basics

What the DPDP Act says about retention and erasure: provisions, and what is missing

The Act ties erasure to the purpose and to consent, not to a calendar. Section 8(7) tells you to erase when consent is withdrawn or the specified purpose is no longer served, unless law requires retention. Rules 6 and 8 add a one-year log rule and a three-year inactivity rule for named classes. Nothing we found sets one period for all data.

What we found no provision on

• A single retention period, such as “delete after 90 days”, for all personal data.
• How to treat backups. The Act is silent, so your own written approach has to fill the gap.
• A duty to keep a retention schedule, a retention register or an erasure log.
• A fixed number of days for finishing erasure after a trigger under Section 8(7).
• Any wording like a “right to be forgotten”. Section 12 uses “erasure” and ties it to the conditions above. The Act has no GDPR-style “legitimate interest” ground either, so, in our reading, a business wish to keep data is not by itself a reason to retain it.

Decide the rules

How to identify retention triggers: the event that starts the clock

A retention trigger is a dated event that already exists in a system, such as an account closure date, an invoice date or a ticket close date. A period such as “one year” means nothing until you say one year from what. If the date is not stored anywhere, a deletion job cannot find it.

A quick test for a good trigger

1. Is it an event or a date? “When we no longer need it” is not a trigger.
2. Is it stored in a system? If not, add a field before you write the rule.
3. Does one person own it? Someone must keep the date accurate.
4. Can a job read it? A trigger only a human can see makes deletion manual and slow.

Decide the rules

How to decide what should be retained: a six-question test

Keep personal data only while one of three reasons applies: the specified purpose is still being served, a named law requires you to keep it, or a dispute or hold needs it. If none applies, the data is a candidate for deletion. Ask the questions below in order and write the answer in the register.

1. Is the specified purpose still being served? Use the purpose in the notice. A new or vague reason, such as “it may be useful later”, is not the specified purpose.
2. Has the Data Principal withdrawn consent for this purpose? If yes, stop processing and move to the erasure check in the next step. Section 8(7)(a) points to erasure on withdrawal.
3. Does a law require you to keep it? Name the law and the section. “Compliance needs it” without a source is not enough to write “law requires retention” in the register.
4. Is there a dispute, claim, investigation or audit? If yes, a hold applies. Record who placed it and when you will review it.
5. Is it a security log under Rule 6(1)(e) or Rule 8(3)? If yes, the one-year minimum applies, unless another law requires longer.
6. Does a class-specific rule apply to you? Read Rule 8 and the Third Schedule to see whether the three-year inactivity rule covers your business and your purpose.

Where to look for legal retention requirements

The Act does not list the other laws that may require you to keep records. Their periods differ by law and sector, and they change, so this guide does not list periods. Ask your finance, legal and HR advisers to confirm the law and the section for each category. Areas that usually need a check:

• Tax and GST laws, for invoices, ledgers and payment records.
• Company law, for statutory registers and accounting records.
• Labour and employment laws, for payroll, attendance and employee files.
• Sector regulators, for example in banking, insurance, securities, telecom or health.
• Cyber security directions, for logs.

Decide the rules

Mapping retention periods to data categories and purposes: how to write a rule you can run

Write each rule in one sentence: delete [data] [time] after [trigger], unless [hold]. Set one rule per category and purpose, not one rule per system. The period comes from the purpose or from a named law. The table shows how to reach a period for common categories, without suggesting one.

A rule template

Delete the customer account data 30 days after account closure, unless a dispute or a legal hold is open. If a hold is open, delete 30 days after it ends. Source: purpose in the notice. Placeholder period.

The same rule in register terms has a trigger (account closure), a driver (purpose still served), a period (30 days after trigger, paused by hold), a method (delete) and evidence (job report). Notice that the sentence names its own exception. Every rule needs one.

Map the deletion

Mapping erasure and deletion workflows: six steps from trigger to record

An erasure workflow has six steps: detect the trigger, check for a hold, list every copy, delete or anonymise each one, get confirmation from vendors, and record the result. Write one workflow per trigger type, not one per system. The Act sets no fixed number of days for finishing erasure under Section 8(7), so set your own internal target and write it down.

Delete, anonymise or archive: record which one you do

Deleting removes the data. Anonymising keeps a version that cannot be linked to a person. Archiving with restricted access keeps the data for a reason such as a legal requirement, and should be used only for that reason. These are different outcomes, so the register has a method column and asks you to pick one. Do not describe archiving as deletion in a report.

Map the deletion

Production systems, backups, spreadsheets and email: where copies hide and how to clear them

Personal data usually lives in more places than the system you think of as the source. A location sheet lists every place a copy rests, who can delete from it, how it goes and how long it takes. The longest time on the sheet is your real erasure time.

Backups: the Act is silent, so write down what you do

We found no provision in the Act or the Rules that says how backups should be treated when erasure is due. That gap is real, and a clear written approach is the sensible way to cover it. This is good practice, not a legal requirement:

• Keep backup cycles short and documented. Record how long each backup is kept and when the oldest copy expires.
• Limit access. Backups should be used only to restore service, not to look up customers.
• Keep a deletion log. After any restore, run the log again so erased data does not return to production.
• Ask your host. Check how your cloud host or backup vendor ages out copies, and keep their written answer.
• Do not claim more than you do. If a backup holds a copy for 35 days (a placeholder), say so in the register.

Map the deletion

Mapping processor and vendor deletion: how to make sure their copies go too

Section 8(7)(b) requires you to cause your Data Processor to erase personal data you made available to it, so vendor deletion is part of your own erasure workflow. Add every processor that holds a copy to the rule, record how erasure is requested, and file the vendor’s confirmation.

Map the deletion

Handling consent withdrawal vs erasure: five events that look alike and are not

Consent withdrawal, an erasure request, the end of a purpose, inactivity and the end of a retention period each have their own source and their own checks. Withdrawal and the end of a purpose are duties under Section 8(7)(a). An erasure request is a right under Section 12(3). Inactivity is a deemed end of purpose that the Rules define only for named classes.

Withdrawal works at the level of the purpose, not the person

A customer who withdraws consent for marketing has not asked you to close their account. Stop the marketing, erase what only the marketing purpose needed, and keep what the account purpose still needs. If you have mapped each purpose in the inventory, you can see which rows each withdrawal touches. Section 6 also says that withdrawal does not make earlier lawful processing unlawful, so you need not undo what was done before.

Build and use it

Building a retention and erasure register: free Excel file, fields and example

The register is three linked sheets: a register of rules, a list of locations and a log of erasure events. The Excel file below contains all three, a filled example, gap flags and a summary. Enter your details on the download page to get the link.

The register uses the same activity IDs as the Data Inventory Workbook and the same processor IDs as the Data Flow and Processor Worksheet. You can also copy the columns below into any spreadsheet.

Register sheet: 18 fields and a gap flag

Locations sheet: 10 fields and a gap flag

Erasure log sheet: 11 fields and a gap flag

Example: three rules for the fictional store

Build and use it

10 common retention and erasure mapping mistakes and how to fix them

Most failed retention programmes have no trigger, no source or no proof. These ten are the usual causes.

Build and use it

Step-by-step implementation: map retention and erasure in 7 steps

List the activities, set trigger, driver and period, name the legal source, record every location, map the workflow and processors, test with one real record, then approve and review. Each step names who is involved and what you should have at the end.

Build and use it

Worked example: a customer account, from account closure to deletion record

Here is one chain, a customer account at a fictional online store, followed from purpose to proof. The store has seven places that hold the account data and two vendors. In the register, the rule is flagged because vendor erasure is not yet confirmed.

1. 1 · Purpose or requirementRun the customer account and show past orders. The applicable basis is consent. The purpose matches the words in the notice and in the inventory (PA-002).
2. 2 · Retention triggerAccount closure. The customer closes the account, or the store closes it after inactivity. The date is stored in the order database.
3. 3 · Retention period30 days after account closure, unless a dispute or a hold is open (placeholder). The driver is “purpose still served”, which in this case covers a short window for reversing the closure and handling disputes. Invoices follow a separate rule (R-002) because a law the store has named requires them.
4. 4 · System or locationSeven places. Order database, search index, analytics warehouse, nightly backup, helpdesk software, finance spreadsheet and email exports. Two are held by vendors: the cloud host (P-001) and the helpdesk (P-003).
5. 5 · Deletion triggerThe retention period ends. A scheduled job reads the closure date and lists accounts past the 30 days with no hold.
6. 6 · Deletion mechanismOne method per place. A scheduled job deletes from the database. The search index drops the record at the next re-index. The analytics store holds anonymised data. The backup expires on its 35-day cycle (placeholder). The helpdesk deletes on request. The spreadsheet and email exports are cleared by hand by named owners.
7. 7 · EvidenceJob report, re-index log, vendor email, monthly checklist and a ticket. Each one is written to an erasure log row with a date.

Where the locations sheet shows gaps

The erasure log for three events

1. E-001 · R-001Account closed. Trigger date: 2026-09-01. Hold checked: Yes. Cleared: L-001, L-002, L-003. Processors told: P-001. Vendor confirmation: 2026-09-03. Completed: 2026-09-03. Evidence: TKT-1042.
2. E-002 · R-001Erasure request. Trigger date: 2026-09-10. Hold checked: Yes. Cleared: L-001, L-002. Processors told: P-003. Vendor confirmation: none yet. Completed: 2026-09-12. Evidence: TKT-1060. Gap flag: Processor confirmation pending.
3. E-003 · R-003Consent withdrawn. Trigger date: 2026-09-15. Hold checked: not recorded. Cleared: L-008. Processors told: P-002. Vendor confirmation: none yet. Completed: not yet. Evidence: none. Gap flag: Hold not checked.

FAQ

Frequently asked questions: data retention and erasure under the DPDP Act

Related

Continue the data mapping collection

Go to the full method, the legal text and the practical tools. When you are ready to move from records to working controls, see the DPDP implementation framework.