What Is a Candidate Database?
A candidate database is a structured repository inside your ATS that stores information about every person your organisation has ever engaged with in a recruitment context - past applicants, proactively sourced contacts, referred candidates, and people who expressed interest but did not formally apply.
It is distinct from your active hiring pipeline. The pipeline tracks candidates moving through a live recruitment process for a specific vacancy. The candidate database is a long-term strategic asset: a searchable record of talent your organisation has already evaluated or identified, ready to be activated when the right role opens.
Modern ATS platforms include a candidate database as a core feature because the cost of sourcing new candidates from scratch on every hire is significant. A well-maintained database means that a proportion of future hiring needs can be met from people you already know - candidates whose skills have been assessed, whose motivations have been explored, and whose availability can be quickly confirmed.
What data does a candidate database store?
A typical candidate database holds the following per candidate record:
- Full CV and parsed CV data (name, contact details, work history, education, skills)
- Source of the candidate (job board, referral, direct application, LinkedIn, career page)
- Application history - which roles they applied for, when, and the outcome
- Interview notes and structured feedback from assessors
- Custom tags (skills, seniority, department fit, availability)
- Recruiter notes and correspondence history
- Consent records and data retention status
The quality of this stored data - and how easily it can be searched - determines how useful the database is in practice.
Why a Strong Talent Pool Reduces Hiring Costs
Organisations that actively maintain talent pools often report shorter time-to-hire for repeat or similar roles, because they have a starting point that cold sourcing does not provide. Rather than publishing a vacancy, waiting for applications, and running full screening rounds from scratch, a recruiter can first search the database for candidates who were strong in a previous process but were not selected - sometimes called "silver-medal" candidates.
Silver-medal candidates are particularly valuable. They have already been screened and interviewed. The reason they were not hired was timing or fit for a specific role, not a fundamental lack of suitability. When a comparable vacancy opens, re-engaging them is faster and often more reliable than starting a new search.
Industry data from SHRM indicates that the average cost-per-hire in the UK and US ranges from several thousand pounds or dollars upward, depending on role seniority and whether an agency is used. Reducing agency reliance - even for a proportion of hires - through internal sourcing from a talent pool has a meaningful effect on recruitment spend over time. The caveat is that this only works if the database is properly maintained and searchable; an unmaintained database of stale records provides little value.
The cost of not having a database
When candidate data is held in email inboxes, shared drives, or individual spreadsheets, institutional knowledge is lost every time a recruiter leaves the team. A new hire for a role that was filled two years ago may generate 80 applications, many of which overlap significantly with the previous process - but without a searchable database, no one knows. The work is repeated in full. A centralised candidate database makes that prior investment reusable.
How to Structure Your Candidate Database
The practical value of a candidate database depends almost entirely on how well it is structured. A large database of untagged, unsegmented records is difficult to search and easy to neglect. The following areas are worth getting right from the start.
Tagging and Segmentation
Tags are labels applied to candidate profiles that make them findable in future searches. A good tagging taxonomy typically covers several dimensions:
- Skills - specific technical or functional skills (e.g. "Python", "IFRS", "Google Ads")
- Seniority level - entry, mid, senior, lead, director
- Department or function - engineering, finance, sales, operations
- Location or work arrangement - city, remote-eligible, willing to relocate
- Availability status - actively looking, passively open, not available
The key discipline is consistency. If one recruiter tags someone as "Senior Developer" and another uses "Senior Engineer", searches for either term will miss records. Agree your taxonomy before you start tagging and enforce it across the team. Boolean search across tag fields - combining AND, OR, NOT logic - lets recruiters run precise queries across thousands of records in seconds.
Custom Fields and Notes
Beyond tags, structured custom fields capture information that improves search recall and decision-making on re-engagement. Useful fields include: salary expectation range, notice period, preferred work arrangement, and the outcome of any previous interview (e.g. "reached final stage, strong technical skills, narrow loss on culture fit").
Recruiter notes are less structured but equally important. A brief note after each interaction - what was discussed, what the candidate said about their search, what the interviewer's impression was - transforms a record from a name and a CV into a relationship. When you return to that record six months later, those notes make the re-engagement conversation far more natural and credible.
Source Tracking
Recording where each candidate came from is essential for understanding which sourcing channels deliver the most valuable candidates over time. Common source categories include: direct application via your careers page, job board (specify which), LinkedIn (sourced vs. applied), employee referral, recruitment agency, and events or university partnerships.
Source data helps you evaluate channel return on investment. If candidates from employee referrals consistently reach final stages at a higher rate than job board applicants, that is useful information for allocating your sourcing budget - but only if you have tracked source data consistently.
GDPR Compliance for Your Candidate Database
For organisations operating in the UK or EU, GDPR places clear obligations on how candidate data can be collected, stored, and used. A candidate database that is not managed with GDPR in mind is a compliance risk. The following areas are the most important to get right.
Lawful Basis and Retention
For candidates who actively applied for a role, the lawful basis for processing their data during the recruitment process is typically "legitimate interests" or "contract" (taking steps at the request of the data subject prior to entering a contract). The question that arises after the process concludes is how long you can retain their data.
The ICO (Information Commissioner's Office) guidance for UK organisations recommends that retaining unsuccessful candidates' data for approximately six months after the conclusion of a recruitment process is generally reasonable. This allows time to respond to any employment tribunal claims that might arise from the process. After six months, the data should be deleted or the candidate should be asked for fresh consent to remain in your database.
If you want to maintain candidates in an ongoing talent pool beyond this period, you need a separate lawful basis. The two most defensible options are: explicit consent (the candidate ticks a box during application confirming they wish to be considered for future roles, with a clear retention period stated) or legitimate interests (which requires a legitimate interests assessment, or LIA, to be documented). Consent is generally the cleaner approach for ongoing talent pool storage because it is unambiguous and candidate-controlled.
Data Subject Rights
Under GDPR, candidates retain their rights at all times, including after their application has been rejected. These rights include: the right of access (to see what data you hold about them), the right to erasure (to have their data deleted), and the right to restriction (to pause processing while a dispute is resolved).
Your ATS must be capable of actioning these requests promptly. The GDPR requires responses within one month in most cases. This means your candidate database needs a mechanism to locate all data held about a specific individual, export it for subject access requests, and permanently delete it when erasure is requested. Manual processes for this are difficult to scale; an ATS with built-in GDPR workflow tools makes compliance manageable.
Re-engagement and Consent Refreshes
If you want to contact someone who has been in your database for an extended period - particularly if their original consent was tied to a specific recruitment process that has long since concluded - best practice is to re-confirm their interest before reaching out about new roles.
A brief, personalised email asking whether they are open to hearing about relevant opportunities, with a clear opt-out option, achieves two things: it refreshes consent if they respond positively, and it cleans your database of people who have moved on or are no longer interested. Many organisations do this on a 12 to 18-month cycle for their talent pool.
Maintaining Database Quality
A candidate database degrades over time without active maintenance. Contact details change, skills become outdated, and candidates change their availability status. A database full of stale records is not just unhelpful - it can damage your employer brand if you reach out to candidates with irrelevant or poorly timed messages.
Practical maintenance habits that keep a database useful include:
- Quarterly hygiene audits - identify records with no activity in the past 18 months and either update them or remove them
- Prompt record updates after every candidate interaction - add notes, update status, and confirm contact details
- Notifying candidates when you are actively considering them for a new role, rather than contacting them cold with an offer
- Removing duplicate records - the same person may appear under different email addresses or name spellings if they applied multiple times
- Reviewing tags periodically to ensure they reflect current role requirements - a tag taxonomy that made sense two years ago may need updating as the business evolves
Teams that build these habits into their standard post-hire workflow - rather than treating database maintenance as a separate project - tend to find that the database remains genuinely useful over time rather than becoming a neglected archive.
What to Look for in an ATS Candidate Database
Not all ATS candidate database features are equivalent. When evaluating a platform, the following capabilities are the most important to assess:
| Feature | Why it matters |
|---|---|
| Full-text CV search | Search inside CV documents, not just parsed fields - finds skills that CV parsing may have missed |
| Custom tagging and filtering | Flexible taxonomy to segment your talent pool by skills, seniority, location, and more |
| GDPR compliance tools | Retention policy configuration, automated deletion workflows, and data subject request handling |
| Duplicate detection | Prevents the same candidate appearing as multiple records and keeps data clean |
| Bulk import and export | Migrate existing candidate records from spreadsheets or legacy systems; export for audits |
| Activity log and contact history | Full record of every interaction with each candidate - who contacted them, when, and the outcome |
| Job board and email integration | Automatically ingest candidates from sourcing channels so the database grows without manual data entry |
AI-assisted features such as candidate scoring can help surface relevant profiles from large databases more quickly. It is worth noting that in a well-designed ATS, AI scoring is advisory - it highlights candidates that may be worth reviewing, but the hiring decision always rests with the human recruiter or hiring manager. No compliant ATS auto-rejects candidates based on AI assessment alone.
Treegarden's Candidate Database
Treegarden includes a built-in candidate database as a standard feature across all plans (Startup at $299/mo, Growth at $499/mo, and Scale at $899/mo). The database stores full application history, parsed CV data, recruiter notes, and custom tags for every candidate your organisation has interacted with.
You can search across all fields simultaneously - name, email, skills, CV content - and filter by role, pipeline stage, source, date range, or custom tag. Built-in GDPR tools help manage retention policies and data subject requests without requiring manual tracking outside the system. Role-based access controls ensure that hiring managers see only the candidates associated with their assigned roles, while HR managers and administrators have full visibility.
Treegarden's CV parsing extracts structured data automatically on upload, and bulk import supports up to 50 CVs at once - useful for migrating historical candidate records from folders or legacy systems into a searchable format.
Book a demo to see how Treegarden manages your talent pool
Frequently Asked Questions
How long can you keep candidate CVs in your database?
ICO guidance for UK organisations suggests six months after a recruitment process ends is a reasonable retention period for unsuccessful candidates. After that, you should delete the data or ask for fresh consent to keep it. If you want to maintain an ongoing talent pool, include explicit opt-in wording in your application process - for example, asking candidates to confirm they would like to be considered for future roles - and set a maximum retention period, typically 12 to 24 months, with a periodic re-consent email. Always document your retention policy and review it annually.
How do you stay GDPR compliant with a candidate database?
Three steps: (1) Collect only what you need - data minimisation means not asking for date of birth, nationality, or other details you do not need at application stage. (2) Be transparent - your job application privacy notice must explain what you collect, why, how long you keep it, and candidates' rights. (3) Honour data subject requests - if a candidate emails asking to see their data or have it deleted, action this promptly within 30 days under GDPR. An ATS with built-in GDPR tools makes this manageable at scale.
What is the difference between a talent pool and an active candidate pipeline?
A talent pool (or candidate database) holds people you might hire in future - former applicants, referred contacts, sourced candidates who were not right for a specific role but who showed strong potential. An active pipeline is candidates currently progressing through your recruitment process for a specific vacancy. The talent pool is a long-term strategic asset; the pipeline is short-term and role-specific. A good ATS lets you move candidates between the two seamlessly, so when a new vacancy opens you can first check whether anyone in your talent pool is a strong fit before opening a new external search.
How do you re-engage candidates from your talent pool?
Start with personalised outreach - not a generic newsletter, but a message that references the specific role or skills you valued. Reference your previous interaction: for example, noting that you were impressed with their background when they applied for a previous role. Check they are still interested and update their details at the same time. Timing matters: reach out when you have a relevant vacancy, not just to keep in touch with no purpose. If you have a large database, segment by role type or skills so you can target outreach effectively rather than emailing everyone about every role.
Sources
- ICO, Employment practices and data protection: recruitment and selection - guidance on data retention and processing in recruitment contexts
- SHRM Cost-per-Hire Benchmarking Report - national average hiring cost data from survey data of HR professionals
- CIPD Recruitment Factsheet - guidance on recruitment practice including data management and talent pool strategy