GDPR and CVs: how to handle candidate data, by hand or in code

Published 9 October 2026

GDPR and CVs: what the regulation asks of everyone who holds one

Under the General Data Protection Regulation, a CV is personal data from the moment you receive it, so you need a lawful basis to hold it, you must tell the candidate what you do with it, you may keep only what the hiring purpose needs, you must delete it when that purpose is over, and every tool that touches it is part of your answer. None of that depends on whether you read CVs by hand, in an applicant tracking system, or through a parsing API. The rules attach to the data, and the data arrives the second an applicant presses submit.

This article is for two readers. The first is the recruiter or hiring manager who wants a short, practical list of what to do with the CVs already sitting in an inbox. The second is the developer building a job board, an applicant tracking system or a candidate-matching tool, who has to turn those duties into tables, jobs and buttons. We build ResumeJSON, a resume parsing API, so read the parts about parsing as written by an interested party. The regulation quotes below come from the text of the GDPR itself, and they apply whichever tool you pick.

This is a working guide, not legal advice. National rules, works councils and sector regulators add duties on top of the GDPR, and a lawyer who knows your country is the right person for the hard cases.

What a CV actually contains

A typical CV carries more personal data than the form it was attached to. Read one with a GDPR eye and you will usually find:

• Identity and contact data: name, email, phone number, home address, sometimes a date of birth and a photo.
• Career data: employers, job titles, dates, salary history on some CVs, reasons for leaving.
• Education and skills: schools, degrees, certificates, languages.
• Data the candidate volunteered but you never asked for: marital status, nationality, religion, health, a disability, union roles, a political volunteering post.

That last group matters most. Article 9 of the GDPR names special categories of personal data whose processing is prohibited unless one of its listed exceptions applies, including data revealing:

racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership

A CV that mentions a church choir, a union role or a health condition puts that data in your hands whether you wanted it or not. The safe default is not to extract, index or score anything in that group. If your system builds structured records from CVs, decide which fields it keeps and make sure the rest never reach a database column.

Lawful basis: why you are allowed to hold the CV

Article 6 lists the lawful bases for processing. Two cover almost every hiring case:

The legitimate interests basis, in the regulation's words, covers interests "pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject". In plain terms: you must be able to say why your need outweighs the candidate's privacy, and write that reasoning down.

Consent is the weakest basis for the application itself, because a candidate who wants the job is not in a position to refuse freely. Use it for the optional extra, such as keeping a CV in a talent pool, not for the assessment the person applied for.

Tell the candidate what you are doing

Articles 13 and 14 require a privacy notice. When the candidate gives you the CV (Article 13), the notice belongs at the point of collection: on the application form, in the auto-reply, on the careers page. When you obtained the data from somewhere else, such as a referral, a sourcing database or a public profile, Article 14 applies, and the notice is due:

within a reasonable period after obtaining the personal data, but at the latest within one month

The notice says who you are, why you hold the CV, the lawful basis, how long you keep it, who receives it (including your software vendors) and what rights the candidate has. For a job board or applicant tracking system, that means the upload form links to the privacy notice before the file is sent, not after.

Keep only what the hiring decision needs

Article 5 sets the principles, and two of them do most of the work for CVs. Data must be:

adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed

and

kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed

For a recruiter, minimisation means not forwarding full CVs to people who only need a shortlist, and not copying them into spreadsheets that live forever on a shared drive. For a developer, it means designing the data model on purpose. If your matching feature needs skills, job titles and dates, store those. If nothing in the product uses the home address or the date of birth, do not keep them just because the parser returned them.

This is where structured parsing helps rather than hurts. A CV as a PDF is all or nothing: you keep the whole file or none of it. A CV as JSON fields lets you keep the career data, drop the fields nobody needs, and still show the original to the person assessing the application while the role is open. Our guide to extracting information from a resume lists the fields a parser returns; blind resume screening covers hiding identity fields from reviewers.

How long to keep a CV

The GDPR gives no number of days. It gives the principle above and leaves the period to you, so the honest answer is: long enough to finish the hiring decision and defend it, and no longer. Many employers settle on a fixed period after the role closes, set to match how long a rejected candidate could bring a discrimination claim in their country. Whatever you choose, three things make it real:

