Data deletion is one of the most important yet operationally difficult parts of privacy compliance. Organizations may have policies explaining when personal data should be deleted, but implementing that requirement across real enterprise environments is considerably more complex. Personal data rarely exists in one database. It can move between applications, cloud platforms, SaaS systems, APIs, analytics environments, employee tools, backup systems, logs, and third-party processors.

Under India's Digital Personal Data Protection framework, erasure is not simply a technical action performed by deleting a database record. It is a governance process that requires an organization to determine whether personal data should be erased, identify every relevant location where that information exists, determine whether any lawful retention requirement applies, execute deletion across appropriate systems and processors, and maintain sufficient evidence that the process was completed.

The Digital Personal Data Protection Act, 2023 gives a Data Principal the right to request erasure of personal data for processing for which consent was previously given, subject to the conditions and procedures under applicable law. Section 12(3) states that upon receiving an applicable erasure request, the Data Fiduciary is required to erase the personal data unless retention is necessary for the specified purpose or for compliance with any law in force.

The Act also establishes an important broader lifecycle principle. Section 8(7) requires a Data Fiduciary, unless retention is necessary for compliance with applicable law, to erase personal data when consent is withdrawn or when it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier. The Data Fiduciary must also cause the relevant Data Processor to erase personal data that was made available for processing.

This makes data deletion a business-wide responsibility rather than a task belonging only to the IT or database team.

A mature DPDP erasure process should connect privacy governance with data mapping, application architecture, identity management, cloud infrastructure, vendor management, records management, cybersecurity, legal review, and business ownership.

What Is Data Deletion Under DPDP?

Data deletion under DPDP refers to the controlled removal or erasure of personal data when there is no longer a valid reason to continue retaining or processing that information, subject to applicable legal and regulatory requirements.

The concept appears straightforward until it is applied to a modern enterprise.

A customer may create an account through a website, provide information through a mobile application, make a payment through a third-party gateway, contact customer support, interact with a chatbot, receive marketing communications, and generate activity records in multiple backend systems. The customer's personal data may subsequently be replicated into analytics platforms, reporting systems, data warehouses, monitoring tools, cloud storage, backups, and processor environments.

Deleting the customer's primary account record therefore does not necessarily mean that the organization's data lifecycle is complete.

An effective erasure process needs to identify the relevant copies and determine which systems are subject to deletion, which records need to be retained because of applicable law or another valid requirement, and how exceptions should be documented.

This is why DPDP deletion should be understood as a data lifecycle control rather than a simple "delete user" button.

Why Data Deletion Is Important for DPDP Compliance

Organizations frequently focus on preventing unauthorized access to personal data while paying less attention to personal data that should no longer exist.

From a security perspective, unnecessary data creates unnecessary exposure. Every additional database, backup, application log, spreadsheet, SaaS account, cloud bucket, or third-party environment containing personal data represents another location that needs appropriate protection.

If an organization continues retaining personal information long after the purpose for processing has ended, it may increase the potential impact of a future security incident. Attackers do not care whether an organization still needs the information. If the information exists and can be accessed, it can become part of an attacker's target environment.

Data deletion therefore supports both privacy governance and cybersecurity risk reduction.

Effective deletion can also simplify incident response. When an organization knows that outdated information has been systematically removed, security teams have a smaller and more clearly defined data environment to investigate during an incident.

Deletion also reduces the complexity of Data Principal rights management. If unnecessary personal data has already been removed through lifecycle controls, responding to a valid erasure request becomes considerably easier than searching through years of accumulated historical information.

What Does the DPDP Act Say About Erasure?

The DPDP Act provides two important perspectives on erasure.

The first relates to the Data Principal's right to request erasure. Section 12 provides the Data Principal with the right to correction, completion, updating, and erasure of personal data for processing for which consent was previously given, subject to the applicable requirements and procedures. When an applicable erasure request is received, the Data Fiduciary must erase the personal data unless retaining it is necessary for the specified purpose or for compliance with applicable law.

