Compliance · July 18, 2026 · 9 min read

GDPR for hiring: candidate data, consent and erasure

GDPR for hiring: what candidate data rules require on lawful basis, consent and minimisation, and how to honour erasure while keeping an audit trail.

← Part of Compliance-First Hiring AI: LL144 and the EU AI Act

Every application you receive is a pile of personal data you are now legally responsible for, and under the GDPR candidate data rules that responsibility comes with candidate rights most hiring teams underestimate and penalties that climb into the millions for getting it wrong. This matters because hiring collects some of the most sensitive information an organisation ever touches — identity, employment history, sometimes biometric or proctoring data — and does so from people who cannot easily walk away. This guide is for the talent leader who wants an AI-native skills assessment platform that respects those rights by design, and it is a deep dive from our wider guide to compliance-first hiring AI.

The obligations that bite in hiring

GDPR is built on a set of principles — lawfulness, fairness and transparency, purpose limitation, minimisation, accuracy, storage limitation, integrity and accountability. In hiring, four of these turn into concrete, recurring decisions that a recruiter or platform has to get right every time a candidate applies.

• A lawful basis for processing, chosen deliberately, plus clear notice to the candidate about what you collect and why
• Data minimisation — collect what the decision needs, not everything you could ask for
• Separate, explicit consent for higher-intrusion steps such as proctoring, kept apart from the basic application
• Candidate rights: access, correction and erasure, handled on request within the required timeframe

Each of these is easier to honour when the assessment is designed around the decision it supports. If you only collect the signals a role genuinely requires — the approach behind a skills-based hiring process — minimisation is close to automatic, because there is simply less data lying around to govern, secure and eventually delete.

Choosing a lawful basis you can defend

The instinct is to reach for consent, because it feels safe. In recruitment it is often the weakest option. Consent under GDPR must be freely given, specific, informed and unambiguous, and it must be as easy to withdraw as to give. A candidate hoping for a job rarely feels free to say no to an employer, which undermines the 'freely given' test and leaves the basis fragile.

Most core hiring activity is better grounded in legitimate interests or in the steps necessary to take before entering a contract, with a documented balancing test where legitimate interests is used. Consent is then reserved for the genuinely optional, higher-intrusion measures — proctoring being the obvious one — where a candidate really can decline without losing the chance to be assessed. Picking the basis per processing step, rather than defaulting to a single blanket consent, is what makes the whole model hold up under scrutiny.

Notice and purpose limitation

Whatever basis you choose, candidates must be told, in clear language, what you collect, why, how long you keep it, and who sees it. Purpose limitation then holds you to that stated purpose: data gathered to assess a candidate for one role cannot quietly become a marketing list or a permanent talent-pool record without a fresh basis and fresh notice. In hiring this is where teams drift — a CV submitted for one job lingers in an applicant-tracking system for years, its original purpose long expired. A retention schedule that actually deletes on time is the unglamorous backbone of the whole regime.

Special-category and biometric data

Some data carries heightened protection: information revealing racial or ethnic origin, health, or biometric data used to identify a person, among other categories. Hiring teams stumble into this more often than they expect. A proctoring system that analyses a candidate's face, or an accessibility accommodation that reveals a disability, can pull you into special-category territory, where processing is prohibited unless a specific condition applies and the safeguards are correspondingly stricter.

The safe instinct is to avoid collecting special-category data unless you have a clear, documented reason and a valid condition for doing so. Where proctoring is genuinely necessary, treat it as the intrusive measure it is: separate consent, a completed impact assessment, tight retention, and a plainly explained purpose. The alternative — sweeping up sensitive data because a tool happens to capture it — is exactly the pattern regulators single out. Designing assessments that measure skill through work rather than surveillance, as an AI Sandbox work-sample does, keeps most of this risk off the table entirely.

Two clauses that bite hardest

Beyond the everyday principles, two provisions shape how an AI-native assessment can be built at all. The first is Article 22. It gives candidates the right not to be subject to a decision based solely on automated processing where it produces legal or similarly significant effects — and a hiring rejection generally clears that bar. This is precisely why a meaningful human-in-the-loop review is not optional for consequential hiring decisions. Candidates also gain the right to obtain human intervention, to express their view, and to contest the outcome.

