# The data you already hold: re-notice, re-consent or delete before May 2027

> Under section 5(2) of the DPDP Act, consent given before the provision commences on 13 May 2027 stays valid until withdrawn, but the fiduciary must send each person a notice as soon as reasonably practicable. Section 5(2) protects only data held on consent you can prove. Data collected without consent needs a section 7 legitimate use, fresh consent or erasure. This guide gives a decision list for every legacy data set, a multi-channel notice and re-consent campaign with the records to keep, and an erasure plan that covers processors, derived data and the one-year floor.

Source: https://dpdp.commons.inc/dpdp-existing-data · Updated 25 October 2026 · By the Commons Trust team (commons.inc)

Consent a person gave before section 5(2) of the DPDP Act commences on 13 May 2027 stays valid, and you may go on using her data until she withdraws it (s. 5(2)(b)). In return you must send her a notice "as soon as it is reasonably practicable" saying what data you hold and why, how to withdraw consent and raise a grievance, and how to complain to the Data Protection Board (s. 5(2)(a)). Section 5(2) protects only data held on consent, and in practice only consent you can prove (s. 6(10)). Records collected without consent need a section 7 legitimate use, fresh consent, or erasure. Every consent you collect between now and 12 May 2027 is also "before commencement", so the next six months are the cheapest time to fix collection, sort what you hold and delete what you no longer need.

Like the Act (s. 2(y)), we use "she" and "her" for every person.

**Jump to what you need.**

