The hardest part of DPDP compliance for hiring is not understanding the law. It is operationalising the law inside a hiring workflow that was built around speed, vendor handoffs, and minimal candidate friction. The DPDP Act and Rules describe what compliant data processing looks like. They do not describe how to redesign a fifteen-year-old BGV programme to get there without breaking hiring velocity, blowing up vendor relationships, or losing internal alignment.
That is the work that has to happen between now and 13 May 2027.
This blog is an eight-step playbook for that work, structured the way the actual programme needs to be sequenced rather than the way the Rules happen to be numbered. Each step covers what the obligation is, where the typical Indian HR programme breaks down today, and what compliant operational practice looks like. It is written from the experience of guiding clients through this work since the Rules were notified, with attention to the points where most teams get stuck.
Step One: Map the Data Flow
Almost every DPDP programme that fails does so because the organisation never built a complete map of how candidate and employee data actually moves through its systems. Compliance work that is not anchored in a data flow map is essentially guesswork.
The mapping exercise asks five questions for every category of data the hiring process touches. What data is collected? From whom? For what purpose? Where does it go? Who has access to it at each stage? For BGV specifically, the data categories typically include: identity documents (PAN, Aadhaar, passport), address proofs, photographs, education certificates, employment letters and pay slips, professional references, criminal record certificates, credit reports, social media handles, and in some cases biometric verification data and drug test results. Each of these categories needs to be mapped from the point of collection (candidate portal, vendor system, recruiter inbox) through every system it passes through (ATS, HRIS, vendor database, manager review interface, archive) to the point of deletion or indefinite storage.
The mapping needs to extend to vendors and processors. BGV vendors, payroll providers, identity verification services, drug testing labs, document storage providers — each of these is a Data Processor in the DPDP framework, and the Data Fiduciary’s obligations follow the data into their systems.
Most organisations doing this work for the first time discover, in the mapping, three uncomfortable things. First, that they hold significantly more candidate and employee personal data than they realised — including data they collected years ago and never deleted. Second, that the data is fragmented across many more systems than they expected, with no master inventory. Third, that they cannot answer basic questions about what their BGV vendor does with candidate data after a report is delivered.
The mapping is foundational. Every subsequent step in the programme depends on it. Organisations that try to skip this step typically end up redoing it six months later, having wasted the intervening work.
Step Two: Redesign the Consent Architecture
The consent redesign is the most visible part of the compliance work and the part where the operational impact on hiring is felt first. Done well, it is invisible to candidates and adds minimal time to the process. Done poorly, it becomes a friction point that hurts hiring velocity for months.
The DPDP-compliant consent architecture has several specific elements.
First, the consent is separated from the offer letter. The offer is the employment proposal. The consent is a distinct document, executed by the candidate after they have received and accepted the offer in principle, but before any BGV processing begins. This separation matters because consent bundled with an offer is not legally free. The path most organisations take is to issue a conditional offer followed by a separate BGV consent document, with the formal joining contingent on satisfactory verification.
Second, the consent document is granular. It identifies the specific categories of personal data being collected for each type of check. Education verification has its own consent clause. Employment verification has its own. Criminal record check has its own. Address verification has its own. Each clause names the data being collected, the vendor(s) involved, the purpose, and the retention period.
Third, the consent is in plain language and, where the candidate’s preferred language is not English, in the relevant regional language. For organisations operating across India, this typically means producing the consent in at least Hindi and the principal regional languages of the workforce. The translation work is meaningful but not enormous; the harder operational question is which language to default to for each candidate and how to capture that information.
Fourth, the consent includes the rights inventory. Candidates must be informed of their right to access their data, to request correction, to request erasure, to withdraw consent, and to raise grievances. The mechanism for exercising each right must be clearly identified. A working contact point — typically a Data Protection Officer or designated privacy contact, with a published email address and response timeline — must exist.
Fifth, the consent is captured in a way that produces an evidentiary record. A tick box on a digital portal with timestamp, IP, and document version control is the cleanest. An e-signature on a PDF is acceptable. A wet signature on a paper form is the most cumbersome but legally robust. The key is that the record must be retrievable on demand and must show what specifically was consented to, when, and by whom.
Step Three: Overhaul the Vendor Contracts
Under DPDP, the relationship between Data Fiduciary and Data Processor is governed by contract. The contract has to do specific work that most legacy BGV agreements do not do.
The Data Processing Agreement should cover the categories of personal data being processed, the purposes for which the processor can use the data, the duration of processing, the security safeguards the processor is required to implement (mapped to Rule 6’s minimum standards), the breach notification timelines and processes, the sub-processor restrictions and approval requirements, the candidate rights handling procedures, the data return and deletion obligations on termination, the audit rights of the Data Fiduciary, the cooperation obligations in the event of regulatory inquiry, and the liability allocation.
Three of these areas tend to be where the contract negotiation gets meaningful. The sub-processor question — whether the BGV vendor can use further vendors of its own, and on what terms — needs explicit handling. Most BGV vendors do use further processors for specific check categories, and the chain of accountability needs to be made visible. The breach notification timeline needs to allow the Data Fiduciary to meet its 72-hour obligation to the Data Protection Board; that means the vendor must notify the Fiduciary materially faster than 72 hours, ideally within 24 hours of becoming aware. And the audit rights need to be exercisable; a contract that gives the Fiduciary the right to audit but never gets exercised is not actually compliance, it is paper compliance.
For organisations with multiple BGV vendors, the contract overhaul work is multiplied. The right sequencing is usually to start with the largest vendor relationship, develop a model DPA in negotiation with that vendor, and then use the model as the starting point for renegotiation with smaller vendors.
Step Four: Implement the Rule 6 Security Safeguards
Rule 6 sets out the minimum security safeguards every Data Fiduciary must implement. For BGV operations, this translates into specific technical and organisational requirements.
Encryption, masking, or tokenisation of personal data is the most visible requirement. Candidate documents — at rest in storage, in transit between systems, and in vendor handoffs — must be protected. The historic practice of emailing PAN cards and Aadhaar copies between recruiter and vendor is now non-compliant. The replacement architecture is typically a secure document upload portal at the candidate end, encrypted transmission between systems, and encrypted storage at rest with role-based access controls.
Access controls on computer resources mean that BGV data should only be accessible to individuals with a defined business need. Recruiters typically need read access during the active verification window. Managers may need read access during onboarding. The broader HR team should not have routine access to historical BGV records. The Data Protection Officer needs administrative access for audit and rights-handling purposes. Each role needs to be defined, documented, and technically enforced through the underlying systems.
Logging and access visibility must be sufficient to detect, investigate, and remediate unauthorised access. This is not just a system administrator’s concern; the logs need to be reviewed periodically, and the review needs to produce evidence. In practice, this typically requires a security information and event management capability or equivalent infrastructure.
Continuity measures — backups, recovery procedures, redundancy — are required so that processing can continue in the event of compromise. For BGV, this is mostly an extension of standard HRIS continuity planning, but it needs to be explicitly documented.
Equivalent safeguards must be required of Data Processors via contract — which loops back into Step Three.
Step Five: Build Breach Response Readiness
Rule 7 establishes the dual breach notification regime: affected Data Principals must be informed “without delay” and the Data Protection Board must receive a detailed report within 72 hours. The penalty for failure is up to ₹200 crore.
For most Indian HR teams, building this capability is a genuinely new exercise. The starting point is incident detection — the ability to know when something has gone wrong. For BGV specifically, the detection sources include the vendor’s own monitoring (with mandatory notification to the Fiduciary), the Fiduciary’s internal access logs, candidate complaints, regulatory inquiries, and external sources such as security researchers or law enforcement.
The response playbook needs to cover several scenarios: candidate document leak from vendor system, unauthorised access to internal HRIS records, accidental disclosure during BGV process, mishandling by an internal employee, and physical security incidents. For each scenario, the playbook defines: how detection happens, who is notified internally, what investigation steps are taken, what regulatory and individual notifications are required, who drafts and approves the communications, and what remediation steps follow.
The 72-hour clock is tight. The infrastructure needs to be tested before it is needed. Tabletop exercises with the cross-functional team — HR, legal, security, communications, executive — surface the gaps that real incidents would otherwise reveal at the worst possible moment. Most organisations doing this for the first time identify multiple gaps in the first exercise, refine the playbook, and re-test.
Step Six: Govern Retention and Erasure
The retention question requires defining, for each category of BGV data, how long it will be retained, on what legal or business basis, and how the deletion will happen at end of retention. The defaults that have governed Indian BGV programmes — keep everything, forever — are no longer compliant.
The retention schedule should distinguish between categories. Candidate identity documents collected during BGV may need a shorter retention than employment verification records that may be required for statutory or regulatory purposes. Documents pertaining to rejected candidates may need a different retention than those for hired employees. Documents required by sector-specific regulators (financial services, healthcare, regulated industries) follow those regulators’ retention rules.
Once the schedule is defined, the technical infrastructure to enforce it needs to exist. This typically means automated deletion processes that operate against both the employer’s systems and the vendor’s systems, with evidence trails showing that deletion occurred. For organisations with significant historic BGV data accumulation, there is also a one-time remediation exercise: identifying and dealing with the existing backlog of data that has been retained beyond the retention period that the new policy will establish.
The candidate’s right to request erasure adds a separate workstream. The 90-day response timeline under Rule 14 means the Data Fiduciary must have a mechanism to receive requests, route them, verify the identity of the requester, execute the deletion, and confirm to the requester. The deletion must extend to vendor systems, which again loops back into Step Three.
Step Seven: Plan for Cross-Border Transfer
The cross-border transfer regime under Section 16 of the DPDP Act is permissive by default — transfers are allowed unless the Central Government restricts a specific country. As of mid-2026, no countries are on the restricted list. For BGV operations involving overseas verification of education, employment, or criminal records, this means the cross-border component is operationally straightforward.
The work that still needs to happen has two parts. First, the contractual posture with overseas processors needs to be DPDP-aligned: equivalent security safeguards, breach notification timelines that allow the Indian Data Fiduciary to meet its own obligations, audit rights, deletion obligations. Second, the contracts need to include contingency clauses for the eventuality of a country being added to the restricted list — termination rights, re-routing clauses, transition support obligations.
For organisations whose BGV operations involve significant overseas data flows — typically those hiring globally distributed workforces or running BGV for multinational clients — this work is non-trivial. It is also forward-looking; the country restrictions could be added on relatively short notice, and the contingency planning needs to be in place before the notification, not after.
Step Eight: Prepare for SDF Designation
For larger Indian organisations and major BGV vendors, the Significant Data Fiduciary question is going to become live in the next twelve to eighteen months. The criteria for designation are not yet fully crystallised, but volume of data processed, sensitivity of data, and potential impact on Data Principals are all factors. Organisations with employee headcounts in the tens of thousands, BGV vendors processing millions of candidate records annually, and platforms holding large volumes of sensitive HR data are all candidates.
SDF status triggers additional obligations. A Data Protection Officer based in India, with reporting lines to senior management and operational independence, must be appointed. Annual data protection impact assessments must be conducted. Periodic independent audits must be commissioned. Algorithmic governance requirements apply to systems that make significant decisions using personal data.
Organisations that may be designated should begin scoping the SDF readiness work now. The DPO recruitment alone can take six months. Building the DPIA and audit capabilities behind the role takes longer. Waiting for the designation notice to start the work is not a viable strategy.
Sequencing and Cross-Functional Ownership
The eight steps are written in operational sequence. Data flow mapping has to come first because every subsequent step depends on it. Consent and vendor contracts should run in parallel because they inform each other. Security safeguards and breach response readiness build on the technical foundation. Retention, cross-border, and SDF preparation sit on top.
What no single function can do alone is own the programme. HR has to own the workflow redesign and the candidate experience. Legal has to own the consent architecture and the vendor contracts. IT and security have to own the technical safeguards and the breach detection infrastructure. Procurement has to own the vendor rebalancing and ongoing oversight. Finance has to own the budgeting and resource allocation. The DPO — or the equivalent privacy contact for organisations not yet designated as SDFs — has to own the coordination and the regulatory engagement.
The organisations that complete this work in good time are the ones that have constituted a cross-functional DPDP programme office with explicit executive sponsorship, dedicated resourcing, and a clear timeline mapped to the May 2027 compliance deadline. The organisations that try to do it through ad hoc working groups, with no senior ownership and no dedicated budget, tend to make slow progress and discover late in the cycle that they will not make the deadline.
The clock has started. Eighteen months is the runway. The work that fits comfortably in eighteen months does not fit at all in twelve. The right time to start is now.
AMS Inform provides background verification and workforce screening services across 160+ countries, including dedicated DPDP-aligned BGV programme design for Indian enterprises and multinationals operating in India. To assess your current state and build a structured plan to the May 2027 deadline, visit AMSinform.com.
