Candidate Database Compliance: GDPR and DPDP Act Checklist

Most recruitment teams are sitting on a legal liability they haven’t priced in. European regulators processed an average of 443 personal data breach notifications every single day in the twelve months to January 2026, a 22% jump from the year before, and fines issued under GDPR since 2018 have now crossed €7.1 billion. 

Recruitment databases, full of resumes, phone numbers, salary history, and interview notes, sit squarely inside the scope of that enforcement wave.

Candidate database compliance isn’t a legal footnote anymore. It’s an operational requirement that touches every stage of hiring from the moment a resume lands in your inbox to the day (which should be defined, not indefinite) that data gets deleted. 

Two frameworks now govern this for most global and India-facing companies: the EU’s General Data Protection Regulation (GDPR) and India’s Digital Personal Data Protection (DPDP) Act, 2023, now backed by the DPDP Rules, 2025.

The two regimes overlap in spirit; both are consent-driven, both grant individuals rights over their own data, but they diverge in specifics: retention expectations, breach notification timing, and penalty structure are not identical. A hiring team that assumes “GDPR-compliant” automatically means “DPDP-compliant” is making an expensive assumption.

This piece breaks down what both laws actually require for candidate data, how long you can legally hold on to a resume, what a working consent process looks like, and a checklist you can run against your own candidate database management setup today.

What Is Candidate Database Compliance?

Candidate database compliance is the practice of collecting, storing, processing, and deleting job applicant data in line with applicable data protection law, primarily GDPR for EU-connected data and the DPDP Act for India-connected data. 

It covers lawful basis for collection, defined retention periods, candidate rights (access, correction, deletion), and breach reporting obligations for any system that stores resumes, contact details, or interview records.

The Core Problem: Recruitment Databases Are Compliance Blind Spots

Recruitment data has a specific problem that most other business data doesn’t: it keeps arriving on autopilot and rarely gets cleaned up. A mid-sized company running 40 open roles a year through job posting software can accumulate 8,000–12,000 candidate records in 24 months, most of which are unsuccessful applicants whose data has no defined expiry date.

Industry audits of European recruitment databases have repeatedly found that somewhere between 40% and 70% of stored candidate profiles are past any reasonable retention window, not because anyone decided to keep them, but because no one set a deletion clock in the first place. 

That’s not a minor housekeeping issue. Under GDPR, indefinite retention without a stated purpose is treated as a violation on its own, independent of whether a breach ever occurs.

The DPDP Act compounds this for India-facing hiring teams. Since the DPDP Rules, 2025 were notified on November 13, 2025, and began phased enforcement with further phases scheduled through November 2026 and full penalty enforcement by May 2027, companies hiring in India can no longer treat data protection as a “we’ll deal with it later” item. 

Penalties under the Act can reach ₹250 crore (roughly $30 million) for serious violations, and unlike GDPR’s percentage-of-turnover model, DPDP penalties are set in absolute rupee terms per violation category, which can hit smaller companies disproportionately hard.

Most teams underestimate the size of this exposure by 3–4x, because they’re counting active job openings, not the accumulated backlog sitting in old spreadsheets, email threads, and abandoned candidate database management tools from a previous ATS.

Where Compliance Risk Actually Hides in the Hiring Stack

Candidate database compliance doesn’t live in one tool; it’s spread across every point where a candidate’s data gets touched, copied, or forwarded. Mapping those points is usually more revealing than reading the regulation itself.

Job Posting Software and the Data Collection Moment

Compliance starts before a candidate ever reaches your database at the job posting stage. Job posting software that pushes listings to multiple boards often pulls applicant responses back through different integrations, each with its own data handling terms. 

If your careers page, LinkedIn Easy Apply, and a third-party job board all feed into the same candidate database management system, you have three separate consent capture points to audit, not one. 

A common failure mode: the careers page has a compliant consent checkbox, but the job-board integration imports applicants without ever showing them that language, because the board’s own form is what candidates actually filled out.

AI Interview Scheduling and Assessment Tools

AI interview scheduling and screening tools introduce a second layer of exposure: they usually process candidate data on a separate vendor’s infrastructure, which means every scheduling link, video interview recording, or automated assessment result is a cross-border or third-party transfer question waiting to be asked. 

Under GDPR, this triggers a data processing agreement requirement with the vendor. Under the DPDP Act, it raises a “Significant Data Fiduciary” question if volumes are large enough, since heightened obligations, including mandatory audits, apply once an organization crosses thresholds the government designates for that category. 

Before enabling an AI screening feature, it’s worth confirming the vendor deletes interview recordings and transcripts on the same schedule your own retention policy specifies, rather than keeping a separate copy indefinitely on their side.

