Guide · For recruiters

Pseudonymisation vs anonymisation — what the difference means for recruiters

A CV with the name blacked out is not anonymous. It is pseudonymised, and the GDPR treats those two words very differently. Here is what each means in the regulation's own text, why a CV almost never reaches the second, why the first is still worth doing, and how to do it properly by hand.

Updated 19 Aug 20269 min readEnglish

Short answer

Pseudonymised data is still personal data. Anonymous data is outside the GDPR altogether. A CV whose name, phone, email and address have been replaced by placeholders is pseudonymised: you still hold the original and the mapping, and the career history that remains can identify the person on its own. That is the GDPR's definition in Article 4(5); Recital 26 puts anonymous information — data that cannot be linked back to a person by any means reasonably likely to be used — outside the regulation.

For a recruiter the consequence is twofold. Truly anonymising a CV is almost never achievable — a career path is itself a fingerprint. Pseudonymising one is well worth doing: the GDPR names it as a security measure (Articles 25 and 32), it is data minimisation in practice, and it sharply reduces what a third-party AI tool receives. Done properly, that means consistent placeholders, a key kept apart from the file, control over who sees the key, and deleting it when the purpose ends.

The two definitions, in the regulation's words

Pseudonymisation is defined in Article 4(5) GDPR as processing personal data “in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures”. Three things are packed in there: the data can still be linked back; something (a key, a mapping, the original file) does the linking; and that something is kept apart and protected.

Anonymous information is described in Recital 26 as information that “does not relate to an identified or identifiable natural person”, or personal data “rendered anonymous in such a manner that the data subject is not or no longer identifiable” — and the data-protection principles “should therefore not apply” to it. The test is “all the means reasonably likely to be used, such as singling out, either by the controller or by another person”. The same recital says pseudonymised data that could be attributed to a person using additional information “should be considered to be information on an identifiable natural person”.

The regulators read it the same way. The Article 29 Working Party — predecessor of today's EDPB — wrote in its Opinion 05/2014 on Anonymisation Techniques that “pseudonymisation is not a method of anonymisation. It merely reduces the linkability of a dataset with the original identity of a data subject, and is accordingly a useful security measure.” Its three tests for any supposedly anonymous dataset: can someone still single out an individual, link records about them, or infer information about them? “Removing directly identifying elements in itself is not enough.” The UK ICO's anonymisation guidance, with a chapter on pseudonymisation, lives in its UK GDPR guidance hub. Israel's Privacy Protection Authority describes the amended Protection of Privacy Law (Amendment 13, in force since 14 August 2025) as covering anyone identifiable “with reasonable effort, directly or indirectly” — the same logic, on the PPA's Amendment 13 pages. This guide describes the rules; it is not legal advice.

Question Pseudonymised CV Anonymised data
Still personal data? Yes — Art. 4(5), Recital 26 No — the GDPR “does not concern” it (Recital 26)
Can it be linked back? Yes, with the key — often without it, from the career history Not by any means reasonably likely to be used, by anyone
Lawful basis, transparency, processor terms? All still apply None — outside the regulation
Named by the GDPR as a safeguard? Yes — Art. 25(1), Art. 32(1)(a) No — it is an exit from the regulation
Still useful for screening? Yes — the experience is intact Rarely — employers, dates, places, institutions would have to go
Realistic for a single CV? Yes — the right target Almost never — aggregate statistics only

Why a redacted CV is pseudonymous, not anonymous

Take a typical file after a careful manual pass. The header now reads [PERSON_1] · [PHONE_1] · [EMAIL_1] · [ADDRESS_1] · [URL_1]. Underneath it still says: senior backend engineer at a forty-person payments start-up in Haifa, 2021–2025; before that four years in a named bank's fraud team; MSc from the Technion, 2017. Run the Working Party's three tests:

And the plainer reason: you kept the original, because you need to phone the candidate back. The mapping [PERSON_1] → Dana Cohen exists in your ATS, your inbox or your head — and Article 4(5) says that is exactly what makes the redacted copy pseudonymous. Crossing the line would mean deleting or generalising the employers, dates, locations and institutions and destroying every copy of the original and the key; what is left is not a CV anyone can screen. For a single candidate document the honest target is good pseudonymisation.

Why pseudonymising is still worth doing

“Still personal data” sounds like bad news. It is not. Pseudonymisation is the technical measure the GDPR names again and again, because it lowers risk without destroying the data's value:

Two cautions. Pseudonymised data is still personal data, so this changes nothing about your lawful basis, candidate privacy notice or processor terms with an AI vendor — see Recruiters, GDPR and AI. And the Working Party notes that anonymising is itself “further processing”; so is pseudonymising. It is part of your processing, not a way out of it.

How to pseudonymise a CV properly, by hand

