The right to erasure under India’s Digital Personal Data Protection Act, 2023 is an important privacy right— but it is not an unconditional “right to be forgotten.” Section 12 gives a Data Principal the right to request erasure of personal data, subject to an important limitation: a Data Fiduciary may retain the data where retention is necessary for the specified purpose or for compliance with a law in force.

For organisations, this means that implementing the right to erasure is not simply a matter of adding a “Delete My Data” button. It requires a defensible framework for identifying personal data, determining whether retention is still necessary, coordinating deletion across processors and systems, handling legally required records, and maintaining evidence of compliance.

The Digital Personal Data Protection Act, 2023 (“DPDP Act”) therefore approaches erasure through two complementary mechanisms:

1. a Data Principal’s right to request erasure under Section 12; and
2. a Data Fiduciary’s independent obligation to erase data when the specified purpose is no longer being served, subject to applicable retention requirements, under Section 8.

The Digital Personal Data Protection Rules, 2025 (“DPDP Rules”) add an important operational layer by prescribing circumstances in which certain classes of Data Fiduciaries must erase personal data after specified periods of inactivity.

1. What Is the Right to Erasure Under the DPDP Act?

Section 12 of the DPDP Act is titled “Right to correction and erasure of personal data.”

Under Section 12(1), a Data Principal has the right to:

• correction;
• completion;
• updating; and
• erasure

of personal data for the processing of which the Data Principal has previously given consent, including consent referred to in Section 7(a), subject to the requirements or procedures under applicable law.

The erasure component is specifically addressed by Section 12(3).

In substance, the provision requires a Data Fiduciary to erase personal data when the Data Principal requests erasure unless retention is necessary for the specified purpose or for compliance with a law in force.

This is the central legal principle:

The DPDP Act creates a conditional right to erasure, not an absolute right to deletion.

That distinction is critical.

A business cannot simply say that a customer has no right to deletion because it has a “legitimate business need.” At the same time, a Data Principal cannot necessarily demand deletion of every record where another applicable law requires the organisation to retain it.

The correct analysis is therefore:

What data is being requested for erasure → why is it being processed → is the specified purpose still being served → is retention necessary → does another law require retention → what data can actually be erased?

2. Is the DPDP Right to Erasure the Same as the GDPR Right to Be Forgotten?

No.

This is one of the most important distinctions that businesses should understand.

The GDPR contains a broadly framed right to erasure, commonly described as the “right to be forgotten,” under Article 17. Its legal architecture includes several grounds on which an individual can request erasure.

The DPDP Act takes a different approach.

Section 12 expressly connects the right to erasure to personal data processed for which the Data Principal has previously given consent, including the situation referred to in Section 7(a).

Therefore, organisations should avoid simply copying a GDPR Article 17 policy and labelling it a DPDP-compliant erasure procedure.

Key distinction

Issue	DPDP Act	GDPR
Statutory right	Section 12	Article 17
Terminology	Right to erasure	Right to erasure / commonly “right to be forgotten”
Scope	Expressly linked to consent-based processing under Section 12	Applies across several legal bases, subject to Article 17 conditions
Absolute right?	No	No
Legal retention exception	Yes	Yes
Purpose-based retention	Central to the DPDP framework	Relevant, but structured differently
Operational framework	DPDP Rules provide additional mechanisms	GDPR/Member State framework and guidance

Compliance lesson: A GDPR-style deletion policy may be useful as a starting point, but it should not be treated as a substitute for a DPDP-specific legal analysis.

3. Section 12: Breaking Down the Right to Erasure

Section 12 actually combines four different rights:

3.1 Right to correction

A Data Principal can request correction of inaccurate or misleading personal data.

3.2 Right to completion

Where personal data is incomplete, the Data Principal can request that it be completed.

3.3 Right to updating

Where information has changed, the Data Principal can request that it be updated.

3.4 Right to erasure

The Data Principal can request deletion of personal data, subject to the statutory retention exception.

The four rights should not be treated as interchangeable.