Recruitment Email Templates and Consent Language

Recruitment email templates are an underrated compliance surface. Auto-rejection emails, talent-pool invitations, and re-engagement campaigns all involve processing stored candidate data for a new purpose each time they’re sent. 

A rejection template that also pitches “we’ll keep your resume on file” is quietly expanding the original consent scope unless that talent-pool language was part of the original application form. 

The fix is straightforward: separate the transactional rejection message from any request to extend retention, and make the extension request an explicit yes/no choice rather than an assumed default.

GDPR and DPDP Requirements for Candidate Data: A Deep Dive

Lawful Basis: Why “We Need It to Hire” Isn’t Always Enough

Under GDPR, every piece of candidate data you touch needs a documented lawful basis, typically consent or legitimate interest for active applicants, and contract necessity once someone is hired. 

The DPDP Act takes a narrower, more consent-centric approach: data can be processed either with explicit, informed consent from the candidate (a “Data Principal” in DPDP terminology) or under a defined “legitimate use,” which includes employment-related purposes but is more tightly scoped than GDPR’s legitimate interest test.

Practically, this means your application form language matters. A checkbox that says “By applying, you agree to our terms” doesn’t meet the specificity bar either law expects. 

Consent needs to state what data is collected, why, how long it’s kept, and who it might be shared with (background check vendors, AI interview scheduling tools, assessment platforms).

Data Retention: How Long Can You Actually Keep a Resume?

This is the single most common compliance gap in recruitment. Neither GDPR nor the DPDP Act sets one universal retention number; both require you to define a purpose-based retention period and justify it. 

But regulatory guidance gives usable benchmarks:

• Unsuccessful candidates (GDPR): UK ICO and EDPB guidance points to 6–12 months as reasonable, unless the candidate has separately consented to a longer “talent pool” retention.
• Talent pool retention (GDPR): French CNIL guidance permits up to 2 years for candidates who’ve explicitly opted into future-opportunity contact, but this requires a fresh consent capture, not a silent carry-over.
• Hired candidates: Once someone becomes an employee, their data moves out of “candidate” retention rules and into standard HR/payroll retention schedules, which are typically longer and governed by employment and tax law.
• DPDP Act: The Act doesn’t prescribe a fixed number of months for candidate data specifically. Instead, it requires that data be erased once the purpose for collecting it has been fulfilled, unless retention is required for legal compliance, placing the burden on the employer to define and document that window.

A workable data retention policy, in practice, looks like this:

1. Classify candidate records by stage: active applicant, rejected applicant, talent pool, hired employee.
2. Assign a retention window to each category (e.g., 9 months for rejected applicants, 24 months for opted-in talent pool).
3. Automate expiry inside your ATS so records are flagged or deleted on schedule rather than relying on manual review.
4. Re-capture consent before extending retention beyond the original stated period.
5. Log deletions so you can demonstrate compliance if a candidate or regulator asks.
6. Audit quarterly for records that have silently exceeded their window; this is where most violations are actually found.

Consent Management Basics

Consent isn’t a one-time checkbox event; it’s a state that needs to be tracked, refreshed, and revocable.

A functional consent management setup should let a candidate see what data you hold, withdraw consent, and trigger a deletion request without needing to email HR and wait a week for a manual response. 

Under GDPR, access and deletion requests generally need a response within 30 days; the DPDP Rules similarly require Data Fiduciaries to respond to Data Principal requests within a defined timeframe set by the Rules.

Security and Breach Notification

Both frameworks assume breaches will happen and focus regulation on response speed. GDPR requires notifying the relevant supervisory authority within 72 hours of becoming aware of a breach involving personal data, where feasible. 

The DPDP Rules, 2025 introduce comparable urgency for Indian data fiduciaries, requiring prompt notification to both the Data Protection Board of India and affected individuals once a breach is identified, reinforcing why candidate database management systems need built-in access logging and encryption, not just password protection.

Cross-Border Data Transfer

If your AI interview scheduling tool, resume parser, or assessment vendor is hosted outside the candidate’s home jurisdiction, cross-border transfer rules apply. 

GDPR requires an approved transfer mechanism (Standard Contractual Clauses, or reliance on frameworks like the EU-US Data Privacy Framework, upheld by the European General Court in September 2025). 

The DPDP Act’s cross-border transfer restrictions remain subject to further government notification as of mid-2026, meaning companies hiring in India should watch this space rather than assume the current lighter-touch position is permanent.

Documenting Your Compliance Position

Both frameworks reward organizations that can show their reasoning, not just their outcome. 

