A practical guide to automated candidate sourcing under GDPR

Article 6 of the GDPR lists six lawful bases, and for sourcing only one fits realistically. Consent fails because you cannot ask someone for consent before you have their details, and consent collected in a first email would not cover the collection that already happened. Contract does not apply because there is no contract or pre contractual request yet. That leaves legitimate interests under Article 6(1)(f), which permits processing that is necessary for a legitimate interest you pursue, as long as the individual's interests and rights do not override it.

Legitimate interest is not a blank check. It works when the data is professional rather than private, when the person would reasonably expect to be approached about relevant roles given how they present themselves publicly, and when you collect only what the outreach requires. It fails when you scrape personal social accounts, collect sensitive details or keep contacting someone who said no. Good GDPR compliant candidate sourcing logs the basis and the source per candidate, so you can show your reasoning later instead of reconstructing it.

A legitimate interest assessment is the written reasoning behind your choice of basis. Regulators and courts look for three parts, often called the purpose test, the necessity test and the balancing test. It does not need to be long, but it should be specific to the type of role and the sources you use, and you should revisit it when either changes. Writing one template per role family and adjusting it per search keeps the effort reasonable.

The balancing test is where most of the thinking happens. A senior software engineer who publishes a detailed professional profile and lists themselves as open to opportunities has a high expectation of recruiter contact. A nurse whose only online trace is a staff photo on a hospital website has a much lower one. The safeguards you apply, such as a clear notice, an easy opt out and short retention, carry weight in the balance and can tip a borderline case into an acceptable one.

Article 13 covers data you collect from the person directly. Article 14 covers data obtained from somewhere else, which is exactly what sourcing is. It requires you to tell the person a specific list of things, and the list is longer than many recruiters expect. The good news is that most of it is the same for every candidate in a given role, so it can live in a short block within the first message plus a link to a fuller privacy notice.

Two items are easy to miss. The first is the source: Article 14 requires you to say where the data came from and whether it came from publicly accessible sources. The second is the specific legitimate interest you rely on, which must be stated when that is your basis. Leaving either out is one of the most common gaps in recruiter outreach templates.

Article 14(3) sets the timing. The general rule is a reasonable period after you obtain the data and at the latest within one month. If you use the data to communicate with the person, the notice must be given at the latest at the time of that first communication. If you plan to disclose the data to another recipient, such as sending a profile to a client, it is due at the latest when the data is first disclosed. For sourcing, the second rule almost always applies, which is why the notice belongs in the first message rather than in a later follow up.

There is an exemption in Article 14(5)(b) for cases where informing people would involve disproportionate effort, but it is a poor fit for outreach. If you are already emailing someone, telling them who you are and why costs almost nothing. The exemption is more relevant for people you found and then discarded without ever contacting, which is one reason short retention for unused profiles matters so much.

Below is an example of a short notice for the bottom of a first outreach email. Treat it as a starting point to review with your counsel, not a finished legal text, and replace the bracketed parts with your own details.

Sample notice text. Why you are hearing from us: [Company] is the controller of the limited professional information we hold about you, namely your name, current and past roles, skills and a work contact address, which we found on public professional profiles and open web sources. We use it only to contact you about the [Role title] role and similar opportunities, based on our legitimate interest in filling open positions with qualified professionals. We share it only with the hiring team for this role and with service providers that process it on our behalf under contract. If you do not reply, we delete your details after 30 days. You can ask us to access, correct or delete your data, or object to this processing, at any time by replying to this email or writing to [privacy contact], and you can complain to your local data protection authority. To stop all contact from us now, use the one click opt out link below. Our full privacy notice is at [link].

Notice what the sample avoids. It does not bury the source in a separate document, it gives a concrete retention period instead of "as long as necessary", and it makes objecting as easy as replying. Candidates who feel respected in the first message are far more likely to answer, even when the answer is not now.

Article 21 gives individuals the right to object to processing based on legitimate interests. For practical purposes, treat any objection from a sourced candidate as final for your whole organization, not just for the role that contacted them. Recruiting teams often run several searches in parallel, and a person who opts out of one sequence and then receives an email about a different role from a colleague a week later has every reason to escalate to a regulator.

The fix is a suppression list held at the workspace level, checked before every send by every recruiter and every role, and populated automatically by a one click opt out link in every message. Keep only the minimum needed to honor the opt out, such as a hashed email address, rather than the full profile. Local email rules in some countries add their own requirements on top of the GDPR, so confirm the details for the markets you recruit in.

The storage limitation principle says personal data should be kept no longer than necessary for the purpose. For a sourced person who never replied, the purpose ends quickly, because the role moves on and the person showed no interest. A short default, such as automatic deletion after 30 days for non responders, is easy to defend and easy to explain in the notice. Some teams extend it to 90 or 180 days for long running searches, which can be justified if the reasoning is documented.

Candidates who engage are different. Someone who replied, completed a screen and asked to be considered for future roles can be kept longer, ideally with their explicit agreement and a review date. Applicants who came through your own apply page follow your normal applicant retention policy. Good recruitment automation enforces retention on a clock instead of leaving it to a recruiter who promises to clean up the database one day.

Sourced candidates do send data subject access requests, often simply because they want to know how you found them. Under Article 12 you must respond without undue delay and within one month, extendable by two further months for complex or numerous requests if you tell the person within the first month. You generally cannot charge a fee unless a request is manifestly unfounded or excessive.

The hard part is not the deadline but finding everything. A candidate's data can be scattered across a sourcing tool, a spreadsheet, an email thread and an ATS note. Tooling that keeps one record per candidate, with every source, message and score attached, lets you export or delete it in one click and answer within days instead of weeks. Whatever you use, log each request and the date you completed it, because that log is your evidence if the person later complains.

The controller decides why and how personal data is processed. The processor acts on the controller's documented instructions. When a company or agency uses a sourcing platform, the customer is the controller for candidate data, because it decides which roles to fill, whom to contact and what to keep. The platform is the processor, and Article 28 requires a data processing agreement between them that sets out instructions, security measures, sub processors and assistance with requests.

Agencies add a layer. An agency sourcing for a client is usually a controller in its own right for its candidate database, and the client becomes a controller once it receives a profile. That is why the notice should name the categories of recipients and why many agencies only share full details with a client after the candidate agrees to be put forward. When you evaluate automated candidate sourcing tools, ask for the DPA, the list of sub processor categories and where data is hosted before you import a single profile.

Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects on a person, and rejecting someone for a job can qualify. Automated scoring is fine as an input. What you should avoid is a pipeline where software alone decides who is rejected and nobody with real authority reviews it. A shortlist that a hiring manager approves or rejects, with the evidence behind each score visible, keeps a meaningful human decision in the process.

Two further habits help. Avoid collecting special category data such as health, religion or ethnicity, which Article 9 restricts heavily and which has no place in a sourcing profile. Keep scoring criteria job related and documented so you can explain a decision if asked. If you hire in jurisdictions outside the EU, such as US states and cities with their own rules on automated hiring tools, check those requirements with counsel as well, because the GDPR is only one layer of the picture.