The HR guide to the DPDP Act

India's Digital Personal Data Protection Act reorganises the relationship between an employer and a candidate's data. It does not prohibit background verification — verification remains lawful, and for regulated roles it remains mandatory. What it removes is the mechanism most Indian employers have relied on to authorise it: a broad clause buried in an offer letter that says the company may verify "any and all information" by "any means it deems appropriate".

That clause is no longer consent. Understanding why is most of the work.

The three words that change hiring

The Act requires consent to be free, specific and informed. Each word does something.

Free means the candidate can decline without disproportionate consequence. A role that genuinely requires a criminal record check can be conditioned on that check — the consequence is proportionate to the purpose. Conditioning the same role on consent to a credit check that has nothing to do with the job is not.

Specific means consent attaches to a purpose, not to a company. "We may verify your background" names no purpose. "We will confirm your employment dates with your two most recent employers, and verify your degree with the issuing university" names two. Consent covers what it names.

Informed means the notice comes before the collection, in language the person actually reads, and lists what is collected, why, and for how long it is kept.

The practical consequence is that a single consent checkbox at the offer stage cannot carry a verification programme. Consent has to be captured per purpose, at a point where the candidate can see what each purpose is.

Notice is a separate obligation

Consent and notice are often treated as one artefact. They are not. The notice is what you tell the candidate; the consent is what they give you in response. A notice that does not itemise the checks cannot produce specific consent, no matter how clearly the candidate ticked the box.

A workable notice states, for each check: the data collected, the source it will be verified against, the purpose it serves for this specific role, the retention period, and how to withdraw consent. That last item is not optional, and it is where most existing processes fail — many have no withdrawal path at all.

Withdrawal has to actually work

The Act gives the candidate a right to withdraw consent, and the withdrawal has to be as easy as the giving. In a verification context this raises an awkward but answerable question: what happens to a check already in flight?

The honest answer is that withdrawal stops future processing. It does not retroactively unmake a verification that has already completed, and it does not compel you to delete a record you have an independent legal obligation to retain — a regulated financial institution's records under RBI rules, for instance. What it does compel is that you stop, that you say so, and that you do not quietly continue because the check was convenient.

Build the stop into the system. A withdrawal that requires an operations person to remember to cancel something is a withdrawal that will sometimes not happen.

Retention is the obligation most programmes fail

Purpose limitation has a consequence that catches people out: when the purpose is served, the data has to go. A verification report supports a hiring decision. Once the decision is made and any appeal window has closed, the underlying documents — the Aadhaar XML, the payslip, the degree certificate scan — no longer have a purpose.

Most verification programmes keep everything, indefinitely, because storage is cheap and nobody has ever been asked to justify it. Under the Act, indefinite retention of candidate documents without a stated purpose is the default failure mode, and it is the one that leaves the largest quantity of sensitive data sitting where a breach can reach it.

Two things follow. Set a retention period per data class rather than one period for everything. And separate the verdict from the evidence: the finding that a degree was confirmed can reasonably be kept for the life of the employment; the scanned certificate that established it usually cannot.

Your vendor is a Data Processor, and that is contractual

If you use a verification provider, you are the Data Fiduciary and they are your processor. The obligation stays with you. The Act expects that relationship to be governed by contract, which in practice means your vendor agreement should be specific about: what they may process and for what purpose, where the data is stored, what happens when you instruct deletion, how quickly they notify you of a breach, and whether they may use your candidate data for anything of their own — model training included.

That last one is worth asking directly. An AI-native verification platform processes a great deal of candidate data, and "we may use aggregated data to improve our services" is a clause that deserves a straight answer about what leaves your tenant.

Where a discrepancy meets a data right

The Act also gives candidates a right to correction. In verification, this collides with something specific: a discrepancy is not an error. If a candidate's stated employment dates do not match the provident fund record, the candidate may ask you to "correct" your record to match their claim.

What they are entitled to have corrected is inaccurate personal data you hold. They are not entitled to have a verified finding overwritten with an unverified assertion. The way through is to hold both: the claim as declared, the finding as verified, and the discrepancy as a discrepancy. A system that stores only a final verdict has nowhere to put a contested correction, and will end up either ignoring the right or destroying the finding.

A working checklist

• Replace the blanket offer-letter clause with per-purpose consent captured at collection time.
• Write a notice that itemises each check, its source, its purpose and its retention period.
• Build a withdrawal path that actually halts in-flight processing, and log it.
• Set retention per data class, and separate verdicts from the evidence behind them.
• Put processing terms in the vendor contract, including what the vendor may do with your data.
• Store declared data, verified data and discrepancies as three distinct things.

None of this makes verification harder to run. It makes it harder to run carelessly, which is the point.

• DPDP
• compliance
• consent
• data retention