A Data Protection Impact Assessment (DPIA), effectively mandatory under GDPR for any high-volume automated screening and increasingly expected practice under DPDP for AI-driven hiring tools, doesn’t need to be a 40-page document. 

For most startups and SMBs, a working DPIA covers four things: what data is collected, why, what the risk of misuse or breach looks like, and what controls reduce that risk. 

Keeping this as a living document, reviewed each time a new hiring tool is added to the stack, does more for candidate database compliance than any one-off legal review.

Vendor and Sub-Processor Accountability

Every additional vendor in your hiring stack background check providers, skills assessment platforms, reference-check tools is technically a sub-processor of candidate data, and both GDPR and DPDP place responsibility on the primary organization (the Data Fiduciary, in DPDP terms) to ensure those vendors meet the same standard. 

This means your vendor contracts should specify retention limits, breach notification timelines, and deletion procedures that mirror your own policy, not whatever the vendor’s default terms happen to say. 

Skipping this step is one of the more common reasons a compliant-looking internal process still fails an external audit.

Case Studies: Compliance in Practice

Case 1: A Series B SaaS company (120 employees, hiring across EU and India).

An internal audit found 14 months of candidate data sitting in a legacy spreadsheet with no retention tags, alongside their ATS. 

After consolidating into a single candidate database management system with automated retention rules, the team cut its “orphaned record” count by 78% in one quarter and closed a gap that would otherwise have surfaced during a Series C data protection review.

Case 2: A staffing agency handling 3,000+ applications annually. 

Rejected-candidate data was being retained indefinitely “in case a role reopened.”

After implementing a 9-month auto-delete window with an opt-in talent pool extension, the agency reduced its stored candidate volume by roughly 55% while retaining every candidate who had actively chosen to stay reachable, turning a compliance risk into a cleaner, more relevant pipeline.

Case 3: A fintech startup hiring simultaneously in the EU and India.

The team was running two separate consent processes: a GDPR-style form for EU roles and a generic form for Indian roles that hadn’t been updated since before the DPDP Rules took effect. 

After the November 2025 notification, they rebuilt a single candidate database compliance workflow that applied the stricter of the two frameworks’ requirements by default, rather than maintaining parallel policies.

The consolidation took roughly three weeks and eliminated the risk of an Indian candidate’s data being processed under EU-only assumptions that didn’t reflect DPDP’s consent-specific rules.

Comparison: Evaluating Your Compliance Approach

The clearest signal a system is working: you can answer “how long have we held this candidate’s data, and why” in under a minute, for any record, without opening five different tools.

Cost is often the deciding factor teams weigh against these options, and it’s worth being specific rather than vague about it.

Building even a basic in-house retention and consent layer typically runs ₹8–15 lakhs in initial engineering time for a small team, plus ongoing maintenance as regulations shift; the DPDP Rules’ phased rollout through May 2027 alone guarantees at least two more rounds of required updates. 

A modern ATS with compliance features built in shifts that cost into a subscription, which is usually the better trade for teams under 200 employees that don’t have a dedicated data engineering function to maintain custom tooling indefinitely.

The migration question also matters more than teams expect.

Switching candidate database management systems mid-year, without a plan for the data sitting in the old tool, is how orphaned records end up outside any retention policy in the first place.

A clean migration should include an audit of what’s being carried over, an explicit decision on what gets left behind (and deleted, not just abandoned), and a fresh consent check for any records older than your defined retention window.

What Most Teams Get Wrong

The most common mistake isn’t ignoring compliance; it’s treating it as a one-time policy document rather than an operating habit. 

Teams write a retention policy, store it in a shared drive, and never connect it to the actual candidate database management system doing the storing. The policy and the software drift apart within two hiring cycles.

The second mistake is conflating consent for the application with consent for ongoing contact. 

A candidate who applied to one role did not agree to be in your database for the next three years of open positions that require a separate, explicit opt-in, and treating it as implied is one of the more frequently cited GDPR violations in HR-sector enforcement.

The third and most avoidable mistake is assuming a tool’s marketing claim of “GDPR-ready” substitutes for an actual internal audit. 

Software can provide the mechanism for retention limits and deletion logs; it cannot decide what your retention periods should be or make sure your team is actually using the feature. 

Compliance is a process the software supports, not a checkbox the software ticks on your behalf.

A fourth pattern worth naming: treating candidate database compliance as solely a legal or HR responsibility, with no input from whoever actually configures the ATS or job board integrations. 

In practice, the person setting up an application form’s fields and the person writing the privacy policy are often different people who never compared notes. 

That gap is where consent language and actual data collection quietly drift apart: the form asks for more than the policy discloses, or the policy promises a retention window the system was never configured to enforce. 

