Correcting customer data without creating a second mistake

A customer reports a wrong address. One employee fixes the sales screen, but the next parcel goes to the old location because the warehouse imported yesterday’s file. The correction existed in one place and failed in the workflow that mattered.

Section 12 of the DPDP Act provides for correction, completion and updating of relevant personal data, with its stated prior-consent scope including section 7(a). Section 8(3) separately requires completeness, accuracy and consistency where data is likely to be used to make a decision affecting the person or disclosed to another fiduciary. As of 22 October 2026, these duties are scheduled for May 2027 under the commencement notification.

Identify the record before changing it

Start by confirming the requester and the record concerned. A matching name is rarely enough when a business serves families or has several customers with common names. Use the identifiers already appropriate to the service and avoid disclosing information while trying to verify the request.

Clarify whether the customer is correcting an error or reporting a later change. “This was never my address” and “I moved last month” can require different treatment of historic records. Record the distinction so staff do not rewrite a past transaction as though it occurred at the new location.

Verification should reflect the risk. A change to a delivery instruction may need a different check from changing the account used for refunds. Do not let an easy-to-obtain detail become sufficient authority to redirect money or sensitive communications.

Find the authoritative field and its copies

In a hypothetical equipment rental business, the booking system holds the current delivery address, finance retains completed invoices and the logistics team receives a daily export. The team should identify which system governs future deliveries and how the other systems receive updates.

Make the correction there, then trace the downstream effect. Is today’s delivery batch already created? Does the courier receive a new instruction? Does a customer-service cache continue to display the previous value? A system diagram can make these dependencies visible without requiring a large data-governance platform.

For each downstream system, define whether it should replace a current value, append a correction or preserve a historic record with an explanatory note. The appropriate treatment depends on the purpose and applicable retention requirements.

Preserve history for a reason

Keeping an audit trail can help explain who changed a record and why. That does not justify retaining unnecessary copies of the disputed information everywhere. Separate the operational current value from a restricted history needed for evidence or legal requirements.

For an invoice, a business may need to follow an applicable correction procedure rather than silently altering the original. Verify that procedure for the relevant accounting or sector regime. Do not invent a universal DPDP instruction to overwrite every historic document.

If a value is disputed but cannot immediately be verified, record the dispute and assess whether continuing to use it could harm the person. Escalate the decision to an appropriate owner. Avoid choosing between blind acceptance and indefinite inaction when a temporary restriction or clarification may be available.

Check the result where it will be used

The rental business should test the next dispatch record, not only the edit screen. A confirmation from the courier or a checked order preview may provide useful evidence that the change reached the operational destination.

Keep the request, decision, systems updated, unresolved exceptions and completion evidence. The exact record format is a recommended control. The final rights rule addresses published request routes and identifiers but does not prescribe a universal correction ticket template.

Tell the customer what was corrected and any meaningful limitation. If a historic invoice remains unchanged for a specific legal reason, explain that separately from the current address update. A vague “done” message can create false expectations about every copy.

Prevent the next mistake

Review why the wrong value entered the workflow. Was it mistyped at a counter, imported from an old form, overwritten by a vendor sync or merged with another person’s profile? Fixing the individual record without addressing the cause can produce the same complaint again.

Useful improvements might include field validation, a confirmation step for important changes, clearer source priority or an exception queue for conflicting updates. These are implementation choices that should match the risk and workload.

The final test is practical: the correct person has the correct current information in the systems that act on it, necessary history is understandable, and the business can show how it reached that result. A successful correction changes the outcome, not merely a field on one screen.