DPDP NavigatorAct 2023 · Rules 2025
All guides
Rights & Grievances

Verifying Identity for Rights Requests Without Creating a New Privacy Risk

29 Jul 20267 min read

Verifying who is making a rights request is necessary, but collecting more identity data than the request warrants creates a new processing risk of its own.

The verification paradox

Rights requests exist to give a Data Principal control over their own personal data, but answering that request safely requires confirming the requester actually is who they claim to be - otherwise you risk handing someone else's personal data to an impersonator, which is its own serious failure. That verification step, however, involves collecting or checking identity information, which is additional processing that needs its own justification.

The goal is proportionality: verify enough to be confident, without turning every rights request into an opportunity to collect a fuller identity profile than you actually need for the underlying relationship.

Matching verification rigor to request sensitivity

Not every rights request carries the same risk if it goes to the wrong person. A request to correct a mailing address carries less exposure than a request for a full access summary that includes financial or health-related data, so it makes sense to tier verification accordingly rather than applying a single fixed standard to everything.

For lower-risk requests, matching against details you already hold - an existing registered email, a prior transaction reference - may be sufficient. For higher-risk requests, a stronger check, such as a government-issued document already on file compared against a fresh submission, is more appropriate. The key is that the stronger check should draw on information already collected for a legitimate purpose, rather than prompting the individual to hand over new sensitive documents solely to prove who they are.

Retention and disposal of verification artifacts

Whatever identity information is collected or reviewed during verification should have a short, defined retention period tied to the request itself, not folded permanently into the individual's broader profile. Keeping a scanned identity document indefinitely after a single rights request has been resolved creates exactly the kind of unnecessary processing the Act is designed to discourage.

Document the verification method used for each request, even briefly, so that if the process is ever questioned you can show what standard was applied and why, without needing to retain the underlying sensitive artifact itself.

Where to go next

The Request Handling Toolkit includes a tiered verification framework that can be adapted to match your organization's risk profile, so verification stays proportionate across different types of rights requests.