The second perspective relates to the Data Fiduciary's broader responsibility to erase personal data when the relevant purpose is no longer being served or consent has been withdrawn, subject to applicable legal retention requirements. Section 8(7) also extends the operational responsibility to relevant Data Processors by requiring the Data Fiduciary to cause them to erase the personal data made available for processing.

These provisions mean that organizations should not build their deletion process only around individual requests.

They should also establish lifecycle-driven deletion that identifies when personal data has reached the end of its justified retention period.

Data Principal Erasure Requests vs Automatic Data Deletion

These two concepts should be separated in an enterprise privacy program.

A Data Principal erasure request occurs when an individual exercises the applicable right to request deletion of their personal data.

Automatic or lifecycle-based deletion occurs when the organization's retention rules determine that information is no longer required for the specified purpose and no applicable legal requirement requires continued retention.

The technical mechanisms may overlap, but the governance triggers are different.

For an erasure request, the organization needs to validate the request, identify the relevant data, determine whether an exception applies, execute deletion where appropriate, and communicate through the applicable process.

For lifecycle deletion, the organization needs to monitor retention periods and business events, identify records that have reached the end of their approved retention period, check for legal holds or other exceptions, and initiate deletion.

A mature architecture should support both processes rather than treating one as a substitute for the other.

The First Step: Know Where Personal Data Exists

An organization cannot reliably delete information that it cannot locate.

This is why data discovery and data mapping are foundational to an effective DPDP erasure process.

Personal data can exist in structured databases, application systems, cloud storage, spreadsheets, emails, customer-support platforms, HR systems, analytics tools, data warehouses, identity platforms, application logs, development environments, testing environments, backup systems, and third-party SaaS applications.

The organization therefore needs a data inventory that goes beyond identifying major business applications.

It should understand which applications contain personal data, what categories of information they hold, how information enters the system, where information is transferred, which processors receive it, what systems consume the information, and how deletion propagates between connected systems.

For example, deleting a customer profile from a CRM may not automatically remove the customer's information from a marketing platform, analytics database, support platform, or data warehouse.

Without data-flow visibility, deletion becomes dependent on assumptions.

Why Data Mapping Is Critical for Erasure

A strong DPDP data map creates the foundation for deletion because it connects personal-data categories with systems and processing activities.

Consider a typical enterprise data flow in which a customer submits information through a website. The website sends the information to an application server, which stores it in a customer database. The CRM receives a copy, the marketing platform receives selected fields, an analytics platform receives event data, and a customer-support system receives account information.

When the customer later requests erasure, the organization needs to know which of those systems contain the relevant information.

The answer cannot simply be "the CRM."

The organization needs to understand the complete data lineage.

This is why data deletion should be designed together with data mapping. If a business recently completed a DPDP data-mapping exercise, the resulting map should become a practical input into the deletion workflow rather than remaining only as compliance documentation.

Building an Effective DPDP Erasure Workflow

An effective deletion workflow begins when a valid deletion trigger occurs.

The trigger may be a Data Principal request, expiry of an approved retention period, closure of an account, completion of a business purpose, withdrawal of consent where applicable, termination of a service relationship, or another event defined by the organization's retention framework.

Once the trigger occurs, the organization should identify the relevant individual, data category, processing purpose, and systems involved.

The organization should then determine whether any exception prevents immediate deletion. This is particularly important where applicable law requires continued retention, where information is subject to a legal hold, or where another valid requirement requires preservation.

After the decision is made, the deletion workflow should execute against the relevant systems.

The organization should then verify that the deletion occurred and address downstream processors and dependent systems.

Finally, the organization should record appropriate evidence of the decision and action.

This creates a lifecycle that can be represented conceptually as:

Deletion Trigger → Identity Validation → Data Discovery → Retention Check → Exception Review → Deletion Execution → Processor Deletion → Verification → Evidence

