The right to erasure in recruiting: a practical workflow
A candidate asked you to delete their data. What Article 17 requires, the one-month deadline, where candidate data hides, and a workflow that actually works.
What the right to erasure actually requires
Article 17 of the GDPR gives a candidate the right to have their personal data erased without undue delay when it is no longer necessary for the purpose it was collected for — and a rejected candidate's data usually stops being necessary the moment the process ends. Under Article 12(3) you must act on the request within one month (extendable by two further months for complex cases, if you tell the candidate in time). The right is not absolute: you may retain the minimum needed to establish or defend legal claims — for recruiting, typically evidence of a fair process inside a discrimination-claim window — but that exception covers that minimum, not the whole file.
Where candidate data actually lives
The reason erasure requests hurt is not the deleting; it is the finding. A single interview process typically leaves personal data in:
- the ATS record — the copy everyone remembers;
- calendar events on every interviewer's account, each carrying the candidate's name and often their email;
- email: invitations, confirmations, reminders, internal threads;
- scheduling tools: booking records, status pages, notes;
- scorecards and feedback, which are the candidate's personal data too, even when written by your interviewers;
- the shadow copies: spreadsheets, exports, Slack messages.
An erasure workflow that only clears the ATS record leaves most of that standing. The first practical step is knowing your map: which systems hold candidate data, and who can delete from each. (Minimizing that map in the first place is the theme of our privacy-safe recruiting guide.)
A workflow that fits inside one month
- Log the request with its date — the clock starts on receipt, not on triage.
- Verify identity proportionately: reply to the address on file rather than demanding documents for a routine request.
- Check the exceptions honestly: if you retain anything (for example, minimal process evidence inside a claim window), write down what and why — and delete the rest.
- Erase across the map: ATS, scheduler, calendars, templates queued to send, and any synced copies. Cancel anything scheduled to go out to the candidate.
- Keep PII-free proof: an erasure log entry saying a deletion happened and when, containing no personal data itself.
- Confirm to the candidate — and then stop emailing them; an erased candidate must also drop out of every future send.
Making it one click instead of six systems
Most of the workflow above is mechanical, which means it can be built into the tooling rather than into someone's checklist. In Cadence, erasure is a single action — available to the recruiter, and to the candidate directly from their private status page. It wipes the candidate record, unsent and queued email, scheduling artifacts, and synced ATS fields together, refuses any later send to the erased candidate at the moment of sending, and keeps the PII-free audit entry that proves the erasure happened. Retention expiry feeds the same pipeline, so candidates who pass your retention period are processed without anyone remembering to run a purge. The architecture behind this is described on the interview scheduling built for GDPR page.
The bar to aim for
A good test of your process: could a new team member execute an erasure request correctly on their first day, inside an afternoon, without asking legal? If the answer is yes — because the systems map is short, the deletion is automated, and the log writes itself — then Article 17 is a routine ticket instead of a fire drill. That is the difference between a policy that reads well and a practice that holds up.