DPDP Access, Correction, and Erasure: Engineering Guide

A privacy request is not complete when someone forwards an email to engineering. The team must verify the requester, find the relevant personal data, apply the requested change where appropriate, coordinate with processors, preserve records that must lawfully remain, and communicate the result without exposing another person’s account.

For an authentication system, this work touches users, sessions, identities, audit events, support tools, email providers, analytics, backups, and deletion jobs. This guide turns that surface area into an engineering workflow. It is educational information, not legal advice; qualified counsel should determine how the Digital Personal Data Protection Act, 2023 and the notified rules apply to a particular organization.

Start with a rights-request record

Create one internal record for every request. Do not manage the process through an unstructured support thread.

The record should contain:

• an opaque request ID;
• request type: access, correction, completion, erasure, or consent withdrawal;
• received time and channel;
• claimed identity and account identifiers;
• verification state;
• systems and processors in scope;
• decisions, owners, and deadlines;
• actions performed and evidence; and
• completion or rejection communication.

Keep sensitive documents out of the record unless they are necessary. The system for handling privacy rights should not become a new warehouse of identity data.

Verify the requester without creating a new privacy risk

The person making the request must be connected to the account or data in question. That does not mean asking everyone to upload a government identity document.

Use the least intrusive method appropriate to the risk:

1. Ask a signed-in user to confirm the request through an authenticated account.
2. For a logged-out user, use a verified account channel and a short-lived, single-use confirmation.
3. For a high-risk change, add stronger verification or manual review proportionate to the harm.
4. If the requester cannot use the normal recovery path, separate account recovery from the privacy decision.

Do not reveal whether an account exists before verification. A public endpoint that confirms email addresses can turn a privacy workflow into an account-enumeration tool.

Build a data map before building deletion code

An identity record rarely lives in one table. Map the systems that can contain personal data:

For each location, document the controller, processor, retention rule, deletion mechanism, and evidence returned. If a vendor has no usable deletion interface, that is an architecture and procurement risk—not merely a support inconvenience.

Access requests need a safe export

An export should contain the requester’s relevant personal data in a readable format without including secrets or another person’s information.

Exclude password hashes, private keys, raw access tokens, one-time codes, internal abuse rules, and information that would compromise another account. Review shared records carefully: a team invitation or support conversation can contain data about several people.

Generate exports asynchronously when the data set is large. Encrypt the artifact, make the download short-lived, log access to it, and delete the artifact after its retrieval window closes. Do not attach a permanent archive to an ordinary email.

The authentication data-retention guide helps define which source records should exist long enough to appear in an export.

Correction requests must propagate

Changing an email address in the primary user table is not enough if the old value remains in a search index, customer-support profile, messaging provider, or authorization claim.

Treat a correction as a workflow:

verified request
  -> validate the proposed value
  -> update the source of truth
  -> rotate or revoke affected sessions when risk requires it
  -> publish an internal correction event
  -> update processors and derived stores
  -> verify completion

Preserve the distinction between correcting a fact and rewriting history. An audit event may need to record that an administrator changed an address without silently altering the historical actor information. Counsel and security owners should define the lawful and operational treatment.

Erasure is a state machine, not one SQL statement

Erasure often requires several ordered actions:

1. Freeze conflicting account changes.
2. Revoke active sessions, refresh tokens, API keys, and recovery links.
3. Remove or anonymize active profile data.
4. Delete credentials and connected identities.
5. Send deletion commands to processors.
6. Mark backups for expiry under the documented retention schedule.
7. Retain only records that have a documented lawful or security reason to remain.
8. Record completion without recreating the erased profile.

Make the operation idempotent. A retried job should continue safely rather than restore a field, issue a second contradictory processor request, or fail because one record is already gone.

Consent withdrawal needs downstream enforcement

The DPDP Act addresses withdrawal of consent and the cessation of processing where another lawful basis does not apply. A product toggle is only the first step.

The system must identify processing tied to that consent, stop future jobs, notify relevant processors, and decide what existing data must be erased or retained. Keep authentication required to operate the account separate from optional analytics, marketing, personalization, or enrichment consent.

Design for partial failure

Processor APIs time out. Export jobs fail. A backup deletion window may run later than an active-store deletion. The workflow needs explicit states such as received, verifying, in_progress, waiting_on_processor, completed, and rejected.

For every step, store:

• attempt time;
• result code;
• retry policy;
• responsible owner; and
• evidence that does not contain the erased data itself.

Alert on requests stuck beyond the organization’s approved service window. A spreadsheet checked once a month is not a reliable rights-request system.

Test the workflow before a real request arrives

Use synthetic users to test:

• an access export with shared records;
• an email correction while sessions remain active;
• an erasure job when one processor is unavailable;
• a repeated deletion request;
• restoration of an old backup after deletion; and
• a request from someone who cannot access the account.

The backup test matters: restoring data must also restore the deletion ledger or replay completed deletion actions, otherwise erased profiles can silently return.

The DPDP engineering checklist covers the wider product surface. For identity architecture and India-resident authentication, explore NamoID Customer Identity.