The exact implementation will differ between organizations, but the governance logic should remain consistent.

Step 1: Validate the Deletion Trigger

The first technical or operational action should not necessarily be deleting data.

The organization should first establish why deletion has been triggered.

For a Data Principal request, the organization should follow its approved procedure for validating the request and confirming that the request relates to the relevant individual and data.

For automated deletion, the organization should establish which business event caused the retention period to expire.

This distinction matters because an incorrect deletion trigger can result in legitimate records being deleted prematurely.

For example, an account closure event may initiate a deletion workflow, but the organization may have separate legal requirements requiring certain transaction records to remain available. The workflow therefore needs to distinguish between records that can be deleted and records that must continue to be retained.

Step 2: Identify the Personal Data

Once the trigger is validated, the organization needs to determine which personal data is actually within scope.

This is more complicated than searching for a person's name.

Personal data may be associated with customer IDs, email addresses, mobile numbers, account identifiers, employee numbers, device identifiers, transaction IDs, support tickets, authentication records, or other identifiers.

The organization should use the strongest available identifiers to locate relevant records while minimizing the risk of accidentally deleting another individual's information.

This process becomes particularly important in large databases where the same individual may have multiple accounts, historical records, or identifiers across different business systems.

Identity resolution should therefore be designed carefully and tested before deletion automation is deployed at scale.

Step 3: Identify Every Relevant System

The next stage is to identify where the personal data exists.

This should include the primary application as well as downstream and upstream systems that received or generated the information.

Organizations should consider databases, CRM platforms, marketing systems, customer-support tools, analytics platforms, data warehouses, cloud storage, file repositories, identity systems, application logs, reporting environments, and relevant third-party processors.

The exact scope depends on the organization's architecture.

The important principle is that the deletion workflow should be based on known data flows, not assumptions about where the information is stored.

Step 4: Check Retention Exceptions

Deletion should not automatically override every other legal or operational obligation.

The DPDP Act itself recognizes that personal data may need to be retained when retention is necessary for the specified purpose or for compliance with applicable law.

The organization therefore needs an exception-management mechanism.

An exception could arise because a particular record must be retained under another law, because it is subject to a legal hold, because it is necessary for an ongoing investigation, or because another documented requirement requires continued preservation.

The exception should not be used as a generic reason to retain an entire customer profile.

Instead, the organization should identify the specific records that must remain available and separate those records from information that can be deleted.

This supports a more precise approach to privacy compliance.

Step 5: Execute Deletion Across Systems

After the deletion decision is approved, the organization should execute deletion across the relevant systems.

The implementation depends heavily on the organization's technology architecture.

Modern applications may use APIs, event-driven architectures, microservices, queues, data warehouses, caches, search indexes, object storage, analytics platforms, and third-party SaaS systems.

Deleting information from the primary database may therefore require downstream deletion events.

For example, an application could generate a deletion event that is consumed by connected systems. Each system can then identify the relevant record and execute its own deletion or approved retention logic.

This architecture can significantly improve consistency compared with relying on manual requests to individual system owners.

Step 6: Manage Data Processor Deletion

Third-party processors require special attention.

The DPDP Act requires the Data Fiduciary to cause relevant Data Processors to erase personal data when the applicable erasure obligation arises.

This means the organization needs operational mechanisms for processor deletion.

A vendor contract alone may not be enough.

The organization should understand whether the processor provides APIs, administrative controls, deletion workflows, account-closure procedures, or formal deletion confirmations.

Where deletion cannot be technically verified in real time, the organization should establish an appropriate evidence process.

The objective is to prevent a situation in which the organization's internal systems show that data has been deleted while a third-party platform continues retaining the same personal information.

Step 7: Address Backups and Disaster Recovery

Backups are one of the most difficult areas of data deletion.

Production databases are generally designed to support direct modification or deletion, while backup systems may be immutable, encrypted, replicated, or retained for disaster recovery.

