The previous piece set out what the DPDP framework changes for employers who verify. This one is about building a programme that meets it.
It is written for the HR operations lead, the talent acquisition head, or the compliance manager who has just been told “make our background checks DPDP-ready by May” and has no idea where to begin.
The honest answer is that there are five places to begin, and they map to the five obligations that matter: notice and consent, scope, the vendor contract, retention and erasure, and breach readiness. Taken in order, they form a programme that can be stood up in roughly twelve weeks.
Step one: take consent out of the offer letter
The single most common failure in Indian verification programmes is also the easiest to fix.
Consent for background verification currently lives inside the offer letter or appointment letter in the overwhelming majority of Indian companies. One clause, general in wording, signed alongside forty other terms.
Rule 3 of the DPDP Rules requires the notice to be presented independently of other information. So the first task is structural: create a standalone consent instrument, separate from the offer, that the candidate reads and acts on as a distinct step.
In practice this means a digital consent form, served at the offer-acceptance stage, that the candidate completes before any check is initiated. The form carries its own timestamp, its own record of what was shown, and its own affirmative action (a tick, a signature, an OTP confirmation).
The timing matters. Consent must precede collection. A form sent on day one of employment, after the vendor has already pulled education records, is evidence of the wrong thing.
Step two: itemise the notice to the check
Rule 3 requires an itemised description of the personal data being collected, and the purpose for each item.
The practical way to meet this is to build the notice from the check package, line by line.
For a standard Indian package, the notice might carry seven lines, each pairing a check with the data it uses and the reason it is run. Identity verification, using PAN and Aadhaar-linked confirmation, to confirm the candidate is who they say. Education verification, using degree certificates and university records, to confirm the qualification claimed. Employment verification, using relieving letters, experience letters and UAN history, to confirm tenure and dual-employment status. Address verification, using proof of address and physical or digital confirmation, to confirm residence. Criminal record check, using court and police records at the stated address history, to confirm the absence of relevant proceedings. Reference check, using the referees named by the candidate, to confirm role and performance. And where the role requires it, a credit or financial check, with the specific regulatory or role-based reason stated.
Each line also states who will process the data (the employer and its named verification partner), how long it will be retained, and how the candidate can withdraw consent or raise a complaint.
The point of itemising is not bureaucracy. It is that a candidate who later disputes the check cannot say they did not know what would be collected, and the Board cannot say the notice was vague.
Step three: scope the package to the role
The Act’s principle of purpose limitation, and the practical limits of Section 7(i), both push in the same direction: run the checks the role justifies, not the checks the package contains.
Most Indian employers currently run a single package across every hire, from a junior developer to a finance controller. Under DPDP that is a liability, because the employer must be able to say why each check was necessary for each role.
The fix is a short role-tiering exercise. Group roles into three or four risk tiers based on access to money, data, vulnerable people and regulatory exposure. Assign a check package to each tier. Document the reasoning in one page.
A junior developer with no financial access probably does not need a credit check. A controller does. A field engineer visiting customer homes probably needs a criminal check at every address in the last seven years. A remote content writer may not.
The tiering document does two things. It makes each check defensible as necessary. And it usually reduces the number of checks run, which lowers cost, speeds turnaround, and shrinks the volume of data that must later be erased.
Step four: rewrite the vendor contract
Section 8(2) requires a valid contract between fiduciary and processor. Most existing BGV agreements were written as service contracts, and they need to become data processing agreements.
The clauses that matter are these. A definition of the purpose and scope of processing, tied to the itemised notice. A requirement that the vendor process only on the employer’s documented instructions. Security obligations, with specific technical and organisational measures. A breach notification duty from vendor to employer, with a timeline short enough that the employer can meet its own 72-hour reporting window. Sub-processor controls, because most verification involves field agents, court search partners and database providers, each of whom touches the data. Retention and erasure terms that mirror the employer’s own policy. Audit rights. And a return-or-destroy clause for the end of the engagement.
Two practical points. First, the contract should name the verification partner so that the consent notice can name them too. Second, the employer should ask to see the vendor’s own consent-capture and erasure mechanisms. A vendor that captures candidate consent digitally inside its platform, and that can show an erasure log, is doing part of the employer’s compliance work for them. One that cannot is adding to it.
Step five: define the erasure point, and apply it
Section 8(7) requires erasure when the purpose is served. For a verification programme, that means writing down, for each category of candidate, when the purpose ends and what happens next.
For hired candidates, the purpose of the pre-employment check ends at joining. If the employer intends to retain the report, it must identify a separate lawful purpose: a sectoral record-keeping rule, a defined window for defending claims, or a stated continuous-screening programme for which fresh consent is taken. That purpose, and its duration, goes into the retention policy and into the notice the candidate saw.
For rejected candidates, the purpose ends at the decision. The report and its underlying documents should be erased within a short, defined window after the rejection is communicated. Thirty days is a defensible figure that allows for any immediate dispute; longer periods need a stated reason.
For withdrawn candidates (those who accepted an offer and then declined, or who withdrew consent mid-process), the purpose ends at withdrawal, and erasure follows.
The policy is only half of it. The other half is the mechanism. Someone has to own a monthly erasure run, across the HRMS, the vendor platform, the shared drive, and the email threads where reports were forwarded. The vendor must be instructed to erase on the same schedule and must confirm in writing. And the erasure must be logged, because “we deleted it” is a claim, and a log is evidence.
Expect this step to be the hardest. It touches habits that are a decade old, and it requires someone to go through an archive that nobody has looked at since it was created.
The cross-border layer for global employers
For companies headquartered outside India, there is a sixth step that sits across all five.
If verification reports on Indian candidates flow to a parent company in the UK, the Gulf, Singapore or the United States, the DPDP obligations follow the data. In practice this means the consent notice must disclose the transfer and the receiving entity. The intra-group arrangement under which the parent receives the data must satisfy Section 8(2), since the parent is processing on the Indian entity’s behalf. And the erasure schedule must reach the parent’s systems, not just the Indian subsidiary’s.
The common failure here is an HR system of record sitting in London or Dubai, holding a copy of every Indian verification report, with no erasure routine because nobody in London or Dubai thinks of the Indian candidate as their data subject. Under the DPDP framework, they are.
Breach readiness: the step nobody wants to rehearse
Rule 7 requires the employer to notify affected individuals without delay and to file a detailed report with the Board within 72 hours.
A verification file breach is not hypothetical. BGV data is dense with identity documents, it passes through multiple hands, and it is often stored in the least controlled part of the HR estate.
Breach readiness for a verification programme means four things. An inventory of where verification data lives, so that the scope of a breach can be established quickly. A contact route to every candidate in the archive, which is itself an argument for not keeping rejected candidates’ files. A template notice in plain language. And a rehearsed chain from vendor to employer to Board that can run inside three days.
Run the drill once. The gaps it exposes are usually in the inventory, which is the part that cannot be fixed on the day.
What a DPDP-ready verification file looks like
Put the five steps together and a single verification case, opened in May 2027, looks like this.
A standalone digital consent, timestamped, showing the itemised notice the candidate saw and the affirmative action they took. A role-tier reference, pointing to the one-page justification for the checks run. A vendor case record, under a processing agreement that names the vendor and binds its sub-processors. The report itself. A retention tag, stating the erasure date and the purpose that sets it. And, in due course, an erasure log entry confirming that the file was destroyed on schedule.
Six artefacts. None of them exotic. All of them absent from the typical Indian verification file today.
Twelve weeks, in order
For a team starting now, the sequence that works is this.
Weeks one to three: build the role-tiering and the itemised notice together, since the notice is built from the package and the package is built from the tiers.
Weeks four to six: stand up the standalone consent instrument, digital, timestamped, served at offer acceptance.
Weeks seven to nine: renegotiate the vendor contract into a processing agreement, and confirm the vendor’s own consent and erasure mechanisms.
Weeks ten to twelve: write the retention and erasure policy, run the first archive clean-up, and run the breach drill.
That lands a programme by the end of January, with three months of operation before the May obligations bite. It also means that when the Consent Manager framework goes live on 13 November, the employer is already building to the architecture the Board expects, rather than discovering it.
The real change
For most of its history, background verification in India has been something an employer does to a candidate. The candidate’s role was to supply documents and wait.
The DPDP framework turns that around. The candidate becomes a data principal with rights: to know, to consent, to withdraw, to have their data erased. The employer becomes a fiduciary with duties, and the verification partner becomes a processor inside the employer’s perimeter.
The companies that treat this as a compliance tax will do the minimum and hope. The companies that treat it as a trust mechanism will find something else: candidates who are told precisely what will be checked and why, and who know the file will not sit on a server forever, are more forthcoming, more accurate, and less likely to walk away from the offer.
That was always the point of verification. The law has just caught up with it.
