Verify a requester without collecting another identity dossier

Verifying a privacy requester should reduce the chance of disclosing or changing the wrong person’s information. It should not automatically create a second collection of identity documents that is harder to protect than the original record.

Begin with the action requested and the harm an incorrect decision could cause. Updating a delivery instruction, releasing an account summary and erasing a disputed record may need different assurance. A single upload-your-ID rule is unlikely to explain those differences well.

Use what the organisation already knows

A customer making a request from an authenticated account gives the organisation a different starting point from an unknown email address. Existing account context may help connect the person with the relevant records, but the team still needs to assess whether that context is trustworthy for the requested action.

Consider whether the account was recently recovered, whether the request concerns another person’s information and whether the response destination has changed. These are proposed review factors, not a prescribed DPDP verification formula.

The OWASP Authorization Cheat Sheet distinguishes access decisions from simple identity assumptions through its recommendations on least privilege and permission checks. Knowing who controls an account does not automatically authorise disclosure of every record connected with it.

Where more evidence is necessary, ask for the smallest additional information that resolves the specific uncertainty. Explain why it is needed and how it will be handled.

Do not use the response to reveal the answer

A verification step can accidentally disclose the very information it is meant to protect. For example, asking an unknown sender to confirm a full stored address by displaying that address first reveals it before the check is complete.

Design questions and channels carefully. Avoid sending a detailed account summary to a newly supplied email address just because the requester asks. Use an approved route for confirming destination changes.

Similarly, avoid security questions based on easily discoverable facts. The purpose of this article is workflow design, not a recommendation for a particular authentication mechanism. A security owner should assess the mechanism and its recovery paths before it is relied on.

A hypothetical request from a changed number

Imagine a customer of a local appliance service who says their old telephone number is no longer available. They ask for a summary of repair records and provide a new number for the response.

The team should not reject the request automatically, nor should it immediately send the history to the new number. A reviewer follows an approved alternative process using appropriate existing context and, where justified, limited supporting evidence.

The reviewer records the decision and the method used without copying every item into a general case note. If an identity document is needed for a justified verification step, the team determines who can view it, which parts are necessary and when the copy should be removed under the applicable policy.

A record saying “verified through approved alternative process, reviewer and time recorded” may be operationally more appropriate than retaining an unrestricted scan forever. The actual evidence design should be agreed with the organisation’s legal and security owners.

Keep request verification distinct from other checks

The DPDP Act’s individual-rights provisions should be read in their own scope. Do not turn a parental-consent provision or a nominee workflow into a general rule requiring every adult requester to submit the same identity document.

The substantive rights framework is scheduled for 13 May 2027 under the commencement notification, as checked on 22 October 2026. This is readiness guidance. Existing sector-specific and other applicable obligations need their own assessment.

A representative’s request creates a separate question: what authority does that person have to act? Verifying the representative’s identity and verifying their authority are different tasks. Keep the scope of any authority visible, and avoid assuming it permits unrestricted account access.

Design the evidence lifecycle

Verification material needs an owner and a retention decision. Separate raw supporting documents from the outcome record where practical. Restrict access to both, because an internal reference can still identify a person.

NIST IR 8062 encourages attention to unnecessary exposure even inside an authorised environment. Apply that idea to the support team: which reviewer needs to inspect the document, and which colleague only needs to know that the approved check succeeded?

Before adopting a verification process:

• Match the assurance to the requested action.
• Prefer reliable existing context where suitable.
• Explain the reason for additional evidence.
• Avoid revealing stored information during the check.
• Provide an approved alternative when a channel is unavailable.
• Record identity and representative authority separately.
• Limit access and retention of supporting material.

Test the process with synthetic cases involving a lost number, a shared household account and an authorised representative. The aim is a decision the organisation can defend without making every person submit a new dossier.