An organization therefore needs a documented backup strategy that explains how deletion interacts with backup retention.

The organization should understand how long backups remain available, how backup rotation works, whether expired data naturally falls out of the backup lifecycle, how restored systems are handled, and how obsolete personal data is prevented from being reintroduced into production.

The objective should not be to create an impractical promise that every historical backup copy will disappear instantly.

Instead, the organization should establish a technically realistic, documented, and legally reviewed approach that prevents backups from becoming a mechanism for indefinite retention.

Step 8: Consider Logs, Caches, and Secondary Copies

A common deletion gap occurs because organizations focus on application databases while ignoring secondary data stores.

Personal information may appear in application logs, debugging records, monitoring platforms, search indexes, temporary storage, caches, message queues, analytics events, or exported reports.

The organization should therefore assess whether these environments contain personal data and whether the relevant retention policy requires deletion or controlled expiration.

Security logs deserve particular attention because they may have legitimate retention requirements for security monitoring, investigation, or regulatory purposes. They should not automatically be treated as ordinary customer records.

At the same time, security logging should not become a justification for storing unnecessary personal information indefinitely.

Organizations should therefore apply appropriate data-minimization and retention controls to logs themselves.

Step 9: Verify That Deletion Actually Happened

A deletion process is incomplete if the organization assumes the operation succeeded without verification.

Verification can occur at different technical levels depending on the environment.

A database system may provide confirmation that a record was removed. A SaaS platform may provide a deletion status. An API may return confirmation. A downstream system may generate an event showing that the deletion was processed.

For sensitive or high-risk workflows, organizations may require additional evidence that downstream systems completed the action.

The verification process should also consider failure scenarios.

If one downstream system is unavailable when the deletion event is generated, the organization should have a retry mechanism or exception workflow rather than silently losing the deletion request.

This is particularly important in distributed enterprise architectures where systems may be temporarily unavailable.

Step 10: Maintain Evidence of the Deletion Decision

Privacy compliance requires more than performing an action. Organizations should also be able to demonstrate that the action was governed appropriately.

Deletion evidence should generally establish that a valid trigger occurred, the relevant data was identified, applicable retention exceptions were evaluated, deletion was initiated, relevant systems were processed, and the outcome was recorded.

The evidence should itself be designed carefully because maintaining a detailed deletion log containing unnecessary personal data can create another privacy problem.

Organizations should therefore record the minimum information necessary to demonstrate the action without recreating the personal-data record they were attempting to delete.

This creates an important principle:

The deletion record should prove that deletion happened without becoming a new repository of unnecessary personal data.

Handling Legal Holds and Other Exceptions

A robust deletion architecture must support exceptions.

Suppose an organization receives an erasure request while the relevant records are subject to an active legal hold. Automatically deleting those records could interfere with another legal obligation.

The system should therefore be capable of placing the relevant records into an approved preservation state.

However, a legal hold should not become permanent.

Organizations should assign ownership to the exception, record the reason for preservation, establish a review mechanism, and release the hold when the underlying requirement ends.

Once the hold is released, the normal retention and deletion process should resume.

This creates a controlled relationship between privacy deletion and legal preservation requirements.

Data Deletion and Data Security

Data deletion should also be integrated with cybersecurity controls.

When an account is deleted, the organization should consider whether authentication credentials, access tokens, active sessions, API keys, device associations, and other security-related records need to be revoked or handled separately.

For example, deleting a customer's profile from a business database without invalidating active sessions could leave an account accessible even though the underlying personal data has been removed.

Similarly, employee offboarding may require identity and access termination alongside data-retention decisions.

The privacy lifecycle and identity-security lifecycle are therefore interconnected.

Deletion workflows should be designed with security teams rather than being treated solely as privacy processes.

Data Deletion in Cloud Environments

Cloud environments can make deletion more complex because personal data may exist across databases, object storage, snapshots, replicas, managed services, analytics platforms, and third-party integrations.

