Correction and erasure request handling under the DPDP Act
A practical checklist for Indian teams handling correction and erasure requests, identity checks, retention exceptions, vendors and evidence records.
Data>Nuance
Correction and erasure requests should not disappear into the same cupboard as forgotten HR forms.
Correction and erasure request handling under the DPDP Act needs a workflow that is practical enough for support teams and precise enough for legal review. Individuals may ask a business to correct inaccurate personal data, complete incomplete data, update records or erase data where the legal conditions are met. The request may sound simple, but the data may sit across product systems, CRM, HR tools, payment records, vendor platforms and archived exports.
The DPDP Act recognises correction and erasure rights, and the DPDP Rules, 2025 should be checked from official sources before final implementation decisions. For operational readiness, the goal is to decide who receives the request, how identity is verified, which systems are checked, what action is taken, and what evidence is kept.
What to review
Review intake channels. Correction and erasure requests may arrive through support tickets, email, account settings, HR, sales teams or grievance routes. Staff should recognise plain-language requests even when the user does not use legal terminology.
Review identity checks. Before changing or deleting records, confirm that the requester is linked to the relevant account or record. The check should be strong enough to prevent unauthorised changes, but not so heavy that it becomes a barrier.
Review system locations. A name, phone number, address, employment record or consent preference may appear in several places. Map the systems that hold the relevant data and identify the owner for each one.
Review retention exceptions. Erasure may not mean immediate deletion from every system. Some records may need to be retained for legal, fraud, accounting, employment, dispute or security reasons. Exceptions should be documented and explained clearly.
Review backups and exports. Teams should decide how archived reports, logs, backup cycles and downloaded spreadsheets are handled. If these stores are ignored, the request record may say closed while old copies continue to circulate.
Review vendor workflows. Processors, HR vendors, marketing platforms, analytics providers and cloud tools may hold copies or derived records. Vendor instructions should cover correction, deletion, suppression and evidence of completion.
Implementation steps
Create request categories. Separate correction, completion, update, erasure, suppression and consent-withdrawal requests. The categories help support teams route the request correctly and avoid promising deletion when suppression or retention review is required.
Build a system-action checklist. For each system, list the owner, data field, correction method, erasure method, retention exception, vendor contact and evidence record. Keep this checklist close to the request register.
Use proportionate verification. Match the verification level to the risk of the action. Updating a newsletter email may need a lighter check than deleting an account, changing payroll details or correcting employment records.
Prepare response templates. Responses should confirm what was changed or erased, what could not be erased, why an exception applies, and how the individual can raise a grievance. Avoid technical shorthand that only internal teams understand.
Track downstream completion. A request should not close merely because the first system was updated. Check CRM, product, support, billing, marketing, HR and vendor systems where relevant. Record unfinished actions and owners.
Run sample tests. Test one correction request, one account erasure request, one employee record correction and one vendor-dependent deletion. The test should expose unclear ownership before a real request creates pressure.
Common mistakes
- Treating erasure as a single delete button while copies remain in CRM, support tools, vendors or exports.
- Correcting the visible account record but leaving inaccurate data in billing, HR, marketing or analytics systems.
- Rejecting or delaying requests without documenting the identity check, retention exception or action owner.
How DataNuance can help
DataNuance can help design correction and erasure workflows, map systems, prepare retention exception rules, review vendor instructions, test sample requests and create response templates for support, HR, legal and product teams. To review correction and erasure request handling, contact DataNuance through our contact page.
FAQs
Does every erasure request require immediate deletion?
No. The request needs review against the applicable legal basis, retention duties, fraud or dispute needs, security requirements and system constraints.
Can correction requests be handled by support alone?
Simple corrections may start with support, but legal, HR, security or product owners should be involved where records are sensitive, disputed or system-wide.
What evidence should be kept after a request is completed?
Keep the request, identity check, systems reviewed, actions taken, exceptions applied, vendor confirmations, response sent and closure date.
How should vendors be handled?
Vendor contracts and operating instructions should say how correction or erasure requests are sent, completed, evidenced and escalated when delayed.
Sources
This publication is general information and is not legal advice for a specific organisation or matter.