The second is the expectation of a Data Protection Impact Assessment. Where you deploy intrusive measures such as proctoring, or evaluate people at scale, a DPIA is the expected step, not a nice-to-have. It forces you to justify the intrusion and document the safeguards before you collect a single frame of video. Done properly it is also your best evidence, later, that you took the risk seriously — the same instinct that makes an adverse-impact analysis worth running before you rely on a selection method rather than after a complaint.

Article 22 in practice

The trap with Article 22 is treating a human step as sufficient when it is merely present. A reviewer who rubber-stamps a machine's ranking has not really been in the loop; the decision was still, in substance, automated. Meaningful review means the person can understand the basis for the result, has the authority and information to change it, and actually exercises judgement. Building the workflow so that overriding the machine is normal — the same discipline that keeps AI-generated assessments honest — is what turns a legal requirement into a real safeguard.

Erasure without amnesia

Article 17 gives candidates a right to erasure — often called the right to be forgotten. In hiring it collides with another duty: keeping enough of a record to show that a decision was made fairly, without discrimination, and in line with your own process. Delete everything and you have honoured one obligation while destroying the evidence you need for the other; keep everything and you have ignored the erasure request. Teams often treat this as an unavoidable tension.

It is not, if the data is stored with erasure in mind. The answer is to separate the personal content that identifies the candidate from the anonymised record that a decision was made and a process was followed. Remove the former on request; retain the latter. The deletion is real, because the individual can no longer be identified from what remains. The audit trail survives, because the fact of a fair, consistent process does not depend on knowing whose application it was. The two obligations only fight each other when personal and audit data are stored as a single inseparable blob.

Access and portability requests

Erasure is not the only right that turns up in an inbox. Candidates can ask for access to the data you hold on them, ask that inaccuracies be corrected, and in some cases ask for their data in a portable form. A subject access request over a hiring decision is a common flashpoint: the candidate wants to know what was recorded and how the outcome was reached. If your records are scattered across email threads, spreadsheets and a proctoring tool, answering within the statutory window becomes a scramble.

The teams that handle these calmly are the ones whose data lives in one place with a clear structure, so an access request is a query rather than an archaeology project. That same structure is what makes a fair-process argument possible when a rejected candidate — or a regulator — asks how the candidate evaluation was conducted. Being able to answer quickly is not just compliance hygiene; it is a signal that the process was consistent enough to withstand the question.

Vendors, processors and shared responsibility

Most hiring teams do not build their own assessment stack; they use tools. That does not offload the obligation. As the employer deciding why and how candidate data is processed, you are typically the controller, and the vendor running the tool on your behalf is usually a processor acting on your instructions. The controller carries the accountability, which means the choice of vendor is itself a compliance decision. A written data-processing agreement, clarity on where data lives, and confidence that the processor can support access and erasure requests are not optional extras.

The uncomfortable questions to ask a vendor are the useful ones. Where is candidate data stored, and for how long? Can it delete an individual on request while preserving anonymised records? Does it log reviewer actions in a form you could hand to a regulator? If a vendor cannot answer these cleanly, the burden lands back on you at the worst possible moment — during a breach, an audit, or a subject access request. Choosing a compliance-first tool means choosing one where these answers are built into the product rather than promised in a sales call.

Building for the rights, not around them

The through-line across lawful basis, consent, Article 22 and erasure is that GDPR rewards systems designed for candidate rights from the start and punishes ones that treat privacy as a bolt-on. Minimise what you collect, choose a basis you can defend, keep a human genuinely accountable for consequential decisions, and store data so that identity and evidence can be pulled apart on request. Every one of those choices is easier to make at design time than to retrofit under the pressure of a request or a complaint.

There is a quiet bonus here worth naming. The same practices that satisfy GDPR — minimisation, a clear basis, a human in the loop, a clean audit trail — also make your hiring fairer and more defensible on their own terms. Collecting less noise sharpens the signal you evaluate on; a logged, reviewable decision is easier to defend against a discrimination claim; and a candidate who is told the truth about how they will be assessed arrives more willing to engage. Privacy discipline and good hiring turn out to point the same way, which is also why it dovetails with the work of reducing bias in hiring.

That is the same posture the EU AI Act demands for high-risk hiring systems, and the two regimes reinforce each other: keep a person in the loop, keep a defensible record, collect only what you need. A compliance-first design treats those as architecture, not afterthoughts — see how consent, review and audit logging fit together in a live demo.