# The First-Contact Notice Playbook for Cold-Sourced People

*You can ship an Article 14 first-contact notice to every cold-sourced person within one month of acquisition, folded into first outreach, with per-record proof.*

- Canonical URL: https://www.refolk.ai/guides/first-contact-notice-cold-sourced
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-09-05
- Last reviewed: 2026-09-05
- Reading time: 16 min

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.

> **Rule:** The clock starts at acquisition
>
> Log an obtained-on timestamp the moment you source a record. The one-month outer limit runs from that date, not from first contact, and the earliest of the three triggers controls.

### 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.

| Field group | What to state | Article 13 also requires it? |
|---|---|---|
| Controller and DPO | Identity and contact details of the controller, and the DPO where applicable | Yes |
| Purpose and basis | Purposes of processing and the legal basis; the legitimate interests where you rely on Article 6(1)(f) | Yes |
| Data and origin | Categories of data held, and the source of the data | No, Article 14 only |
| Retention | Storage period or the criteria used to set it | Yes |
| Rights | Access, rectify, erase, restrict, object, portability, withdraw consent, and complain to a supervisory authority | Yes |

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.

> **Watch out:** A website privacy policy is not a notice
>
> Passive publication does not discharge Article 14. Individuals must be actively informed. Treating your public policy page as the notice is a common way records look compliant but are not.

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.

**EUR 1,000 - Damages for failing to notify a single applicant**

BAG 8 AZR 117/24, awarded for the missing Article 14 notice, not the rejection.

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.

| Country | Sourcing-role profiles | Top employer in sample | UK:DE multiple |
|---|---|---|---|
| Germany | 323 | Google | 1.0x (base) |
| United Kingdom | 1,101 | Sharp Brains | 3.4x |

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.

| Role group (Germany) | Profiles | Sourcers per notification owner |
|---|---|---|
| Sourcing roles | 323 | - |
| Data-protection roles | 254 | 1.27 |

**1.27 - Sourcing-role profiles per data-protection-role profile, Germany**

Refolk's index. The approval bottleneck is why the notice has to be templated and automated.

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.

