The First-Contact Notice Playbook for Cold-Sourced People

You sourced people from LinkedIn, GitHub, and the open web without their knowledge, and the law now puts a clock on you: tell each person you hold their data, in the right words, before the deadline runs out. This playbook is for recruiting and revenue operations and anyone answerable for how the data was gathered. It turns the Article 14 duty into a workflow that ships a compliant first-contact notice inside first outreach, with logged proof that the obligation was discharged, and without tanking your response rate.

Two other guides in this library cover adjacent ground. The Legitimate Interest Assessment for Cold-Sourced Contacts covers your lawful basis, and a deletion-request runbook is reactive to a person's request. This one is the proactive duty that neither covers: you must notify a person you sourced indirectly, on a fixed clock, whether or not they ever ask.

What Article 14 requires and when the clock starts

Article 14 of the GDPR applies whenever you obtain personal data from somewhere other than the person themselves, which is exactly what cold sourcing is. The controller must provide the required information within a reasonable period after obtaining the data, and at the latest within one month.

The single most misread part is when the clock starts. It runs from acquisition, not from the moment the person becomes a candidate, a contact, or a customer. A vendor who scraped emails in January and emails them in March is already late. Three triggers can end the period, and the earliest one wins:

• One month from obtaining the data. This is the outer limit.
• The time of your first communication with the person, if you use the data to contact them.
• The time of first disclosure, if you pass the data to another recipient.

Because first communication is itself a trigger, the smart move is to make your first message carry the notice. That discharges the duty at the exact moment it is most likely to matter and keeps you off the one-month cliff.

The fields you must include

Article 14(1) and 14(2) enumerate the information. Most of it overlaps with a standard direct-collection notice under Article 13, but two fields are unique to Article 14, and they are the two most often dropped: the categories of personal data you hold, and the source you obtained them from.

If you copy a customer privacy template into your recruiting notice, you will almost certainly ship it without source and categories. That is a defect a regulator can spot in seconds.

Why the exemptions almost never save you

The five exemptions in Article 14(5) are narrow and require documentation, and for cold-sourced named candidates the one you would reach for generally fails. The exemption most people invoke is 14(5)(b): impossibility or disproportionate effort. It sounds like it was written for large scraped lists. It was not written to excuse them.

If you rely on disproportionate effort or impossibility, you have to publish your privacy information and conduct a DPIA to prove and document that the exemption was appropriate and justified. Recital 62 gives the factors: the number of data subjects, the age of the data, and any appropriate safeguards adopted. Note that "impossibility" is all-or-nothing with no degrees; you cannot be partly unable to notify someone whose name and email you already hold.

Enforcement is closing the door in real time. Where providers held names and contact details, they could not justify why notifying individuals would be disproportionate, and simply publishing a website privacy policy was not enough. Individuals must be actively informed, typically within one month of collection. The ICO rejected the 14(5)(b) exemption for scraped public job-platform data where names and contacts were held. In Poland, the UODO fined a firm over failure to inform more than six million people sourced from public data, and the country's Supreme Administrative Court upheld that reading of the exemption restrictively.

The practical rule that falls out of this: for every named, contactable person, notify. Reserve the exemption for genuinely edge cases, and when you do use it, produce the written Recital 62 assessment and the DPIA at the same time. A strategy built on disproportionate effort is a depreciating asset.

What the enforcement record actually shows

The load-bearing precedent is a German labor case, and it is smaller and sharper than the headline fine ceilings suggest. In its judgment of 5 June 2025 (case 8 AZR 117/24, available in German only), the Federal Labor Court, the BAG, upheld a Düsseldorf ruling ordering a university to pay EUR 1,000 in damages to a lawyer-applicant after the university ran a Google search on him before a job interview.

The reasoning is the part to internalise. The damages were not awarded because the applicant was rejected. They were awarded because the university failed to inform him about the processing of his personal data obtained from the internet and its use in the recruitment process. The court found a breach of the information obligations under Article 14(1)(b), and it held that Article 82(1) does not require consideration of the severity of the fault; the compensatory function excludes fault as a factor in the amount of damages.

Read that twice. A clean, defensible rejection still creates liability if you never told the person you held their data. The trigger is the missing notice, on its own.

The maximum GDPR fine is far larger, at EUR 20 million or 4% of global annual turnover, but the EUR 1,000-per-person mechanism is the one that scales against a cold-sourcing operation. Multiply it across a scraped list and the exposure is linear in the number of people you failed to notify. This is also why the EDPB's coordinated enforcement work has turned to Articles 12 to 14 transparency: it is a systemic, checkable duty rather than a judgment call.

The trigger is the missing notice, on its own, and Article 82 does not weigh how sorry you are.

Where the load lands: capacity and geography

Two figures from Refolk's index shape how you should staff this. First, volume is not where the case law is. In Refolk's index there are 1,101 sourcing-role profiles in the United Kingdom against 323 in Germany, a 3.4x multiple, yet Germany produced the sharpest precedent. The largest sourcing population runs high volume under case law set elsewhere, so UK operations cannot treat the BAG ruling as a foreign curiosity.

