Learn how to verify DPDP privacy requests proportionately without collecting excessive Aadhaar, identity documents or unnecessary personal data.
Overview
A customer asks you to delete their personal data.
Your privacy portal responds by asking for:
- a passport;
- an Aadhaar copy;
- a selfie;
- proof of address;
- an account statement;
- a signed declaration.
The company may be trying to prevent fraud.
But the request has now created a new sensitive-data collection event.
The customer wanted less data held.
The privacy workflow collected more.
Identity verification is necessary—but it is not unlimited
Privacy teams face a real risk.
If they disclose personal information to the wrong person, the request process itself becomes a security incident.
If they delete the wrong account, the business may harm another customer and destroy records it was required to retain.
Verification cannot be removed from the workflow.
It must be designed proportionately.
The question is not:
“Should we verify?”
It is:
Start with the risk of the action
Not every privacy request creates the same risk.
Consider four examples.
### Marketing opt-out
The requester asks to stop promotional messages to a registered email address.
The action reduces processing and discloses little information.
A one-time link or confirmation through the same channel may be enough.
### Consent withdrawal
The requester withdraws an optional consent inside an authenticated app.
The organisation already knows which account is acting.
A second identity-document upload may add no meaningful assurance.
### Data access request
The requester asks for a complete copy of financial, health or employment information.
Wrongful disclosure could cause serious harm.
Stronger authentication or manual review may be justified.
### Account erasure
The requester asks to delete an account containing transaction, contract or regulated records.
The organisation must verify identity, assess retention duties and confirm the consequences.
The workflow should adapt to the request.
A single government-ID form for every scenario is not risk-based verification.
Use the identity signals you already trust
Most enterprises already authenticate customers and employees.
They use:
- account passwords;
- passkeys;
- one-time passwords;
- registered mobile numbers;
- verified email addresses;
- customer IDs;
- patient IDs;
- employee credentials;
- transaction references;
- branch verification;
- device authentication.
A privacy request submitted from an authenticated account should begin with those signals.
This reduces friction and avoids creating a duplicate repository of identity documents.
For a guest request, the portal can start with the identifiers the organisation already uses to recognise the individual.
Ask for a registered email before a passport.
Ask for an order number before proof of address.
Ask for a patient ID before a full medical document.
Escalate only when the match remains uncertain or the requested disclosure is high risk.
Do not turn Aadhaar into the default privacy password
Aadhaar is a powerful identifier.
That does not make it the correct default for every privacy request.
Collecting it can create additional obligations and exposure:
- secure transmission;
- restricted access;
- masking;
- retention control;
- breach risk;
- vendor handling;
- deletion evidence.
Before requesting Aadhaar or another government ID, ask:
- Is the requester already logged in?
- Can a registered contact channel be used?
- Does the organisation already hold a customer identifier?
- Is the request low risk?
- Would a one-time code provide enough assurance?
- Is only a verification result needed rather than a document copy?
- How quickly will the document be deleted?
Progressive verification creates a better balance
Progressive verification applies stronger checks only when the risk or uncertainty increases.
A practical model can have four levels.
### Level 1: Channel confirmation
Use a registered email, mobile number or authenticated session.
Appropriate for low-risk preference and consent actions.
### Level 2: Record matching
Match account, booking, order, employee, patient or transaction identifiers already held by the organisation.
Appropriate when the requester is not logged in but the action remains limited.
### Level 3: Strong authentication
Use multi-factor authentication, branch validation, knowledge checks based on existing records or approved identity services.
Appropriate for sensitive access, correction or deletion requests.
### Level 4: Manual exception review
Request narrowly defined additional evidence when automated methods fail or fraud indicators appear.
Appropriate for name changes, inactive accounts, authorised representatives, dependants or disputed ownership.
The user should not begin at Level 4.
Failed matching should not become a dead end
A privacy request may fail to match for legitimate reasons.
The user may have:
- changed email addresses;
- changed their name;
- closed the account;
- used guest checkout;
- interacted through a partner;
- used several mobile numbers;
- created several profiles;
- never received a direct account;
- acted through a parent, guardian or authorised representative.
A weak workflow either fulfils the request without confidence or rejects it with a generic response.
A better workflow explains what could not be verified and offers a safer next step.
For example:
“We could not match the email address provided. You may verify using the mobile number registered with your account or provide the relevant order reference.”
The request should remain traceable through escalation.
Authorised agents need two questions answered
When another person submits a request, the organisation must assess:
- Is the Data Principal’s identity sufficiently established?
- Is the representative authorised to act for that person?
These are different checks.
A letter of authority does not prove the underlying identity.
An identity match does not prove authority.
The workflow should separate:
- requester details;
- Data Principal details;
- relationship or authority;
- scope of authority;
- validity period;
- supporting evidence;
- review decision.
This is especially important for parents, guardians, caregivers, nominees, legal representatives and enterprise administrators.
Verification data needs a deletion policy
Privacy teams often retain identity documents because they want audit evidence.
This can create a permanent secondary identity database.
A more proportionate evidence record may contain:
- verification method;
- assurance level;
- identifiers matched;
- result;
- date and time;
- reviewer;
- exception reason;
- request type;
- decision rationale;
- downstream action;
- deletion date for temporary evidence.
The organisation may not need to retain the full passport or Aadhaar image after verification.
Where a document must be retained, define:
- the legal or operational reason;
- access roles;
- storage location;
- encryption;
- retention period;
- deletion method;
- vendor access;
- audit controls.
Verification artefacts are personal data too.
Separate verification from fulfilment
A privacy request workflow has at least five stages:
### 1. Intake
Capture the request, right, channel and initial identifiers.
### 2. Verification
Establish identity and, where relevant, authority.
### 3. Scope
Identify systems, products, entities, processors and records connected to the requester.
### 4. Decision and fulfilment
Apply exemptions or retention duties, complete the approved actions and obtain processor confirmation.
### 5. Response and evidence
Communicate the outcome and preserve an audit-ready record.
When verification is mixed with fulfilment, teams often send unnecessary identity documents to vendors and internal system owners.
Processors usually need a verified customer or record identifier—not a copy of the requester’s passport.
The portal should not reuse request data
Information collected to verify a rights request should not quietly enter:
- marketing databases;
- fraud-model training;
- customer profiling;
- sales workflows;
- product analytics;
- support enrichment;
- identity graphs unrelated to the request.
The verification purpose should be explicit and technically enforced.
Request analytics should use minimised operational fields, such as request type, processing time, outcome and escalation reason.
Do not measure privacy operations by creating a new behavioural dataset about people exercising their rights.
India’s DPDP implementation needs an identity policy
The DPDP Act provides Data Principals with rights relating to access, correction, erasure and grievance redressal.
The implementation challenge is operational.
Enterprises should define:
- which identifiers are accepted;
- which request types require authentication;
- which actions can be completed from an authenticated session;
- when additional evidence is justified;
- how authorised persons are handled;
- how long verification evidence is retained;
- who can review exceptions;
- how processors receive verified instructions;
- how the organisation records its decision.
The policy should be approved jointly by privacy, security, legal, IAM, fraud, customer operations and product teams.
It should not live only inside a legal notice.
A practical verification design checklist
Review one privacy request journey and ask:
### Request classification
Is the user selecting access, correction, erasure, consent withdrawal, grievance or another action?
### Authentication reuse
Can the request be submitted from the authenticated product experience?
### Minimum identifier
What existing identifier is sufficient to locate the relevant records?
### Risk level
What harm could result from an incorrect fulfilment?
### Progressive escalation
Does the workflow ask for more only when the first method fails?
### Government ID control
Is government ID optional, exceptional or mandatory—and why?
### Secure collection
Are sensitive uploads protected in transit and at rest?
### Restricted access
Can only authorised reviewers see verification evidence?
### Retention
When are temporary documents and images deleted?
### Processor handoff
Do vendors receive only the reference needed to complete the action?
### Evidence
Can the organisation prove the request was verified and fulfilled without retaining unnecessary data?
What Consentica contributes
Consentica can provide a connected interaction layer for consent, preferences, withdrawal, privacy requests and grievances.
For request verification, the platform can support:
- authenticated and guest journeys;
- configurable verification levels;
- one-time links and OTPs;
- existing customer-identifier matching;
- multilingual request forms;
- authorised-agent workflows;
- request categorisation;
- owner and SLA assignment;
- processor task propagation;
- response evidence;
- verification-artefact retention;
- audit logs.
The objective is not to replace enterprise IAM, KYC or fraud controls.
It is to ensure that privacy requests use those signals proportionately and preserve a complete evidence trail.
The privacy experience should reduce data—not multiply it
A rights portal is often the most visible proof that an organisation respects customer control.
That experience fails when the person must surrender more sensitive information to ask for less processing.
Strong verification and data minimisation are not competing goals.
The right architecture can do both:
- reuse trusted identity;
- classify request risk;
- escalate only when needed;
- limit internal and vendor exposure;
- delete temporary evidence;
- prove the complete decision.
Your privacy portal should verify the requester.
It should not create a second identity database.
### Contextual CTA
Select one high-volume privacy request and list every field or document the requester must provide. For each item, record whether the organisation already holds it, why it is necessary, who can access it and when it is deleted.
### Product CTA
Consentica helps enterprises manage consent, preferences, withdrawal, Data Principal requests, grievances and downstream fulfilment through configurable journeys and audit-ready evidence.
Explore Consentica:
Ready to review this consent workflow? Explore Consentica and request a product demonstration for your customer journey.