I ran this search: `Data protection officers at German companies with 200+ employees in Frankfurt or Berlin.` - [see the full result list](https://www.refolk.ai/s/t02vc108n2).

*Returns named DPOs with company and location, so you know who must sign off the exemption screen before a batch ships.*

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 first-contact notice pipeline

1. **Trigger capture** - Timestamp the obtained-on date the moment a person is sourced
2. **Categorise** - Record the source platform and the categories of data held
3. **Exemption screen** - Run the documented Recital 62 test per batch
4. **Fold into outreach** - Deliver the notice at or before first contact
5. **Deliver and log** - Send in writing, capture timestamp and channel
6. **Store proof** - Retain notice version, acquisition date, send date per record

*The notice rides inside first outreach, and every stage leaves a logged artifact.*

#### The Article 14 first-contact procedure

1. **Capture the acquisition trigger** - Log the acquisition date the moment a person is sourced from LinkedIn, GitHub, or the open web. Done when every record carries a timestamped obtained-on date that starts the one-month clock. Treat acquisition date as the hard start rather than deferring to first contact.
2. **Categorise source and data** - Record the source URL or platform and the data categories held for each record. These two fields are Article 14-specific and are the ones most often dropped. Done when source and categories are populated on every record.
3. **Screen the batch for exemptions** - Run a documented Article 14(5)(b) disproportionate-effort test using the Recital 62 factors of number of data subjects, age of the data, and safeguards. Done when there is a written assessment plus a DPIA where the exemption is relied on. For named and contactable candidates, expect the exemption to fail.
4. **Draft the layered notice** - Build a layered notice covering all Article 14(1) and 14(2) fields, including source and categories of data. Keep a short first-contact summary that links to the full text. Done when the template is approved by the DPO.
5. **Fold the notice into first outreach** - Deliver the notice at or before first contact, and at the latest within one month of acquisition. First communication is itself a deadline trigger, so shipping the notice with the first message discharges the duty. Done when the notice link or text is present in the first message.
6. **Deliver and timestamp** - Send in writing or by electronic means and capture the send timestamp and delivery status per record. Done when each record has a delivery log entry with a send date and channel.
7. **Store per-record proof** - Retain the notice version, acquisition date, send date, and channel for every record. Done when the record is auditable and demonstrates the notice shipped inside the deadline.
8. **Route US-resident records** - Apply CCPA notice-at-collection for California applicants and check VCDPA entity exemptions for Virginia records. Done when the US branch of the workflow is documented separately from the EU branch.

### 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.

**First-contact notice summary, folded into first outreach**

```
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.
```

*Replace the bracketed controller details with your own; keep the source and categories lines, they are the Article 14-only fields.*

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.

> **Note:** The duty cannot be outsourced
>
> Liability attaches to the party that processes. A sourcer cannot push the Article 14 risk onto LinkedIn, GitHub, or a data broker. Your acquisition creates your own duty to notify.

## 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.

| Regime | Fixed indirect-notice deadline | Documented enforcement figure |
|---|---|---|
| EU GDPR Article 14 | 1 month from acquisition | EUR 1,000 damages, BAG 8 AZR 117/24 |
| Poland (UODO, public data) | Same, Article 14 | Notice duty for 6M+ people |
| US CCPA | Notice at or before collection, no month clock | HR exemption expired 1 Jan 2023 |

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.

#### Discharge check for a cold-sourced batch

- [ ] Every record has a timestamped obtained-on date that starts the clock
- [ ] Source platform and categories of data are populated on every record
- [ ] Any exemption claim has a written Recital 62 assessment and a DPIA
- [ ] The notice text contains both source and categories of data
- [ ] The notice was actively sent to the person, not merely published on a policy page
- [ ] Each record has a send date and channel logged as delivery proof
- [ ] The notice version, acquisition date, and send date are retained per record
- [ ] US-resident records were routed to a CCPA notice-at-collection and VCDPA check

## 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.

## Frequently asked questions

### When does the Article 14 clock actually start?

It starts when you obtained the personal data, not when the person becomes a candidate or a contact. The outer limit is one month from acquisition. Two earlier triggers can shorten it: the time of first communication with the person, and the time data is first disclosed to another recipient. Whichever of the three comes first sets your deadline, so a record scraped weeks before you email it may already be late.

### Does sending the notice inside my first outreach email count?

Yes, and it is the legally optimal move. First communication is one of the three deadline triggers, so delivering the notice with your first message discharges the duty at the moment it is most likely to be tested. Include a short summary plus a link to the full layered notice, and log the send timestamp and channel so you can evidence it later.

### Can I rely on the disproportionate-effort exemption for a large scraped list?

Rarely. Article 14(5)(b) is narrow and requires documentation, including a DPIA and published privacy information. For named, contactable candidates it generally fails: the ICO rejected it for scraped job-platform data and Poland's UODO enforced a notification duty over more than six million people sourced from public data. Publishing a website privacy policy is not enough; individuals must be actively informed.

### What does Article 14 require that a normal privacy policy does not?

Two extra fields beyond an Article 13 direct-collection notice: the categories of personal data you hold, and the source you obtained them from. The rest overlaps with a standard notice: controller identity, DPO contact, purposes and legal basis, retention period, the legitimate interests where you rely on them, the data-subject rights, and the right to complain to a supervisory authority. Omitting source and categories is the most common defect.

### Do US candidates fall under the same one-month rule?

No. Neither the CCPA nor Virginia's VCDPA imposes a fixed one-month indirect-notification clock. The CCPA requires a notice at or before collection, stating the categories collected and the uses for each category; California's HR and applicant exemption expired on 1 January 2023. The VCDPA exempts several entity types including GLBA institutions, HIPAA entities, non-profits, state agencies, and universities. Route US-resident records to their own branch.

### What proof do I need that I sent the notice?

There is no publicly mandated per-record log format, but the accountability principle requires you to be able to document compliance. Retain, per record, the notice version sent, the acquisition date, the send date, and the channel. Article 14 information must be provided in writing or by electronic means, and regulators expect you to document how notices are delivered. Keep it auditable so you can show the notice shipped inside the deadline.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/first-contact-notice-cold-sourced*