How to manage applicant data: a GDPR-first playbook
The single most useful thing you can do this afternoon is document the lawful basis for every category of applicant data you hold, then map where that data actually lives. Everything else in applicant data management follows from those two steps.
Your immediate three-step action plan:
- Record your lawful basis. For most recruitment activity, legitimate interests is the correct basis, but it must be supported by a written Legitimate Interests Assessment (LIA), not assumed.
- Map your systems. List every place applicant data sits: your ATS, email, shared drives, spreadsheets, third-party vetting providers. Enable automatic expiry wherever the system allows it.
- Redact before sharing. Before any CV reaches a client, remove direct identifiers and any details that could reveal protected characteristics.
The governing authorities are the Information Commissioner’s Office (ICO) and UK GDPR (the UK’s retained version of the EU General Data Protection Regulation). Both set out clear expectations for recruiters, and the ICO distinguishes between what you must do and what you should do. Treat the “shoulds” as mandatory unless you can document an equally compliant alternative.
Table of Contents
- 1. Start with purpose: what data do you need and why?
- 2. Which applicant data should you actually collect?
- 3. UK legal essentials: GDPR, ICO guidance, LIAs and DPIAs
- 4. Choosing an ATS or CRM that enforces compliance
- 5. Day-to-day database hygiene: keeping your records accurate
- 6. Security controls and incident response for applicant data
- 7. Retention schedules, archiving and secure deletion
- 8. Transparency and candidate rights: privacy notices and SARs
- 9. Templates and checklists you can implement today
- 10. How Securityjobsboard implements GDPR-first applicant-data management
- Key takeaways
- What recruiters who got retention wrong taught me
- Securityjobsboard supports GDPR-compliant hiring for UK security employers
- Useful sources and further reading
- FAQ
1. Start with purpose: what data do you need and why?
Before you configure a single field in your ATS, write down the business reasons you process applicant data. This is not a bureaucratic exercise. It is the foundation of a defensible data map, and without it, an LIA or a Data Protection Impact Assessment (DPIA) is impossible to complete properly.
Define your recruitment purposes first. Common purposes include shortlisting candidates for live roles, maintaining a talent pool for future outreach, conducting pre-employment vetting, and sharing profiles with client organisations. Each purpose needs its own documented lawful basis. Shortlisting and talent-pool outreach typically sit under legitimate interests. Vetting that involves criminal records or health data requires a separate legal condition.
Build a simple data map. A data map does not need to be a complex spreadsheet. A four-column table works well: data category, purpose, lawful basis, and storage location. Walk through every system your team touches: your ATS, email inboxes, shared cloud folders, local drives, and any third-party suppliers such as background-check providers or psychometric-testing platforms.
Pro Tip: Record your LIA in the same document as your data map. The LIA has three parts: the purpose test (is there a legitimate interest?), the necessity test (is processing necessary to achieve it?), and the balancing test (do the candidate’s interests override yours?). Keeping it alongside the data map means you can update both when a new purpose or system is added.
Once the map exists, you have a single source of truth for compliance decisions, SAR responses, and vendor procurement conversations.
2. Which applicant data should you actually collect?
The principle of data minimisation under UK GDPR is straightforward: collect only what you genuinely need for the stated purpose. In practice, many recruitment databases are bloated with fields that were added speculatively and never used.
Standard fields that are defensible to collect:
- Full name, contact details (email, phone), and location
- Right-to-work status and relevant documentation references
- Work history, skills, qualifications, and professional certifications
- Salary expectations (not salary history, which carries discrimination risk)
- Availability and notice period
- Source of application (for pipeline analytics)
Fields to treat with caution or avoid:
- Date of birth (use only where age verification is legally required)
- Precise home address at application stage (town or region is usually sufficient)
- Detailed health information beyond what is strictly necessary for role-specific adjustments
- Photographs, unless the role has a documented operational requirement
Special-category data covers health, disability, ethnicity, religion, sexual orientation, and criminal convictions. You may only collect it when a specific legal condition applies, such as the candidate’s explicit consent or a legal obligation. Pre-employment vetting data is treated as high-risk and must be securely destroyed as soon as the recruitment process concludes.
Redaction workflow before client sharing:
| Step | Action | Reason |
|---|---|---|
| 1 | Remove candidate name and contact details | Prevents direct client contact; protects placement fee |
| 2 | Remove date of birth and address | Reduces discrimination risk |
| 3 | Remove any health or disability references | Special-category data; not the client’s decision |
| 4 | Remove protected-characteristic indicators | Supports bias-free shortlisting |
| 5 | Save redacted version separately | Maintains audit trail of what was shared |
Redacting before sharing is not just a compliance step. It protects your commercial position by preventing clients from bypassing you to contact candidates directly.
3. UK legal essentials: GDPR, ICO guidance, LIAs and DPIAs
UK GDPR applies to any organisation processing personal data in the UK. For recruiters, the practical obligations cluster around four areas: lawful basis, data subject rights, retention, and high-risk processing.
Lawful basis and LIAs. Legitimate interests is generally the most appropriate basis for processing applicant data, but it is not a free pass. The ICO’s three-part LIA test requires you to demonstrate a genuine interest, show that processing is necessary, and confirm that the candidate’s rights do not override that interest. Consent is rarely appropriate in recruitment because the power imbalance between employer and candidate means consent cannot be freely given.
DPIAs for AI-driven tools. The ICO recommends completing a DPIA before procuring any AI-assisted recruitment tool. This covers automated CV screening, scoring algorithms, and any system that makes or significantly influences a hiring decision. The DPIA must assess bias risk, document human oversight mechanisms, and explain to candidates how the logic works.
ICO position on AI in recruitment: “Organisations should complete a DPIA before deploying AI recruitment tools, assess for bias, ensure human oversight of automated decisions, and be able to explain the logic to candidates on request.”
Retention and rights requests. There is a genuine tension in the rules. ICO guidance points towards shorter retention for unsuccessful candidates, while some statutory frameworks require records to be kept for at least one year. The defensible position is to adopt the statutory minimum with documented justification, then apply automatic deletion at that point. Subject Access Requests (SARs) must be responded to within one calendar month. Erasure requests require permanent deletion from all storage locations, including backups.
Practical record-keeping minimum:
- A written LIA for each processing purpose
- A DPIA for any AI or automated decision-making tool
- A retention schedule with documented justification
- A log of SARs received and responded to
- Evidence of staff training on data handling
4. Choosing an ATS or CRM that enforces compliance
Technology does not make you compliant, but the right technology makes compliance far easier to maintain consistently. When evaluating an applicant tracking system (ATS) or candidate relationship management (CRM) platform, treat data-protection features as a procurement requirement, not a nice-to-have.
Feature checklist for a compliance-first ATS:
- Automated retention expiry with configurable timelines
- Role-based access controls so only authorised staff see sensitive records
- Encryption at rest and in transit
- Audit logs showing who accessed, edited, or deleted a record and when
- Built-in redaction tools for CV sharing
- DPIA documentation support or integration with your compliance workflow
- Data export and deletion workflows that cover backups
Vendor questions to ask at procurement:
- Are you the data processor and are we the data controller? Is this confirmed in a Data Processing Agreement?
- Where is data stored, and is it within the UK or an adequacy-approved jurisdiction?
- How do you handle deletion requests, including from backups?
- Can you provide evidence of your own DPIA or security review?
- What is your process if you suffer a breach affecting our data?
When evaluating options, think in categories rather than brand names. Entry-level field apps typically offer basic tracking and limited access controls; mid-market ATS platforms add automation, audit logging, and integrations; enterprise platforms bring advanced AI features, which require their own DPIA before deployment. The applicant tracking system guide for UK security employers on Securityjobsboard covers the practical differences in more detail.
Named platforms worth considering:
- Bullhorn is a widely used mid-market ATS with strong CRM capabilities, configurable retention rules, and audit logging. It suits agencies managing high candidate volumes.
- Oleeo is built specifically for UK-regulated recruitment environments, with GDPR compliance features, diversity monitoring, and structured workflow controls baked in.
- Nimble takes a lighter-touch CRM approach, useful for smaller teams managing talent pools rather than high-volume pipelines. It integrates with email and calendar tools, though its compliance feature set is less deep than dedicated ATS platforms.
For any platform using AI-driven screening, the ICO’s guidance on AI procurement is the starting point for your DPIA. Ask vendors for bias-mitigation evidence and clear contract language on controller/processor responsibilities before signing.
5. Day-to-day database hygiene: keeping your records accurate
A candidate database degrades faster than most recruiters expect. Unstructured entries, duplicate records, and outdated contact details are the primary reasons talent pools lose value. Poor hygiene does not just create compliance risk; it costs you quality candidates.
Recommended hygiene schedule:
- Daily: Parse incoming CVs automatically via your ATS; flag duplicates for review before they are saved.
- Weekly: Review uncontacted records older than 90 days; trigger a re-engagement email or archive flag.
- Monthly: Run a deduplication report; merge or delete duplicate profiles; verify that automated expiry rules are firing correctly.
- Quarterly: Audit segment tags for accuracy; review opt-out lists; check that third-party integrations are not re-importing deleted records.
Database health metrics to track:
| Metric | What it measures | Target |
|---|---|---|
| Duplicate rate | Percentage of records with a matching email or phone | Below 5% |
| Stale record rate | Records with no activity in 12+ months | Below 20% |
| Opt-out rate | Candidates who have withdrawn consent for outreach | Monitor for upward trend |
| Re-engagement response rate | Replies to reactivation emails | Benchmark against previous campaigns |
Automation reduces the manual burden significantly. CV parsing, auto-tagging by skill or location, and expiry scheduling all reduce data decay without requiring daily manual intervention. Personalised outreach to segmented groups achieves 3–5x higher response rates than generic bulk emails, so the effort of maintaining clean segments pays back in pipeline quality.
The candidate pipeline concept is useful here: think of your database not as a static archive but as a live pipeline with stages, and apply hygiene rules at each stage transition.
6. Security controls and incident response for applicant data
Recruitment data is a high-value target. Common breaches involve misconfigured cloud storage, not sophisticated attacks. UK recruiters must be ready to notify the ICO within 72 hours of becoming aware of a reportable breach, which means having a response plan before an incident happens.
Core controls to implement now:
- Encryption at rest and in transit for all candidate records
- Role-based access: only the people who need a record for their current task should be able to see it
- Two-factor authentication on every system that holds personal data
- Audit logs that record access, edits, and deletions with timestamps and user IDs
- A named data protection lead who owns the incident response process
Incident response checklist:
- Detect: Identify the breach through monitoring, a staff report, or a vendor notification.
- Contain: Revoke access, isolate affected systems, and preserve evidence.
- Assess: Determine what data was exposed, how many candidates are affected, and the likely risk to individuals.
- Notify the ICO: If the breach is likely to result in a risk to individuals’ rights and freedoms, notify within 72 hours. Document your reasoning if you decide not to notify.
- Inform affected candidates: Where the risk is high, notify individuals without undue delay.
- Remediate: Fix the root cause, update access controls, and document the full incident timeline.
Pro Tip: The most common misconfiguration is a shared cloud folder with “anyone with the link” access enabled. Audit every shared folder and cloud storage bucket quarterly, and set default sharing to “restricted” on any platform that stores candidate data.
Reducing your breach surface is as important as having a response plan. Apply least-privilege access, redact CVs before sharing, and minimise the number of backup copies that retain personal data.
7. Retention schedules, archiving and secure deletion
How long you keep applicant data is one of the most practically contested areas of UK recruitment compliance. The ICO leans towards shorter retention for unsuccessful candidates; some statutory frameworks require at least one year. The defensible approach is to adopt the statutory minimum, document your justification, and then apply automatic deletion at that point.
Implementing automated expiry:
- Set a default retention period in your ATS (commonly 12 months for unsuccessful candidates, longer for placed candidates where employment records apply).
- Configure automated expiry notifications: send candidates a re-consent or deletion notice 30 days before expiry.
- Log every deletion action with a timestamp, the record ID, and the reason.
- Verify that deletion cascades to integrated systems: email archives, cloud storage, and third-party processors.
Secure disposal checklist:
- Confirm deletion from the primary ATS record
- Confirm deletion from email threads containing candidate data
- Confirm deletion from shared drives and cloud folders
- Notify third-party processors (vetting providers, psychometric platforms) to delete their copies
- Retain only the deletion log, not the personal data itself
The right to erasure under UK GDPR requires permanent deletion from all storage locations, including backups and secondary cloud environments. This is not optional and it is not satisfied by archiving. Budget time for deletion verification, and keep an auditable trail of erasure actions.
For automated expiry design, a multi-year window is a common compliance-first default for talent-pool records, with shorter windows for vetting data.
8. Transparency and candidate rights: privacy notices and SARs
Candidates have a right to know what you do with their data before you do it. A privacy notice is not a legal formality to bury in a footer. It is the mechanism by which you demonstrate transparency, and the ICO will look at it first in any complaint investigation.
What your recruitment privacy notice must cover:
- Who is the data controller and how to contact them
- What data you collect and why (purposes and lawful bases)
- How long you keep it
- Whether you use automated decision-making or AI tools, and how the logic works
- Who you share data with (clients, vetting providers, cloud platforms)
- How candidates can exercise their rights (access, erasure, objection, portability)
Handling SARs and erasure requests step by step:
- Log the request on receipt, noting the date (the one-month clock starts immediately).
- Verify the requester’s identity before disclosing anything.
- Search all systems: ATS, email, shared drives, third-party processors, and backups.
- Compile the response or confirm deletion across all locations.
- Respond within one calendar month; extend by two months only for complex or numerous requests, and notify the candidate of the extension within the first month.
For talent-pool outreach, always include a clear opt-out mechanism in every communication. Personalised, segmented outreach reduces opt-out rates compared with generic bulk emails, because candidates receive messages that are actually relevant to them.
Where you use AI-driven screening, tell candidates in the privacy notice. Explain what the tool does, that a human reviews the output, and how they can request a manual review. This is not just good practice; the ICO expects it.
9. Templates and checklists you can implement today
The gap between knowing the rules and actually following them is usually a missing template or an unclear process owner. The items below are designed to be copied into your internal documentation immediately.
One-page implementation checklist:
- [ ] Data map completed and signed off by a named data owner
- [ ] LIA documented for each processing purpose
- [ ] DPIA completed for any AI or automated screening tool
- [ ] Retention schedule set and automated expiry configured in ATS
- [ ] Redaction workflow documented and staff trained
- [ ] Privacy notice published and linked from application forms
- [ ] SAR and erasure response process documented with named owner
- [ ] Supplier Data Processing Agreements in place for all third parties
- [ ] Incident response plan documented and tested
- [ ] Staff training completed and logged
Template documents to build or adapt:
| Template | Key sections to include |
|---|---|
| Simple LIA outline | Purpose, necessity, balancing test, sign-off date |
| DPIA checklist | Processing description, necessity, risks, mitigations, DPO consultation |
| CV redaction checklist | Fields to remove, who redacts, version control |
| Data map CSV | Data category, purpose, lawful basis, storage location, retention period |
| Vendor question list | Controller/processor split, data residency, deletion workflow, security evidence |
Vendor procurement note: Once a supplier provides assurances (data residency, deletion timelines, security certifications), record them in the contract or a signed addendum. Verbal assurances are not enforceable. If a supplier cannot provide a Data Processing Agreement, do not use them.
For practical guidance on screening applicants efficiently while maintaining these controls, the process of combining automation with human review is covered in detail elsewhere.
10. How Securityjobsboard implements GDPR-first applicant-data management
A useful way to see these principles in practice is to look at how a UK niche job board builds compliance into its core workflow rather than bolting it on afterwards.
Securityjobsboard, which operates within the UK security sector and holds BSIA affiliation, integrates several of the controls described in this article directly into its employer-facing tools. The applicant tracker includes role-based access controls so that only authorised team members can view candidate profiles. Candidate data is handled in line with UK GDPR, with privacy notices accessible at the point of application. The platform’s design reflects the principle that compliance and candidate experience are not in tension: a clear, transparent process builds candidate trust and improves application rates.
The BSIA affiliation adds an additional layer of accountability. Employers using the platform operate within a sector that already requires rigorous vetting and data handling, so the compliance infrastructure is built to match those standards rather than the minimum statutory floor.
Pro Tip: The most effective way to balance compliance with candidate experience is to make your privacy notice part of the application journey, not a separate legal document. A two-sentence plain-English summary at the top of the application form (“We’ll keep your details for 12 months. You can ask us to delete them at any time at [email].”) does more for trust than a 2,000-word policy buried in a footer.
For employers in the security sector, the GDPR compliance benefits of a structured approach extend beyond avoiding fines: they include faster hiring, better candidate relationships, and a defensible position if a complaint is ever raised.
Key takeaways
Effective applicant data management requires documenting lawful bases, automating retention expiry, redacting CVs before client sharing, completing DPIAs for AI tools, and maintaining audit logs across every system that holds candidate data.
| Point | Details |
|---|---|
| Record lawful bases first | Document an LIA for each processing purpose before collecting or using applicant data. |
| Automate expiry | Configure your ATS to delete or archive records at the statutory minimum (typically 12 months for unsuccessful candidates). |
| Redact before sharing | Remove names, contact details, and protected-characteristic indicators before sending CVs to clients. |
| Run DPIAs for AI tools | Complete a DPIA at procurement stage for any AI-driven screening or automated decision-making system. |
| Securityjobsboard | The platform’s applicant tracker and GDPR-first design give UK security employers a compliant, audit-ready workflow from day one. |
What recruiters who got retention wrong taught me
The most instructive compliance failures in recruitment are rarely dramatic. They are quiet accumulations: a shared drive that nobody audited for three years, a talent pool that kept growing because nobody set an expiry rule, a vetting report that sat in an email inbox long after the candidate withdrew.
Consider a scenario that plays out regularly in mid-sized agencies. A candidate submits a SAR. The recruiter searches the ATS and finds the record. But the candidate also applied two years earlier via a different email address, and that record sits in a separate spreadsheet on a shared drive. The vetting report from the first application is still in an email thread. None of it was deleted because nobody owned the deletion process. The response is late, incomplete, and the ICO complaint follows.
The corrective actions are not complicated. Automation catches what manual processes miss: set expiry rules, configure deletion cascades to email and cloud storage, and assign a named data owner who is accountable for the quarterly audit. Redaction and training close the remaining gaps. The teams that handle this well are not the ones with the most sophisticated technology. They are the ones who wrote the process down and trained everyone on it.
The harder lesson is that retention policies only work if they are enforced automatically. A policy that relies on a recruiter remembering to delete a record is not a policy. It is a wish. The moment you accept that, the solution becomes obvious: configure the system to do it, log that it happened, and verify the log quarterly.
Securityjobsboard supports GDPR-compliant hiring for UK security employers
Managing applicant data compliantly takes real infrastructure: a platform that handles access controls, candidate privacy, and audit trails without adding hours of admin to every hire.
Securityjobsboard is built specifically for UK security sector recruitment, with employer tools designed around the compliance requirements described in this article. The employer dashboard gives hiring managers a structured way to manage applicants, with candidate privacy features and BSIA-affiliated credibility that candidates in the sector recognise and trust. The platform handles the operational side of applicant data so your team can focus on making the right hire rather than managing spreadsheets.
For employers ready to move from ad-hoc data handling to a structured, compliant workflow, visit the Securityjobsboard employer pages to see the full range of tools and get support from the team.
Useful sources and further reading
The sources below are the primary references for the guidance in this article. Use them when completing your own LIA, DPIA, or retention schedule.
- ICO — Recruitment and selection guidance: ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/recruitment-and-selection/ — the definitive UK reference for lawful basis, retention, and candidate rights in recruitment.
- ICO — Pre-employment vetting: ico.org.uk — pre-employment vetting of candidates — specific guidance on handling high-risk vetting data and secure disposal.
- ICO — AI in recruitment: ico.org.uk — thinking of using AI to assist recruitment? — DPIA requirements and bias-mitigation expectations for AI-driven hiring tools.
- Securityjobsboard — Protect candidate data in recruitment: securityjobsboard.co.uk/blogs/protect-candidate-data-recruitment-gdpr-guide-2026/ — practical operational steps for UK recruiters.
- Securityjobsboard — Job seeker privacy guide: securityjobsboard.co.uk/blogs/job-seeker-privacy-in-the-uk-your-2026-guide/ — useful for understanding the candidate perspective on AI-driven hiring and privacy notices.
When completing an LIA, use the ICO’s recruitment and selection guidance as your primary reference for the balancing test. When completing a DPIA for an AI tool, the ICO’s AI-in-recruitment blog post sets out exactly what the ICO expects to see documented.
FAQ
What is applicant data under UK GDPR?
Applicant data is any personal information collected during a recruitment process, including CVs, contact details, interview notes, assessment results, and vetting records. Under UK GDPR, it must be processed lawfully, kept accurate, and deleted when no longer needed.
What lawful basis applies to processing applicant data?
Legitimate interests is typically the most appropriate lawful basis for recruitment activity, but it must be supported by a documented LIA. Consent is rarely suitable because the power imbalance in recruitment means it cannot be freely given.
How long should you keep applicant data for unsuccessful candidates?
The defensible position is to retain records for the statutory minimum (at least one year where applicable), document your justification, and then apply automatic deletion. ICO guidance favours shorter retention; the key is to set a fixed period and enforce it automatically.
What is the 70/30 rule in recruiting?
The 70/30 rule is a general guideline suggesting recruiters spend most of their time on active sourcing versus administrative tasks. It is not a statutory or ICO requirement, and definitions vary between organisations.
What is the 7-second rule for CVs?
The 7-second rule refers to research suggesting that recruiters spend an average of around seven seconds on an initial CV scan before deciding whether to read further. It underlines the importance of clear formatting and relevant information at the top of a candidate’s profile.
