DPDP legacy data: 6 steps to remediate pre-consent records before May 2027

Summary. India notified the Digital Personal Data Protection Rules, 2025 on 14 November 2025 under G.S.R. 846(E), starting an 18-month phased compliance clock that runs out around 14 May 2027. Rule 4, covering Consent Managers, lands earlier at roughly 14 November 2026. The provision most Indian engineering teams have not budgeted for is Section 5(2) of the DPDP Act, 2023, which covers personal data collected before the Act commenced on 11 August 2023. That data does not become illegal, but you owe every one of those people a notice, and you must be able to act when they say no. Getting it wrong sits inside the penalty band that reaches ₹250 crore for a failure of reasonable security safeguards, with ₹50 crore for other violations. The Ministry of Electronics and Information Technology received 6,915 inputs across seven consultation cities before finalising the Rules.

Most compliance writing about the DPDP Act covers the easy half: put a consent banner on the signup form, write a privacy notice, appoint a contact. That work is real, and it is also the part your product team can finish in a sprint.

The hard half is everything already in your database.

A ten-year-old Indian company holds customer records from channel partners, employee files from three HR systems, lead lists bought in 2019, transaction histories, support tickets and behavioural logs. None of it was collected under a DPDP-valid consent, because DPDP-valid consent did not exist. This article is about that data: how the Act actually treats it, what you have to do, and the order to do it in.

What Section 5(2) actually says

Read the provision itself rather than a summary of it. Section 5(2) of the Digital Personal Data Protection Act, 2023 reads:

"Where a Data Principal has given her consent for the processing of her personal data before the date of commencement of this Act,— (a) the Data Fiduciary shall, as soon as it is reasonably practicable, give to the Data Principal a notice informing her,–– (i) the personal data and the purpose for which the same has been processed; (ii) the manner in which she may exercise her rights under sub-section (4) of section 6 and section 13; and (iii) the manner in which the Data Principal may make a complaint to the Board, in such manner and as may be prescribed. (b) the Data Fiduciary may continue to process the personal data until and unless the Data Principal withdraws her consent."

Three things follow from that text, and each one is routinely misreported.

First, there is no deletion mandate for legacy data. Clause (b) is permissive: you may keep processing until withdrawal. Vendors selling "DPDP purge" tooling sometimes imply otherwise.

Second, the trigger is "as soon as it is reasonably practicable", not a fixed date. That is a softer standard than the 18-month Rules clock, and it is also harder to plan against, because reasonableness is judged after the fact by the Data Protection Board of India rather than announced in advance.

Third, the notice is not optional and it is not a privacy-policy update. It has to reach the person, and it has to tell them what data you hold, why you processed it, how to withdraw, and how to complain to the Board.

Section 5(3) adds a delivery requirement that engineering teams miss until late: the Data Principal must be given the option to access the notice "in English or any language specified in the Eighth Schedule to the Constitution". That is 22 languages, and it turns a one-off email template into a localisation task.

The clock: what starts when

The Rules commence in three tranches. Rule 1(2) puts rules 1, 2 and 17 to 21 into force on publication. Rule 1(3) puts rule 4 into force "one year after the date of publication of this Gazette". Rule 1(4) puts rules 3, 5 to 16, 22 and 23 into force "eighteen months after the date of publication of this Gazette".

The Rules state periods, not calendar dates, so the deadlines below are computed from the 14 November 2025 publication date reported by the Press Information Bureau. Worth noting for your legal team: the notification itself is dated 13 November 2025, so treat any date you compute as approximate by a day.

Tranche	Rules in force	Approximate date
On publication	Rules 1, 2, 17-21 (Board constitution, procedure, appeals)	14 November 2025
Twelve months	Rule 4 only (Consent Manager registration and obligations)	14 November 2026
Eighteen months	Rules 3, 5-16, 22, 23 (notice, security, breach, erasure, SDF duties)	14 May 2027
Section 5(2) legacy notice	Act provision, no Rules date attached	"As soon as reasonably practicable"
Penalty exposure	Act Schedule, enforced by the Board	Live once the Board acts