For example:

“My address is incorrect” is primarily a correction/update request.

“I no longer want you to retain my old marketing profile” may be an erasure request.

“My account is closed, so delete all information about me” is an erasure request, but it still requires an assessment of whether particular records must be retained.

This distinction becomes important when designing Data Principal Rights Request (“DPRR”) workflows.

4. When Must a Data Fiduciary Erase Personal Data?

Section 12(3) establishes the basic rule:

On receiving an erasure request, the Data Fiduciary must erase the relevant personal data unless retention is necessary for:

1. the specified purpose; or
2. compliance with a law in force.

This creates a two-stage decision.

Stage 1: Identify the data

The organisation must determine what personal data relates to the request.

This may include data stored in:

• customer databases;
• CRM systems;
• HR systems;
• billing platforms;
• marketing platforms;
• support systems;
• mobile applications;
• websites;
• data warehouses;
• analytics platforms;
• cloud storage;
• archives;
• logs; and
• Data Processors’ environments.

Stage 2: Apply the retention test

For each category of data, the organisation should ask:

Is retention necessary for the specified purpose?

If the answer is no, the default position should move towards erasure.

If the answer is yes, the organisation should document why.

The organisation should separately ask:

Is retention required by another applicable law?

If yes, the relevant data may need to be retained for the required period.

5. “Business Need” Is Not Automatically a Valid Reason to Refuse Erasure

This is an area where many DPDP compliance policies can go wrong.

A company should not respond:

“We need to retain your data because it is important to our business.”

That is too broad.

The DPDP framework requires a connection between retention and the specified purpose or a legal requirement.

A defensible retention assessment should instead identify:

• the particular category of personal data;
• the specified purpose;
• why that purpose continues to exist;
• the applicable retention period, if any;
• the law requiring retention, where applicable;
• who has access to the retained data; and
• when the data will ultimately be erased.

Example

Suppose a customer closes an account.

The organisation may have:

• marketing preferences;
• account profile information;
• transaction history;
• invoices;
• payment records;
• fraud-prevention records;
• customer-support correspondence; and
• authentication logs.

It may not be appropriate to treat all of these categories identically.

Some information may no longer be required and should be erased.

Other information may need to remain because an applicable law requires retention.

Therefore:

Account closure ≠ automatic deletion of every database record.

But equally:

Legal retention of one category ≠ permission to retain everything indefinitely.

This is a crucial compliance principle.

6. Right to Erasure and Consent Withdrawal Are Different

Another common mistake is treating withdrawal of consent and erasure as the same request.

They are related but legally distinct mechanisms.

Under the DPDP framework, a Data Principal can withdraw consent, while Section 12 provides a separate right concerning correction, completion, updating and erasure.

Section 8 also creates an independent obligation concerning erasure when consent is withdrawn or when it is reasonable to assume that the specified purpose is no longer being served.

Practical distinction

Withdrawal of consent

The Data Principal says:

“I no longer consent to this processing.”

Erasure request

The Data Principal says:

“Erase my personal data.”

In a mature privacy programme, these requests should trigger linked but distinct workflow events.

For example:

Consent withdrawn → stop applicable processing → assess retention → erase data where required → retain only what is legally or purposefully necessary.

7. Section 8 Creates a Separate Erasure Obligation

This is one of the most significant points that should be included in any serious article on DPDP erasure.

The Data Fiduciary does not have to wait for a Data Principal to submit an erasure request.

Section 8(7) requires a Data Fiduciary to erase personal data when:

• the Data Principal withdraws consent; or
• it is reasonable to assume that the specified purpose is no longer being served,

whichever is earlier, subject to the statutory retention exception.

The Act also requires the Data Fiduciary to cause its Data Processor to erase personal data that was made available for processing.

This is the storage-limitation / purpose-limitation side of DPDP compliance.

Therefore, there are two routes to deletion:

Route 1 — Request-driven

Data Principal → erasure request → Data Fiduciary assesses → erase unless retention exception applies.