Second, the people who must sign off exemption assessments are thin on the ground. In Refolk's index, Germany has 254 data-protection-role profiles against 323 sourcing-role profiles, so there are roughly 1.27 sourcers for every notification owner. The people generating cold records nearly outnumber the people who can approve how they are handled.

The operational conclusion is direct: you cannot run a bespoke per-batch legal review at sourcing volume with that ratio. The DPO's time goes into approving one strong template and the exemption screen, and delivery is automated. Everything below is built to fit that constraint.

If you need to map who in your own market carries this duty, that is a sourcing question in itself.

Finding the right privacy owner in plain English is exactly what Refolk is for, and it removes the friction of guessing which contact on a company page actually holds the accountability.

The workflow, start to finish

Here is the whole procedure, in order, with the owner and rough duration for each stage. It assumes you have already settled your lawful basis in a separate legitimate-interest assessment; this workflow discharges the transparency duty that sits on top of that basis.

The layered notice, structured for outreach

A layered notice is short at the top and full underneath. The first message carries a two-line summary and a link; the linked page carries every Article 14 field. This keeps the outreach readable while making the full disclosure available and logged.

How I found you: I identified your public professional profile from [LinkedIn / GitHub / a public source] and am contacting you about a role.

The data I hold about you: your name, professional contact details, and public career information, obtained from [that source].

I am [Controller name], acting as data controller. My legal basis is legitimate interest in recruitment. You have the right to access, correct, or erase this data, to object, and to complain to a supervisory authority. Full details and my DPO's contact are here: [link to full notice].

If you would rather I delete your data, reply "delete" and I will remove it.

Weaving the notice into outreach this way is the point where the compliance work and the response-rate work stop fighting each other. A single sentence about how you found someone reads as candour, not as a legal footnote.

How this goes wrong

The failures below are the ones that make a record look compliant while it is not. Each has a specific check you can run against your own pipeline.

• Clock started at first contact, not acquisition. The record looks fine because a notice went out with the first email, but the person was sourced weeks earlier and the one-month window had already closed. Check the obtained-on timestamp against the send date on a sample of records.
• Blanket disproportionate-effort claim. A whole batch is marked exempt with no per-batch DPIA behind it. Check for a written Recital 62 assessment. For named and contactable candidates, this exemption almost never holds.
• Website privacy policy treated as the notice. Passive publication fails; individuals must be actively informed. Check that an actual message went to the person, not that a policy page exists.
• Missing the Article 14-only fields. The notice was copied from an Article 13 template and omits source and categories of data. Check that both appear in the notice text.
• No delivery proof. The notice was sent but not timestamped or logged, so the deadline cannot be evidenced even if it was met. Check that each record has a send date and channel.
• Assuming US records are covered by the EU notice. California needs a notice at collection and Virginia's exemptions differ. Check residency routing so US-resident records go to their own branch.
• Relying on the upstream source's compliance. The acquisition triggers a fresh, non-delegable duty on you. Even with contracts pushing it to the source, it is the controller that is responsible, and irregularities by the third party will in principle constitute a breach by the controller. Check that your own send exists for every record; a broker's or platform's compliance is not yours.

Routing US-resident records

Neither major US regime imposes the fixed one-month indirect-notification clock that Article 14 does, so US records run on a separate branch. The core surviving duty in California is a notice at collection, which requires two pieces of information: the categories of personal information collected, and for each category, the uses of that information. Note the timing difference: the CCPA duty is a notice at or before collection, not a month afterward.

California removed its HR carve-out. The CPRA extended a temporary carve-out for HR-related data but expanded the required disclosures, and with the expiration of the exemption on 1 January 2023, the CCPA applies fully to the personal data of personnel and job applicants. Virginia's VCDPA takes a different shape and exempts several entity types: financial institutions subject to Gramm-Leach-Bliley, entities regulated by HIPAA, non-profits, Virginia state agencies, and colleges and universities. Check which apply before you assume coverage.

The practical takeaway is that a single EU notice does not cover a US-resident candidate, and the trigger for the US notice is earlier, not later. Route on residency at the trigger-capture stage so you never have to reclassify a batch after the fact.

Before you call the job done

Run this checklist against a batch before you treat the obligation as discharged. It is deliberately about verifiable artifacts, not intentions.

Keeping the workflow current

This is not a one-time build, because the legal surface is moving. The exemption is narrowing: the ICO has rejected 14(5)(b) for scraped job-platform data and Poland's Supreme Administrative Court has read it restrictively, so any strategy leaning on disproportionate effort is depreciating and should be re-checked rather than assumed. The safe default stays the same: notify every named, contactable person.

Set a recurring review on three things. First, re-read Article 14 against your live template each time you change what data you collect, because a new data category changes the categories field. Second, watch coordinated enforcement activity on Articles 12 to 14, since that is where transparency scrutiny is concentrating. Third, re-run your residency routing whenever you enter a new market, because US state laws differ in both timing and entity exemptions and neither imposes the EU month clock.

The one thing that does not change is the mechanism behind the EUR 1,000 award: Article 82 is compensatory and fault-blind, and the missing notice alone is the trigger. Build the workflow so that the notice ships inside first outreach, so that every send is logged, and so that you can prove, per record, that you told the person within a month of taking their data. Do that and the obligation is discharged before anyone has to ask.