An organization should therefore identify which cloud services contain personal data and understand how each service handles deletion, replication, backups, snapshots, and recovery.

Cloud architecture should support lifecycle controls wherever possible.

Storage lifecycle policies, database retention mechanisms, automated workflows, event-driven deletion, access controls, and monitoring can help organizations enforce approved retention rules more consistently.

However, cloud automation should always be tested carefully.

An incorrectly configured deletion policy can result in accidental removal of legitimate records, while an overly conservative policy can allow unnecessary personal data to remain indefinitely.

Data Deletion in SaaS Applications

SaaS applications create another common challenge because the organization does not control the underlying infrastructure.

A company may use dozens or hundreds of SaaS applications that contain personal information.

When a customer, employee, or other Data Principal becomes subject to an erasure workflow, the privacy team may not know which SaaS applications contain the relevant data.

This makes SaaS discovery an important part of data mapping.

Vendor due diligence should also determine how the SaaS provider supports deletion, what happens to backups, whether sub-processors receive copies, how long data remains after account termination, and whether deletion confirmation can be obtained.

The organization should incorporate these capabilities into vendor selection and third-party risk assessments rather than discovering limitations only when an erasure request arrives.

Data Deletion and AI Systems

AI introduces another layer of complexity to enterprise erasure.

Personal data can be processed through AI assistants, large language models, AI APIs, retrieval-augmented generation systems, vector databases, agent platforms, connectors, monitoring platforms, and application logs.

If personal data from a customer record is used as input to an AI-enabled application, the organization needs to understand where that information may have been copied or transformed.

For example, personal data may appear inside a prompt, an AI response, an application log, a retrieval document, an embedding store, a vector database, or an AI observability platform.

The organization therefore needs to determine whether its AI architecture supports appropriate data deletion and retention controls.

This is especially important for enterprise AI deployments because deleting the original source record does not automatically mean that derived or replicated information has disappeared from every downstream system.

AI governance and privacy engineering should therefore address data deletion at the architecture stage.

Building Automated DPDP Erasure Workflows

For large enterprises, manual deletion cannot provide reliable lifecycle management at scale.

Automation can connect business events to privacy workflows.

An account closure event, for example, can trigger an orchestration workflow that identifies the customer, retrieves the applicable retention policy, checks for exceptions, generates deletion requests for connected systems, tracks processor actions, retries failed operations, and records the final outcome.

This creates a controlled workflow rather than a series of disconnected manual tasks.

Event-driven architectures can be particularly useful because deletion events can propagate through multiple systems without requiring the privacy team to manually contact every application owner.

However, automation should be introduced only after the organization understands its data architecture.

Automating an incomplete data map simply makes incomplete deletion happen faster.

The foundation should therefore be accurate data discovery, clear retention rules, defined ownership, documented exceptions, and tested system integrations.

Testing the DPDP Deletion Process

Organizations should periodically test whether their deletion process actually works.

A useful test can begin with a controlled test identity whose personal data has been intentionally placed across relevant systems.

The organization can then initiate an erasure workflow and verify whether the information disappears from the expected systems, whether processors receive the appropriate instruction, whether exceptions are handled correctly, and whether evidence is generated.

Testing should also cover failure conditions.

For example, what happens if a processor API is unavailable? What happens if a downstream database rejects the deletion? What happens if the customer exists under multiple identifiers? What happens if a legal hold is added while the deletion workflow is running?

These scenarios help organizations identify weaknesses before a real Data Principal request exposes them.

Deletion testing should therefore become part of privacy assurance and not be treated as a one-time implementation activity.

Metrics for Monitoring Data Deletion

Organizations should also monitor the performance of their erasure process.

Useful operational metrics can include the number of deletion requests received, the percentage completed within the organization's defined service levels, the number of requests requiring exceptions, the number of failed downstream deletions, the number of processor deletions awaiting confirmation, and the number of records discovered outside the known data map.