Rule 3, which prescribes what a notice must contain, sits in the 18-month tranche. Secondary coverage often reports it as immediate. It is not.

That gap matters for sequencing. Your Section 5(2) notice obligation comes from the Act and has no Rules deadline, while the detailed content requirements in Rule 3 do not bite until May 2027. The practical read: design the legacy notice to Rule 3's standard now, because you will not want to run the campaign twice.

What Rule 3 will require of the notice

Rule 3 of the DPDP Rules, 2025 requires that the notice:

"(a) be presented and be understandable independently of any other information that has been, is or may be made available by such Data Fiduciary; (b) give, in clear and plain language, a fair account of the details necessary to enable the Data Principal to give specific and informed consent for the processing of her personal data, which shall include, at the minimum, — (i) an itemised description of such personal data; and (ii) the specified purpose or purposes of, and specific description of the goods or services to be provided or uses to be enabled by, such processing; and (c) give, the particular communication link for accessing the website or app, or both, of such Data Fiduciary, and a description of other means, if any, using which such Data Principal may— (i) withdraw her consent, with the ease of doing so being comparable to that with which such consent was given; (ii) exercise her rights under the Act; and (iii) make a complaint to the Board."

"An itemised description of such personal data" is the phrase that turns this into an engineering problem rather than a legal one. You cannot itemise what you have not inventoried. A notice that says "we hold information about you" does not meet the standard.

Step 1: inventory before you touch anything

The instinct is to start deleting. Resist it, because Section 8(7) creates an erasure duty that survives whatever you do, and you cannot prove you honoured it if you no longer know what you had.

Build a data map keyed on three questions per store: what personal data is in here, when was it collected, and on what basis. That third column is the one nobody has. Most Indian companies can answer it for post-2023 signups and cannot answer it for anything older.

A workable schema for the register:

CREATE TABLE dpdp_data_register (
  store_id            TEXT PRIMARY KEY,
  store_type          TEXT NOT NULL,          -- rds | s3 | mongo | saas | csv_share
  owner_team          TEXT NOT NULL,
  personal_data_items JSONB NOT NULL,         -- itemised, per Rule 3(b)(i)
  specified_purpose   TEXT NOT NULL,          -- per Rule 3(b)(ii)
  lawful_basis        TEXT NOT NULL,          -- consent | s7_legitimate_use
  collected_from      DATE,
  collected_to        DATE,
  pre_commencement    BOOLEAN GENERATED ALWAYS AS
                        (collected_to < DATE '2023-08-11') STORED,
  processor_shared    TEXT[],                 -- s8(7)(b) downstream erasure
  retention_basis     TEXT,                   -- statute forcing retention, if any
  last_reviewed       DATE NOT NULL
);

The processor_shared column is not decoration. Section 8(7)(b) requires a Data Fiduciary to "cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing to such Data Processor". If your CRM, your analytics warehouse and your email platform each hold a copy, an erasure request that only clears your primary database has not been honoured.

Step 2: separate consent data from legitimate-use data

Section 4 allows processing on exactly two grounds: consent, or the "certain legitimate uses" in Section 7. There is no general legitimate-interests basis of the kind European teams are used to, which is the single most common mistake in DPDP gap assessments written by people carrying GDPR habits.

Section 7 lists nine grounds, (a) through (i). Several of them absorb large amounts of what looks like legacy consent data:

• 7(a) covers data the person voluntarily provided for a specified purpose and has not objected to.
• 7(d) covers processing required to fulfil a legal obligation in India.
• 7(e) covers compliance with a judgment, decree or order.
• 7(i) covers employment purposes and safeguarding the employer.

That last one is the reason your HR data is a smaller problem than your marketing data. Payroll records retained under the Income-tax Act, statutory registers under the Companies Act, and employment files generally sit outside the consent regime. Classify them as Section 7 grounds in the register and stop treating them as a re-consent problem.

