The Candidate Record Retention and Deletion Reference

This reference tells you how long to keep each candidate record you hold and when you are required to delete or anonymize it. It is for recruiting operations, revenue operations, and anyone answerable for how candidate data was gathered and disposed of. Jump to the row for the record type in front of you and read across: retention clock, start trigger, lawful basis, and the exact deletion action.

Most published guidance folds everyone into an applicant-tracking model. That model is wrong for the fastest-growing category you hold: people you sourced who never applied. They carry their own clock, their own notice duty, and their own lawful basis, and their clock is the shortest and hardest of all. This document treats that row as a first-class citizen.

Why candidate retention has no single number

There is no universal retention period for candidate data, and any vendor who hands you one is guessing. GDPR's storage-limitation principle does not name a number of months. It requires that personal data be kept only as long as necessary for the purpose for which it was collected, and that you can demonstrate this is proportionate. Your retention period is not handed to you. You have to justify it, document it, and enforce it.

That is the whole reason a reference like this exists. The number you defend comes from the collection purpose plus the relevant legal floor, and the floor moves by jurisdiction and record type. The ICO ties the recruitment floor to claim windows: unless there is a clear business reason, you should not keep records for unsuccessful applicants beyond the statutory period in which a claim arising from the recruitment process may be brought. In the UK that window is six months under the Equality Act 2010. CIPD recommends keeping recruitment paperwork for six to twelve months.

That ratio is the shape of the problem. In Refolk's index of professional profiles, the people minting sourced-prospect records outnumber the people governing retention roughly twenty-seven to one. Sourcing is a distributed frontline activity; retention governance is centralized. Records get created faster than the notice and deletion duties on them get discharged.

How long to keep candidate data by jurisdiction

The retention floor for an unsuccessful applicant is the window in which they could bring a claim, and that window is different in every country you hire into. The table below is the floor: the minimum defensible period, not a target.

Two things in that table trip teams up. First, the US federal floor is one year from the date of the record or the personnel action, whichever occurs later. Under 29 CFR 1602, any personnel or employment record, including application forms submitted by applicants and other records having to do with hiring, must be preserved for that year. If an employee is involuntarily terminated, their records must be retained for one year from the date of termination.

Second, France's row does not measure the same thing as the others. CNIL Délibération 2020-092 sets a two-year outer limit from last contact for candidate data, with re-consent required before that period expires. Last contact is a reset event, not a fixed start. A single global "keep twelve months" rule under-retains in the US the moment a personnel action lands and mis-triggers in France the moment you email a prospect again.

Beyond the applicant floor, US federal rules add longer clocks for adjacent records. ADEA recordkeeping requires payroll records for three years, and FLSA requirements applicable to the Equal Pay Act require payroll records for at least three years. Once a charge of discrimination is filed, the clock goes open-ended: the respondent employer must preserve all personnel records relevant to the charge or action until final disposition. The EEOC recordkeeping rule bites at fifteen or more employees for Title VII, ADA, and GINA, and twenty or more for ADEA.

The sourced-prospect row: shortest clock, hardest duty

A person you sourced who never applied is not an applicant, and treating them as one is the most common lawful-basis error in recruiting. Legitimate interest, not consent, is the standard basis for initial contact, and you owe an Article 14 notice within one month.

Legitimate interest can cover initial contact with candidates who have a reasonable expectation of being approached, for example someone sourced from a public LinkedIn profile. For long-term talent-pool retention, consent is the safer basis: explicit, revocable, and renewed before it expires. Either way, you must complete a legitimate-interest assessment, name the source, and give an easy right to object.

The timing duty is where the row turns hard. You must notify the person within a reasonable period and at the latest within one month of obtaining the data, or at the moment of first communication, whichever is earlier. The consequence of missing it is not a warning. Send an email to sourced candidates to inform them you are processing their data within one month after you first processed it. If you do not send this email within a month, you should delete their data from your database immediately.

The sourced prospect has the shortest, hardest clock you hold, and most teams file it under the longest.

So the sourced-prospect clock inverts the usual intuition. The applicant gets six to twelve months of grace. The prospect gets a one-month notice window, and blowing it collapses the lawful basis to "delete now." This is not theoretical enforcement. Regulators have sanctioned several B2B data vendors in the 2023 to 2025 window specifically for missing the Article 14 notice, the exact failure mode of this row.

If your notice discipline depends on remembering to log each sourced contact by hand, it will fail at volume. Refolk lets you source in plain English and see where each profile came from, which is the source-named, object-easy posture Article 14 asks for at the point of contact rather than a month later.

What starts and resets the retention clock

The clock does not start when you receive an application. In Greenhouse's documented model the trigger is rejection on all applications. The data retention period marks the length of time your organization has determined to keep a candidate's or prospect's data after they have been rejected from all jobs. A candidate still active on any one job keeps their record alive.

The reset is a renewed-consent email, and its length is fixed to the original. Greenhouse Recruiting's consent-extension email allows your organization to configure an email that is automatically sent to candidates or prospects before their data retention period expires to ask for consent. The length of time for the extension is the same as the original data retention period.

The documented worked example: if you activate the data retention timer on May 25, 2018, and set the period for 365 days, you will receive an email immediately after activation to delete candidate personal data for any rejected candidates who were rejected on or prior to May 25, 2017. The timer looks backward from activation, so switching it on surfaces an immediate backlog rather than only governing new records.