Another valuable metric is the percentage of major applications that have an automated deletion capability.

These measurements can help privacy and technology leadership understand whether the organization has a functioning deletion program or merely a written policy.

Metrics should be used to identify control weaknesses rather than simply to produce compliance dashboards.

Common Data Deletion Mistakes

One of the most common mistakes is treating deletion as a single-database operation. In modern enterprise environments, personal data frequently exists in multiple systems, and deleting only the primary record may leave significant copies behind.

Another common problem is failing to distinguish between deletion and retention exceptions. Organizations sometimes either delete everything immediately or retain everything indefinitely because of a broad legal concern. Both approaches can create governance problems.

Ignoring third-party processors is another major weakness. If a CRM, cloud provider, analytics service, or other processor continues retaining personal data, the organization's internal deletion process is incomplete.

Backup environments are frequently overlooked as well. Organizations may successfully delete production data while retaining years of backup copies without a documented lifecycle strategy.

A further problem is the absence of verification. A system may report that a deletion request was submitted, but that does not necessarily prove that every downstream system completed the action.

Finally, organizations sometimes retain excessive personal information inside deletion logs and audit records. Evidence of deletion is important, but the evidence itself should be designed according to data-minimization principles.

How Digital Defense Can Help

Digital Defense can help organizations assess and strengthen their DPDP data deletion and privacy lifecycle controls.

A DPDP Data Mapping Assessment can identify where personal data exists across applications, databases, cloud services, APIs, SaaS platforms, processors, analytics environments, and other systems. This provides the visibility required to build a reliable erasure workflow.

A DPDP Compliance Gap Assessment can evaluate whether current privacy processes, governance structures, Data Principal rights mechanisms, processor controls, and technical safeguards align with applicable DPDP requirements.

A Data Retention and Deletion Assessment can evaluate whether the organization has defined retention periods, deletion triggers, legal exceptions, system ownership, processor requirements, backup handling, and evidence mechanisms.

A Third-Party Risk Assessment can examine whether vendors and Data Processors have adequate mechanisms for handling deletion requests and lifecycle expiration.

Digital Defense can also support organizations in assessing the technical side of data lifecycle management across applications, APIs, cloud environments, databases, identity systems, and enterprise platforms.

The objective is to help organizations move from a written deletion policy to an operational process that can be implemented, tested, monitored, and demonstrated.

Executive Takeaways

Data deletion under DPDP should not be treated as a simple database operation. It is a coordinated privacy and technology process that must account for personal-data locations, processing purposes, legal retention requirements, processors, backups, logs, cloud environments, SaaS applications, and downstream systems.

The DPDP Act gives Data Principals a right to erasure subject to applicable conditions and requires erasure unless retention is necessary for the specified purpose or compliance with applicable law. The Act also places responsibility on Data Fiduciaries to cause relevant Data Processors to erase personal data when the applicable erasure obligation arises.

The most effective approach is to build deletion into the data lifecycle from the beginning rather than treating it as an exceptional manual activity.

Organizations should know where personal data exists, understand how it flows between systems, define when deletion is triggered, identify legitimate retention exceptions, automate deletion where practical, manage processor actions, address backups and secondary copies, and verify that deletion actually occurred.

The final objective is not simply to make a record disappear from one database.

The objective is to establish a repeatable, auditable, technically enforceable process for removing personal data when the organization no longer has a valid reason to retain it.

Frequently Asked Questions

What is data deletion under DPDP?

Data deletion under DPDP refers to the process of erasing personal data when an applicable deletion trigger occurs, subject to the specified purpose and any legal or other applicable retention requirements. It includes both responding to applicable Data Principal erasure requests and implementing lifecycle-based deletion.

Does the DPDP Act give Data Principals a right to erasure?