Route 2 — Organisation-driven

Consent withdrawn / purpose completed → Data Fiduciary assesses → erase unless retention exception applies.

A privacy programme that only handles individual deletion requests but does not conduct periodic retention reviews is therefore incomplete.

8. What Do the DPDP Rules, 2025 Say About Erasure?

The final DPDP Rules, 2025 introduce more detailed requirements around retention and erasure.

Rule 8 deals with the point at which a specified purpose is deemed no longer to be served for specified classes of Data Fiduciaries and purposes.

For covered entities, personal data must be erased after the applicable period where the Data Principal has neither:

• approached the Data Fiduciary for performance of the specified purpose; nor
• exercised her rights in relation to the processing,

unless retention is required by law.

The Rules also require advance communication.

At least 48 hours before the applicable erasure period expires, the Data Fiduciary must inform the Data Principal that the personal data will be erased unless the Data Principal logs into the account, otherwise initiates contact for the specified purpose, or exercises rights relating to the processing.

This is an important compliance development because it moves the framework beyond simply responding to deletion requests.

It creates a mechanism for proactive, lifecycle-based data deletion.

9. The Three Categories Specifically Covered by Rule 8

The Third Schedule identifies specific large-scale Data Fiduciaries for the purpose of Rule 8’s prescribed inactivity periods.

These include:

1. Large e-commerce entities

The rule applies to an e-commerce entity having not less than two crore registered users in India.

For covered purposes, the relevant period is three years from the date on which the Data Principal last approached the Data Fiduciary for the specified purpose or exercised rights, or from commencement of the DPDP Rules, 2025, whichever is later. Certain account and virtual-token functions are excluded.

2. Large online gaming intermediaries

The rule applies to an online gaming intermediary having not less than fifty lakh registered users in India.

The corresponding inactivity period is also three years, subject to the exclusions specified in the Third Schedule.

3. Large social media intermediaries

The rule applies to a social media intermediary having not less than two crore registered users in India.

Again, the specified period is three years, subject to the exclusions in the Schedule.

These thresholds should not be mistakenly presented as a general three-year deletion rule applicable to every business in India.

They are specific Rule 8 / Third Schedule requirements applying to identified classes of Data Fiduciaries and purposes.

10. The One-Year Retention Requirement for Certain Processing Logs

Rule 8 contains another important provision that organisations should not overlook.

For processing covered by the Seventh Schedule, the Data Fiduciary must retain the relevant personal data, associated traffic data and other processing logs for a minimum of one year from the date of processing, after which the data and logs must be erased unless further retention is required by applicable law or notified by the Government.

This creates an important distinction between:

User-requested deletion and mandatory regulatory retention.

For example, the Rules themselves illustrate a scenario where an e-book platform may need to retain order information and processing logs for at least one year even after the customer deletes the account.

This is why a “delete account” function cannot be designed as:

DELETE FROM customer_table WHERE customer_id = X

Real-world compliance requires a data-category-by-data-category retention analysis.

11. What Happens When Data Is With a Data Processor?

The DPDP Act places responsibility on the Data Fiduciary to cause its Data Processor to erase personal data that was made available to the processor for processing.

This is particularly important for modern technology environments.

A company may have customer information distributed across:

• SaaS applications;
• cloud hosting providers;
• payment processors;
• CRM providers;
• email platforms;
• customer-support platforms;
• analytics providers;
• identity-verification providers;
• marketing technology providers; and
• outsourced service providers.

Deleting data from the primary application is therefore not necessarily sufficient.

A mature erasure workflow should look like this:

Data Principal request

↓

Identity / request verification

↓

Data discovery

↓

Data inventory and classification

↓

Retention assessment

↓

Deletion decision

↓

Deletion from primary systems

↓

Deletion / instruction to Data Processors

↓

Deletion from eligible secondary systems

↓

Backup / archive handling

↓

Validation

↓

Completion notification

↓

Audit record

This is where legal compliance meets technology architecture.

12. What About Backups?