- **Programme heads and operations:** [The decision list](#the-decision-list-erase-record-notify-or-re-consent), [The notice campaign](#running-the-notice-and-re-consent-campaign), [People who do not answer](#people-you-cannot-reach-or-who-do-not-answer).
- **CTOs, SaaS and data owners:** [What to log](#what-to-log-for-every-contact), [If you are the processor](#saas-companies-and-processors), [Erasing properly](#erasing-every-copy-including-derived-data).
- **DPOs and lawyers:** [What "before commencement" means](#what-before-commencement-means), [Where the law is unclear](#where-the-law-is-unclear).
- **Everyone:** [A calendar to 13 May 2027 and after](#a-calendar-to-13-may-2027-and-after).

## What "before commencement" means

Section 5(2) applies where she gave consent "before the date of commencement of this Act". The Act is coming into force in pieces, and section 1(2) says a provision's reference to "the commencement of this Act" means the coming into force of that provision. Section 5 commences on 13 May 2027 (G.S.R. 843(E)), so "before commencement" means before 13 May 2027.

- **Consent collected today is legacy consent.** A consent recorded in December 2026 through a well-built form will, from 13 May 2027, ride on section 5(2): valid until withdrawn, with a notice owed.
- **The notice duty arises at commencement.** Whether a notice you send before 13 May 2027 discharges section 5(2)(a) is untested. Our view: if every form you use from now on carries a notice that meets Rule 3 and contains what section 5(2)(a) asks for, a short confirmation after 13 May 2027 is enough, and cheap to send.
- **Erasure before May is simpler.** The DPDP duty to erase (s. 8(7)) and the one-year retention floor (Rule 8(3)) both start on 13 May 2027. Data you delete before then is never handled under the new regime. Body corporates must still follow the SPDI Rules, 2011 until that date, and any other law that sets a retention period.

The date could move. In January 2026 MeitY reportedly discussed with industry a cut in the run-in to twelve months, at least for Significant Data Fiduciaries, and bringing some provisions forward, including the cross-border rules; reports differ on its scope ([Business Standard](https://www.business-standard.com/technology/tech-news/meity-may-cut-compliance-timeline-for-key-dpdp-rules-to-12-months-126012201293_1.html)). As of 25 October 2026 nothing has been notified. The [DPDP timeline](/dpdp-timeline) tracks it.

## What section 5(2) asks of you

| Duty | Source |
|---|---|
| A notice to each person who consented before commencement, as soon as reasonably practicable, covering the data and the purposes for which it has been processed, how to withdraw consent and use your grievance route, and the manner of complaining to the Board | s. 5(2)(a) |
| In the prescribed manner. The Rules set no separate manner for section 5(2) notices; Rule 3 is the only notice rule, and we apply it: standalone, itemised, plain language, with a link to your website or app and the means to withdraw, exercise rights and complain | s. 5(2)(a), Rule 3 |
| Available in English or any Eighth Schedule language | s. 5(3) |
| You may continue until she withdraws. Withdrawal must be comparably easy to how she gave consent; you and your processors then stop within a reasonable time, unless the Act, the Rules or another law requires or authorises the processing | s. 5(2)(b), 6(4), 6(6) |

In practice the protection is only as good as your proof of consent (s. 6(10)), and it covers only the purposes she agreed to. A new purpose needs a fresh notice under section 5(1) and a consent that meets section 6(1). Data held with no consent at all needs another basis; the [Act guide](/dpdp-act-guide#what-a-valid-notice-says) explains why section 5(2) cannot supply one.

## The decision list: erase, record, notify or re-consent

Start from a data map: every system, spreadsheet, form tool, WhatsApp group, field phone, vendor and partner that holds personal data. The [data mapping guide](/dpdp-data-mapping) has a four-week method. Then ask these questions of each data set, and of each purpose within it, in order. The first "yes" or "no" that ends the list is the answer.

1. **Do we still need it for a purpose we can name?** If no: **erase** (s. 8(7)(a)), unless another law requires you to keep it.
2. **Does a section 7 legitimate use cover that purpose?** If yes: **record the basis** and stop. No section 5(2) notice is due.
3. **Did she consent, and can we prove a valid consent: the notice she saw and her recorded yes?** If yes: **send the section 5(2) notice** and keep to the consented purposes.
4. **Is the purpose worth a re-consent campaign?** If yes: **re-consent** with a fresh notice and request. If no: **erase**.

| Outcome | What it typically looks like | Evidence to file |
|---|---|---|
| Erase (Q1, or Q4 = no) | Closed programmes, rejected applications past any appeal window, leavers' files past statutory periods, test copies of production data, exports in inboxes and shared drives | Erasure log |
| Record the basis (Q2) | Payroll and attendance (s. 7(i)); information a law requires you to disclose to the State (s. 7(d)); records kept under a court order (s. 7(e)); data she gave for a purpose plain at the time and has not objected to (s. 7(a)) | One line per purpose naming the clause and why it fits |
| Section 5(2) notice (Q3) | App or web consent logs with the notice version; double opt-in mailing lists; recorded field consents; SPDI-era written consents that name the purpose | Consent record plus the notice campaign log |
| Re-consent (Q4 = yes) | Pre-ticked boxes, consent buried in terms of service, one "I agree" for several purposes, forms with no record of the version she saw, "verbal consent" with nothing written down; photographs and case stories; children's records | New consent record |

- **Sort by purpose as well as data set.** A donor database can hold receipts kept for tax law (record the basis), a newsletter she opted into (notice), and a bought wealth-screening profile (erase).
- **Question 3 is about proof and validity.** Section 6(10) requires you to prove notice and consent "in accordance with the provisions of this Act and the rules". A bundled or pre-ticked consent is hard to defend under section 6(1) even where you can prove the click.
- **Read section 7(a) narrowly.** It covers use "for the specified purpose for which the Data Principal has voluntarily provided her personal data", and "specified purpose" is defined by the notice you gave (s. 2(za)). The Act's own illustration is a pharmacy customer who gives her phone number to receive a receipt: the number may be used for the receipt. Legacy data qualifies only where the purpose was that plain at collection. The [legitimate uses guide](/dpdp-legitimate-uses) goes ground by ground.
- **Section 7(b) is for the State.** A private NGO or contractor delivering a scheme usually acts as the State's processor, or needs its own basis.

### Sensitive data under SPDI consents

Until 13 May 2027, body corporates collecting sensitive personal data must have consent in writing (by letter, fax or email) for its purpose, under rule 5(1) of the SPDI Rules, 2011. A written SPDI consent that names a specific purpose and can be produced is good evidence for question 3. One folded into a privacy policy that she accepted along with everything else is weak under section 6(1). The DPDP Act has no sensitive category, but the type of data affects any penalty (s. 33(2)(b)), so we prioritise health, financial, biometric and children's records in the campaign.

### Data you received from partners or funders

When a partner, implementing NGO or funder shared personal data with you, ask what she was told. If the partner's notice named you or your purpose and the partner can produce the consent records, the consent can support question 3. If it did not, treat the data as unproven and re-consent or erase. Where you and the partner both decide purpose and means, both are fiduciaries (s. 2(i)): agree in writing who sends the section 5(2) notice so she receives one message, not two. The [CSR foundations guide](/dpdp-for-csr-foundations) covers funder roles.

### Children, and people with lawful guardians

Section 9(1) requires verifiable parental consent "before processing any personal data of a child", and storage is processing (s. 2(x)). Our view: section 5(2) does not lift that duty, so route legacy records of children still under eighteen to re-consent unless the old consent already met Rule 10, using reliable identity and age details you already hold (Rule 10(1)(a)), details she provides, such as an ID showing date of birth (Rule 10(1)(b)(i)), or a virtual token from an authorised entity such as DigiLocker (Rule 10(1)(b)(ii)). The same goes for adults whose lawful guardian consents (s. 9(1), Rule 11), which applies only to a person who, despite adequate support, cannot take legally binding decisions (Rule 11(2)(d)); the [children's data guide](/dpdp-childrens-data) covers methods.

A person who was a child when her parent consented and is now an adult is the Data Principal herself (s. 2(f), 2(j)). Send the section 5(2) notice to her directly.

## When re-consent is worth it

Re-consent needs a full notice under section 5(1) and Rule 3, a consent that meets section 6(1), and a record you can produce. People who ignore the request have not agreed. We recommend re-consenting only where:

- the purpose is live and you would collect the data again today;
- you hold a channel she registered and can reach her on it;
- you can record each answer against the notice version;
- the alternative is losing something she would want, such as updates on her application;
- no section 7 use fits.

Do not tie the request to the service. "Agree to research use or lose your scholarship updates" makes consent conditional and fails section 6(1). Ask for each optional purpose separately.

### A volume worksheet

Fill in your own numbers before committing. We give no costs or response rates, because they depend on your channels and your people.

| Line | Formula | Your figure |
|---|---|---|
| A. Records to contact | From the decision list | |
| B. Attempts per record | We recommend at least two, on different days | |
| C. Channels per attempt | SMS, WhatsApp, email, IVR, field | |
| D. Outbound messages | A × B, split by channel (C) | |
| E. Template lead time | Ask your SMS and WhatsApp providers how long template registration and approval take; add translation and review | |
| F. Helpline calls expected | D × your own estimate of the call-back rate | |
| G. Helpline capacity | Agents × calls per agent per day × campaign days | Must exceed F |
| H. Field visits | Records reachable only in person ÷ visits per facilitator per day | |

## Running the notice and re-consent campaign

Keep the two message types separate. A section 5(2) notice informs her that you will continue on her existing consent; she need not reply. A re-consent request asks a question, and only a yes lets you continue.

### Illustrative section 5(2) notice by SMS

> [Organisation] holds your name, mobile number, village and course record from your 2024 tailoring training, used to send you job and course updates, as you agreed. Full notice, your rights, and how to complain to the Data Protection Board: example.org/notice or call 1800-XXX-XXXX. To stop updates, reply STOP or give a missed call to 9XXXXXXXXX.

Illustrative only. Send it in the Scheduled language she uses. The link must open a notice that meets Rule 3 on its own: itemised data, purposes, and the link and other means to withdraw, exercise rights and complain to the Board (Rule 3(a)–(c)). The Board has no confirmed online complaint facility as of 25 October 2026, so point to your own page explaining how to complain, and update it when the Board publishes a route. The [notice-writing guide](/dpdp-consent-notice) has full texts.

### Illustrative re-consent request by SMS

> [Organisation]: before you reply, read or hear our notice on your 2024 training record (what we hold, why, your rights, how to withdraw and how to complain to the Data Protection Board): example.org/consent or call 1800-XXX-XXXX. Reply 1 if we may send you job and course updates. Reply 2 if we may use your photo in reports to donors. Reply 12 for both. To change your mind later, reply STOP1 for updates, STOP2 for photos, or STOP for both. If you do not reply, we will not use your data for these purposes.

The notice comes with the question, as section 5(1) requires ("accompanied or preceded"), and each purpose has its own answer.

### Illustrative field or IVR script

1. Greet her, say who you are and why you are calling or visiting.
2. Play or read the whole notice, including withdrawal, her rights and how to complain to the Board, in the Scheduled language she chooses, with dialect audio if she prefers, before any question (s. 5(1)). Confirm she has heard it.
3. Ask: "May we send you job and course updates by SMS?" Record yes or no.
4. Ask: "May we use your photograph in reports to donors?" Record yes or no. Do not pre-fill either answer.
5. Tell her how to change her mind for each purpose: the number to call, or STOP1, STOP2 or STOP.
6. On IVR, after the notice: "Press 1 for yes to updates. Press 2 for yes to photographs. Press 3 for yes to both." Later calls offer "press 7 to stop updates, 8 to stop photographs, 9 to stop both." Each key is logged separately; a hang-up before the prompts finish records no answer.

The [field consent guide](/dpdp-field-consent) covers oral and assisted consent in depth.

### Choosing the channel

| Channel | Use it for | Proof to keep | Watch for |
|---|---|---|---|
| SMS | Mobile numbers she gave you | Provider's delivery report; message ID; template version | Templates go through your provider under TRAI's commercial-communication rules; always give a phone number as well as a link, for feature phones |
| WhatsApp | Numbers she uses with you on WhatsApp | Delivery and read receipts; button responses | WhatsApp's own opt-in policy; never from staff personal accounts |
| Email | Donors, customers, alumni, business contacts | Send log, bounces, withdrawal and reply clicks | Put the notice in the body; bounces go to the unreachable track |
| IVR | Low-literacy groups, feature phones, dialect speakers | Number, time, duration, prompts played, keys pressed | A call that ends before the notice plays is not delivery |
| Field visit | Children's and families' records, vulnerable groups, people no other channel reaches | App record: facilitator, time, notice version and language, each answer | Script it so facilitators do not improvise content |
| In-app banner | Active users of your app or portal | Display and acknowledgement event per user | Pair with SMS or email; an unread banner is weak evidence |

We recommend starting with the cheapest channel she registered, then escalating, and reserving field visits for children's data, vulnerable groups and people no channel reaches.

Offer the notice in English or an Eighth Schedule language, with dialect audio where needed (s. 5(3)); the [notice-writing guide](/dpdp-consent-notice) covers language choice and translation records.

## What to log for every contact

Keep one row per person, per data set, per attempt.

| Field | Example |
|---|---|
| Person and identifier | Trainee 21-0457 · mobile ending 3391 |
| Data set, outcome and purposes | Skilling CRM, 2021–2024 · section 5(2) notice · course and job updates |
| Basis relied on | s. 5(2), consent recorded at enrolment on form v2.1 |
| Notice version and language | s5(2)-notice v1.0 · Hindi; Santali audio offered |
| Channel, attempt and time | SMS · attempt 1 of 2 · 18 May 2027 10:02 IST |
| Delivery status | Delivered (provider receipt) |
| Response and action | STOP · removed from update list and provider suppression list 19 May 2027 |
| Processors told | SMS provider, CRM vendor · date |

At campaign level, keep the query that defined each recipient list and its run date; every notice text and translation with version and approval; a suppression list of people who withdrew, so later campaigns and restored backups never contact them; and daily totals of sent, delivered, failed, withdrawn and unanswered for your leadership.

## SaaS companies and processors

If your customer decides why and how data is processed, it is the fiduciary and sends the section 5(2) notices. Your job is to make that possible: per-customer exports of the people in scope, the consent evidence you hold, and the ability to process withdrawals and suppressions quickly across your system and your sub-processors (s. 6(6), 8(7)(b)). Expect customers to ask for a backfilled consent ledger with these fields:

| Field | Note |
|---|---|
| Subject identifier | The customer's ID, not only yours |
| Purpose | One row per purpose |
| Source of consent | Form, app, import, partner |
| Original notice version and date | Or "unknown", which sends the record to re-consent |
| Evidence pointer | Log ID, file, timestamp |
| Section 5(2) notice sent | Date, channel, delivery status |
| Withdrawal | Date and propagation status to sub-processors |

Where you use customer data for your own purposes, such as product analytics or model training, you decide those purposes and, in our view, are the fiduciary for them, so the notices for that processing are yours. The [SaaS guide](/dpdp-for-startups) covers roles.

## People you cannot reach, or who do not answer

Section 5(2)(a) asks for a notice "as soon as it is reasonably practicable"; it does not say what happens when you cannot deliver one. We suggest a ladder:

1. Try every channel she registered with you.
2. Try again on a different day and at a different hour.
3. Ask a community worker or self-help group leader to pass on a message asking her to call you. Do not give them her data or let them decide for her.
4. Publish the notice on your website, app login page and centre notice boards, as a backstop to the steps above.

**Our recommended defaults:**

- **Unreached after notice:** a section 5(2) notice undelivered after two documented attempts on different channels. Keep processing to the minimum, add no new uses, and try again at the next scheduled contact. If she is still unreached twelve months after the last attempt, erase; that also clears the Rule 8(3) floor.
- **No answer to re-consent:** two attempts over at least 30 days with no reply. Stop that purpose and erase data held only for it; from 13 May 2027 this is subject to the Rule 8(3) floor. Restrict anything a law requires you to keep.
- **Dormant:** delivered or not, she has not approached you and no service has run for her for three years. Erase, unless a law says otherwise. Section 8(7)(a) requires erasure once "it is reasonable to assume that the specified purpose is no longer being served"; the Rules fix that period only for large e-commerce, gaming and social media platforms (Rule 8(1), Third Schedule), so everyone else must choose and justify one.

Write the default into your retention schedule before the campaign starts, so field teams and IT apply the same rule.

## Erasing every copy, including derived data

| Location | Method | Evidence |
|---|---|---|
| System of record | Hard delete, or irreversible anonymisation where you need aggregate history | Erasure job log: record IDs, data set, date, job |
| Warehouses, dashboards, search indexes, caches | Rebuild from the cleaned source, or delete by ID | Job log; row counts before and after |
| Derived data: analytics tables, embeddings, features, trained models | Delete per-person rows and embeddings; for models, retrain on cleaned data or document why the model cannot reproduce her data | Job log; model card or decision note |
| Exports, inboxes, shared and personal drives | Search by data set name and identifiers; delete and empty trash; get a signed confirmation from each holder | Search terms; confirmations |
| Field phones and WhatsApp | Delete chats and media; exit and archive groups; wipe returned devices | Device and group list with date and confirmer |
| Processors | Written instruction under s. 8(7)(b) and the contract | Processor's confirmation of scope and date |
| Partners who are fiduciaries | Tell them; their erasure is their duty | Copy of notice and reply |
| Backups | Expire on a documented cycle; never restore erased records | Backup policy; suppression list |

The Act says nothing specific about models or embeddings; the derived-data row is our recommended practice. For backups, follow the approach in the [Act guide](/dpdp-act-guide#if-you-are-the-processor): Rule 6(1)(d) requires them, and the Rules are silent on erasing from them. If a vendor contract has no erasure clause, add one now; the [processor contracts guide](/dpdp-processor-contracts) has terms.

### The one-year floor after 13 May 2027

Rule 8(3) requires every fiduciary to keep personal data, associated traffic data and processing logs for at least one year "from the date of such processing", for the Seventh Schedule purposes, and then erase them unless another law requires more. Rule 6(1)(e) separately asks for a year of logs and personal data for security investigations. Storage is itself processing (s. 2(x)), so read literally the year never starts while you hold the data. Our view: count the year from the last operation other than storage, such as the last use, update or disclosure. On that reading, data you have not used, updated or disclosed for over a year can be erased at once. Data you used recently, including data that was the subject of a section 5(2) notice, may need to sit in locked storage until the year passes, even after she withdraws: stop all use, take it out of operational systems, and keep it only for the Seventh Schedule purposes. Tell her that is what you are doing.

Neither rule applies before 13 May 2027, which is one more reason to finish erasure first. Other laws, such as accounting, tax, labour and sector rules, set their own periods; section 8(7) yields to them. List the law and period for each data set; Your [data map](/dpdp-data-mapping) is the natural place to record them.

## A skilling nonprofit's legacy data, sorted

This illustration is a composite, not a client story. A skilling nonprofit in Jharkhand has trained young women since 2018. In November 2026 it holds about 60,000 trainee records across a CRM, three years of Google Sheets from before the CRM, an alumni WhatsApp community and a donor database.

**The sort.** The 2018–2020 sheets were typed from paper forms with no consent wording, and placement tracking for those cohorts ended years ago: erase. The CRM records from 2021 were collected on a tablet form with a Hindi consent screen for "course and job updates" and a logged yes: section 5(2) notice. The same form had a pre-ticked box for photographs: re-consent. About 1,800 current trainees are under eighteen: re-consent with verifiable parental consent. Trainer payroll rests on section 7(i), donor receipts on tax law: record the basis. The donor newsletter was double opt-in: notice.

**Before May.** It erases the old sheets and their copies in staff drives in December 2026, logs the erasure, and keeps district-level counts. In January it rebuilds the tablet form: a Rule 3 notice in Hindi with Santali audio, separate unticked choices for updates and photographs, and a parent step that records identity and age from a document showing date of birth or a DigiLocker token. The WhatsApp community closes and alumni updates move to SMS. The SMS and CRM vendors sign contracts with erasure and breach clauses. In February and March, facilitators visiting current trainees ask parents separately about photographs and record verified parental consent.

**After 13 May 2027.** In the week of 17 May, SMS notices go to the alumni and the donor list. Failures get WhatsApp, then IVR. Alumni who reply STOP join the suppression list the next day. Those unreached after two attempts are held, retried at the October alumni meet, and erased if still unreached a year after the last attempt. Campaign logs stay for a year (Rule 8(3)).

## Where the law is unclear

These are our positions until the Board or the courts settle them.

**Does "commencement" in section 5(2) mean 13 May 2027?** Yes. *Why:* section 1(2) ties references to commencement to the coming into force of the provision. *Would change if:* the commencement date is amended. *Confidence:* high.

**Does a notice sent before 13 May 2027 discharge section 5(2)(a)?** Possibly, if it already contained everything section 5(2)(a) and Rule 3 require and stays accurate. *Why:* the duty arises at commencement, and the rights and Board route it must describe exist only from then; the text does not say whether an earlier notice counts. We recommend a short confirmation after May. *Would change if:* the Board or MeitY issues guidance. *Confidence:* low.

**Must a pre-commencement consent meet section 6(1) to count?** Probably, in practice. *Why:* section 5(2) asks only that she "has given her consent", but section 6(10) requires proof of consent "in accordance with" the Act and Rules. *Would change if:* the Board accepts old-style consents in an early case. *Confidence:* low.

**Can section 7(a) cover data collected without any notice?** Narrowly. *Why:* "specified purpose" is defined by a notice (s. 2(za)), and the Act's pharmacy illustration shows a narrow, obvious purpose. *Would change if:* the Board reads 7(a) broadly or strictly. *Confidence:* low.

**Does section 5(2) relieve the section 9(1) duty for legacy children's data?** We think not. *Why:* section 9(1) requires verifiable consent before any processing of a child's data, and continued storage is processing; section 5(2) deals with notice for old consents. *Would change if:* a notification or decision treats legacy parental consent as sufficient. *Confidence:* medium.

**Is an SMS with a link a notice "given" to her?** Yes, if the SMS states the data and purpose and the linked notice meets Rule 3, with a phone route for people without data. *Why:* Rule 3(c) contemplates a link plus "other means"; Rule 3(a) requires the notice to be understandable on its own. *Would change if:* the Board expects the full notice in the message. *Confidence:* medium.

**May you keep processing for people you could not reach?** For a limited time, with documented attempts. *Why:* section 5(2)(b) is not stated to depend on delivery, and section 5(2)(a) asks for what is reasonably practicable; indefinite reliance is hard to square with section 8(7)(a). *Would change if:* the Board sets expectations for reach. *Confidence:* medium.

**When does the Rule 8(3) year start for data you only store?** From the last operation other than storage. *Why:* storage is processing (s. 2(x)), so a literal reading never starts the clock, which cannot be what a minimum period intends. *Would change if:* guidance defines "the date of such processing". *Confidence:* low.

**Does the Rule 8(3) floor delay erasure after withdrawal?** For storage, probably yes; for use, no. *Why:* after withdrawal you must stop processing unless the Act, the Rules or another law requires or authorises it (s. 6(6)); the erasure duty yields to retention necessary under law (s. 8(7)); and Rule 8(3) is such a requirement. *Would change if:* guidance clarifies the interaction. *Confidence:* medium.

## A calendar to 13 May 2027 and after

Only the rows citing a section reflect a legal duty; the rest are planning dates.

| When | What | Who |
|---|---|---|
| By 30 November 2026 | Data map with every data set and an owner for each | Data owners, led by the DPDP owner |
| By 15 December 2026 | Decision list applied to every data set and purpose; basis written down | DPDP owner, legal, programme heads |
| December 2026 to February 2027 | Erasure of everything marked erase, across exports, drives, phones, derived data and processors | IT, data owners, vendors |
| By 31 January 2027 | Every live collection point carries a Rule 3 notice and a section 6 consent with records | Product, programmes, field leads |
| January to March 2027 | Notice and re-consent texts translated; templates approved; IVR recorded; field scripts tested; worksheet filled | Comms, field leads, legal |
| February to April 2027 | Re-consent campaigns; verifiable parental and guardian consent | Field teams, product |
| April 2027 | Dry run on a sample of 500 records, including withdrawals and suppressions | Operations, IT |
| From 13 May 2027 | Section 5(2) notices, as soon as reasonably practicable (s. 5(2)(a)) | Operations |
| June to August 2027 | Follow-ups; unreached records held or erased under your default | Operations, field teams |
| Monthly from June 2027 | Leadership report: delivered, withdrawn, unreached, erased | DPDP owner |

A small organisation can run the same plan on one page: list data sets, erase what you do not need by Christmas, fix forms by January, and send one SMS or email notice to everyone who consented in the week after 13 May 2027. The [NGO hub](/dpdp-for-nonprofits) has a minimum version for small teams.

**How we wrote this guide.** We worked from the text of the Digital Personal Data Protection Act, 2023 (No. 22 of 2023), the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), the commencement notification G.S.R. 843(E) and the DPDP (Removal of Difficulties) Order, 2026 (S.O. 5458(E), 5 October 2026), which corrects the wording of section 9(1) without adding duties or moving dates. Events after 13 November 2025 come from the linked public reports, last checked 25 October 2026. Statements marked "our view", "our position" or "we recommend" are our judgement, not the law. This guide explains the law; it is not legal advice.
{: .note }

## Questions people ask

### Does section 5(2) apply to a marketing list we bought or rented?

Our view: no. Section 6(10) asks you to prove that consent was given 'to the Data Fiduciary', and a consent she gave a list broker was not given to you for your purposes. You would need your own basis: a fresh notice and consent under sections 5(1) and 6, or a section 7 legitimate use, and none of the section 7 uses fits cold marketing. Stop using bought lists, erase them, and ask any future seller for the notice text and consent records before you buy.

### Do we need to send a section 5(2) notice to our employees?

Only for processing based on their consent, such as photographs on your website or a voluntary wellness programme. Most employment processing, such as payroll and attendance, can rest on section 7(i), and section 5(2) does not apply to it. The rights to access and to correction and erasure cover data given on consent or under section 7(a) (s. 11, 12). The rights to grievance redressal and to nominate apply whatever the basis (s. 13, 14). Tell staff through HR how to use them; see our employee data guide.

### A person asks us to delete her data in January 2027. Does DPDP require us to?

Not yet. The right to erasure (s. 12(3)) and the duty to erase on withdrawal (s. 8(7)) commence on 13 May 2027. Until then, body corporates remain bound by the SPDI Rules, 2011, and any sector rules. We recommend honouring the request now unless another law requires you to keep the data, and recording what you did.

### Can we keep anonymised data after erasure?

Yes, if it is genuinely anonymised. The Act covers data about an individual who is identifiable by or in relation to that data (s. 2(t)); data that identifies no one falls outside it. Test it practically: could your staff, a partner or an attacker re-identify a person using the data together with what else they hold? Aggregate counts for a large area are lower risk. A row-level table with age, gender, village and caste can identify people in a small village.

### Can a Consent Manager run our re-consent campaign?

Not as your agent. A person may give, manage, review or withdraw consent through a registered Consent Manager (s. 6(7)), which is accountable to her (s. 6(8)). Applications for registration open on 13 November 2026 (Rule 4), but they go to a Board that, as of 25 October 2026, has no Chairperson or Members, so we have found no registered Consent Manager yet. For a legacy campaign, your own SMS, email, IVR and field teams remain the route. See our Consent Managers guide.

### Is paper data covered by section 5(2)?

Only once it is digitised. The Act applies to personal data collected in digital form, or collected on paper and digitised later (s. 3(a)). A register kept only on paper is outside it. A scanned register, a phone photo of it, or a spreadsheet typed from it is inside it. Our view: treat paper you digitise after 13 May 2027 as new collection and give a notice under section 5(1) at that point.

## About Commons Trust

Commons Trust is a DPDP compliance programme and consent management platform from commons.inc that takes nonprofits, foundations, startups and corporates from wherever they are to fully compliant with India's Digital Personal Data Protection Act. Contact: hello@commons.inc · https://dpdp.commons.inc/#start