On the morning of 14 November 2025, the Ministry of Electronics and Information Technology published the final text of the Digital Personal Data Protection Rules, 2025 in the Gazette of India. For the previous two years, Indian businesses had been operating under a peculiar regulatory state: the Digital Personal Data Protection Act, 2023 had been passed and assented to in August 2023, but without the operational rules, almost none of its provisions could be enforced. Compliance teams had drafted policy documents, run awareness sessions, and produced gap analyses. The actual operational lift had largely been postponed.
The notification of the Rules ended that waiting period. The Act now has the operational specificity that turns principles into enforceable requirements. The Data Protection Board of India is constituted and functioning. The staggered timeline has begun. And the eighteen-month window for full compliance — running to 13 May 2027 — is the longest runway the Indian compliance ecosystem is going to get.
For hiring and background verification, this is one of the most consequential regulatory developments of the decade. The verification process that most Indian employers and BGV vendors have been running for the last fifteen years was built for a regulatory environment that no longer exists. The structural assumptions that have governed the relationship between employer, candidate, and BGV vendor are being rewritten in ways that most HR teams have not yet internalised.
This is a landscape view of what actually changes, and why the next eighteen months are the period in which the compliance work has to happen.
Background Verification Records Are Now Personal Data Under Enforceable Law
The foundational shift is conceptual rather than procedural. Background verification has historically been treated, in Indian HR practice, as a category of information that exists in a kind of regulatory grey zone. It was clearly sensitive — it contained personal details, employment history, education records, criminal record information, sometimes credit data and biometric verification — but no comprehensive legislation was directly addressing it. The Information Technology (Reasonable Security Practices) Rules, 2011 imposed some obligations around “sensitive personal data,” but enforcement was patchy and the framework was widely viewed as having been overtaken by international practice.
The DPDP Act and Rules end that ambiguity. Background verification records are personal data. They contain identifiers, contact information, employment details, educational records, financial information, criminal data, address proofs, and in many cases Aadhaar and biometric verification artefacts. Every single data element collected during a BGV process is now squarely within the scope of the Act. The employer is the Data Fiduciary. The BGV vendor is the Data Processor. The candidate is the Data Principal. The relationships between them, the obligations of each, and the consequences of getting it wrong are now defined in enforceable law.
This sounds technical, but the practical consequences are immediate. Every step of the BGV workflow that previously sat in the “we’ve always done it this way” category now has a specific regulatory framework against which it can be measured. And in most cases, the existing practice does not measure up.
The Consent Regime Has Been Rebuilt
The most visible change for HR teams is the consent architecture. Rule 3 of the DPDP Rules 2025 requires that notices be presented in a way that is “independently understandable,” uses clear and plain language, and contains an itemised description of the personal data being collected and the specific purposes for processing. The consent itself, under the Act, must be free, specific, informed, unconditional, and unambiguous.
Each of those words has operational weight.
“Free” means the consent cannot be coerced. A consent clause bundled into an offer letter — where the candidate’s only practical choice is to consent or lose the job — is not free consent. This is one of the most uncomfortable findings for HR teams reviewing their current practice, because the bundled-offer-letter approach is the dominant pattern in Indian hiring today. The path forward is to separate the offer from the consent: the offer is the employment proposal, the consent is a separate document the candidate executes after they have received the offer but before BGV begins. The separation is not cosmetic; it is structurally required.
“Specific” means the consent cannot be a generic blanket. A clause saying “we will conduct background verification” is not specific enough. The consent must identify the specific categories of data being collected — education verification, employment verification, criminal record check, address verification, identity verification, professional reference checks, and so on — and the specific purposes for each.
“Informed” means the candidate must understand what they are consenting to. This is where the regional language requirement becomes operationally consequential. The Rules require notices to be presented in clear and plain language. For an Indian workforce that includes candidates whose primary language is not English, this typically means consent materials need to be available in at least the principal regional languages of the candidate population — Hindi, Tamil, Telugu, Marathi, Bengali, Gujarati, Kannada, Malayalam, and others depending on geographic spread.
“Unconditional” means the consent cannot be made dependent on conditions unrelated to the processing. “Unambiguous” means it must be expressed through a clear affirmative action — a tick box, a signature, an explicit acceptance — not inferred from inaction or silence.
The single-line offer-letter consent clause that has anchored Indian BGV programmes for fifteen years satisfies essentially none of these requirements. It is bundled with the offer, it is generic, it is in English only, it does not name the data or the vendors, and it does not provide for withdrawal. The remediation is not a wordsmithing exercise. It is a redesign of how consent is captured, when in the workflow it is captured, and what supporting infrastructure is required.
The Vendor Relationship Has Been Reframed
Under the DPDP framework, the BGV vendor is a Data Processor. The employer is the Data Fiduciary. And the foundational principle of the framework is that the Data Fiduciary remains responsible for compliance with the Act regardless of any agreement with the Processor.
This single principle reshapes the employer-BGV vendor relationship.
Historically, employers have treated BGV as something the vendor does. The vendor collects the candidate’s documents, runs the checks, generates a report, and the employer reads the report. If something goes wrong — a verification error, a data leak from the vendor’s database, an unauthorised use of candidate information — the employer’s instinct has been to hold the vendor accountable through the contract and consider the matter closed.
Under DPDP, that posture does not work. If the BGV vendor fails to implement reasonable security safeguards and a candidate’s personal data is breached, the employer as Data Fiduciary is liable for the failure to ensure the vendor was compliant. The vendor is also liable, but the employer’s exposure is independent of and additional to the vendor’s. The penalty architecture — up to ₹250 crore for failure to implement reasonable security safeguards — applies to the Data Fiduciary regardless of which party in the chain caused the breach.
The practical consequence is that vendor due diligence has gone from a procurement exercise to a continuing compliance obligation. The Data Processing Agreement between employer and BGV vendor must contain specific terms: the categories of data being processed, the purposes for which it can be processed, the security safeguards the vendor must implement (mapped to Rule 6’s minimum requirements), the breach notification timelines, the audit rights, the sub-processor restrictions, the data return and deletion obligations on termination. Most existing BGV vendor agreements were drafted before DPDP and contain none of this. The contracts need to be reopened.
The Security Safeguards Have Specific Operational Content
Rule 6 of the DPDP Rules 2025 sets out the minimum security safeguards every Data Fiduciary must implement. The list is short but specific: encryption, masking, or tokenisation of personal data; implementation of access controls on computer resources holding personal data; maintenance of logs and visibility of access to enable detection, investigation, and remediation of unauthorised access; data backups and continuity measures; contractual requirements that Data Processors implement equivalent safeguards; and appropriate technical and organisational measures to ensure observance of these safeguards.
Each of these has direct application to BGV operations. Candidate documents — Aadhaar cards, PAN cards, education certificates, employment letters, passport copies — must be encrypted in transit and at rest. Access to BGV records must be controlled and logged at the individual user level. Backups must exist and be tested. The vendor’s systems must meet the same standards as the employer’s. And the controls must be auditable — not just policy documents on a shelf, but live infrastructure with evidence of operation.
For most Indian HR teams, this is a meaningful uplift. The historic pattern has been to share candidate documents over email, store them on shared drives, and rely on the vendor to “handle the data securely” without ever asking what that meant operationally. Under DPDP, that pattern needs to change. The remediation work is real — typically several months of system redesign, vendor coordination, and process change — and it cannot be done overnight.
The Breach Notification Clock Has a New Definition of “Without Delay”
Rule 7 of the DPDP Rules 2025 establishes the breach notification framework. On becoming aware of a personal data breach, the Data Fiduciary must inform each affected Data Principal “without delay” via their registered communication channel, providing a description of the breach, its likely consequences, mitigation measures, safety steps the Data Principal can take, and contact details for queries. The Data Protection Board must be notified without delay, and a detailed report must be submitted within 72 hours — covering the nature, extent, timing, location, causes, mitigation, findings on responsibility, remedial measures, and a summary of notifications to affected individuals.
The penalty for failure to notify is up to ₹200 crore per incident.
For BGV operations, this changes the operational requirements in two ways. First, breach detection capability has to exist. Most Indian HR teams have never built a structured detection capability for BGV-related breaches; they have relied on the vendor to tell them if something has gone wrong. Under DPDP, the Data Fiduciary’s obligation to notify the Board starts when the Fiduciary becomes aware — which means the Fiduciary needs the infrastructure and the vendor relationship to ensure awareness happens quickly. Second, the 72-hour response capability has to be built. This is incident response infrastructure: defined roles, escalation paths, communication templates, technical investigation capacity, regulatory engagement protocols. Most organisations do not have this for BGV today.
The Retention Question Has Been Resolved
For fifteen years, the dominant Indian BGV retention practice has been: keep everything, forever, just in case. Candidate documents have accumulated in vendor systems and employer HRIS platforms without any structured deletion regime. Under DPDP, this practice is now a direct violation.
Section 8(7) of the Act and Rule 8 of the Rules require that personal data be erased once the purpose for which it was collected is no longer being served — either because consent has been withdrawn, the purpose has been fulfilled, or the retention period has expired. For BGV records, this means the retention period must be defined, documented, and enforced. Different categories of BGV data may have different retention rationales — onboarding verification may justify a shorter retention than statutory background data required for regulated industries — but the days of indefinite retention are over.
The candidate’s right to request erasure under Section 12 of the Act adds a second layer. When a candidate exits the organisation and is no longer subject to ongoing verification needs, they can request that their BGV records be deleted. The Data Fiduciary must respond within 90 days under Rule 14 and must ensure the deletion happens across the entire chain — including the BGV vendor’s databases. This requires technical infrastructure that most vendor relationships were not built to support.
Cross-Border Transfer: A Different Regime From What Most Expected
One of the most-discussed and most-misunderstood elements of the DPDP framework is its approach to cross-border data transfer. Many commentators expected India to follow the European model — explicit transfer mechanisms, adequacy decisions, standard contractual clauses. The actual framework is different.
Section 16 of the DPDP Act adopts a “negative list” approach: personal data may be transferred outside India to any country except those that the Central Government specifically restricts by notification. As of the Rules’ notification, no countries have been explicitly restricted. The practical effect is that cross-border transfer is permitted by default, with the government retaining the discretion to restrict specific countries in the future based on policy considerations.
For Indian BGV operations, this is significant in two ways. First, it makes cross-border verification operations — verifying candidates’ overseas education, employment, or criminal records — more straightforward than under GDPR-style frameworks. The operational compliance burden is on contractual and security terms with the overseas processor, not on bespoke transfer mechanisms. Second, it creates a watching brief: the government can restrict transfers to specific countries on relatively short notice, and BGV operations relying on overseas data flows need a contingency plan for that eventuality. Vendor contracts should include termination and re-routing clauses that activate if a destination country is added to the negative list.
The Significant Data Fiduciary Question
For larger organisations and BGV vendors operating at scale, an additional layer applies. Section 10 of the Act allows the Central Government to designate certain entities as Significant Data Fiduciaries based on factors such as volume and sensitivity of data processed, risk to Data Principal rights, potential impact on sovereignty and integrity, and security implications.
SDF designation triggers enhanced obligations: appointment of a Data Protection Officer based in India, annual data protection impact assessments, periodic audits by independent auditors, additional algorithmic governance requirements, and potential cross-border transfer restrictions. The criteria are not yet fully crystallised, but the broad expectation is that large BGV vendors, major HRIS providers, and enterprise employers with significant volumes of employee data are likely candidates for designation.
Organisations that may fall into the SDF category should begin scoping the additional compliance work now. The DPO role alone — capable, independent, properly resourced, with reporting lines to senior management — takes time to design and staff. Building the audit and DPIA capabilities behind it takes longer still.
The Eighteen-Month Question
The notification of the DPDP Rules 2025 starts an eighteen-month clock. Full compliance is required by mid-May 2027. Some elements activate earlier — the Consent Manager framework becomes operational in November 2026, certain foundational provisions and Board functions are already live.
Eighteen months sounds like a long time. It is not. The compliance work for hiring and BGV operations typically takes longer than the work for customer-facing data flows, because the data is more sensitive, the vendor relationships are more entrenched, the legacy practice is more deeply ingrained, and the cross-functional coordination required is more complex. HR has to own the workflow redesign. Legal has to own the consent and contract overhaul. IT and security have to own the safeguards. Procurement has to own the vendor rebalancing. Each of these is a multi-month effort and they have to be done in sequence.
The organisations that get to the May 2027 deadline in good shape are the ones that have started this work in 2026, with adequate resourcing and clear cross-functional ownership. The organisations that wait until late 2026 to begin will not complete the work in time. The organisations that wait until 2027 will be operating outside the law from the moment enforcement begins.
The DPDP Rules are the most significant regulatory development for Indian hiring and BGV operations in this generation. The Act has been on the books for two years. The Rules are now live. The compliance work is now real. The next eighteen months are when it has to happen.
AMS Inform provides background verification and workforce screening services across 160+ countries. For Indian enterprises and multinationals operating in India who need to build a DPDP-aligned BGV programme before the May 2027 deadline, visit AMSinform.com to speak with our team.