Backups present one of the most difficult operational questions.

Organisations frequently maintain:

• disaster-recovery backups;
• database snapshots;
• immutable backups;
• archival copies;
• security logs;
• system logs; and
• business-continuity copies.

A sound DPDP implementation should therefore distinguish between:

Active production data

Data that is readily accessible and actively used for processing.

Backup data

Data retained primarily for disaster recovery or business continuity.

Legally retained data

Data that must remain available because of an applicable legal obligation.

The organisation should define a documented backup-retention and restoration strategy rather than assuming that every backup must be manually modified every time an erasure request arrives.

The critical objective should be to ensure that deleted data does not simply re-enter active processing when a backup is restored.

Where retention is permitted or required, access should also be appropriately restricted.

13. Can a Company Refuse an Erasure Request?

Yes—but the refusal should be legally and operationally defensible.

The DPDP Act expressly recognises retention where it is necessary for:

• the specified purpose; or
• compliance with a law in force.

A good refusal should therefore not merely say:

“Your request has been rejected.”

Instead, the organisation should explain, to the extent appropriate:

• which category of personal data is being retained;
• why it must be retained;
• whether the reason is an ongoing specified purpose or a legal obligation;
• the applicable retention period, where determinable;
• what data has nevertheless been erased; and
• what happens when the retention period expires.

Partial compliance may be the correct outcome.

For example:

Data category	Outcome
Marketing profile	Erase
Promotional preferences	Erase/update
Closed-account profile	Potentially erase, subject to retention assessment
Transaction record	Retain if legally required
Invoice	Retain if legally required
Security/fraud record	Retain where justified by applicable requirements
Unnecessary analytics copy	Erase
Processor copy	Instruct processor to erase where required

The DPDP Act should not be interpreted as creating an all-or-nothing approach.

14. Special Consideration for State Processing

The Act contains specific exemptions concerning processing by the State and its instrumentalities.

Section 17(4) expressly provides that, in specified State processing circumstances, Section 12(3) does not apply, and Section 8(7) is also disapplied. There is also a conditional exclusion concerning Section 12(2).

This means a general statement such as:

“Every Data Principal can always demand deletion of personal data under the DPDP Act”

would be legally overbroad.

The applicability of the right must always be checked against the Act’s exemptions and the nature and purpose of the processing.

15. How Should a Data Principal Make an Erasure Request?

The DPDP framework is designed around readily accessible mechanisms through which Data Principals can exercise their rights.

The final Rules require organisations to provide a mechanism through which Data Principals can exercise their rights, including through the Data Fiduciary’s website or application.

A practical request could state:

Subject: Request for Erasure of Personal Data under Section 12 of the DPDP Act, 2023

I request erasure of my personal data processed by your organisation under Section 12 of the Digital Personal Data Protection Act, 2023.

Please identify the personal data covered by this request and erase such data unless retention is necessary for the specified purpose or required under applicable law.

If any personal data is retained, please provide the applicable basis for retention and, where possible, the expected retention period.

A Data Fiduciary should then route the request into its formal rights-request workflow.

16. What Should Businesses Do When an Erasure Request Is Received?

A DPDP-compliant operating procedure should contain at least the following stages.

Step 1: Receive the request

Capture:

• date and time;
• requester details;
• request type;
• channel;
• account/reference information; and
• scope of the request.

Step 2: Verify the requester

Verification should be proportionate.

The organisation should avoid collecting excessive additional personal information merely to process a privacy request.

Step 3: Identify the relevant data

Map the Data Principal across:

• databases;
• applications;
• business functions;
• processors;
• analytics systems;
• archives; and
• other relevant repositories.

Step 4: Identify the purpose

For every relevant category, identify the original or applicable specified purpose.

Step 5: Apply the retention test

Ask:

Is retention necessary for the specified purpose?

and:

Is retention required by law?

Step 6: Determine the disposition

Each data set should be assigned an outcome:

• erase;
• retain;
• partially erase;
• restrict access;
• anonymise where appropriate; or
• otherwise handle according to the applicable legal requirement.