Note the trigger disagreement between models. Greenhouse keys the clock to rejection; CNIL keys it to last contact. If you run both an ATS and a nurture CRM, the same person can have two different expiry dates. Pick the earlier one to be safe, and record which trigger governs each store.

What a defensible deletion actually removes

Deletion and anonymization are not the same record state, and "the profile says Anonymized" is not proof the person is gone. Data selected for deletion in a retention rule is removed from all reports and from the candidate profile after a configured time period when the candidate is rejected on all applications, or when the candidate requests that their data be deleted.

The named profile fields a rule clears include the name and pronunciation recording, replaced with "Anonymized #", personal pronouns, current company, and current title. That is the profile layer. It is not the whole record.

This is why a deletion action has to name the artifact class it targets. Think of the record in layers, and confirm each one.

The bottom two layers are where deletions leak. When you log a disposal, state which layers it covered. If a request was a full erasure and the activity feed still names the person, the job is not finished, whatever the profile shows.

How this goes wrong: failure modes and false positives

Most retention failures are not missed calendar dates. They are wrong models, false confidence, and orphaned copies. These are the recurring ways the work fails.

• Treating deleted as gone. The profile reads "Anonymized #" but the activity feed still names the person. The fix is to verify the log, not the profile, and to record which artifact layers the deletion actually cleared.
• Consent as a licence for indefinite storage. Most recruiters mistakenly think consent allows indefinite storage. Under GDPR, consent must be specific, informed, and withdrawable, and for talent pools it must be renewed before it expires. Consent held is not consent kept.
• The seven-year myth. The seven-year figure applies to financial and accounting records under tax legislation, not candidate CVs. Conflating the two is one of the most common GDPR mistakes in recruitment, and it turns a six-month floor into a six-and-a-half-year liability.
• Sourced prospect folded into the applicant model. No Article 14 notice within a month means unlawful holding, and the required action is immediate deletion. This is the single most enforced failure in the 2023 to 2025 vendor sanctions.
• Orphaned copies in subprocessors. Data may remain in support, monitoring, CRM, and file-sharing tools after internal deletion. If you delete only in the ATS, the record survives everywhere else you piped it.
• Deleting under a live legal hold. Legal-hold processes must integrate with retention schedules, or a normal deletion becomes evidence-destruction liability. Once a charge is filed, retention is open-ended until final disposition; the hold overrides the schedule every time.
• Wrong clock trigger. Using application date when the ATS uses rejection-on-all-jobs, or ignoring CNIL's last-contact reset, under-retains or over-retains silently. Nobody notices until an audit or a subject access request forces the count.

One matrix helps you sort what to do when a record's clock has run but its state is ambiguous.

Who creates the records versus who governs them

Retention is a governance function riding on a sourcing function, and the two are staffed at wildly different scales. In Refolk's index of professional profiles, US talent sourcers number 4,942 against 186 US recruiting-operations professionals. That is the twenty-seven-to-one ratio driving the backlog.

The comparator rows carry a second warning for cross-border teams. Sourcing capacity concentrates in the US against Germany at thirty to one, while operations capacity concentrates against the UK at only six to one. A German or UK team sourcing US-style volumes is running proportionally thinner governance headcount, so the notice and deletion duties on their records pile up faster relative to the people who can discharge them.

The operational takeaway: automate the two duties that scale with sourcing volume, the Article 14 notice and the expiry sweep, because you cannot hire governance headcount in step with sourcing headcount.

The retention and deletion procedure

Run this once to build the schedule, then let steps six and seven run on the sweep cadence. The roles in parentheses are the accountable owner for each step.

Sources disagree on cadence. Some recommend quarterly audits; others recommend an annual full review plus quarterly spot checks. Treat annual as the review floor and quarterly as the enforcement sweep. Run a monthly or quarterly review of records approaching the retention end date, confirm whether any legal hold, audit request, government inquiry, or litigation matter requires continued retention, and perform a full review at least annually.

Record series: [applicant | sourced-prospect | payroll | performance]
Candidate or batch ID:
Trigger event and date: [rejection-on-all-jobs | last-contact | erasure request] on YYYY-MM-DD
Retention period applied:
Legal hold check: [none active | hold ID ____ , deletion suspended]
Artifact layers cleared: [profile fields | reports/exports | activity logs | subprocessor copies]
Action: [deleted | anonymized]
Destruction date: YYYY-MM-DD
Destruction method:
Approver:

The deletion checklist

Run this before you sign off any disposal, whether it is a scheduled sweep or a one-off erasure request. A subject access request or erasure request carries a thirty-day response window, so the checklist has to be fast to run.

Keeping the schedule current

A retention schedule is not a document you write once. It decays as tools change, as you hire into new jurisdictions, and as regulators move. The mechanism to keep it live is the annual review plus the monthly or quarterly enforcement sweep, but the trigger for an off-cycle review is a change event: a new assessment tool, a merger, a new hiring country, or a security incident.

Three things to re-check rather than assume. First, the claim windows by jurisdiction, because a floor changing shifts every applicant row that depends on it. Second, your subprocessor list, because a new vendor is a new place records hide from deletion. Third, whether any sourced-prospect data has reached a model, given the deployment risk the EDPB opinion raised. Re-check the mechanism, not last year's answer, and the schedule stays defensible.