Deleting Applicant Data Under GDPR: Retention Periods for Recruitment Teams

Applicant data looks harmless at first. A CV arrives by email. A PDF is uploaded to your ATS. A few interview notes sit in a calendar invite. Over time, these small traces become a real privacy risk.

GDPR requires clear purposes, limited retention and evidence that deletion actually happens. Recruitment is especially sensitive. You process detailed information about people who often have little visibility into your internal workflow.

This guide explains how long you can keep applicant data. It also shows when you must delete it, which exceptions apply and how to build a practical deletion process.

Why Applicant Data Cannot Stay in Your System Forever

The core rule sits in Article 5(1)(e) UK GDPR and EU GDPR. Personal data may be kept only for as long as necessary for the purpose for which it was collected.

In recruitment, that purpose is usually specific. You want to fill a role. Once the role is filled, that purpose ends for rejected candidates.

After that point, you need another legal basis. Without one, you cannot simply keep CVs, cover letters, certificates, interview notes or screening results.

Many teams think, “This person may fit a future role.” That is understandable. Legally, it is not enough.

If you want to keep data for future vacancies, you need a proper talent pool process. That means consent, transparency and a separate retention period.

What Counts as Applicant Data?

Applicant data is not only the CV. In a normal hiring process, many different records are created.

Typical examples include:

• CVs, cover letters and certificates
• contact details and salary expectations
• interview notes and internal assessments
• email communication with candidates
• test results and work samples
• rejection reasons and ATS status fields
• AI scores, matching values and screening comments
• metadata such as upload time or application source

Derived data also counts. If your tool calculates a match score, that score is personal data.

This is particularly important in AI-assisted screening. A ranking looks technical. It still describes a real person and affects their employment opportunities.

The Practical Rule: Three to Six Months After Rejection

Across many European recruitment processes, a practical retention period has emerged: rejected applicant data is usually deleted after three to six months.

The reason is legal defence. Rejected candidates may bring discrimination or unfair treatment claims. In the UK, claims under the Equality Act 2010 usually move quickly. In the EU, national employment laws often create similarly short timeframes.

Many employers therefore keep application records for about six months after the end of the process. This is often defensible.

But six months is not an automatic right. You must document why the period is necessary.

For low-risk roles, three months may be enough. For senior roles, complex assessments or higher litigation risk, six months may be justified.

Keeping data longer needs a concrete reason. An active dispute would be one example.

When Does the Retention Period Start?

The clock should not start when the application arrives. It should start when the recruitment process ends for that candidate.

A clear trigger could be:

• the rejection email is sent
• the final selection round closes
• the chosen candidate signs the contract
• the vacancy is formally closed

Choose one trigger and document it. Otherwise, nobody knows when deletion is due.

Best practice is simple. Every application has a status and a date. When the status changes to “rejected” or “role filled”, your system sets a deletion date automatically.

HireSift can support this structured workflow. Deletion should not depend on someone remembering an old spreadsheet.

What Do You Actually Need to Delete?

Deleting data means more than removing a candidate from the visible list. You need to check all relevant copies.

This includes:

• files in your ATS or recruitment platform
• PDFs in cloud folders
• email attachments in personal inboxes
• exports in Excel or CSV files
• notes in project management tools
• calendar attachments and interview documents
• backups once the normal backup cycle expires

Shadow copies are the hidden risk. They appear when recruiters download CVs and store them locally.

A good deletion policy reduces these copies. Use central systems, clear permissions and limited download access wherever possible.

Talent Pools Need Consent and Their Own Retention Period

Talent pools are allowed. They just need a separate legal basis.

The cleanest option is freely given consent. Candidates must understand why you are keeping their data.

Your consent wording should cover:

• the purpose of the talent pool
• the types of data you will store
• the planned retention period
• the right to withdraw consent
• a privacy contact for questions

Do not keep talent pool data indefinitely. A common practical period is twelve months. After that, ask again or delete the data.

Consent must be specific. It should not be hidden in a general privacy policy paragraph.

Use a separate checkbox. It should not be pre-ticked.

Handling Speculative Applications

Speculative applications are different because they are not tied to a specific vacancy. You still need a defined purpose.

You can review the application for currently suitable roles. If no suitable role exists, you must decide quickly.

Either you request talent pool consent, or you delete the data after a short review period.

A general “we may need this later” storage policy is weak. A simple automated workflow makes this much safer.

AI Screening: Do Not Forget Scores and Criteria

AI-assisted recruitment creates additional data. This includes matching scores, criteria ratings and generated summaries.

These records must be deleted alongside the application. Deleting the original PDF while keeping the score is not enough.

Training data matters too. If a vendor uses applicant data to train models, you need a very clear legal basis.

Check your Data Processing Agreement. It should prevent candidate data from being used for model training without your explicit permission.

For sensitive roles, you should also record which criteria were applied. This helps with access requests, complaints and internal audits.

How to Build a Practical Deletion Policy

A deletion policy does not need to be complex. It does need to be specific.

Start with five building blocks.

1. Define your data types List the applicant data you process. Include documents, notes, scores, emails and exports.

2. Map each purpose Connect every data type to a purpose. Examples include selection, communication, legal defence and talent pooling.

3. Set retention periods Assign a period to each purpose. Rejected applicants are usually three to six months. Talent pools are commonly twelve months.

4. Name responsible owners Decide who checks deletion runs. Privacy cannot be an undefined side task for HR.

5. Keep deletion evidence Record that deletion happened. Avoid storing unnecessary content in the deletion log.

A simple log is often enough: candidate ID, deletion date, data category and the person or system that executed it.

Example Retention Periods for Recruitment

These periods are a practical starting point:

• rejected applicants: three to six months after rejection
• hired applicants: relevant records move to the employee file
• talent pool entries: twelve months, then renewed consent or deletion
• speculative applications with no suitable role: one to three months
• interview notes: same period as the application
• AI scores and screening summaries: same period as the application
• backups: deletion after the normal backup cycle

Adjust these values to your risk profile. Document the reason briefly.

Common Mistakes in Recruitment Teams

The most common mistake is unclear ownership. Nobody feels responsible until a candidate sends an access request.

The second mistake is manual exporting. CSV files are created, shared and then forgotten.

The third mistake is a talent pool without real consent. It feels efficient, but it creates avoidable legal risk.

The fourth mistake relates to AI tools. Teams delete the source document but keep analysis results and match scores.

The fifth mistake is email sprawl. Applications stay in personal inboxes for years.

What About Access and Erasure Requests?

Candidates can request access to their data. They can also ask for deletion when no legal basis remains.

You should therefore know where applicant data sits. Otherwise, every request becomes a manual investigation.

A central candidate profile helps. From there, you manage status, retention period and deletion.

If you keep data for legal defence, explain that clearly. Then delete it automatically once the period ends.

Conclusion: Deletion Is Part of Recruitment Operations

Deleting applicant data is not a minor technical task. It is a core part of your recruitment process.

The main rule is simple. Keep data only while you have a clear purpose. For rejected applicants, three to six months is often defensible.

Talent pools need separate consent and their own retention period. AI scores, notes and exports belong in the same deletion workflow.

When you handle this well, you reduce privacy risk and make recruitment easier to manage.

HireSift helps teams structure applications, document criteria and keep deletion deadlines visible. That makes your process faster, fairer and GDPR-aware.