Step 7: Cascade the decision

Where relevant, instruct Data Processors and other service providers.

Step 8: Validate

Confirm that deletion has occurred across the systems covered by the workflow.

Step 9: Document

Maintain an appropriate audit record showing:

• request received;
• verification performed;
• systems searched;
• data identified;
• retention analysis;
• legal basis for retention;
• deletion actions;
• processor instructions;
• completion date; and
• response provided to the Data Principal.

17. The Role of Data Mapping in DPDP Erasure Compliance

An organisation cannot reliably erase data that it cannot locate.

This makes data mapping one of the foundational requirements for an effective DPDP programme.

A data inventory should ideally identify:

Data element	Purpose	System	Processor	Retention	Erasure method
Name	Account management	CRM	Cloud provider	Defined period	Application deletion
Email	Account communication	CRM	Email provider	Defined period	Delete/propagate
Phone	Authentication	IAM	SMS provider	Defined period	Delete
Transaction data	Transaction record	ERP	Cloud provider	Legal requirement where applicable	Retention then deletion
Marketing profile	Marketing	CDP	Marketing vendor	Consent/purpose based	Delete
Support tickets	Customer support	Helpdesk	SaaS provider	Defined period	Delete/archive as applicable

Without such mapping, an organisation’s deletion process will inevitably have blind spots.

18. DPDP Erasure and Data Retention Policies Must Work Together

A common compliance mistake is creating:

Policy A — Data Retention Policy

and

Policy B — Data Subject Rights Policy

without connecting them.

That approach creates operational inconsistency.

The retention policy should define:

• categories of data;
• purposes;
• retention periods;
• legal retention requirements;
• deletion triggers;
• responsible teams; and
• disposal mechanisms.

The rights procedure should then use those rules when processing an erasure request.

In other words:

Retention policy determines how long data should ordinarily remain.

Erasure workflow determines what happens when an individual asks for deletion.

Legal-hold / regulatory requirements determine what cannot yet be deleted.

These three components must operate together.

19. DPDP Erasure Compliance: Common Mistakes

Mistake 1: Treating DPDP as GDPR

The DPDP Act has its own statutory architecture.

A GDPR policy copied without modification may create incorrect assumptions about the scope of the right.

Mistake 2: Assuming every deletion request must result in complete deletion

Section 12 expressly recognises retention exceptions.

Mistake 3: Deleting only from the primary database

Personal data may exist in dozens of systems and processors.

Mistake 4: Retaining everything “for business purposes”

Retention should be connected to the specified purpose or applicable legal requirements.

Mistake 5: Ignoring Section 8

Organisations should not wait for individuals to request deletion where the statutory purpose-based erasure obligation is triggered.

Mistake 6: Ignoring processors

The Act expressly addresses erasure by Data Processors.

Mistake 7: Having no evidence

A company should be able to demonstrate how an erasure request was handled.

Mistake 8: Treating backups as an afterthought

Backup and disaster-recovery architecture should be incorporated into the deletion strategy.

Mistake 9: Assuming the Rules’ three-year period applies to everyone

The Third Schedule’s three-year periods apply to specified classes of large e-commerce, gaming and social media entities and specified purposes.

Mistake 10: Ignoring phased commencement

The DPDP Act and Rules do not all become operational simultaneously.

The final Rules specify different commencement dates for different provisions. Rules 1, 2 and 17–21 commenced on publication; Rule 4 follows after one year; and Rules 3, 5–16, 22 and 23 follow after 18 months.

20. DPDP Erasure Compliance Checklist for Businesses

A business preparing for DPDP compliance should ask:

Governance

• Do we have a documented erasure policy?
• Who owns Data Principal Rights Requests?
• Is there a designated privacy/DPO function where required?
• Is there a defined escalation process?

Data discovery

• Do we know where personal data is stored?
• Have we mapped applications and repositories?
• Have we identified Data Processors?
• Do we know where backups exist?

Legal assessment

