GDPR right to erasure for HR records: how to delete employee data and prove it

An erasure request from a former employee and a legal retention obligation usually point in opposite directions. You have to resolve that conflict record by record, and you have to be able to show your reasoning later.

The GDPR gives individuals the right to have their personal data erased. HR holds some of the most sensitive personal data in any organization, and also some of the most heavily regulated. When a former employee sends a deletion request, the answer is rarely a simple yes or no. Part of the file must go. Part of it must stay. And you need a record of which was which.

The short answer

You must erase employee data when the reason you held it no longer applies, unless a specific legal ground requires you to keep it. Payroll, tax, and social security records almost always fall under a retention obligation that overrides the erasure request. A recruitment file for a rejected candidate usually does not. The work is deciding, per category, which rule wins, and keeping proof of that decision.

What the right to erasure actually says

The right to erasure lives in Article 17 of the GDPR. It gives a data subject the right to obtain deletion of their personal data without undue delay when one of several conditions applies. The two that matter most for HR are:

• The data is no longer necessary for the purpose it was collected for.
• The data was processed on the basis of consent, and that consent has been withdrawn.

An employment relationship is not usually built on consent. It runs on the employment contract and on legal obligations. That distinction matters, because it changes which erasure grounds apply and which exemptions you can rely on.

When you must refuse the request

Article 17(3) lists the exemptions. The one that dominates HR is the exemption for compliance with a legal obligation. If a national law requires you to keep a record, the erasure right does not force you to delete it early.

The categories under a retention obligation are the usual ones: payroll and wage tax records, employment contracts and amendments, and occupational health and safety records. Payroll and tax records are the clearest case, kept for years under national tax law, so you cannot delete them on request. The exact period for each category is set out in HR data retention periods in the EU.

When an exemption applies, you do not delete. You also do not simply ignore the request. You respond, you explain the legal ground for keeping the data, and you record that you did so. A refusal you cannot explain later is a refusal that looks like non-compliance.

When you must delete

Where no retention obligation and no other exemption applies, the data goes. Common HR categories that usually must be erased once their purpose ends:

• Recruitment data for rejected candidates. Once the vacancy is filled and any short retention window for discrimination claims has passed, there is no purpose left. Without consent the window is short, roughly four weeks under Dutch guidance. With the candidate’s consent, up to a year is common so you can approach them for a future role.
• Application data you were allowed to keep with consent after the candidate withdrew that consent.
• Performance notes and internal HR correspondence that outlived their purpose and are not part of a record you are obliged to keep.
• Access credentials, badge logs, and IT account data once offboarding is complete and any security review window has closed.

Storage limitation is not only reactive. Article 5(1)(e) requires that you keep personal data no longer than necessary in the first place. It is a separate principle from data minimization under Article 5(1)(c), which limits how much you collect. A deletion request is often just the moment you discover you were holding data you should already have removed.

The part most teams get wrong: proof

Deleting the data is half the obligation. Being able to demonstrate that you deleted it is the other half, and it is the half that fails during an audit.

Article 5(2) sets out the accountability principle. You must be able to demonstrate compliance, not just claim it. For erasure that means you should be able to show, for a specific request:

1. What was requested and when.
2. Which categories you erased and which you retained.
3. The legal ground for anything you kept.
4. When the erasure actually happened.
5. That the erased data is genuinely gone and not sitting in a backup that quietly restores it.

A supervisory authority such as the Dutch Autoriteit Persoonsgegevens or the French CNIL, acting on a complaint from the former employee, will ask for exactly this. “We deleted it” is not an answer. A dated, tamper-evident record of the decision and the action is.

The backup problem

Backups are where erasure claims fall apart. If you delete a record from your live system but a nightly backup restores it three weeks later, you have not erased anything. Regulators accept that immediate deletion from every backup is not always technically feasible, but they expect a documented approach: the data is put beyond use, excluded from restores, and purged on the next backup rotation. What they do not accept is silence. If you cannot describe your backup deletion process, you cannot demonstrate erasure.

Tell the others

Erasure does not stop at your own systems. Article 19 requires you to communicate the erasure to every recipient the data was disclosed to, unless doing so proves impossible or involves disproportionate effort. For HR that usually means your payroll bureau, your pension administrator, and any processor that received the record. Deleting your copy while a processor keeps theirs is not erasure. It is a gap, and it is one you have to close and document.

A defensible erasure workflow for HR

A workflow that survives scrutiny looks like this:

1. Log the request with a timestamp when it arrives.
2. Classify the file by category. Separate the parts under a retention obligation from the parts that must be erased.
3. Record the decision per category, including the legal ground for anything retained.
4. Execute the deletion on the categories that must go, including the backup handling.
5. Capture proof that the deletion happened: what was deleted, when, and by which process.
6. Respond to the individual within the one-month deadline, extendable by two months for complex requests.

The output of a good workflow is not just deleted data. It is a defensible file that shows, months or years later, that you did the right thing for the right reason. This is the idea behind defensible deletion: destruction that comes with its own evidence.

How SealDoc supports HR erasure

SealDoc treats each protected file as a subject with a retention state, and records its lifecycle as timestamped, tamper-evident evidence. When you assign a retention period, place or lift a legal hold, or request destruction, each step is written to an append-only audit trail with an RFC 3161 timestamp and linked into a hash chain so the sequence cannot be rewritten after the fact.

When a subject reaches destruction, SealDoc produces a certificate artifact and an evidence pack that document the decision, the timeline, and the assurance behind them. SealDoc attests the destruction decision and the lifecycle around it. The byte-level deletion of the data and its purge from backups are carried out by your storage layer, and the certificate records the assurance behind each step rather than assuming it. It states plainly what it does and does not attest, so an auditor sees an honest record rather than an unverifiable claim. The proof is captured at the moment of the decision, which is exactly when accountability under Article 5(2) is easiest to satisfy and hardest to reconstruct after the fact.

Data lives on infrastructure inside the EU, with no US hyperscaler in the path, so the erasure record itself does not create a new transfer problem.