DPDPA Section 12: Correction, Completion, Updating and Erasure

It is easy to write a privacy policy that promises users control over their data. It is entirely different to actually find that data and delete it.

DPDPA Section 12 sets out the right of a Data Principal to get their personal data corrected, completed, updated, or erased. These rights apply where the processing is based on the Data Principal’s consent, and they must be exercised in the manner prescribed under applicable rules, including Rule 13.

This is not a theoretical promise. It imposes clear, operational obligations on Data Fiduciaries to act, to propagate changes to downstream recipients, and to respond within defined timelines.

What DPDPA Section 12 Grants

Section 12 recognises four distinct rights for consent-based processing:

• Correction. Fix inaccurate or misleading personal data.
• Completion. Add missing information where the data is incomplete.
• Updating. Replace outdated personal data where it has changed.
• Erasure. Request deletion of personal data.

These are practical controls. Think spelling corrections, missing apartment numbers, updated phone numbers, or a full DPDP right to erasure request when a user closes an account or withdraws consent.

Scope and Applicability

• Who can use these rights. A Data Principal who has consented to the processing of their personal data by a Data Fiduciary.
• What must the Data Fiduciary do. On receiving a valid request, the Data Fiduciary must correct, complete, or update the data. For erasure, the Data Fiduciary must delete the data unless retention is necessary for the specified purpose, or required by law, or by a judgment or order of a court or tribunal.
• How requests are made. The manner is prescribed by rules. Rule 13 governs procedures and includes a 30-day response expectation.

How Correction, Completion, and Updating Work in Practice

• Correction. Covers inaccuracies or misleading records. “Misleading” includes technically accurate entries that create a false impression due to missing context. Example: recording an arrest but omitting that charges were dropped.
• Completion. Fills missing fields necessary to make the record accurate. Example: adding a missing apartment number.
• Updating. Replaces data that was accurate at the time but has since changed. Example: a new phone number or address.

Expect the Data Fiduciary to ask for reasonable evidence. Government ID for a name or date of birth, payment confirmations for transaction status, or official documents for address changes are typical. Opinions or preferences that are not factual inaccuracies fall outside the correction right.

The Ripple Effect: Downstream Obligations

Once a Data Fiduciary corrects, completes, or updates your data, Section 12 requires more than fixing the record in one place. The Data Fiduciary must:

• Inform all other Data Fiduciaries and Data Processors with whom the data was shared that a correction, completion, or update has occurred.
• Take reasonable steps to ensure those parties make the same changes in their systems.
• Inform the Data Principal of who else holds the data so the Data Principal can verify downstream updates if needed.

Reasonable steps include formal notifications, contractual obligations that require downstream corrections, appropriate follow-ups, and documentation of efforts. The law expects effort and traceability, not blind trust.

The Right to Erasure

A Data Principal who consented to processing can request erasure. The Data Fiduciary must delete the personal data unless retention is:

• Necessary for the specified purpose that still persists.
• Mandated by any law in force.
• Necessary to comply with a judgment or order of a court, tribunal, or similar authority.

What counts as DPDP data erasure in operational terms?

• Permanent deletion from active systems qualifies.
• Deleting from production while allowing short-term backup retention with scheduled destruction is acceptable.
• Proper anonymization that irreversibly de-identifies the data qualifies.
• Soft deletes that only hide the record do not qualify.
• Keeping full copies in logs or archives with no expiry does not qualify.

A sound approach is partial erasure. Delete what can be deleted now, retain what must be kept by law with clear retention periods, and schedule automatic deletion when those periods expire.

Boundaries and Exceptions

The Data Fiduciary is not required to alter or erase data if:

• Alteration or erasure is not feasible or involves disproportionate effort. Examples include reconstructing years of offline backups to locate a single record or editing an individual out of thousands of archived public event photos. Poor internal data practices are not a shield. Routine updates or deletion across modern systems will rarely qualify as disproportionate.
• Retention is required by law or necessary to comply with judicial or quasi-judicial orders.
• Retention remains necessary for the specified purpose that has not yet been fulfilled.

When relying on an exception, the Data Fiduciary should explain the rationale and, where possible, offer partial erasure.

Request Handling: Expectations and Timelines

• Identity verification. Confirm the requester’s identity before making changes.
• Evidence. Ask for reasonable proof where facts are disputed. Avoid imposing excessive burdens that exceed what is necessary to verify accuracy.
• Timelines. Acknowledge and act within the 30-day period referenced under Rule 13. Escalate complex matters early.
• Communication. Confirm actions taken, specify any data retained with reasons, and provide the list of downstream entities notified following corrections.

Requests should be processed without charging fees. Retaliation or service degradation after a rights request is not acceptable.

What Changes for Operators and Teams

To comply with Section 12 and Rule 13 in real organizations, you need hard controls, not policy slides.

• Intake and tracking. A dedicated channel to receive rights requests, ticketing with SLAs, and identity verification steps.
• Data mapping. A current inventory of systems and data flows, including all downstream recipients and processors for each category of personal data.
• Correction and update workflows. Playbooks for each data domain, with clear owners, evidence standards, and approvals. Audit logs for every change.
• Ripple effect automation. A registry of all recipients per data element and an automated notification process with follow-ups and proof of delivery.
• Deletion tooling. Capabilities to delete data across production systems, search indexes, caches, and analytics stores. Clear handling for backups and logs, and documented anonymization methods where used.
• Retention matrix. A legal register of retention obligations tied to data categories, with automatic purge schedules and exceptions management.
• Refusal protocol. A documented proportionality assessment, legal basis analysis, and standard communication templates for partial or full refusals.
• Monitoring and reporting. Metrics on volume of requests, turnaround times, downstream completion rates, and exceptions invoked. Regular reviews with engineering and legal.

Common Pitfalls to Avoid

• Ignoring or delaying requests beyond statutory timelines.
• Performing soft deletes and claiming erasure.
• Overstating legal retention without a specific statute or order.
• Using backups as a permanent excuse to retain data.
• Failing to notify downstream recipients after corrections.
• Demanding excessive evidence for simple factual fixes.
• Charging fees for exercising rights.
• Not informing the Data Principal about entities who also hold the data.

Treat these as audit findings waiting to happen. They are preventable with the right controls and accountability.

Closing

Section 12 is straightforward on paper and unforgiving in execution. You need accurate records, clean deletion paths, and disciplined downstream governance. The complexity lives in legacy systems, scattered data flows, and unclear ownership. That is where most teams stumble.

At Regodit, we structure these requirements into auditable workflows. Intake, verification, correction, erasure, downstream notifications, retention exceptions, and evidence trails all live in one place. It turns Section 12 from a compliance risk into a repeatable process that actually stands up to scrutiny.