• Is the data processed based on consent?
• What is the specified purpose?
• Is the purpose still being served?
• Is retention necessary?
• Does another law require retention?
• Does an exemption apply?

Technical controls

• Can we delete records from production systems?
• Can deletion be propagated to downstream systems?
• Can we send deletion instructions to processors?
• How are backups handled?
• How do we prevent deleted information from being reintroduced?

Documentation

• Do we record each request?
• Do we record the decision?
• Do we document the reason for retention?
• Do we maintain evidence of processor deletion?
• Do we record final closure of the request?

User experience

• Is the rights mechanism easy to find?
• Can users submit requests digitally?
• Is the process understandable?
• Do communications clearly explain the outcome?

21. A Practical DPDP Erasure Decision Tree

A simple decision tree can help operational teams.

Has the Data Principal requested erasure?

↓ Yes

Is the personal data within the scope of the request?

↓ Yes

Is the processing covered by the applicable Section 12 right?

↓ Yes

Is retention necessary for the specified purpose?

→ Yes: Retain only the necessary data and document the reason.

→ No: Continue.

Is retention required by another law?

→ Yes: Retain only what is legally required and for the applicable period.

→ No: Erase.

Then:

Is the data held by a Data Processor?

→ Yes: Cause the processor to erase it where required.

→ No: Complete the internal deletion workflow.

Finally:

Validate + document + respond to the Data Principal.

22. What Should a DPDP-Compliant Erasure Policy Contain?

A mature organisational policy should address at least:

1. Scope
2. Definitions
3. Applicable Data Principal rights
4. Request submission channels
5. Identity verification
6. Request logging
7. Data discovery
8. Purpose identification
9. Retention assessment
10. Legal-retention assessment
11. Exemptions
12. Partial deletion
13. Processor coordination
14. Backup handling
15. Deletion validation
16. Response process
17. Escalation
18. Grievance handling
19. Record keeping
20. Periodic testing and audit

The policy should also distinguish between:

deletion from active systems

and

expiration of data from backups and archives.

23. Why the Right to Erasure Is Really a Data Governance Issue

It is tempting to treat the right to erasure as a privacy team’s responsibility.

That is too narrow.

Effective erasure requires collaboration between:

• Legal;
• Privacy;
• Compliance;
• IT;
• Security;
• Engineering;
• Product;
• HR;
• Finance;
• Procurement;
• Customer Support; and
• third-party vendors.

The privacy team can define the legal decision framework.

But engineering must make deletion technically possible.

Procurement must ensure processor contracts support the requirement.

Security must ensure deleted data is not unnecessarily exposed.

Business teams must understand why certain data can or cannot be retained.

Therefore, the right to erasure is ultimately a data lifecycle management problem.

24. Current Legal Status: An Important Caveat for 2026

As of September 2026, organisations should distinguish between:

the law as enacted,

the Rules as notified,

and

the provisions that have actually commenced.

The DPDP Rules, 2025 were notified in November 2025. However, the Rules themselves provide for phased commencement. Rules 3, 5–16, 22 and 23 are scheduled to commence 18 months after publication, while other provisions commenced earlier.

The corresponding commencement notification for the DPDP Act places Sections 11–17—including Section 12—in the 18-month commencement group.

Accordingly, 13 May 2027 is the key date generally associated with the commencement of the Section 12 rights framework, calculated from the November 2025 notification. Organisations should nevertheless monitor MeitY notifications and any subsequent amendments or clarifications rather than treating the calculated date as immune from change.

This distinction is particularly important for legal publications.

A responsible DPDP article should not say simply:

“The right to erasure is currently fully enforceable under Section 12.”

The more accurate formulation is:

Section 12 establishes the statutory right to erasure, while the commencement of that right and its detailed operational framework follow the phased commencement mechanism notified by the Government.

25. DPDP Act Right to Erasure vs. Data Deletion: The Bigger Picture

The most important takeaway is that the DPDP Act does not view personal data deletion as merely an individual request.