Marketing lists are the opposite case. A purchased lead list from 2019 has no Section 7 ground, no demonstrable consent, and no realistic path to one.

Data class	Typical DPDP basis	Legacy action
Payroll and statutory HR records	Section 7(i) and 7(d)	Map and document; no notice campaign
Active customer accounts	Consent, Section 5(2) legacy notice	Notice, then honour withdrawal
Dormant customer accounts	Consent, plus Third Schedule if in scope	Notice, then time-based erasure
Purchased or scraped lead lists	None available	Erase; do not attempt re-consent
Support tickets and call recordings	Consent, sometimes 7(a)	Notice, apply retention limit
Analytics and behavioural logs	Consent, if linkable to a person	De-identify or erase

Step 3: send the Section 5(2) notice, once, properly

The notice campaign is a one-time event per Data Principal, and it is the point of maximum risk, because you are writing to your entire historical user base at once telling them you hold their data.

Three decisions shape whether it goes well.

Channel. Email is the default and has the worst reach against a decade-old list. In-app notice on next login reaches active users reliably and never reaches dormant ones. Most teams end up running both, plus SMS for records where that is the only identifier held.

Granularity. Rule 3(b)(i) wants an itemised description. Sending one generic notice to everybody is cheaper to build and weaker to defend. Generating a per-segment notice from the data register, so a person who only ever bought once sees a shorter list than a person with a full behavioural profile, is defensible and is roughly a week of additional work if the register from Step 1 exists.

Withdrawal path. Section 6(4) requires that withdrawal be as easy as giving consent was. If the original consent was a pre-ticked box in a 2018 checkout flow, the bar for withdrawal is very low indeed, which means a one-click link, not a support ticket.

Union Minister for Electronics and Information Technology Ashwini Vaishnaw described the resulting obligation in Parliament: "now anybody who uses personal data of any user, any citizen of India will basically have a protection mechanism through which consent would have to be taken, data minimization would have to be done, the right to forget will have to be done, and the purpose will have to be very clearly defined", as reported by The Tribune.

Step 4: build the withdrawal and erasure pipeline before the notice goes out

This is the sequencing error that costs the most. Teams send the legacy notice, get a withdrawal spike in the first 72 hours, and have no automated path to honour it.

Section 6(6) requires that on withdrawal the Data Fiduciary "shall, within a reasonable time, cease and cause its Data Processors to cease processing the personal data". Section 8(7) requires erasure "upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier", unless retention is necessary for compliance with a law in force.

Neither provision names a number of days. The Act says "within a reasonable time" and nothing more, so do not import a 30-day or 72-hour figure from GDPR practice and present it as a DPDP requirement.

What the pipeline needs:

# withdrawal-fanout.yaml — one event, every store
on_withdrawal:
  principal_id: "{{ principal_id }}"
  received_at: "{{ iso8601 }}"
  targets:
    - store: primary_postgres
      action: soft_delete_then_purge
      purge_after: P7D
    - store: analytics_warehouse
      action: deidentify          # keep aggregates, drop the key
    - store: crm_saas
      action: api_erase           # processor, s8(7)(b)
      retry: exponential
    - store: email_platform
      action: api_erase           # processor, s8(7)(b)
    - store: backup_snapshots
      action: tombstone_on_restore
  retain_if:
    - basis: statutory
      cite: "Income-tax Act retention"
      scope: financial_records_only
  evidence:
    write_to: dpdp_erasure_log
    fields: [principal_id, requested_at, completed_at, stores, exceptions]

Two details are load-bearing. Backups almost never support selective deletion, so the standard pattern is a tombstone list consulted on restore rather than surgery on the snapshot itself. And the evidence log matters more than the deletion, because in an inquiry you will be asked to demonstrate the erasure happened, not merely assert it.

