Most recruitment processing does not rely on consent. Consent is difficult to make freely given in an employment context and can be withdrawn at any time, so legitimate interests or the steps-prior-to-contract basis usually fit better — with consent reserved for genuinely optional things like joining a talent pool.
- Consent is fragile in recruitment: withdrawable, and hard to call freely given given the power imbalance.
- Decide a retention period per purpose, document the reason, and delete on schedule — "in case something comes up" is not a purpose.
- A candidate’s right of access covers interview notes and scores, not just their application form.
- Solely-automated decisions with significant effects are restricted; meaningful human involvement is the usual answer.
- Special-category data — health, ethnicity, biometrics — needs an additional condition and should stay out of the evaluation path entirely.
This is general information, not legal advice. Data-protection analysis is fact-specific and supervisory-authority guidance evolves. Take advice on your own processing.
Mistake 1: relying on consent
The instinct is that consent is the safest, most respectful basis. In recruitment it is usually the weakest, for two reasons.
It is hard to call freely given. Consent must be freely given, and a candidate who wants a job from you is not in a position of free choice. Where there is a meaningful imbalance of power, consent is a shaky foundation.
It is withdrawable at any time. If your processing rests on consent and a candidate withdraws it halfway through, you are obliged to stop — including, potentially, stopping the process you were both engaged in.
The bases that generally fit recruitment better:
| Processing | Typical basis |
|---|---|
| Assessing an application for a role the person applied to | Steps prior to entering a contract, or legitimate interests |
| Keeping an unsuccessful application for a defined period to defend a potential claim | Legitimate interests, or legal obligation where one applies |
| Right-to-work and pre-employment checks | Legal obligation |
| Holding someone in a talent pool for future roles | Consent — this one genuinely is optional |
| Diversity monitoring statistics | Usually consent, with an additional condition for special-category data |
Note the shape: consent belongs where the candidate has a real, cost-free choice. That is exactly the talent-pool row, and almost nothing else.
If you use legitimate interests, do the balancing exercise and write it down. The documentation is part of the basis, not an optional extra.
Mistake 2: keeping everything forever
"We might have a role for them later" is a hope, not a purpose. Storage limitation requires that you keep personal data no longer than necessary for the purpose you identified.
There is no universal number. What is required is a decision, per purpose, with a reason:
- Live process — until the role is filled, plus a short wrap-up window.
- Unsuccessful applicants — a defined period linked to the limitation period for a potential claim in your jurisdiction. Take local advice on the length.
- Talent pool — a defined period on consent, with a genuine re-consent or deletion point.
- Assessment results — as long as they are meaningful. A skills score has a natural shelf life; keeping a five-year-old result is neither useful nor defensible.
Then enforce it in the system. A retention policy nobody automated is a document describing what you wish happened. The test is simple: can you show that a candidate who applied on a given date has been deleted on schedule, without someone remembering to do it?
Mistake 3: forgetting that notes are personal data
The right of access covers personal data about the individual — which generally includes interviewer notes, scorecards, assessment results and internal comments about them, subject to limited exemptions such as other people's personal data.
Two consequences worth internalising:
Write notes as if the candidate will read them. Because they might. This is also a quality improvement: "weak on system design — could not distinguish mitigation from root cause" is both disclosable and useful, whereas "not a fit, odd vibe" is neither.
Keep the notes somewhere you can find them. A DSAR is a deadline. If interview feedback lives in four Slack DMs, a shared doc and someone's notebook, you cannot answer it. Centralise scoring in the system of record.
Mistake 4: automated decisions without a real human
Decisions based solely on automated processing that produce legal effects or similarly significantly affect a person are restricted. Rejecting a job application is capable of being exactly that kind of decision.
The usual answer is genuine human involvement — but "genuine" is the operative word, and a rubber-stamp does not qualify. A reviewer with 200 candidates and no time is not making a decision; they are transmitting one. The mechanics of getting this right are in what "meaningful human oversight" actually requires, and the overlapping AI Act obligations in the EU AI Act and hiring.
Mistake 5: special-category data drifting into the evaluation
Health data, racial or ethnic origin, religious belief, biometric data used for identification — these need a lawful basis and an additional condition, and they should not be anywhere near your evaluation surface.
Three ways they arrive by accident:
- Diversity monitoring bolted onto the application form, so the data sits alongside the assessment where reviewers can see it. Keep it in a separate, voluntary channel, aggregated, and structurally unavailable to anyone scoring.
- Accommodation requests processed in the same thread as evaluation. Handle them on a separate path and record only what is operationally needed.
- Biometric or video analysis in assessment tooling. Facial or voice analysis may involve special-category processing and carries additional restrictions in some jurisdictions. See why webcam proctoring is the wrong fix.
A short list of what to actually have
- A record of processing covering recruitment, with purposes and bases.
- A candidate privacy notice that a human can read, given at the point of collection.
- Documented legitimate-interests assessments where you rely on that basis.
- Retention periods per purpose, automated, with evidence of execution.
- A DSAR route that can actually reach interview notes and scores within the deadline.
- Sub-processor transparency — who else touches candidate data, and on what terms.
- Transfer mechanisms for any data leaving the EEA, plus residency options where required.
- Special-category data isolated from the evaluation path by design, not by instruction.
- A deletion path that genuinely deletes, including from backups on a defined cycle.
How CalHire is built for this
Several of these are structural in the platform rather than procedural:
- Data minimisation by design. The evaluation surface holds verified skills and scores. Identity is stripped at a hard architectural boundary before any model is involved, and there is no résumé stored as the record of a candidate — an uploaded résumé only pre-fills declared skills.
- Per-region residency. Data can be pinned to the EU, India or the UAE.
- Verifiable erasure. DSAR and deletion flows with configurable retention, and erasure you can evidence rather than assert.
- Consented, per-employer identity reveal. A candidate's real identity unlocks for one employer, at an allowed stage, with their consent, recorded in an immutable ledger. Disclosure is an event with a record, not a default state.
- Sub-processor transparency published at /legal/sub-processors.
- Every decision logged and attributed to the human who made it, in a tamper-evident audit trail.
Our privacy policy is at /legal/privacy and the security posture in the trust center.
The pattern in all five mistakes is the same: teams treat data protection as paperwork applied after the process is designed. It is cheaper and far more defensible as a constraint on the design — decide what the evaluation genuinely needs to see, and then most of the compliance problem stops existing.
Frequently asked questions
- Do we need consent to process job applications?
- Usually not, and relying on it often makes things worse. Consent must be freely given, which is difficult to establish where the person wants a job from you, and it can be withdrawn at any moment — potentially mid-process. Legitimate interests, or processing necessary for steps prior to entering a contract, generally fit recruitment better. Reserve consent for genuinely optional processing such as keeping someone in a talent pool.
- How long can we keep candidate data?
- For as long as necessary for the purpose you identified, and no longer. There is no universal number in the GDPR. Set a period per purpose — one for the live process, one for defending a potential claim, one for a talent pool held on consent — document why, and enforce it automatically. An unenforced policy is not a policy.
- Do candidates have a right to see interview notes?
- The right of access covers personal data about them, which generally includes interviewer notes, scores and assessment results, subject to limited exemptions such as third-party personal data. The practical consequence is that notes should be written as if the candidate will read them — which also happens to improve them.
- Can we make hiring decisions automatically?
- Decisions based solely on automated processing that produce legal effects or otherwise significantly affect someone are restricted, and rejecting a job application is capable of being such a decision. The usual route is genuine human involvement in the decision — which has to be substantive rather than a formality. See our piece on meaningful human oversight.
- Does GDPR apply if we are not in the EU?
- It can. The territorial scope extends to processing related to offering goods or services to, or monitoring the behaviour of, people in the EU. A company outside the EU recruiting for EU-based roles should assume it is in scope and take advice.