Article 4(5) doubles as a checklist: replace the identifiers, keep the key separately, protect the key. These steps work in Word or a text editor and with any AI tool.

  1. Fix the token scheme before you start

    Typed, numbered placeholders: [PERSON_1], [EMAIL_1], [PHONE_1], [ADDRESS_1], [URL_1], [DATE_1]. The type tells the model what was there (so it writes “contact the candidate” rather than inventing a name); the number keeps two emails apart. One scheme for the whole team.

  2. Work on a copy and replace consistently

    Open a copy in Word (ask for .docx if it came as a PDF). For each identifier use Find & Replace → Replace All, so the same value gets the same token everywhere — header, footer, footnotes. A second email becomes [EMAIL_2], never [EMAIL_1] again.

  3. Clear the places that aren't in the text

    Rename the file (candidate-a.docx, not Dana_Cohen_CV.docx), then File → Info → Inspect Document → Document Properties and Personal Information → Remove All. Resolve tracked changes, delete comments, remove any photo.

  4. Write the key somewhere else, and restrict who can open it

    One row per candidate: candidate-a → real name → ATS record → date. Keep it in your ATS or a separate, permission-controlled sheet — not in the folder you upload from, not in the AI chat. The redacted copy can travel; the key should not. Limit it to the people who need to contact the candidate, using the sharing controls you already have (drive permissions, ATS roles). That is Article 4(5)'s “kept separately” and “technical and organisational measures” in one step.

  5. Decide per task what else to remove

    For a first-pass summary the employers and dates stay — they are the substance. For a fairness-oriented screen, also generalise graduation years and drop university names and anything that signals age, gender, ethnicity or religion (see AI screening, bias and blind CVs). Harder to re-identify; still not anonymous.

  6. Set an end date for the key, and keep a one-line record

    When the role closes, delete the key row and the redacted copies you no longer need; the original stays only where your candidate data already lives, under your normal retention rule. With key and original gone, leftover copies are closer to anonymous — though Recital 26 still asks what “another person” could do with the career detail. Note the scheme, where the key lived, who could see it and when it was deleted: at a small agency, that paragraph is your “technical and organisational measures”.

What the manual method costs

Per CV
6–10 minthe replace pass, the hidden places, writing and filing the key
At 20 CVs a day
≈ 2–3 hoursevery day, before a single CV has been screened
What leaks
Consistencya name left in the footer, a second phone as [PHONE_1], a key saved next to the file

Our estimates for a recruiter working carefully in Word; yours will differ. The pattern will not: the cost is per CV, every time, and the misses are the ones that break the definition — an inconsistent token or a key in the wrong place.

What this doesn't solve

  • Re-identification from the rest of the CV. Employer names, job titles, universities and dates are deliberately left in place — they are what you screen on — and together they can point at one person. A pseudonymised CV is not an anonymous one.
  • Your legal footing. Pseudonymised data is still personal data. Placeholders reduce what you disclose; they do not create a lawful basis, update your candidate privacy notice or sign a processor agreement. No tool makes you compliant with anything.
  • Key management. Where the token or your manual key is stored, who can reach it and when it is deleted are the half of Article 4(5) no software does for you.
  • Scans, images and Hebrew PDFs. Sunda reads Word, text and text-layer PDFs — the kind you can select text in. A scanned or photographed CV has no text layer, so it is refused outright rather than handed back looking redacted; a PDF whose text is Hebrew, Arabic or another non-Latin script is refused too, because the built-in PDF font cannot rewrite those characters. Ask for the .docx, or a PDF you can select text in, or use the manual steps above.
  • The look of a redacted PDF. Sunda rebuilds the document from the extracted text instead of patching the original — the only way to reach the copies of a name that sit in metadata, font subsets and form fields. You get the words and the page breaks back, not the layout, fonts, images or columns: right for feeding an AI, wrong for forwarding to a client as it is.
  • Perfect detection. Structured data — emails, phone numbers, IBANs, card and Israeli ID numbers — is caught reliably by rules; names and addresses depend on the optional on-device model and will miss some. Read the output before you share it.

Questions recruiters ask

If I remove the name and contact details, is the CV anonymous?

No. It is pseudonymised: you still hold the original and the mapping, and the rest of the CV — employers, dates, titles, education — can identify the person on its own. Under the GDPR (Article 4(5), Recital 26) pseudonymised data is still personal data; anonymous data cannot be linked back to a person by any means reasonably likely to be used.

Is pseudonymised data still personal data under the GDPR?

Yes. Recital 26 says pseudonymised data which could be attributed to a person by the use of additional information should be considered information on an identifiable person, so every usual obligation still applies. At the same time Articles 25 and 32 name pseudonymisation as an appropriate safeguard: it is both still regulated and actively encouraged.

Can a CV ever be truly anonymised?

Rarely, as an individual document. The Article 29 Working Party's test is whether anyone can still single the person out, link records about them, or infer things about them; a career history usually fails all three even with the name gone. Passing would mean removing or generalising employers, dates, locations and institutions — at which point the CV no longer tells you what you need to know. Aggregated statistics about a pool can be anonymous; a single CV almost never is.

Is encrypting a CV pseudonymisation or anonymisation?

Pseudonymisation, as long as a key exists. The Article 29 Working Party's Opinion 05/2014 lists encryption with a secret key among pseudonymisation techniques, because whoever holds the key can restore the data, and Article 32 of the GDPR names pseudonymisation and encryption side by side as security measures. Encrypted data is personal data in the hands of anyone who can get the key — so who holds it, where it lives and when it is destroyed is the whole question.