It establishes a broader lifecycle principle.

A Data Fiduciary should know:

Why is this data being collected?

↓

Why is it being processed?

↓

How long is it necessary?

↓

When does the purpose end?

↓

Does a law require continued retention?

↓

If not, when and how will it be erased?

This is the real significance of the DPDP framework.

The right to erasure gives the Data Principal a mechanism to challenge continued retention.

Section 8 places an independent responsibility on the Data Fiduciary to erase data when the statutory conditions are met.

The DPDP Rules add more specific retention and erasure mechanisms for certain classes and purposes.

Together, these provisions push organisations towards a more disciplined approach to data minimisation, purpose limitation, retention management and deletion governance.

Conclusion

The right to erasure under Section 12 of the DPDP Act, 2023 is a significant Data Principal right, but it is not an unconditional right to demand that every piece of personal information disappear immediately.

The legal framework is based on a balance between individual control and legitimate data retention.

For Data Principals, this means there is a statutory mechanism to request erasure of personal data, subject to specified-purpose and legal-retention exceptions.

For Data Fiduciaries, it means something much broader: organisations must build the capability to understand what personal data they hold, why they hold it, where it resides, how long it needs to be retained, and how it will ultimately be erased.

The most effective DPDP compliance strategy is therefore not simply:

“Build a delete button.”

It is:

“Build a defensible data lifecycle.”

That lifecycle should connect consent, purpose, data inventory, retention schedules, Data Principal requests, processor management, technical deletion, backups, legal holds, audit trails and governance.

As India moves toward the operational phase of the DPDP framework, organisations that address erasure only at the policy level may discover that the real challenge lies much deeper—in their systems, contracts, data architecture and operational processes.

Right to erasure is therefore not merely a privacy-rights issue. It is a test of whether an organisation genuinely knows and controls the personal data it processes.

Legal sources

• Digital Personal Data Protection Act, 2023 — Ministry of Electronics and Information Technology / Government of India.
• Digital Personal Data Protection Rules, 2025 — notified by the Government of India in November 2025.
• Third Schedule to the DPDP Rules, 2025 — prescribed periods for specified classes of Data Fiduciaries under Rule 8.
• MeitY Act and Policies portal — official repository for the DPDP Rules and related implementation documents.

26. Frequently Asked Questions

Is the right to erasure absolute under the DPDP Act?

No.

Section 12(3) allows retention where it is necessary for the specified purpose or compliance with a law in force.

Can a company retain some of my data while deleting the rest?

Yes.

Where only certain categories must be retained, the organisation should not automatically treat the retention requirement as justification for retaining all personal data indefinitely.

Does deleting my account automatically delete all my data?

Not necessarily.

Some information may need to be retained because of the specified purpose or legal requirements.

Does withdrawing consent automatically mean all data must immediately disappear?

Not necessarily.

Withdrawal of consent and erasure are distinct concepts, and retention may still be permitted or required in particular circumstances.

Does DPDP require companies to delete data from their vendors?

The Act requires a Data Fiduciary to cause its Data Processor to erase personal data that was made available for processing, subject to the applicable statutory framework.

Does the DPDP Act have a “right to be forgotten”?

It is better to use the statutory terminology “right to erasure” when discussing Section 12.

Calling it a “right to be forgotten” can create confusion with the GDPR concept and its broader jurisprudential context.

Does the three-year rule apply to every company?

No.

The three-year periods in Rule 8’s Third Schedule apply to specified large e-commerce entities, online gaming intermediaries and social media intermediaries, subject to the conditions and purposes specified in the Schedule.

What should a company do if it cannot delete information because the law requires retention?

It should identify the relevant data and legal requirement, retain only what is necessary, appropriately control access, and delete the information when the applicable retention obligation ends.

Disclaimer: This article is intended for general informational and compliance-awareness purposes and does not constitute legal advice. Organisations should assess their specific processing activities, applicable sectoral laws, contractual obligations and the latest Government notifications before adopting a DPDP erasure procedure.