Yes. Section 12 provides a Data Principal with a right to erasure of personal data for processing for which consent was previously given, subject to the applicable requirements and procedures. Upon receiving an applicable request, the Data Fiduciary must erase the personal data unless retention is necessary for the specified purpose or compliance with applicable law.

Does a company have to delete all personal data when a customer requests deletion?

Not necessarily. The DPDP Act recognizes that personal data may need to be retained where retention is necessary for the specified purpose or compliance with applicable law. The organization should therefore determine which records are subject to deletion and which records have a valid documented retention requirement.

Does DPDP deletion apply to Data Processors?

Yes. Section 8(7) requires the Data Fiduciary to cause relevant Data Processors to erase personal data when the applicable erasure requirement arises. Organizations therefore need mechanisms for communicating and verifying deletion with processors.

Should backups be included in a DPDP deletion process?

Yes. Organizations should assess how personal data exists in backups and disaster-recovery environments and establish a documented approach for handling information that reaches the end of its approved retention period.

What happens to personal data stored in application logs?

Organizations should determine whether their logs contain personal data and whether the information is necessary for security, operational, legal, or other purposes. Where personal data is retained in logs, the organization should apply appropriate retention and access controls rather than allowing logs to become an uncontrolled source of indefinite personal-data retention.

How should companies handle deletion across multiple applications?

Organizations should use data mapping and system integration to identify downstream systems and coordinate deletion. Where technically appropriate, event-driven workflows and APIs can automate deletion across connected applications while providing status tracking and retry mechanisms.

Does data deletion apply to AI systems?

Where AI systems process personal data within the scope of the DPDP framework, organizations should consider deletion across prompts, responses, logs, vector databases, retrieval systems, connectors, monitoring platforms, and third-party AI services where applicable. Deleting the original source record does not automatically establish that all derived or replicated information has been removed.

How can an organization prove that data was deleted?

Organizations can maintain appropriate evidence showing the deletion trigger, scope, retention-exception decision, systems processed, processor actions, deletion status, verification results, and completion date. The evidence should itself follow data-minimization principles and should not unnecessarily recreate the personal data that was deleted.

How often should a DPDP deletion process be tested?

Organizations should test the process periodically and whenever significant applications, vendors, data flows, or privacy workflows change. Testing should include both normal deletion scenarios and failure conditions such as unavailable processors, failed downstream deletions, duplicate identities, and legal-retention exceptions.

Conclusion

Data deletion is one of the clearest tests of whether an organization's privacy program actually operates in practice.

A company may have a comprehensive privacy policy, a data-retention schedule, and a Data Principal rights procedure, but those controls have limited value if the organization cannot identify where personal data exists or cannot technically remove it when the applicable deletion condition arises.

The DPDP Act establishes an important legal foundation by recognizing the Data Principal's right to erasure and requiring erasure unless continued retention is necessary for the specified purpose or compliance with applicable law. It also requires Data Fiduciaries to ensure that relevant Data Processors erase personal data when the applicable obligation arises.

The 2025 Rules add more detailed mechanisms around when specified purposes are deemed no longer served for certain classes of Data Fiduciaries and purposes. Rule 8 includes specific provisions concerning erasure, advance notification in the applicable circumstances, and retention of specified data and processing logs for certain purposes.

However, the Rules are subject to phased commencement. The official commencement notification provides that Rules 1, 2 and 17–21 came into force upon publication, Rule 4 comes into force one year after publication, and Rules 3, 5–16, 22 and 23 come into force eighteen months after publication of the 13 November 2025 Gazette.

For organizations, this makes preparation particularly important. The technical work required for reliable deletion cannot be implemented overnight.

Businesses should start with data mapping, identify personal-data locations, define retention and deletion rules, establish exception management, assess processors, address backups and logs, implement technical workflows, and test the complete process.

The goal should not be to create a policy that says personal data will be deleted.

The goal should be to build an enterprise environment in which the organization can actually identify, delete, verify, and demonstrate the deletion of personal data when the applicable requirement arises.