The real cost here is usually the fan-out to processors, not the primary delete.

Step 5: apply the Third Schedule retention limits if they reach you

The Rules set a default erasure period for three classes of large platform. Reporting by Business Standard on the day of notification set out the thresholds: e-commerce entities and social media intermediaries with more than 20 million registered users in India, and online gaming intermediaries with more than 5 million registered users, must delete a user's personal data after three years of non-use, with 48 hours' notice before deletion.

The three-year clock runs from the person's last interaction, not from registration. A user who logs in once a year never triggers it.

If you are under those thresholds, this rule does not apply to you, and you should not adopt it voluntarily as a "best practice" without checking it against your own retention needs. If you are over them, it is a scheduled job with a notice step, and it interacts with Step 4: the same erasure pipeline serves both.

Business Standard also reported that platforms with more than 5 million registered users in India are to undertake an annual audit and a Data Protection Impact Assessment as Significant Data Fiduciaries. That threshold is lower than the e-commerce erasure threshold, so a mid-size platform can be an SDF without being in the Third Schedule.

Step 6: instrument it, then leave it running

Legacy remediation is a project. DPDP compliance is not. The register from Step 1 decays the moment a team ships a new table, so the useful end state is a check in CI that fails when a migration adds a column that looks like personal data and no register entry exists for it.

The Rules require a published grievance path. Rule 14(3) requires a Data Fiduciary and Consent Manager to publish prominently the period within which grievances will be resolved, capped at ninety days. Publish the number, then measure against it, because a published ninety-day promise you miss is worse evidence than a published thirty-day promise you keep.

India-specific considerations

Consent Managers are the part of the framework with no European analogue and the earliest deadline. Rule 4 comes into force twelve months after publication, around 14 November 2026, and PIB confirms Consent Managers must be companies based in India. If your consent architecture assumes a foreign consent-management platform, that assumption has roughly four months left. We covered the readiness work separately in our DPDP Consent Manager framework guide.

Penalty exposure is heavily skewed toward security rather than paperwork. The highest band, up to ₹250 crore, attaches to failure to maintain reasonable security safeguards. Breach non-notification and children's-data violations each reach ₹200 crore. Any other violation of the Act or Rules reaches ₹50 crore. A legacy database with no access controls is therefore a larger financial risk than a late notice.

Appeals from the Data Protection Board go to the Telecom Disputes Settlement and Appellate Tribunal, and the Board itself is constituted as a four-member digital-first body with online complaint filing. Those rules are already in force, since they sit in the Rule 1(2) tranche.

For teams building on Indian financial data, the consent architecture under the Account Aggregator framework solves a narrower version of the same problem and is worth studying before you design your own; see our Account Aggregator integration guide. For the wider engineering programme, our DPDP engineering playbook for Indian startups covers the build side, and our breakdown of DPDP compliance cost covers budgeting against the 2027 date.

Sequencing summary

Step	Blocking dependency	Do it by
1. Inventory and register	Nothing; start here	Now
2. Classify consent vs Section 7	Register exists	Before notice drafting
3. Draft notice to Rule 3 standard	Itemised inventory	Before campaign
4. Withdrawal and erasure pipeline	Register and processor list	Before the notice sends
5. Third Schedule retention job	Pipeline exists, thresholds checked	14 May 2027
6. CI checks and grievance SLA	All of the above	Continuous

The order is not arbitrary. Steps 4 and 3 are the pair teams most often invert, and inverting them is what turns a compliance exercise into an incident.

FAQ

Does the DPDP Act require me to delete personal data collected before August 2023?

No. Section 5(2)(b) says the Data Fiduciary may continue to process pre-commencement personal data until and unless the Data Principal withdraws consent. What the Act requires is a notice to those people. Deletion becomes mandatory only on withdrawal, or under Section 8(7) when the specified purpose is no longer served.

When is the deadline for the Section 5(2) legacy notice?

