The strongest candidate for the role you are working on right now is probably already somewhere in your files. Knowing how to organize a candidate database is what separates finding that person in thirty seconds from re-sourcing a market you already sourced last year. This guide is the practical version: what to unify first, which fields to standardise, how to kill duplicates, and how long you are allowed to keep any of it.
It is written for agency recruiters, in-house teams and independent headhunters who never chose a messy system. It accumulated.
Why Scattered CVs Cost You Placements
A fragmented candidate base never announces itself with an error message. It shows up as small, recurring costs that look like ordinary recruiting work.
- Re-sourcing people you already have. The silver medallist from a search eight months ago is a warm, pre-qualified candidate — but only if you can find them.
- Answering "have we seen this person?" from memory. When the answer lives in one recruiter's head, your candidate base has a single point of failure.
- Contacting the same person twice. Two colleagues, two records, two spellings of the same name — and one candidate who now doubts you are organised.
- Compliance exposure. You cannot honour a deletion request if you do not know how many copies of that CV exist or where they live.
The cause is rarely carelessness. It is that every channel creates its own storage: the ATS keeps applicants, referrals arrive by email, sourced profiles sit in a spreadsheet, and client-submitted CVs land in a shared drive nobody indexes.
What a Candidate Database Actually Is
A candidate database is a single searchable store of every person you have ever evaluated, whether or not they applied to a specific job. That is a different object from the two systems it gets confused with.
| System | Built for | Bad at |
|---|---|---|
| Applicant tracking system (ATS) | Moving applicants through the stages of one open vacancy | Finding a person across processes it closed years ago |
| Candidate database | Finding the right person across every source and every past process | Running the day-to-day workflow of a live vacancy |
| Talent pool | Nurturing a small, warm group for a role you expect to open | Breadth — it is a curated subset, not the whole base |
The distinction matters because buying an ATS does not give you a candidate database. An ATS is organised by vacancy; a database is organised by person. It also explains why a keyword search inside your ATS misses people it already holds: filtering by exact terms is not the same as evaluating a career, a gap covered in ATS vs AI candidate matching.
How to Organize a Candidate Database in Six Steps
Work in this order. Each step assumes the one before it, and skipping the first turns everything after it into cleaning half a base twice.
- 1
Inventory every source
List every place a CV can currently live: ATS exports, inboxes, shared drives, spreadsheets, saved sourcing lists. Nothing gets cleaned before you know what exists.
Step 1
- 2
Pick one system of record
Decide where the base will live before you import anything. Two main systems is the problem you started with, not the fix for it.
Step 2
- 3
Import and parse
Bulk-import the CVs and let parsing turn each one into structured fields, instead of leaving them as attachments nobody can search.
Step 3
- 4
Standardise the fields
Agree a fixed vocabulary for role, seniority, location and source. Free text is what makes a base unsearchable six months later.
Step 4
- 5
Deduplicate
Merge records that describe the same person before anyone starts searching, keeping the richest history of the two.
Step 5
- 6
Set retention rules
Give every record a review date the day it enters the base, so it stays current without an annual cleanup project.
Step 6
Steps 1 and 2 are the ones teams skip, and they are the ones that decide whether the other four hold. A base with two systems of record is not a base.
What Fields and Tags Should You Use?
One rule filters the whole discussion: a field earns its place if you would ever search or filter by it. Everything else belongs in the CV itself or in a note.
| Field group | Examples | Why it is worth a column |
|---|---|---|
| Identity | Full name, email, phone | Email and phone are your deduplication keys |
| Role | Current title, function, seniority | The first filter of almost every search you run |
| Constraints | Location, remote preference, notice period, work authorisation, salary expectation | Removes most false positives before you open a single CV |
| Evidence | Skills, industries, languages, certifications | What you actually match against a vacancy |
| Process | Source, last contact, outcome of past processes, consent date | Tells you whether the record is usable and still lawful |
Resist storing more "just in case". The GDPR principles that EU regulators set out for organisations require you to process only the personal data that is necessary and proportionate to the purpose you defined — the data minimisation principle. A field you never filter by is not necessary; it is just risk you are storing.
Tags carry what fields cannot: context that does not fit a column, such as referred by a client, open to relocation or strong culture fit, wrong seniority. Keep the tag list closed and short. An open tag field becomes a second free-text field within a quarter, and free text is what you were escaping.
How Do You Handle Duplicates and Stale Records?
Duplicates are mostly created by parallel sourcing: two recruiters find the same person in the same week through a referral and a job board, and the base gains two half-complete records instead of one good one.
- Match on the stable identifier first. Email and phone survive name changes, accents and transliterations; names do not.
- Merge, never delete. The value of a duplicate is the history attached to it — the interview notes from 2024 belong on the surviving record.
- Block the next one at entry. A duplicate check when a record is created costs seconds; the same check after a year costs a cleanup project.
- Flag staleness by date, not by feel. Sort by last contact and treat anything past your threshold as a record to refresh or retire, not as a candidate to email blind.
Stale is not the same as useless. A four-year-old CV of an excellent engineer is a good reason to reconnect — and a bad basis for judging their current level. Accuracy is a legal obligation as much as a practical one: personal data has to be kept up to date, and a base of CVs that nobody has been asked to refresh stops being accurate long before it stops being big.
How Long Can You Keep Candidate Data?
There is no single number in the GDPR. The rule is that personal data must be kept for the shortest time possible, with time limits set to erase or review it. The retention period is yours to define and justify, not to guess — and the European Commission's own worked example is a recruitment office planning to hold CVs for ten years, a period it treats as disproportionate to the short-to-medium-term purpose of getting someone hired.
In practice that becomes three states rather than a binary keep-or-delete. The French data protection authority describes the lifecycle as an active database, an intermediate archive accessible only to a specific service, and a final stage where data is deleted or made anonymous.
- Active baseSearchable by the whole team while the purpose lasts
- Intermediate archiveRestricted access, kept only for a documented reason
- Deleted or anonymisedRemoved, or kept only as statistics with no person behind them
Every record gets its review date the day it enters the base, not the day someone remembers.
Three consequences for how you organise the base. First, consent has to be a field with a date: keeping someone for future roles is a separate purpose from the process they applied to, and you need to point to when they agreed. Second, vetting material is a higher-risk category and does not belong in the general base — if you run checks, keep what a background check report contains separate and short-lived. Third, deletion has to be reachable: one record per person with one owner is what makes an erasure request a two-minute task instead of a search across four systems.
From an Organised Base to a Shortlist
An organised candidate database is not the goal. It is the precondition for everything that produces a placement, because a candidate who lives in an unindexed email thread cannot be searched, scored, ranked or presented.
- Every CV in one place, parsed into fields instead of sitting as an attachment.
- One record per person, carrying the history of every process they went through.
- A review date on every record, so the base stays accurate on its own.
Once that is true, the rest of the flow becomes mechanical: score each candidate against the live vacancy, keep the reasoning visible so the ranking is defensible, and present the finalists in a client-ready format. That is exactly what our expert service for recruiting teams does on top of the systems you already use.
Frequently Asked Questions
What is the difference between a candidate database and an ATS?
An ATS is organised by vacancy and moves applicants through the stages of one process. A candidate database is organised by person and holds everyone you have ever evaluated, from any source. Most teams need both, and neither replaces the other.
Can you organise a candidate database in a spreadsheet?
Yes, up to a few hundred records and one recruiter. Spreadsheets break on concurrent editing, duplicate control, attachments and retention rules — usually at the exact point where the base has become worth protecting.
How often should you clean your candidate database?
Continuously beats periodically. Put a review date on every record at import so staleness surfaces by itself, then run a scheduled audit every six to twelve months to confirm the rules are working rather than to rebuild the base.
How long can you keep a rejected candidate's CV?
Only as long as you can justify for a defined purpose. The GDPR sets no fixed number: you define the period, document the reason, and apply it automatically, keeping the data for the shortest time possible.
Do you need consent to keep a CV for future vacancies?
You need a lawful basis, and for holding someone in a talent pool beyond the role they applied for, consent is the usual one. Record the date it was given so the record can expire on schedule instead of living forever.