Identity verification before answering data principal requests

Identity checks should be a doorbell, not a drawbridge with a clerk asleep behind it.

Identity verification sits at the awkward middle of every Data Principal request. If it is too weak, the organisation may disclose personal data to the wrong person. If it is too heavy, the organisation makes privacy rights difficult to exercise. Under the DPDP Act, Data Principals have rights relating to access, correction, erasure, grievance redressal and nomination, but those rights need a practical intake path that confirms the requester is entitled to act.

For Indian businesses, the question is rarely whether to verify identity. The question is how much verification is enough for the specific request, account type and data risk. A logged-in request to update a basic profile field is different from an email request seeking transaction history, account deletion, nominee action or access to sensitive support records. One verification rule for every situation creates either unnecessary friction or unnecessary exposure.

A good verification workflow should be risk-based, documented and repeatable. It should use existing account signals where possible, avoid collecting excessive new identity documents, and preserve evidence of why a request was accepted, rejected or escalated.

What to review

Start with the request channels. List every route through which a Data Principal can ask for access, correction, erasure, grievance handling, consent withdrawal or nomination support. Include logged-in account flows, web forms, app forms, email, customer support, enterprise account managers and offline escalations that later enter a digital workflow.

Review the account identifiers used in each route. The DPDP Rules refer to Data Principals furnishing particulars required by the Data Fiduciary to identify them, such as username or other identifier under the applicable terms of service. Your process should say which identifier is enough for each request route and when more proof is required.

Review authentication signals. Logged-in session status, verified email, verified phone, multi-factor authentication, enterprise admin approval, prior support history and payment-linked records can all help. Treat them as signals, not magic. A compromised account or shared mailbox may still need escalation.

Then review sensitive cases. Requests involving minors, persons with disabilities, nominees, account closure, deletion, breach complaints, high-value accounts, fraud flags, financial records, health information or workplace data need a stronger verification and approval path.

Implementation steps

Create verification tiers. Low-risk requests can use logged-in account confirmation or verified email. Medium-risk requests may require an additional account signal, one-time passcode or support callback. High-risk requests should require privacy or legal review before data is disclosed or destructive action is taken.

Define the minimum particulars for each request type. Access requests may need account identifier and a verified contact channel. Correction requests may need the record to be corrected and supporting context. Erasure requests may need confirmation of the account, product and consequences. Nominee requests may need the nomination record and proportionate evidence of the triggering event.

Avoid overcollection. Do not ask every requester for government identity documents by default. If a lighter method can verify the account, use that. If documents are needed, define who can view them, where they are stored, how long they are retained and when they are deleted.

Build escalation rules into the workflow. Escalate when the requester fails verification, claims to act for another person, asks for another user's data, seeks deletion of a disputed account, raises security concerns, or appears connected to fraud, harassment or coercion. These cases should not be handled through template replies alone.

Record the verification decision. The register should capture request channel, identifier used, verification method, reviewer, result, escalation, response date and closure status. The record should be enough to show that the team verified entitlement without storing unnecessary proof forever.

Train support teams on refusal language. If verification fails, the response should explain what information is needed without revealing account details. A poor refusal can itself disclose personal data, such as confirming that a phone number, email address or transaction exists.

Common mistakes

1. Using the same verification requirement for every request, regardless of risk, account type or requested action.
2. Collecting identity documents by default without a retention rule, access restriction or deletion process.
3. Treating a verified email address as conclusive even where the request is high-risk, disputed or made on behalf of another person.

How DataNuance can help

DataNuance helps teams build identity verification workflows that support DPDP rights without turning every request into a security incident. We design request tiers, verification matrices, escalation triggers, support scripts, evidence registers and vendor instructions so privacy, product, support and legal teams apply the same standard. For help implementing this workflow, speak with DataNuance.

FAQs

Is identity verification required before every rights response?

A business should verify that the requester is entitled to make the request before disclosing personal data or taking account-level action. The method can vary by risk. A logged-in request may need less friction than an email request from an unknown address.

Can we ask for government identity documents?

Sometimes, but not as the default answer. Use the least intrusive method that reasonably verifies the requester for the specific risk. If documents are collected, define access limits, retention period, deletion timing and audit records.

What if the requester acts for someone else?

Route the request through an escalation path. For children, persons with disabilities, nominees or authorised representatives, the team should verify the requester, the relationship or authority, and the specific right being exercised before responding.

What should we record after verification?

Record the request channel, account identifier, verification method, result, reviewer, escalation if any, response sent and closure date. Keep the record useful for audit without retaining excessive identity proof.

Sources

• Ministry of Electronics and Information Technology, Digital Personal Data Protection Act, 2023.
• Ministry of Electronics and Information Technology, Digital Personal Data Protection Rules, 2025.