An Applicant Tracking System that keeps every candidate record forever, without a retention date, slowly turns a talent pool into a liability: nobody knows which profiles may still be used, which consent has lapsed and which records should have been deleted months ago. Give every candidate record a retention date, a recorded basis for keeping it — an active application, consent for a talent pool, or another basis your privacy policy names — and a review step before the date passes. No vanity metrics, and no promise that artificial intelligence replaces recruiters.
This matters for recruitment agencies, staffing, secondment, executive search and in-house recruitment. The retention period itself is set by your privacy policy, the General Data Protection Regulation and the advice of your privacy officer or lawyer — not by this article and not by the recruiter’s memory. What the Applicant Tracking System must do is make that period visible and enforceable on every record.
Why candidate records without a retention date become a risk
Retention problems rarely start with bad intent. They start with convenience:
- Rejected candidates stay in the database “just in case”, with no date on which anyone checks whether that is still allowed
- Talent-pool consent was asked once, years ago, and nobody can see whether it still applies
- The same person exists twice, and only one of the two records was ever cleaned up
- CVs and notes sit in attachments and email exports outside the Applicant Tracking System, so deleting the profile does not delete the data
- When a candidate asks what you hold about them, the desk has to search mailboxes and spreadsheets instead of one record
A retention date turns “we should clean the database some day” into a recurring, visible task with an owner.
What a candidate retention date means
Define it clearly in the Applicant Tracking System:
- Retention date — the date on which the record must be reviewed and then extended on a valid basis, anonymised or deleted
- Retention basis — why the record may be kept until then: an active application, recorded consent for a talent pool, an active placement, or another basis named in your privacy policy
- Consent record — when consent was given, for what purpose and through which channel, so it can be shown later
- Named reviewer — the signed-in user who extended, anonymised or deleted the record, consistent with recording who moved the candidate on every stage change
- What it is not — a reminder to call the candidate; that is a next-action date
How to set retention dates automatically in the Applicant Tracking System
Recruiters should not calculate dates by hand. In the Applicant Tracking System:
- Set the retention date automatically when an application closes, based on the exit path: rejected, withdrawn, placed or vacancy closed, using the periods your privacy policy defines
- Ask for talent-pool consent as a separate, recorded step, and only extend the retention date when that consent is actually given
- Keep the candidate source recorded at first application, so you know through which channel the data came in
- Merge duplicate candidates before retention runs, so one person has one retention date instead of two conflicting ones
- Store CVs and notes on the record itself, so anonymising or deleting the record removes the data instead of leaving copies behind
A review queue instead of silent deletion
Show each desk a short queue of records whose retention date falls in the coming weeks. For each one the reviewer chooses: extend on a recorded basis, anonymise, or delete. Do not let records quietly disappear without a trace of the decision, and do not let them quietly stay. Keep an anonymised trace where your policy allows it — the rejection reason or withdrawal reason without the personal data — so reporting on the pipeline still works after the person is gone. Do not invent “compliance scores”; the useful view is simply how many records are overdue for review, per desk.
Where artificial intelligence may help — and where it must not
Artificial intelligence may flag records that look like duplicates, suggest which attachments still contain personal data, or draft the consent-renewal email for a recruiter to check. It must stay secondary. Artificial intelligence does not replace recruiters, does not decide on a legal basis and does not delete or extend a record without a human confirming it. The Applicant Tracking System stores the retention date, the basis, who reviewed it and when.
How this sits next to candidate and client relationships
- The candidate and client relationship records beside the pipeline are only valuable when you are allowed to keep them; retention dates keep that pool trustworthy
- Merging duplicates and retention belong together: one person, one record, one date
- Rejection reasons and withdrawal reasons can survive anonymisation as statistics, so learning does not depend on keeping personal data
A practical week to introduce retention dates
- Ask your privacy officer or lawyer to confirm the retention periods per exit path and the wording of talent-pool consent
- Configure the Applicant Tracking System to set retention dates automatically when an application closes
- Give existing records without a date a review date in batches, starting with the oldest closed applications
- Move CVs and notes that live outside the Applicant Tracking System onto the candidate record
- Agree one weekly moment per desk to work through the retention review queue
That habit is quieter than a yearly clean-up project. It is also what lets you tell a candidate, with confidence, what you hold about them and until when.
Keep only what you may keep — and know why
If your Applicant Tracking System keeps candidate records without a retention date, the database grows while trust in it shrinks. Give every record a retention date, a recorded basis and a named reviewer, and work through a short review queue every week. Keep artificial intelligence as a helper only. Then explore the product or book a demo — we walk through BoldATS retention discipline in your segment.