GDPR for recruiters: the practical version

Why recruiting data is special

A hiring pipeline is one of the most personal datasets a company holds: CVs, salary expectations, interview notes, sometimes health or family details candidates volunteer without being asked. People hand it over at a vulnerable moment, hoping for a job.

GDPR treats that data accordingly, and so do candidates. Handling it carelessly is not just a legal risk; it is exactly the kind of story that travels. The practical requirements, though, are far more manageable than the acronym suggests.

Know your lawful basis

You need a legal reason to process candidate data. For an active application this is straightforward: processing is necessary to evaluate the candidate for the role they applied to. You do not need a consent checkbox for reading the CV someone sent you.

Consent matters at the edges. Keeping a rejected candidate in your talent pool for future roles is a different purpose than the original application, so ask for it explicitly, and make saying no consequence-free. Sourced candidates who never applied deserve to know where their data came from the first time you contact them.

Retention: decide it, automate it

The most common GDPR failure in recruiting is not malice, it is drift: CVs from four years ago still sitting in a shared drive because nobody owns deletion. Data you no longer need has no lawful basis to stay.

Pick a retention period for unsuccessful candidates, six months is a common and defensible choice in the EU, and write it down. Then automate it. A policy that depends on someone remembering to clean up is not a policy, it is an intention. Your system should delete on schedule without a human in the loop.

Make candidate rights easy, not grudging

Candidates can ask what data you hold, ask for a copy, and ask for deletion. Treat these as product features rather than legal threats. The companies that struggle with rights requests are the ones whose candidate data is scattered across inboxes, spreadsheets, and three tools that do not talk to each other.

If your hiring data lives in one system, an access or deletion request takes minutes. If it takes you weeks of archaeology, that is not a GDPR problem, it is an organisation problem GDPR happens to expose.

Keep data where it belongs

Know where your candidate data physically lives and who processes it on your behalf. If you hire in the EU, EU data residency removes a whole category of questions about international transfers, and your data processing agreements with vendors should name every subprocessor that touches candidate data.

This is also becoming a selling point in reverse: candidates and works councils increasingly ask. Being able to answer "EU servers, here is the list of processors" in one sentence builds more trust than a forty-page privacy policy.

The short checklist

• One system of record for candidate data, not inboxes and spreadsheets
• Lawful basis understood: application processing by default, explicit consent for talent pooling
• A written retention period, enforced automatically
• Access and deletion requests answerable within days, from one place
• Data residency known, subprocessors listed, DPAs signed
• Interview notes written as if the candidate will read them, because they may

None of this requires a legal department. It requires choosing defaults once and letting your tools enforce them. (This is practical guidance, not legal advice; for edge cases, ask a professional.)