At a glance
| Document type | HR policy template |
|---|---|
| Issued by | Employer |
| Templates included | 3 ready to use versions |
| Download format | Word (.docx) |
| Statutory reference | Digital Personal Data Protection Act, 2023 |
| Last reviewed | 27 August 2026 |
| Maintained by | Engage HR editorial team |
Verification, reference check and screening
Three activities routinely bundled into one process. They differ in what is being established, who provides it and how reliable the result is.
| Verification | Reference check | Screening | |
|---|---|---|---|
| What it establishes | That a stated fact is true: the employment, the dates, the qualification, the address. | An opinion about how the person worked, from someone who worked with them. | Whether a record exists in a named database or register. |
| Source | The issuing institution or the former employer's records. | A named individual, usually a former manager. | A register, a court record or a commercial database. |
| Reliability | High where the source responds, and the failure mode is silence rather than error. | Variable. Reflects one relationship and the referee's willingness to be candid. | Depends entirely on the coverage and currency of the underlying source. |
| Consent needed | Yes. It involves approaching third parties about an identified person. | Yes, and the candidate should know who is being approached. | Yes, and the specific databases should be named. |
| Common error | Treating an unresponsive former employer as a discrepancy. | Accepting a referee the candidate has coached, or approaching a current employer without permission. | Treating a name match as an identity match. |
What the verification pack contains
Three documents rather than one, because they do different jobs and are read by different people.
- The consent and authorisation form. Signed by the candidate. Names each check, each category of source, the vendor if one is used, how long the results are kept, and how to raise a question about them. This is the document that has to stand up if the process is ever examined.
- The verification policy. Internal. Sets out which checks apply at which level, who initiates them, the stage in the process at which they run, the turnaround expected, and the adverse findings procedure.
- The verification record. The result of each check, the source, the date, who conducted it, and the status. This is what the hiring decision is documented against.
The consent form should be given with the offer rather than earlier in the process, unless there is a reason to run a check before that point. Collecting authorisation from every applicant at application stage means holding the personal data of people who were never going to be verified.
Two things do not belong in the pack. A blanket authorisation to conduct any check the employer considers appropriate, which is not informed consent by any reading. And a clause purporting to release the employer from liability for the accuracy of what it finds, which does not survive contact with the consequence of acting on a wrong result.
3 policy templates
Background Verification Form for candidate consent and authorisation form
The document the whole process rests on. Note that each check is listed separately with its source and that the candidate can decline an individual check rather than only the whole.
[Company Name] BACKGROUND VERIFICATION CONSENT AND AUTHORISATION PART A: ABOUT THIS FORM [Company Name] verifies the information provided by candidates before an appointment is confirmed. This form tells you what will be checked, who will carry out the checks, how long the results are kept, and how to raise a question about anything found. Any offer made to you is conditional on the completion of these checks to [Company Name]'s reasonable satisfaction, as stated in your offer letter dated [Offer Letter Date]. PART B: YOUR DETAILS Full name: [Candidate Name] Any other name previously used: [Former Name, or "none"] Date of birth: [Date of Birth] Contact number: [Contact Number] | Email: [Email Address] Current address: [Current Address] Role offered: [Job Title] | Requisition: [Requisition Reference] PART C: WHAT WILL BE CHECKED Mark your consent for each check. You may decline any individual check. Where you decline, [Company Name] will tell you what effect that has on the offer before taking any decision. 1. Identity What is checked: that the identity document you provide matches the details above. Source: the document you provide, and the issuing authority's verification facility where one exists. Consent: [Yes / No] 2. Employment history What is checked: employer name, designation, dates of employment and reason for leaving, for the employments you have listed at Part D. Source: the HR or verification contact of each former employer. Consent: [Yes / No] 3. Current employment What is checked: as above, for your current employer. Source: your current employer. Note: this check will not be initiated before the date you specify at Part E. Consent: [Yes / No] 4. Education What is checked: the qualification, the institution and the year of award, for the qualifications you have listed at Part D. Source: the awarding institution or its verification facility. Consent: [Yes / No] 5. Professional registration or licence, where the role requires one What is checked: that the registration exists, is current, and is held in your name. Source: the registering body. Consent: [Yes / No / Not applicable] 6. Address What is checked: that you reside at the address given above. Source: a document you provide, or a visit by [Vendor Name] where you agree to one. Consent: [Yes / No] 7. References What is checked: the referee's account of your work, in relation to the role offered. Source: the referees you name at Part D. Consent: [Yes / No] 8. [Any further check the role requires] What is checked: [Description] Source: [Source Description] Why this role requires it: [Reason] Consent: [Yes / No] PART D: INFORMATION YOU PROVIDE Employment: [Employer Name] | Designation: [Designation] | From: [Start Date] | To: [End Date] | Verification contact: [Contact Details] [Repeat for each employment to be verified.] Education: [Qualification] | Institution: [Institution Name] | Year: [Year] | Enrolment or roll number: [Reference] [Repeat for each qualification to be verified.] Referee: [Referee Name] | Relationship: [Relationship] | Organisation: [Organisation] | Contact: [Contact Details] [Repeat for each referee.] PART E: CURRENT EMPLOYER [Company Name] will not contact your current employer before: [Date or Trigger, for example the date you confirm you have resigned]. PART F: WHO CARRIES OUT THE CHECKS Checks are carried out by [Company Name] and by [Vendor Name], engaged by [Company Name] for this purpose. [Where applicable: [Vendor Name] processes this information at [Processing Location].] PART G: HOW LONG THE RESULTS ARE KEPT If you are appointed: for the duration of your employment and for [Retention Period] afterwards. If you are not appointed: for [Retention Period] from the date of the decision, after which the verification record is deleted. PART H: IF SOMETHING IS FOUND If a check produces a result that does not match what you have told us, we will tell you what was found and which source it came from, and give you [Response Window] to respond, before any decision is taken on the offer. You may ask us to correct information we hold about you that is inaccurate. Questions about this process, or about the information we hold, may be raised with [Contact Name], [Designation], at [Contact Details]. PART I: DECLARATION AND AUTHORISATION I confirm that the information I have provided at Part D is true and complete. I authorise [Company Name] and [Vendor Name] to carry out the checks I have consented to at Part C, and I authorise the sources named to release the information sought for that purpose. I understand that this authorisation covers only the checks I have marked Yes, and that I may withdraw it by writing to [Contact Name], in which case [Company Name] will tell me what effect that has on the offer. Signature: ____________________ | Date: [Date] Name: [Candidate Name]
Background Verification Form for background verification policy
The internal document. The section that earns its place is the adverse findings procedure, because verification results are wrong often enough that a process without one will eventually withdraw an offer it should not have.
[Company Name] BACKGROUND VERIFICATION POLICY Policy owner: [Owner Designation] Approved by: [Approving Authority] Version: [Version Number] Effective from: [Effective Date] Next review: [Review Date] 1. PURPOSE This policy sets out which checks [Company Name] carries out before an appointment is confirmed, on what authority, and what happens when a check produces a result that does not match what the candidate has told us. 2. PRINCIPLES 2.1 We verify what the hiring decision relied on. A check that goes beyond the claims the candidate made, or beyond what the role requires, is not carried out. 2.2 We obtain consent for each check, and the candidate may decline any of them. 2.3 A discrepancy is a question, not a finding. Nothing is decided on a check result until the candidate has been shown it and given an opportunity to respond. 2.4 We keep verification records for a stated period and delete them at the end of it. 3. SCOPE OF CHECKS BY LEVEL [Band or Level]: identity, employment history for the last [Number] years, education for the highest qualification claimed, references [Number]. [Band or Level]: as above, plus [Additional Check]. [Band or Level]: as above, plus [Additional Check], plus [Additional Check]. Roles requiring a professional registration: registration status in all cases. Roles with [Named Exposure, for example custody of funds or access to customer data at scale]: [Additional Check], with the reason recorded on the requisition. A check outside the set for the level requires the written approval of [Approving Role], with the reason recorded. 4. WHEN CHECKS RUN 4.1 Checks are initiated after an offer is made and accepted, and the offer states that it is conditional on their completion. 4.2 The current employer is not contacted before the date or trigger the candidate specifies on the consent form. 4.3 Expected turnaround is [Turnaround Period]. Where a check is outstanding on the joining date, [Approving Role] decides whether the candidate joins with the check pending, and the decision is recorded. 5. WHO CARRIES OUT CHECKS 5.1 [Company Name] engages [Vendor Name] under a written contract covering the purpose, the checks permitted, security requirements, sub-processing, the location of processing and deletion at the end of the retention period. 5.2 [Owner Designation] reviews the vendor's process [Frequency], including a sample of completed cases against their source evidence. 5.3 [Company Name] remains answerable for the process regardless of what the vendor's contract says. 6. ADVERSE FINDINGS PROCEDURE 6.1 Where a check produces a result inconsistent with what the candidate provided, the case is referred to [Owner Designation] before anything is communicated. 6.2 [Owner Designation] first establishes whether the result is reliable. A former employer that does not respond, a record that matches on name but not on other identifiers, and an institution whose verification facility is unavailable are not discrepancies. 6.3 Where the result appears reliable, the candidate is told in writing what was found and which source it came from, and is given [Response Window] to respond. 6.4 The candidate's response is considered by [Owner Designation] with the hiring manager. Where the response resolves the matter, the check is recorded as cleared with a note. 6.5 Where it does not, the decision on the offer is taken by [Approving Role], and is recorded with the reason and the evidence relied on. 6.6 A withdrawal of an offer on verification grounds requires [Approving Role]'s written approval in every case. 7. RECORDS AND RETENTION 7.1 The verification record holds, for each check: what was checked, the source, the date, who conducted it, the result and the status. 7.2 Where the candidate is appointed, records are retained for the duration of employment and [Retention Period] afterwards. 7.3 Where the candidate is not appointed, records are deleted [Retention Period] after the decision. 7.4 [Owner Designation] runs the deletion cycle [Frequency] and records that it has been run. 8. ACCESS 8.1 Verification records are accessible to [Named Roles] only. Hiring managers see the status of each check and, where there is an adverse finding, what is necessary to take the decision. 8.2 A candidate may ask what information [Company Name] holds about them from this process, and may ask for inaccurate information to be corrected. Requests go to [Contact Name]. 9. DATA PROTECTION 9.1 This process handles personal data about people who are not employees of [Company Name]. It is operated on the basis of the consent recorded on the authorisation form. 9.2 [Owner Designation] will review this policy against the Digital Personal Data Protection Act, 2023, and against the rules made under it, by [Review Deadline], which is ahead of the date on which sections 3 to 17 of that Act come into force. 10. REVIEW Reviewed by [Owner Designation] on or before [Review Date], and earlier if the checks, the vendor or the legal position change.
Background Verification Form for verification record and adverse finding note
The operational record. The status field matters more than it looks: unresponsive and discrepant are different outcomes and treating them the same is the most common way a good candidate is lost.
[Company Name] BACKGROUND VERIFICATION RECORD PART A: CASE Candidate: [Candidate Name] Requisition: [Requisition Reference] | Role: [Job Title] | Band: [Band or Level] Offer date: [Offer Date] | Proposed joining date: [Joining Date] Consent form signed on: [Consent Date] | Checks consented to: [List] Checks declined by candidate: [List, or "none"] Verification initiated on: [Initiation Date] | Vendor: [Vendor Name] Case owner: [Owner Name], [Designation] PART B: CHECK RESULTS Check: [Check Name] What was verified: [Specific claim being tested] Source approached: [Source Name and Type] Date approached: [Date] | Date responded: [Date, or "no response"] Result: [Matches / Partial match / Does not match / Source unresponsive / Source unable to verify] Detail: [What the source said, in the source's terms] Evidence held: [Document or reference] Status: [Cleared / Query raised with candidate / Outstanding / Closed unverifiable] [Repeat the block for each check.] PART C: SUMMARY Checks cleared: [Number] of [Number] Checks unverifiable through no fault of the candidate: [List] Checks with a discrepancy: [List, or "none"] Overall status: [Complete and clear / Complete with a discrepancy / Incomplete] PART D: ADVERSE FINDING NOTE Complete this part only where a discrepancy has been identified. Do not communicate anything to the candidate before Part D1 is complete. D1. Reliability assessment (by [Owner Designation], before contacting the candidate) What the discrepancy is: [Description] Could this be an identity mismatch: [Assessment] Could this be a records or process failure at the source: [Assessment] Has the source been asked to confirm: [Yes / No] | Outcome: [Outcome] Assessed as reliable enough to put to the candidate: [Yes / No] Assessed by: [Name] | Date: [Date] D2. Put to the candidate What the candidate was told, and how: [Description] Source identified to the candidate: [Yes / No] Date sent: [Date] | Response due by: [Response Deadline] D3. Candidate response Date received: [Date, or "no response"] Summary of the response: [Description] Documents provided: [List, or "none"] Further enquiry made as a result: [Description, or "none"] D4. Assessment of the response Does the response resolve the discrepancy: [Yes / No / Partly] Reasoning: [Description] Materiality to the role offered: [Description] Assessed by: [Name and Designation] | Date: [Date] PART E: DECISION Decision: [Proceed / Proceed with a condition / Withdraw the offer] Condition, where applicable: [Description] Reason for the decision: [Reason, referring to Part D] Approved by: [Approving Role Name and Designation] | Date: [Date] Communicated to the candidate by: [Name] on [Date] PART F: RETENTION Retention category: [Appointed / Not appointed] Delete on or after: [Deletion Date] Deletion confirmed by: [Name] | Date: [Date]
What it has to contain
| Element | Why it matters |
|---|---|
| A per-check consent, not a blanket authorisation | A form authorising the employer to conduct any check it considers appropriate does not tell the candidate what will happen to them, which is the whole function of consent. Listing each check with its source and allowing individual refusal is what makes the authorisation informed. |
| The named vendor and where it processes | Most verification is carried out by a third party, and the candidate is entitled to know who will hold their information. Where the vendor processes outside the country, that raises a question the organisation should have answered before the form is issued rather than after. |
| A stated retention period, different for appointed and unsuccessful candidates | Verification records about people who were never hired are the most commonly forgotten personal data an employer holds. Stating the period on the form commits the organisation to a deletion cycle, and gives the candidate something concrete rather than an assurance. |
| A trigger controlling contact with the current employer | Approaching a current employer before the candidate has resigned can cost them the job they still have. The form should let the candidate name the date or event after which that check may run, and the process must honour it. |
| An adverse findings procedure with a right to respond | Verification data is wrong often enough to matter: name matches that are not identity matches, employers whose records were lost in a merger, institutions whose verification facility fails. A process that acts on a first result without putting it to the candidate will eventually withdraw an offer it should not have. |
| A distinction between unresponsive and discrepant | A former employer that never replies has not contradicted anything. Recording that as a failed check, and treating it as the candidate's problem, penalises people for the record keeping of organisations they left years ago and is the most common unfairness in these processes. |
| A named contact for questions and corrections | The candidate needs somewhere to go, both while the process is running and afterwards. A named person with contact details is also what the organisation will need in place when the data protection duties commence. |
How to write one
- Decide what each level of role actually needs. Set the check set by band and by exposure, and write it down. Running the same checks on everyone means either over-collecting for junior roles or under-checking for sensitive ones, and the first is a data protection problem while the second is the risk the process existed to address.
- Verify claims rather than investigating people. The scope should be what the hiring decision relied on: the employments, the qualification, the registration. A check that goes wider is collecting personal data the role does not need, which is difficult to justify and expensive to hold.
- Issue the consent form with the offer. Collecting authorisation from every applicant means holding verification data about people who were never going to be checked. Making the offer conditional and taking consent at that point keeps the collection proportionate to what is actually happening.
- Contract the vendor properly. The contract should cover the purpose, the permitted checks, security requirements, sub-processing, the location of processing and deletion at the end of the retention period. The employer remains answerable for the process whatever the contract says, so the contract is a control rather than a transfer of responsibility.
- Write the adverse findings procedure before the first case. Decide who assesses reliability, who contacts the candidate, how long they get to respond and who takes the final decision. A process invented under time pressure on a Friday, with a joining date on Monday, produces the decisions organisations later regret.
- Test reliability before putting anything to the candidate. Check whether the result is an identity mismatch, whether the source was asked to confirm, and whether the source has a known records problem. Putting an unreliable result to a candidate damages the relationship even when it is subsequently resolved.
- Run the deletion cycle and record that you ran it. Set a recurring task to delete the records that have reached the end of their retention period, especially for candidates who were not appointed. A retention period nobody enforces is worse than none, because the form told the candidate something untrue.
- Review the process against the data protection timetable. Sections 3 to 17 of the Digital Personal Data Protection Act, 2023 come into force on 13 May 2027, and the rules made under it carry the operational detail. Diarise a review well before that date rather than treating it as a problem for the year it arrives.
What background verification is for
The purpose is narrow and worth stating, because processes that lose sight of it grow in ways that are difficult to defend.
Verification tests the claims the hiring decision was based on. The candidate said they worked at a particular organisation between particular dates in a particular role, that they hold a particular qualification, that they hold a current registration. Verification establishes whether those things are true. It is not an investigation into a person, and it is not an opportunity to gather information the employer might find useful later.
That distinction has practical consequences. It sets the scope of the check set: what was claimed, and what the role requires. It sets the standard for adding a check, which is that the role needs it and the reason is recorded. And it settles what happens when a check comes back empty, since a source that does not respond has not contradicted a claim.
It also frames the failure the process is really guarding against. That is a small number of candidates who materially misrepresent something significant: an employment that did not happen, a qualification not held, a registration that lapsed or was withdrawn. That is a real risk and worth checking for. It is a much narrower risk than the one many verification processes are designed around, and designing for the narrow version produces a faster process, less data held, and fewer good candidates lost to noise.
The adverse findings procedure is the part that matters
Verification data is wrong often enough that an adverse result needs a reliability check before it reaches the candidate. Check three things: whether it is an identity or only a name match, whether the source was asked to confirm or queried once, and whether it has known problems. Where the result survives, tell the candidate what was found and give them time to respond.
Most verification cases clear without incident. The value of the process is entirely in how it handles the ones that do not, and this is the part organisations most often have not designed.
The first thing to understand is that verification data is wrong reasonably often, and in identifiable ways. Database searches return matches on name where the identifiers do not correspond, which is a substantial issue in a country with many common names. Employers merge, are acquired or close, and their records go with them. Verification desks at large organisations give templated non-answers that a vendor may score as unverified. Institutions have verification facilities that are unavailable for weeks. None of these is evidence that a candidate misrepresented anything.
So the procedure needs a reliability step before anything reaches the candidate. Is this an identity match or a name match. Has the source actually been asked to confirm rather than queried once through a portal. Is there a known problem with this source. Putting an unreliable result to a candidate damages the relationship badly, even where it is resolved a day later, and it is entirely avoidable.
Where the result survives that step, the candidate should be told what was found, told which source it came from, and given a stated period to respond. The reason is partly fairness and partly accuracy. The candidate is usually the only person who can explain that the organisation changed its name, that they were on a third party payroll, or that the qualification is recorded under a former name.
Finally, the decision to withdraw an offer on verification grounds should require approval above the hiring manager in every case. It is a decision with serious consequences for someone who may have already resigned elsewhere, and it should not be taken by the person under the most pressure to fill the position.
When the data protection position changes
The Digital Personal Data Protection Act, 2023 is being commenced in stages. Sections 3 to 17, which carry the grounds for processing, the notice requirement, the legitimate uses, the obligations of a data fiduciary and the data principal rights, come into force on 13 May 2027. None of them is a present obligation.
Background verification is one of the most data-intensive things an employer does, and it is done to people who are not employees and who may never become employees. It is therefore worth being precise about the legal position, including the fact that most of it has not started yet.
The Digital Personal Data Protection Act, 2023 is being commenced in stages. Under notification G.S.R. 843(E) dated 13 November 2025, the definitions and the Data Protection Board, penalty and machinery provisions came into force on 13 November 2025. Section 6(9) and section 27(1)(d) come into force on 13 November 2026. Sections 3 to 17, along with several later provisions, come into force on 13 May 2027.
Sections 3 to 17 are where the substance sits. That range covers the grounds for processing in section 4, the notice requirement in section 5, the legitimate uses in section 7, the general obligations of a data fiduciary in section 8, and the data principal rights in sections 11 and 12. None of them is a present obligation. Anyone describing them as current requirements is wrong about timing, whatever they get right about the content.
What that means practically is that there is a run-up, and it is a good one to use. When the duties do commence, an employer running verification will have to meet seven of them. It must show a lawful basis for the processing. Where consent is the basis, it must have given notice of the personal data and the purpose. It must keep the data accurate where the data is used to make a decision affecting the person, and apply reasonable security safeguards. It must erase the data once the purpose is served or consent is withdrawn, unless a law requires it to be retained. And it must publish a contact who can answer questions about processing, and run a grievance mechanism. A process built to that shape now will not need rebuilding later, and each of those things is defensible practice independently of any statute.
The candidate question, and the vendor question
Two questions are unresolved. Whether the section 7(i) legitimate use for employment reaches a candidate rather than an employee is open, so a process should run on consent, which is defensible on either reading. And under section 8 the employer remains responsible for what a verification vendor does with candidate data, whatever the contract says.
Two questions about the coming framework are worth raising specifically, because they bear directly on how a verification process should be designed and neither has an obvious answer.
The first is whether the employment legitimate use reaches candidates. Section 7(i) provides a legitimate use for the purposes of employment, or for purposes related to safeguarding the employer from loss or liability. It then gives examples, ending with the provision of any service or benefit sought by a Data Principal who is an employee. Read one way, employment purposes include hiring. Read another, the provision is oriented towards people who are already employees, and a candidate who has not been engaged is not one. This page does not resolve that, and an employer should not build a process that depends on the wider reading. Operating on consent is defensible under either, and the consent route also produces the artefact the organisation will want anyway: a document showing the candidate was told what would happen.
The second is the vendor. Section 8(1) and (2) make the data fiduciary responsible for compliance in respect of processing undertaken on its behalf by a processor, irrespective of any agreement to the contrary. An employer cannot contract out of the consequences of what a verification vendor does with candidate data. Where that vendor processes outside India, section 16 deals with processing outside India and was not examined for this page, so it is a question to put to advisers rather than one to assume the answer to.
What follows from both is unglamorous and useful. Know which vendor holds what, on what contract, in which country. Sample their completed cases against source evidence rather than accepting their status codes. And hold the deletion obligation as your own rather than the vendor's, because when a candidate asks what became of their information, the answer that the vendor handles that is not an answer.
Common mistakes
| Mistake | Why it causes trouble | What to do instead |
|---|---|---|
| Blanket authorisation wording | The form asks the candidate to authorise any checks the company deems necessary. The candidate has no idea what they agreed to, the employer cannot show they were told, and the authorisation gives far less protection than it appears to. | List each check with its source, allow the candidate to decline individually, and say what declining means for the offer before any decision is taken. |
| Treating an unresponsive source as a failed check | A former employer no longer exists, or has a verification desk that does not answer. The check is recorded as unverified, the candidate is treated as though something was found, and an offer is withdrawn over a record keeping failure the candidate had no part in. | Separate the statuses. Source unresponsive and does not match are different outcomes with different consequences, and only the second is a discrepancy. |
| Contacting the current employer without a trigger | The vendor works through the list and calls the current employer, who did not know the person was looking. The candidate can lose the job they have, over a process that had not yet decided anything. | Put the trigger on the consent form, brief the vendor on it explicitly, and check that their workflow can hold a single check back rather than running the set together. |
| Acting on a first result | A database returns a record matching the candidate's name. The offer is withdrawn the same day. It later turns out the match was on name alone and the record belongs to someone else, and by then the candidate has told their employer they are leaving. | Assess reliability before contacting the candidate, then put the finding to them with the source named and a stated period to respond, and require senior approval for any withdrawal. |
| Keeping unsuccessful candidates' records indefinitely | Verification files for people who were never hired accumulate in a vendor portal and a shared drive, past any purpose, with unreviewed access. It is the largest and least examined store of personal data most HR functions hold. | State a retention period on the consent form, run the deletion cycle on a schedule, and record each run so the commitment made to the candidate is one the organisation actually keeps. |
| Assuming the employment provision covers candidates | A process is designed on the basis that background checks fall within the employment legitimate use, so consent is treated as a formality. The provision refers to the purposes of employment and to a Data Principal who is an employee, and a candidate is not one yet. | Operate the process on consent, which is defensible on any reading, and resolve the question properly before the duties commence rather than after. |
Statutory reference
- Act
- Digital Personal Data Protection Act, 2023
- Key limits
- The timing is the most important limit on this page. As at the date of last verification none of sections 3 to 17 is in force, and nothing described above is a present obligation. Section 7(i) is framed around the purposes of employment and refers to a Data Principal who is an employee; whether it extends to a candidate who has not been engaged is not resolved here and the text is set out as it reads rather than applied to that question. The Digital Personal Data Protection Rules, 2025 were not read, and they carry the manner of notice, the manner of breach intimation, retention periods and the manner of making rights requests, so no procedural detail or period from the Rules appears on this page. Section 9 on children's personal data, section 10 on the additional obligations of a Significant Data Fiduciary and the thresholds for that designation, section 16 on processing outside India, which bears directly on offshore verification vendors, section 17 exemptions, which may narrow several of the statements above, and the penalty schedule were all not read and are not stated here. This page states nothing about any other law bearing on background checks, including the position on obtaining or verifying criminal records, credit information or educational records, each of which is governed by its own framework that has not been examined.
| Provision | What it says |
|---|---|
| Commencement | The Act is brought into force by notification under section 1(2), which permits different dates for different provisions. |
| Commencement | The commencement footnote records notification G.S.R. 843(E) dated 13 November 2025, under which section 2 and sections 18 to 26, 35 to 43 and 44(1) and (3), being the definitions and the Data Protection Board, penalty and machinery provisions, came into force on 13 November 2025; section 6(9) and section 27(1)(d) come into force on 13 November 2026; and sections 3 to 5, section 6(1) to (8) and (10), sections 7 to 17, section 27 except clause (1)(d), sections 28 to 34, sections 36 and 37 and section 44(2) come into force on 13 May 2027. |
| Commencement | Of the provisions described below, all sit in sections 3 to 17 and therefore take effect on 13 May 2027. |
| Section 4 | Provides that personal data may be processed only for a lawful purpose, being one for which the Data Principal has given consent or one of certain legitimate uses, and that lawful purpose means any purpose not expressly forbidden by law. |
| Section 5 | Provides that every request made for consent under section 6 shall be accompanied or preceded by a notice informing the Data Principal of the personal data and the purpose of processing, the manner of exercising rights under section 6(4) and section 13, and the manner of complaining to the Board. |
| Section 7(a) | Provides a legitimate use where the Data Principal has voluntarily provided her personal data for a specified purpose and has not indicated that she does not consent to its use. |
| Section 7(i) | Provides a legitimate use for the purposes of employment or those related to safeguarding the employer from loss or liability, such as prevention of corporate espionage, maintenance of confidentiality of trade secrets, intellectual property, classified information or provision of any service or benefit sought by a Data Principal who is an employee. |
| Section 8(1) and (2) | Make the Data Fiduciary responsible for compliance in respect of any processing undertaken by it or on its behalf by a Data Processor, irrespective of any agreement to the contrary, and provide that a Data Processor may be engaged only under a valid contract, that requirement being expressed as applying to processing for any activity related to offering of goods or services to Data Principals. |
| Section 8(3) | Requires completeness, accuracy and consistency where the personal data is likely to be used to make a decision affecting the Data Principal or to be disclosed to another Data Fiduciary. |
| Section 8(5) and (6) | Require the Data Fiduciary to protect personal data in its possession or control, including where processed on its behalf by a Data Processor, by taking reasonable security safeguards to prevent a breach, and on a personal data breach to intimate both the Board and each affected Data Principal in the prescribed form and manner. |
| Section 8(7) and (8) | Require, unless retention is necessary for compliance with any law, that the Data Fiduciary erase personal data on withdrawal of consent or as soon as it is reasonable to assume the specified purpose is no longer served, whichever is earlier, and cause its Data Processor to erase it, the purpose being deemed no longer served where the Data Principal neither approaches the fiduciary for the specified purpose nor exercises any right for a period to be prescribed. |
| Section 8(9) and (10) | Require the Data Fiduciary to publish the business contact information of a Data Protection Officer, if applicable, or of a person able to answer questions about processing, and to establish an effective grievance redressal mechanism. |
| Sections 11 and 12 | Give a Data Principal the right to access information and the right to correction, completion, updating and erasure, in respect of processing to which she has previously given consent, including consent as referred to in clause (a) of section 7, and section 12(3) requires erasure on request unless retention is necessary for the specified purpose or for compliance with any law. |
Frequently asked questions
What should a background verification form include?
The candidate's details, and each check listed separately with what it establishes and which source will be approached. A consent marker against each check, the information the candidate is providing for verification, and a trigger controlling contact with their current employer. Then the vendor's name and where it processes, the retention period, what happens if something is found, a named contact, and the candidate's signature.
Is candidate consent required for background verification in India?
Consent is the sound basis to operate on, and it is what a well-run process uses. Under the Digital Personal Data Protection Act, 2023 the grounds for processing, the notice requirement and the legitimate uses sit in sections 3 to 17, which come into force on 13 May 2027 rather than now. Building the process on consent works under any reading of what follows.
Does the Digital Personal Data Protection Act apply to background checks today?
Not yet in its substantive parts. Notification G.S.R. 843(E) of 13 November 2025 brought the definitions and the Data Protection Board and penalty machinery into force on the same date. It brings section 6(9) and section 27(1)(d) into force on 13 November 2026, and sections 3 to 17 into force on 13 May 2027. Every duty relevant to a verification process sits in that last group.
Can an employer verify a candidate's current employment without telling them?
It should not. Contacting a current employer can cost the candidate the job they still hold, over a process that has not yet decided anything. Put a trigger on the consent form letting the candidate name the date or event after which that check may run, and confirm the vendor's workflow can hold that check back from the rest.
What should happen when a background check comes back with a discrepancy?
Assess whether the result is reliable first, since name matches, closed employers and unavailable verification facilities are common. Where it survives that, tell the candidate what was found and which source it came from, give them a stated period to respond, consider the response, and require approval above the hiring manager before any offer is withdrawn.
How long should background verification records be kept?
For a stated period the organisation has decided on and will enforce, with a shorter period for candidates who were not appointed. Records about people who were never hired are the most commonly forgotten personal data an HR function holds, and a retention period nobody runs makes the consent form say something untrue.
Is the employer responsible for what a verification vendor does?
Section 8(1) and (2) of the Digital Personal Data Protection Act, 2023 comes into force on 13 May 2027. Under it, the data fiduciary is responsible for compliance in respect of processing undertaken on its behalf by a processor, whatever any agreement to the contrary says. As a matter of practice the employer should already be treating the vendor as a control to be managed rather than a responsibility to be transferred.
Can an offer be withdrawn because of a background check?
Where the offer was expressly made conditional on verification and a material discrepancy survives the adverse findings procedure, yes. Four conditions apply. The offer letter said so. The candidate was shown what was found and given a real opportunity to respond. The discrepancy is material to the role. And the decision was approved above the hiring manager and recorded with its reasons.
Verification records in Engage
Engage holds each check as its own line with its own status, so an unresponsive source does not quietly become a failed check. The adverse findings trail stays attached to the case instead of living in an email thread. Retention runs off the outcome, which means the records of candidates who were not appointed are deleted on the date the consent form promised instead of accumulating unaudited in a vendor portal.
Book a demo