The Act sets no calendar date. Section 5(2)(a) requires the notice "as soon as it is reasonably practicable", which the Data Protection Board of India would assess after the fact. The detailed content requirements in Rule 3 come into force eighteen months after publication of the Rules, which computes to about 14 May 2027.

What must the legacy notice actually contain?

Section 5(2)(a) requires the personal data and the purpose it has been processed for, how the person exercises rights under Section 6(4) and Section 13, and how to complain to the Board. Rule 3 adds that it must be standalone, in plain language, and carry an itemised description of the personal data plus a working withdrawal link.

How long do I have to erase data after someone withdraws consent?

The Act does not give a number. Section 6(6) requires the Data Fiduciary to cease processing "within a reasonable time" and to cause its Data Processors to do the same. Section 8(7) requires erasure on withdrawal or purpose exhaustion, whichever is earlier, unless a law in force requires retention.

Does the three-year deletion rule apply to my company?

Only if you cross the Third Schedule thresholds. Business Standard reported these as e-commerce entities and social media intermediaries above 20 million registered Indian users, and online gaming intermediaries above 5 million. The clock runs from last use, not registration, and 48 hours' notice is required before deletion.

Can I rely on legitimate interests for legacy data the way GDPR allows?

No. Section 4 permits processing only on consent or the certain legitimate uses listed in Section 7, and Section 7 is a closed list of nine specific grounds. There is no general legitimate-interests basis in the DPDP Act, which is the most common error carried over from European compliance work.

What are the penalties if we get legacy remediation wrong?

Under the Act, failure to maintain reasonable security safeguards attracts up to ₹250 crore. Failure to notify the Board or affected individuals of a breach, and violations of children's-data obligations, each reach up to ₹200 crore. Any other violation of the Act or Rules by a Data Fiduciary reaches up to ₹50 crore.

Do Consent Managers have to be Indian companies?

Yes. The Press Information Bureau states that Consent Managers, who help people manage permissions, must be companies based in India. Rule 4 governs their registration and obligations, and it comes into force one year after publication of the Rules, which computes to around 14 November 2026, ahead of the main eighteen-month tranche.

How eCorpIT can help

eCorpIT builds the data-governance layer this work depends on: the register, the withdrawal fan-out to every processor, and the evidence log an inquiry will ask for. Our senior engineering teams design applications aligned with DPDP Act requirements rather than bolting consent onto a finished product. We work with Indian and global teams from Gurugram, and we start with a read-only inventory pass so you know the size of the problem before you commit a budget. Talk to us about scoping a legacy remediation programme against the May 2027 date.

References

1. Digital Personal Data Protection Act, 2023 (full text) — Ministry of Electronics and Information Technology.
2. Digital Personal Data Protection Rules, 2025 (full text, G.S.R. 846(E)) — Ministry of Electronics and Information Technology.
3. DPDP Rules, 2025 Notified: A Citizen-Centric Framework for Privacy Protection and Responsible Data Use — Press Information Bureau, 17 November 2025.
4. DPDP rules mandate deleting user data after three years of inactivity — Business Standard, 14 November 2025.
5. AI apps, AI models covered under latest personal data protection law: Ashwini Vaishnaw in Parliament — The Tribune (ANI), 3 December 2025.
6. Transforming data privacy: DPDP Act, 2023 and DPDP Rules, 2025 — EY India.
7. With rules finalized, India's DPDPA takes force — International Association of Privacy Professionals.
8. Enforcement of the DPDP Act and notification of the DPDP rules — Shardul Amarchand Mangaldas & Co.
9. Digital Personal Data Protection Rules, 2025: Operationalising consent, security, and governance obligations — Lexology.
10. India's DPDP Timeline: Critical Compliance Deadlines for 2026-27 — India Briefing.
11. DPDP Rules 2025: Operational Compliance Guide — iPleaders.
12. Data protection laws in India — DLA Piper Data Protection Laws of the World.

Last updated: 20 July 2026.