On 13 November 2025, the Ministry of Electronics and Information Technology notified the Digital Personal Data Protection Rules. It did so quietly, on a Thursday, with a press release that most HR leaders never saw.
That notification started an 18-month clock. It runs out on 13 May 2027.
Between now and then, every Indian employer that runs a background check on a candidate will need to answer a question that, for the entire history of this industry, nobody has had to answer: can you prove it was lawful?
Not “did you catch the discrepancy”. Not “how fast did the report come back”. Can you prove the candidate was told what you would collect, agreed to it, and that you erased it when you were done.
This piece is about that fourth metric, and why the first hard date arrives much sooner than May.
Three metrics for twenty years
Background verification in India grew up inside a legal vacuum. The Information Technology Act of 2000 and the 2011 SPDI Rules touched sensitive personal data, but in practice they were rarely enforced against employers, and almost never in the context of hiring.
So the industry optimised for what clients measured. Turnaround time: how many days from initiation to report. Coverage: how many checks in the package, how many countries, how many databases. Catch rate: how many discrepancies surfaced per hundred cases.
Those three metrics built good businesses and caught a great deal of fraud. They also created habits that the DPDP framework now treats as liabilities.
The habit of consent as a line item in the offer letter. The habit of running every check in the package regardless of role. The habit of keeping every report forever, because storage is cheap and you never know.
What the Act actually says, and what it does not
Before the operational detail, one correction to the market noise. A large number of vendor blogs now state that “explicit consent is mandatory before any background verification”. That is not quite what the Act says, and the difference matters.
Section 6 of the DPDP Act makes consent one lawful basis for processing personal data. Section 7 lists “certain legitimate uses” that do not require consent, and clause (i) of that section covers processing “for the purposes of employment or those related to safeguarding the employer from loss or liability”.
So an employer has, on the face of the statute, two possible doorways for verification: consent under Section 6, or legitimate use under Section 7(i).
Why, then, is nearly every serious legal adviser telling employers to build on consent?
Three reasons.
First, Section 7(i) is written for processing that is necessary to the employment relationship, and the Act does not define its edges. Verifying that a person holds the degree they claim is close to the core. Searching court records across five districts, or pulling a credit report, or checking social media, is further from it. Rely on 7(i) for the whole package and you are betting that the Data Protection Board agrees every check was necessary.
Second, Section 7(i) speaks of employment. A candidate is not yet an employee. Most practitioners read the clause as extending to recruitment, but it is a reading, not a certainty.
Third, and most practically, consent gives you a record. Legitimate use gives you an argument. When the Board asks, a timestamped itemised consent is a document you can hand over. A legal theory about necessity is a conversation you have to win.
The accurate position, then: consent is the safe harbour, not the only lawful basis. Employers who build on it are not doing so because the law forces them to. They are doing so because it is the only basis that leaves a paper trail.
Rule 3: the notice that most offer letters fail
If consent is the doorway, Rule 3 of the DPDP Rules describes the door.
A valid notice must be presented independently of other information. It must use clear and plain language. And it must carry an itemised description of the personal data being collected and the specific purpose for each item.
Read that against the clause the HR head in Pune showed Sachin: “The company may conduct background verification as it deems fit.”
It is not independent; it sits inside an offer letter. It is not itemised; it does not say which data. It is not specific; “as it deems fit” is the opposite of a stated purpose.
That clause, and the thousands like it across Indian offer letters, does not meet Rule 3. From 13 May 2027, consent gathered that way is not consent.
Rule 4 and the date that matters now
The Rules commence in three phases.
Phase one, from 13 November 2025, brought the Data Protection Board of India into existence and set the definitions.
Phase three, from 13 May 2027, brings in the substantive obligations: notice, consent, security safeguards, breach reporting, individual rights, and cross-border provisions. That is the date on every compliance slide.
Phase two sits in between, on 13 November 2026, and it is the one HR teams should be looking at this month.
Phase two switches on Rule 4: the registration framework for Consent Managers. A Consent Manager is a new regulated intermediary, registered with the Board, that provides a single interface through which an individual can give, review and withdraw consent across the organisations processing their data.
An employer does not need to become a Consent Manager. But from November, the architecture through which consent is expected to flow becomes real, with registered operators and technical specifications. Any employer still planning to “sort out consent nearer the time” will find, from November, that the Board has a working model of what good looks like, and will measure them against it.
There is a second reason November matters. Several practitioner analyses read the commencement notification as bringing the Act’s enforcement and penalty machinery into operation alongside Rule 4. If that reading holds, the Board’s ability to act is live six months before the obligations it would act on. Employers should assume the gap between “the rules apply” and “the regulator can bite” will be short.
Who carries the liability: you, not your vendor
The DPDP Act divides the world into Data Fiduciaries, who determine the purpose and means of processing, and Data Processors, who process on the fiduciary’s behalf.
In a background check, the employer decides which candidate to verify and which checks to run. The employer is the fiduciary. The BGV vendor is the processor.
Two consequences follow.
The first is Section 8(2): a fiduciary may engage a processor only under a valid contract. The vendor agreement that most companies signed years ago, built around turnaround SLAs and per-check pricing, is probably not that contract. It needs to specify purpose, scope, security obligations, breach notification duties, and what happens to the data when the engagement ends.
The second is that the Act places the obligations on the fiduciary. If the vendor mishandles candidate data, the Board’s first question goes to the employer. “Our vendor said they were compliant” is not a defence available under the Act.
For employers, this reframes the vendor relationship. Your verification partner is no longer a supplier whose output you consume. They are a processor inside your compliance perimeter, and their practices are your exposure.
Erasure: the obligation nobody has operationalised
Section 8(7) of the Act requires a fiduciary to erase personal data when consent is withdrawn or when it is reasonable to assume the specified purpose is no longer being served, unless retention is required by law.
Consider what that means for a verification report.
For a candidate who is hired, the purpose of the pre-employment check is served at the point of joining. Whether the report can be retained beyond that depends on whether a separate purpose exists: a regulatory record-keeping duty in a licensed sector, for instance, or a defined period for defending employment claims. That purpose has to be identified and stated, not assumed.
For a candidate who is rejected, the purpose is served the moment the decision is made and communicated. There is no employment relationship to justify retention. The report, and the raw documents behind it, should go.
A note on a figure you may have seen. Several Indian HR blogs assert that rejected-candidate data “must be deleted within 180 days”. That figure comes from the Third Schedule to the Rules, which sets a retention limit for large e-commerce, online gaming and social media platforms. It does not apply to employers as such. The employer’s duty is the general one in Section 8(7): erase when the purpose is served. For a rejected candidate, that is likely to be sooner than 180 days, not later.
Almost no Indian employer currently has a defined erasure point for verification files. That is the single largest gap between where most HR teams are and where the Act expects them to be.
Breach: 72 hours and every affected candidate
Rule 7 sets out breach notification. On becoming aware of a personal data breach, a fiduciary must inform each affected individual without delay, in plain language, with the nature and consequences of the breach and the measures being taken. The Board must be notified promptly, with a detailed report within 72 hours.
Verification files are a concentrated breach risk. A single case contains identity documents, address proof, education certificates, employment letters, and often PAN and bank details. A compromised BGV folder is a breach affecting every candidate in it, each of whom must be told.
The penalty ceiling under the Act for failing to take reasonable security safeguards is Rs 250 crore per instance. Employers should not expect the Board to reach for that figure in year one. They should also not assume it will stay theoretical.
Cross-border: the question global employers ask first
The Act permits transfer of personal data outside India except to countries the Central Government specifically restricts. The Rules add a layer: the Government may notify requirements for certain transfers, and the obligations of a fiduciary follow the data.
For a UK or GCC headquartered company hiring in India, with reports flowing to a regional HR system or a parent-company shared service, the practical consequence is that the Indian candidate’s data remains governed by the DPDP framework after it leaves the country. The consent notice must cover the transfer. The vendor and the receiving entity must be bound by contract. And the erasure obligation does not stop at the border.
The fourth metric, stated plainly
Turnaround, coverage and catch rate are not going away. Clients will still measure them, and vendors will still compete on them.
But from May 2027, a background check in India has a fourth property that it has never had: it is either evidenced or it is not.
Evidenced means: a standalone, itemised consent captured before the first check ran. A vendor contract that meets Section 8(2). A role-based scope that can justify each check as necessary. A defined erasure point, applied. A breach process that can reach every affected candidate inside 72 hours.
Most Indian employers currently have none of these. The good news is that all five can be built in a quarter, and the next piece sets out how.
The less good news is that the clock has been running since November, and the first date on it is three weeks away.
