How long should you keep a CV?

Every agency database has a long tail of people who would be surprised to learn they are in it. That tail is not an asset. It is a liability with a search box on it.

Nobody sits down and decides to keep candidate data forever. It happens because deleting feels like destroying value, because nobody owns the decision, and because the database does not send an invoice that makes you look at it.

So the tail grows. A recruitment database of any age contains people who applied for one role, once, years ago, who have moved country, changed career or retired, and who would be genuinely surprised to hear you still hold their CV, their phone number and a note from a recruiter who left in 2021.

Three reasons the tail is worse than it looks

It is personal data you are accountable for

Under the GDPR and the UK GDPR, personal data must be kept only as long as is necessary for the purpose it was collected for — and you have to be able to say what that period is and why. Several US state privacy laws now cover job applicants too. The obligations differ; the direction does not.

The practical version of this is not the fine. It is the request. Someone emails asking what you hold about them and requesting deletion, and you now need to find every copy: the candidate record, the CV file, the notes, the email thread, the spreadsheet a recruiter exported in March. If that takes a week, the problem is not the request.

It is mostly wrong

A five-year-old CV records a job title the person no longer holds, a salary expectation from a different market, a phone number that may not work, and an availability that has certainly changed. Searching it does not produce candidates; it produces calls that start with an apology.

The stale tail also distorts every number you calculate from the database — the size of your talent pool, the coverage of a search, the value of the asset you think you are building.

It is the size of your worst day

If you ever have to notify people about a breach, the number you will be reporting is the number of records you held. Not the number you were using. The difference between 40,000 active candidates and 400,000 records including everyone since 2014 is entirely a choice you made by not making it.

Deciding the period

There is no universal number, and any vendor offering you one is guessing. What there is, is a method: tie each category to a purpose, and let the purpose set the clock.

1. 1Unsuccessful applicants to a specific roleTwo purposes: being able to defend the hiring decision if it is challenged, and genuinely re-approaching them about something similar. The first is governed by the limitation period for employment claims where you operate; the second is rarely useful past a year or two. Many agencies land between 12 and 24 months. Pick one, write it down, and be able to say why you picked it.
2. 2Talent pool held with consentIf someone has agreed to stay on your books, that agreement should be renewable rather than perpetual. Ask again on a cycle — two years is common — and record the ask and the answer. A re-consent email also does something useful: the people who reply are, by definition, the live half of your database.
3. 3Placed candidates and contractorsLonger, and for entirely different reasons: employment records, tax and payroll obligations, and the terms of the contract you placed them under. That clock is set by employment and tax law rather than by recruitment, and it is usually measured in years after the engagement ends.
4. 4Evaluations, scores and screening decisionsKeep these as long as you keep the application they belong to, and keep them intact. The point of an append-only evaluation history is that it explains a past decision; a record that has been edited or partially deleted answers nothing. If you delete, delete the whole application record rather than hollowing it out.
5. 5Notes and free textThe category everyone forgets. Recruiter notes are personal data, they are disclosable in an access request, and they are frequently the part of the file somebody would least like to read about themselves. Same retention as the record they attach to — and worth a separate conversation about what belongs in one.

Deleting properly

Retention only counts if deletion actually happens, and deletion has two halves that fail separately.

Order matters. Delete the file from storage first, then clear the pointer to it. Do it the other way round and a failure halfway leaves an orphaned file nobody has a record of — a document containing someone’s personal data, with no row pointing at it, which will not appear in any access request you ever run and will sit there indefinitely.

It has to be scheduled. A retention policy enforced by somebody remembering is a retention policy that runs once, in the month it was written. It should be a job that runs on a timer and reports what it did.

Check the copies. The CV in storage is the easy one. The harder ones are the attachment in a shared mailbox, the export someone made to review at the weekend, the backup, and the third-party tool a recruiter connected two years ago. You cannot promise deletion you cannot perform, so the honest move is to know where the copies go and reduce the number of places they can go to.

The other half: who can see it

Retention is how long. Access is who, and it is the half that gets less attention despite being the one with daily consequences.

• “Everyone with a login” is an answer. It is just one you should have chosen on purpose, knowing that it includes the contractor who joined last week and the person working their notice.
• A file link that never expires is a permanent grant. If a CV is served from a URL that works forever, then anyone who was ever sent that link — including someone who has since left — still has the CV. Short-lived signed links, minted per request against a permission check, are the difference between lending a document and publishing it.
• Commercial data is a separate question. Salaries, margins and client terms should not be visible to everyone who can see a candidate, and the restriction should live in the data layer rather than in the interface — otherwise it protects a page rather than the data behind it.
• Exports are where policies go to die. A spreadsheet on a laptop is outside every control you have. Worth knowing who can produce one, and worth asking whether they need to.

Being able to answer the question

The test of all of this is a single email: please tell me everything you hold about me, and delete it.

In a well-run system that is a lookup and a deletion, done in minutes, with a record that it happened. In a typical one it is an afternoon of searching four systems and a shared mailbox, followed by a reply that is more confident than the search justified.

You do not need to guess which one you are. Send yourself the email, from an address that is in your database, and time the honest answer.