Consent under the DPDP Act: what background verification actually requires

India's Digital Personal Data Protection Act, 2023 sets out how personal data may be collected and processed, and background verification sits squarely inside its scope. A screening programme collects identity numbers, address history, employment records and sometimes financial and health information — about a person who is not yet an employee and who is in an unequal negotiating position.

This is not legal advice, and how the Act applies to a specific programme is a question for your counsel. But the operational direction is clear enough to design around, and some common practices are visibly on the wrong side of it.

The clause in the offer letter is not a consent flow

The traditional approach is a paragraph in the offer letter or application form: the candidate agrees that the company may conduct background checks. One signature, unlimited scope, no expiry.

Several things make that fragile under a consent-based regime:

It is not specific. "Background checks" does not tell the candidate whether that means confirming a degree or pulling a credit report. Consent is meaningful only against a stated purpose.

It is bundled. Agreeing to employment terms and agreeing to a financial check are separate decisions, and collapsing them into one signature makes refusal impossible without withdrawing from the job.

It is not withdrawable in practice. If consent lives in a signed PDF in a filing system, there is no mechanism for a candidate to withdraw it — and no way for the company to demonstrate it honoured a withdrawal.

It leaves no record of what was actually agreed. When someone asks, two years later, on what basis a credit check was run, "clause 14 of the offer letter" is a weak answer.

What a defensible flow looks like

Consent per check, not per programme. The candidate sees each check by name — identity, address, education, employment, court records — and agrees to each. A candidate who agrees to five and declines a sixth has made a real choice, and the sixth simply does not run.

Purpose stated in language a candidate understands. Not "verification of antecedents" but "we check that the degree you listed was actually issued by that university."

Timestamped and stored as its own artefact. Consent is evidence. It should be retrievable independently of the report, showing what was agreed, when, and in what wording.

Withdrawable, with the withdrawal doing something. A candidate should be able to withdraw consent for anything not yet completed, and the system should stop that check. Withdrawal that changes nothing operationally is not withdrawal.

Collected before the check runs. Obvious, and still worth stating: a check that starts before its consent exists cannot be retroactively consented to.

Collect less, and keep it for less time

Two habits do most of the work here.

Collect only what the check needs. A court record search needs identity and address history. It does not need a salary figure. Data collected "in case it is useful" is data you must protect, justify and eventually delete.

Set a retention period and honour it. Verification evidence has genuine value — it is what makes a decision defensible if challenged later. But indefinite retention of identity documents for candidates who were never hired is difficult to justify under any purpose limitation. Decide the period, write it down, and make deletion automatic rather than aspirational.

For the candidate

There is a version of this that treats the Act as a compliance tax, and a version that treats it as a description of how people should have been handled all along. The second is cheaper to build and easier to defend.

A candidate who can see exactly what is being checked, why, and what happens to it afterwards is a candidate who is less likely to abandon the process — and a programme designed that way tends to be the one that also survives scrutiny.

• DPDP
• consent
• compliance