1. Write the period down in the privacy notice and in your internal policy, per type of record (applicant, talent-pool member, hired employee).
2. Store a deadline on each record, not just a creation date, so the system knows when a CV is due to go.
3. Run a scheduled job that deletes or anonymises everything past its deadline, and log what it removed.

The third step is the one that gets skipped. A retention policy that nobody enforces is a document, and the CVs keep accumulating under it.

Requests from candidates: access and erasure

Candidates can ask what you hold about them and ask you to delete it. Article 12 sets the clock: you answer:

without undue delay and in any event within one month of receipt of the request

with a possible extension of two further months for complex or numerous requests. To meet that in practice:

• Find every copy. The inbox, the applicant tracking system, the shared drive, the hiring manager's downloads folder, the spreadsheet someone exported. A system that stores the CV in one place and references it everywhere else makes this a single query.
• Delete derived data too. Parsed fields, search indexes, embeddings, match scores and notes are all personal data about the candidate.
• Keep a record of the request and what you did, without keeping the CV itself.

Automated screening has its own rule

If software ranks or rejects candidates, Article 22 matters. It gives people the right not to be subject to a decision:

based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her

Rejecting a job application can qualify. The common design answer is a human who genuinely reviews the decision, rather than one who rubber-stamps the score. Parsing a CV into fields is not a decision; filtering out candidates on those fields with no person looking can be. Our articles on automated resume screening and AI resume screening go further into where that line sits.

Vendors and processors: every tool is part of your answer

Any service that handles CVs on your behalf is a processor, and Article 28 says you may use:

only processors providing sufficient guarantees to implement appropriate technical and organisational measures

Before you send CVs to an applicant tracking system, a cloud drive, an email tool or a parsing API, ask each one:

The fewer copies your vendors keep, the smaller your erasure and breach problem. A tool that never stores the CV cannot leak it later and has nothing to delete when the candidate asks.

How ResumeJSON fits, and what it does not cover

ResumeJSON turns an uploaded CV (PDF, DOCX, or a photo or scan) into structured JSON: name, contact details, every role with normalised dates, education, skills and languages. On data handling, as stated on our privacy page today:

• Documents are not stored. A parse is a single request. The document is read in memory, the JSON goes back, and there is no database in the service to hold a copy.
• The document is sent to a third-party model provider to be read, which makes that provider a sub-processor you should list. Every call carries a data-retention policy that excludes endpoints permitted to keep or train on what is sent, and a parse is refused rather than sent to one that would.
• You stay the controller. No data-processing agreement is published or offered on the site, so if your process requires one, say so before you build on the service.

What the API cannot do is any of your controller duties. Lawful basis, the candidate notice, your retention period and erasure requests stay with you. What the JSON gives you is the shape that makes those duties cheaper: you store the fields you chose, attach a deadline to each record, and delete one row when the candidate asks. You can try it on your own CV with the free resume parser, with no signup and nothing stored, and see exactly which fields come back before you decide which ones to keep.

A checklist for the next CV you receive

For recruiters:

• Link a privacy notice from every place a CV can arrive.
• Keep CVs in one system, not in inboxes and spreadsheets.
• Ask before adding anyone to a talent pool, and record the answer.
• Set a retention period and put the deletion date in your calendar or your tool.
• Answer access and erasure requests within a month.

For developers:

• Show the privacy notice on the upload form, before the file is sent.
• Decide which parsed fields you store; never index special-category data.
• Store a deletion deadline on each candidate record and run a scheduled purge.
• Make erasure one operation that removes the file, the fields, the index entries and the scores.
• Keep a human in any step that rejects a candidate.
• List every vendor that touches a CV, and pick ones that keep as little as possible.

When the manual way is enough

A small employer hiring for one role a year does not need software for any of this. A privacy notice in the job advert, a single folder for applications, a reminder to empty it when the retention period ends, and a written note of who asked for what will meet the same principles. The tooling becomes worth it when CVs arrive by the hundred, when several people review them, or when you are building a product that other employers will rely on to get this right. Then the duties above stop being habits and become features, and the earlier they are in the data model, the less there is to retrofit. Our guide to how to build an ATS shows where they fit in the pipeline.