Closing that gap takes one recurring meeting between recruiting operations and whoever owns data governance, not a new piece of software.

None of this is unique to large enterprises. If anything, smaller recruiting teams are more exposed, because they’re less likely to have a dedicated compliance function catching these gaps before a candidate complaint or an audit does.

Building a Repeatable Compliance Checklist

A one-time audit fixes today’s problem but not next quarter’s. The teams that stay ahead of both frameworks tend to run the same short checklist on a fixed cadence rather than reacting to a specific incident or renewal date:

• Confirm every active data collection point careers page, job boards, referral forms displays consent language that matches your actual retention policy, not a generic placeholder.
• Reconcile retention windows across every category of candidate record, and confirm your ATS is actually enforcing them rather than just displaying them in a settings page.
• Review vendor contracts for AI screening, background checks, and assessment tools against current breach-notification and deletion-timeline standards, since these terms often lag behind the platforms’ own compliance claims.
• Re-run consent for any talent-pool candidates approaching the end of their original stated window.
• Log every deletion and access request response, with timestamps, so a demonstrated compliance history exists before it’s ever needed.

Run this quarterly, and candidate database compliance stops being a project with a deadline and becomes a background process that just runs, which is the actual goal, since neither GDPR nor the DPDP Act rewards a one-time fix over a maintained standard.

Frequently Asked Questions

1. How long can a company legally store candidate resumes? 

There’s no single fixed number under GDPR or the DPDP Act. GDPR guidance from EU regulators typically points to 6–12 months for unsuccessful candidates unless they’ve separately consented to talent-pool retention (up to 2 years in some jurisdictions). The DPDP Act requires deletion once the purpose is fulfilled, with the exact window defined by the employer’s documented policy.

2. Does India’s DPDP Act apply to recruitment data?

Yes. The DPDP Act, 2023, and the DPDP Rules, 2025 (notified November 2025) apply to any digital personal data connected to India, which includes resumes, contact details, and assessment records collected from Indian candidates or processed by companies operating in India, regardless of where the hiring company is headquartered.

3. What is the difference between GDPR and DPDP Act obligations? 

GDPR allows multiple lawful bases for processing, including legitimate interest, and sets fine amounts as a percentage of global turnover. The DPDP Act leans more heavily on explicit consent or narrowly defined “legitimate uses,” and sets fines in fixed rupee amounts up to ₹250 crore per violation category rather than a turnover percentage.

4. Do recruiters need candidate consent to store CVs? 

Generally, yes, either explicit consent or a clearly documented legitimate basis is required under both frameworks. Storing a resume without informing the candidate what it will be used for, or for how long, is a common compliance gap that regulators have flagged in HR-sector audits.

5. What happens if an ATS is not compliant with data protection law?

The company using the ATS remains legally responsible for the data, regardless of the tool’s own compliance posture. Non-compliant retention or consent handling can result in fines, mandatory data deletion orders, and reputational damage from candidate complaints, which are the most common trigger for recruitment-sector investigations.

6. Can candidate data be reused for future job openings? 

Only if the candidate has given separate, explicit consent to be considered for future roles beyond the original application. Reusing rejected-candidate data for a new opening without that consent is treated as a new, unauthorized processing activity under both GDPR and the DPDP Act.

7. Should startups build compliance features in-house or rely on their ATS? 

For most startups and SMBs, relying on an ATS with built-in retention automation, consent logging, and access controls is more reliable than building and maintaining custom compliance tooling, provided the internal team still owns the policy decisions (retention windows, consent language) rather than assuming the software makes them automatically.

If you’re weighing this trade-off before committing to a platform, it’s worth pressure-testing your current recruitment email templates, consent forms, and retention settings against both frameworks first.

8. Is a Data Protection Impact Assessment mandatory for hiring tools? 

Under GDPR, a DPIA is generally required when using automated decision-making or profiling at scale, which covers many AI interview scheduling and screening tools. 

The DPDP Rules don’t use identical terminology, but Significant Data Fiduciaries face comparable audit and assessment obligations once they cross volume thresholds set by the government, making an internal risk assessment good practice even where it isn’t strictly named as mandatory.

Getting Your Candidate Database Audit-Ready

Compliance isn’t a single fix; it’s a recurring discipline of classification, consent tracking, and scheduled deletion, applied consistently across every hiring cycle. Start with a basic audit: pull every place candidate data currently lives, tag each record’s age and consent status, and flag anything past a defined retention window.

Hirium’s centralized candidate database structure, with real-time tracking and automated status workflows, is built to make that audit a five-minute task rather than a two-week project, but the audit itself is worth doing regardless of which system you run it on.