Is AI resume screening legal in India? A DPDP Act guide for HR teams

What the DPDP Act actually asks of a hiring team

Under the DPDP Act your organisation is the Data Fiduciary for candidate data, and a screening vendor typically acts as a Data Processor on your instructions. That framing matters: the obligations sit with you, and your vendor's job is to make meeting them straightforward rather than to absorb them on your behalf.

• Notice and lawful basis: candidates should be told, in clear language, what data you collect and why. Applying for a role is a normal, expected use, but it should be stated rather than assumed.
• Purpose limitation: resumes submitted for one role should not quietly become a permanent marketing database.
• Data minimisation and retention: collect what the evaluation needs, keep it for a defined period, and be able to delete it on request.
• Accuracy: if an automated system mis-parsed a candidate's history, a human must be able to see that and correct it.
• Security safeguards: reasonable technical and organisational measures over candidate data, which procurement will test.
• Accountability: you must be able to show how a decision was reached, not merely assert that it was fair.

Being precise about what the law does and does not say

It is worth stating plainly, because vendors overstate it: India's DPDP Act does not contain a GDPR Article 22-style explicit "right to an explanation" for automated decisions. Anyone telling you the DPDP Act legally mandates algorithmic explainability is selling past the facts.

The obligation is better described as transparency and accountability. You must be able to account for how candidate data was used and how a decision was reached. Explainability is how you satisfy that in practice, and it is also what you will need if a candidate escalates to the Data Protection Board, if a client audits your agency, or if a hiring manager simply asks why someone was passed over. MinMaxHR treats explainability as the operational answer to an accountability duty, not as a claimed legal mandate.

If you also hire in the EU or UK, GDPR Article 22 does apply, and it is materially stricter about decisions produced solely by automated processing. A workflow where a named human makes every rejection, which is how CandidRanker is designed, sidesteps that category rather than arguing about its boundaries.

Where screening tools create real exposure

• Silent auto-rejection. If software removes candidates before a human sees them, you cannot explain individual outcomes and you have no accountable decision-maker.
• Black-box match percentages. "The model said 61%" is not an account of a decision. It is the absence of one.
• Scoring on protected or proxy attributes. Screening should evaluate skills, experience, education and semantics, not infer characteristics the law protects.
• Penalising career breaks. Deducting points for employment gaps disproportionately affects carers and people with health histories, and it is difficult to defend.
• No decision record. If the reasoning was never written down, answering a candidate's question six months later becomes reconstruction rather than lookup.
• Uncontrolled data location and retention. Not knowing where candidate data sits, or being unable to delete it, is a straightforward compliance failure.

How MinMaxHR and CandidRanker are built for this

CandidRanker never auto-rejects. Shortlist, select and reject are human actions requiring a written reason, recorded against a named recruiter, and a prior decision is removed with an explicit clear action rather than an ambiguous pending state. Every match score decomposes into eight visible dimensions with the evidence behind each, so the account of a decision exists before anyone asks for it.

Scoring is deterministic, which means the ranking you defend in an audit is the ranking the system actually produced at the time. Employment gaps are surfaced as neutral discussion points and are never deducted from the score. Scoring-relevant configuration changes are logged with the person, the time and the before and after values.

On data handling: candidate data is stored and processed in Mumbai, India (Google Cloud asia-south1), workspaces are tenant-isolated with row-level security as defence in depth, transport is TLS with encryption at rest, uploads are malware scanned by default (a workspace setting can disable scanning, and those files are then marked unscanned) and support access is explicit, read-only unless granted otherwise, time-bounded to a maximum of 24 hours and separately logged. Deletion removes extracted data, rankings and stored files including quarantined copies. MinMaxHR implements SOC 2-aligned controls, with independent certification on the roadmap.

The vendor questionnaire worth sending

• Can you produce the reasoning for twenty specific candidates we deprioritised last quarter?
• Does your system ever reject or filter out a candidate without a human decision?
• Is scoring deterministic, will the same inputs produce the same ranking next month?
• Where is candidate data stored and processed, and can you delete it on request?
• How are employment gaps treated in the score?
• Which attributes does the model score on, and how do you avoid protected-attribute proxies?
• What is recorded when someone changes the scoring configuration?
• Do you hold a completed SOC 2 report, or do you implement SOC 2-aligned controls? Ask for the precise word.

MinMaxHR publishes its answers to all eight: the methodology is public, the free plan lets you test determinism and explainability on your own data before paying anything, and the security posture is stated in specifics rather than adjectives.