Refreshing stale candidate data without breaking GDPR

Refreshing stale candidate data without breaking GDPR is mostly a question of sequence: the compliance checks run before the enrichment, not after it. Confirm each profile is still inside its retention window and has a live lawful basis, screen the batch against your suppression and opt-out lists, enrich only the records that survive, document why you did it, and tell candidates where the new data came from within a month. Teams that enrich first and tidy up later end up holding fresh, accurate data on people they had no right to process, which is a worse position than the stale database they started with.

Why is bulk enrichment riskier than fresh applications?

When someone applies, the data comes from them, the purpose is obvious, and the lawful basis is at its strongest. None of that holds for a profile untouched for three years. The candidate may have opted out through a channel that never synced back, sent a deletion request that was honoured in your email tool but not your database, or simply aged past the window your privacy notice promised.

Talent rediscovery is still one of the highest-leverage sourcing moves available, which is exactly why the legal mechanics deserve their own playbook. A bulk enrichment run takes whatever per-record doubt exists in your database and multiplies it across thousands of profiles in one afternoon. The answer is not to avoid enrichment; it is to put a gate in front of every step.

Step 1: write down the purpose and lawful basis first

Before any record is touched, document why this batch exists. For most teams the realistic basis for re-engaging past applicants is legitimate interests, which means writing a short legitimate interests assessment: what you want to achieve, why enrichment is necessary, and why candidates’ rights and reasonable expectations do not outweigh it. Date it and store it where an auditor could find it without your help.

Purpose limitation cuts both ways here. “We might need this data someday” is not a purpose; “re-engage past applicants for our open engineering roles this quarter” is. And if the profiles were originally stored on consent, lapsed consent is not repaired by switching to legitimate interests after the fact; the boundary between the two bases is covered in do you need consent to store a CV.

Step 2: gate the batch on retention before any identifier leaves your ATS

A profile past its retention window has one compliant destination: deletion or anonymisation. Enriching it instead is processing without a basis, and the refresh does not restart the clock, because retention runs against your stated purpose, not against how recently you touched the row.

So the second gate is mechanical: run the batch through your retention filter and delete everything that has expired. Expect to lose a meaningful slice here, and treat that as the system working. If your windows are undefined or aspirational, fix that first; how long to keep CVs walks through setting defensible periods.

Step 3: make the suppression list authoritative at every hop

Opt-outs and erasure requests are where refresh projects most often go wrong, because the list gets applied once at the start and then forgotten. It needs to be authoritative at three separate points.

• Before the vendor. Anyone on the suppression list is excluded before their identifiers leave your system. Sending a suppressed person’s email to a third party for matching is itself processing they objected to.
• After the vendor. Enrichment returns new email addresses, aliases and merged identities. Re-screen the results, because a new identifier can match a person who opted out under an old one.
• Before outreach. People keep opting out while your project runs. The final check happens at send time, not at planning time.

There is a subtler trap in the merge step: if a returned record matches someone who exercised their right to erasure, naive import logic silently resurrects a profile you were legally required to destroy. Deduplication must check the suppression and deletion registers before creating or updating anything; honoring candidate opt-outs across channels covers keeping that single authoritative record across email, phone and messaging.

Step 4: enrich the survivors, minimally, through a vetted vendor

Data minimisation applies to what you ask for, not just what you store. If the purpose is re-engagement for specific roles, you need current employer, title and a working contact route. You do not need household composition, inferred salary or a scraped social graph.

The vendor needs three things checked before the first API call: a signed data processing agreement, a credible answer about provenance (where each field actually comes from), and a lawful transfer mechanism if any processing happens outside the EU. Provenance is the one teams skip and regret, because step 5 requires you to tell candidates where the data came from. Refuse special category data outright, and treat social media sourced fields with particular suspicion: lawfully accessible is not the same as lawfully reusable for recruitment.

Step 5: tell candidates where the data came from

GDPR Article 14 applies whenever personal data is collected from a source other than the person it describes. You owe the candidate a notice stating what you obtained, from which source, for what purpose, on what basis, and how to object or request deletion, delivered within one month or at first contact, whichever comes first. This is the most-skipped step in the entire workflow, and the easiest for a regulator to verify after a complaint.

In practice the notice folds naturally into honest re-engagement outreach: you applied with us in 2024, we have refreshed your details from a licensed data provider, here is the role we think fits, here is how to object or be deleted entirely. Candidates respond better to that candour than to a message pretending the relationship never lapsed. It doubles as a self-test: if you would be embarrassed to send the notice, the balancing assessment from step 1 has already failed.

What does the gated workflow look like end to end?

Step	Action	Compliance gate	If the gate fails
1	Define purpose, choose lawful basis	Assessment written, dated, stored	Stop: no basis, no batch
2	Filter the batch by retention	Profile inside its stated window	Delete or anonymise, never enrich
3	Screen against suppression and erasure lists	No match on any identifier, at every hop	Drop the record permanently
4	Send minimal fields to a vetted vendor	DPA signed, provenance known, EU transfer lawful	Change vendor or skip enrichment
5	Merge results and notify candidates	Article 14 notice within one month	Hold all outreach until notice is sent

Every gate either shrinks the batch or stops it. That is by design: a refresh run where nothing got deleted or excluded is not a clean database, it is a workflow whose gates are not wired to anything.

Where does Recruitifly fit?

Recruitifly is built in the EU with these gates as platform features rather than spreadsheet discipline: retention windows, consent tracking, deletion requests and suppression lists live inside the ATS, on EU data residency. The assistant, Fly, can search the talent pool and assemble the candidate batch for you, and because every write is propose-then-confirm, nothing is bulk-updated, merged or messaged until a recruiter has reviewed exactly what will change. That is the correct design for bulk work, not a constraint: a refresh run is precisely where unsupervised automation turns one bad assumption into thousands of violations. Teams with heavier obligations can add the Compliance Engine on top.

The honest footnote: we are in private beta, and no tool replaces the assessment you write in step 1. If a lawful refresh of your talent pool is on the roadmap, talk to us and bring your retention policy; the workflow above is exactly the conversation we want to have.