The Lawful Sourcing Standard for Candidate Data

This is a standard for grading candidate data. It is for recruiting operations, revenue operations, and the person who has to answer for how a record was gathered when a candidate, a platform, or a regulator asks. It turns three separate questions that vendor blog posts routinely blur into fixed pass/fail criteria, plus a verification checklist a sourcer, a recruiter, and a lawyer would all grade the same way.

The failure of most published guidance is that it answers one question and implies it answered all three. Whether collecting a profile is a crime, whether it breaches a platform's contract, and whether keeping it creates data-protection duties are three different questions with three different answers. A record can clear the first and fail the other two. This standard grades each separately.

Why one policy is not enough: the three questions a record must clear

Every candidate record must be graded against three independent questions, and passing one says nothing about the other two. Treating them as a single "is this legal" check is the root mistake this standard exists to remove.

The three questions are:

1. Is collecting it a crime? This is the computer-misuse question. For public data, the answer is usually no, and it is also the least useful question because it is rarely where liability lands.
2. Does collecting it breach a platform's contract? This is the user-agreement question. It is the binding constraint, and it is answered by reading terms of service, not statutes.
3. Does keeping and using it create data-protection duties? This is the GDPR and CCPA question. It governs your lawful basis, your privacy notice, your retention clock, and your response to opt-outs and deletion requests.

The reason to fix this in policy rather than judge it case by case is capacity. In Refolk's index there are roughly 22,500 recruiters and sourcers across the US and UK, set against just 23 profiles that carry a data-protection, privacy, or compliance manager title with GDPR as a listed skill. A policy that depends on a lawyer reading each record cannot scale against that ratio. Fixed criteria can.

The lawful basis: legitimate interest, and the assessment that proves it

For pre-offer sourcing, the defensible lawful basis is legitimate interests under Article 6(1)(f), not consent and not contract. This is the first pass/fail criterion for the data-protection question, and it is settled enough to state as policy.

The ICO advises avoiding consent for this processing because of the imbalance of power between an employer and a candidate, and advises against the contract basis before an employment offer has been accepted. That leaves legitimate interests as the appropriate basis at the sourcing stage. Consent is the weaker choice, not the safer one: it is revocable and it expires, so leaning on it manufactures the deletion duties it was supposed to avoid.

Relying on legitimate interests requires you to carry out and record a Legitimate Interests Assessment, or LIA. The LIA is regulator guidance in form, not express statutory text, but carrying out the assessment is required in substance, and recording it is how you demonstrate accountability. It has three parts:

• The purpose test. What is the specific legitimate interest? Name the role or program, not "recruitment" in the abstract.
• The necessity test. Is this processing actually needed to achieve that purpose, or would something less intrusive do?
• The balancing test. Do the candidate's interests, rights, and freedoms override the business interest? This test must name the candidate's side, not just the company's.

A recent wrinkle: UK GDPR added a seventh lawful basis, "recognised legitimate interests" under Article 6(1)(ea). If your processing falls within a specified recognised category, you still run the purpose and necessity tests but the balancing test is not required. Most sourcing will not fall inside a recognised category, so treat the full three-part LIA as your default and check with your DPO before claiming the shorter route.

The contract question: what hiQ v. LinkedIn actually decided

The binding constraint on collecting public profiles is the platform's user agreement, not the criminal statute. hiQ v. LinkedIn is the case that proves it, because the two questions came out opposite ways.

On the computer-misuse question, hiQ won. The Ninth Circuit held that scraping public content likely does not violate the CFAA and declined to apply the "without authorization" provision to websites that generally permit public access and take no steps to mark data as private. So "is it a crime" resolved in the scraper's favour.

On contract, LinkedIn won. The court found that hiQ's scraping and its use of fake profiles violated LinkedIn's user agreements. The case ended not in a trial verdict but in a stipulated judgment on December 7, 2022: hiQ agreed to a $500,000 judgment for breach of contract, a CFAA violation tied to accessing password-protected pages with fake accounts, a California unauthorized-access violation, and common-law trespass and misappropriation.

hiQ won the crime question and still paid half a million dollars, because the contract was the constraint that actually bit.

Two lessons for the standard. First, a policy that grades only "is it a crime" will pass records that carry real liability. Second, because the case settled, it sets no binding precedent, so the open questions stay open. The practical criterion is narrow and checkable: before collecting from any source, confirm the source's user agreement does not prohibit automated collection, and record what you reviewed.

The Article 14 notice: what it must say and when it must arrive

When you collect a candidate's data from anywhere other than the candidate, Article 14 requires you to give them a privacy notice, and the deadline is the earlier of one month after you obtained the data or the first communication to that person. This is the single most commonly missed pass/fail line in sourcing.

The clock runs from acquisition, not from outreach or from any later conversion event. A vendor who scraped emails in January and sent them in March is already late in January terms. This is not a hypothetical: the CNIL has sanctioned B2B vendors in 2023 to 2025 both for cold emailing without the Article 14 notice and for describing the source too vaguely.

The notice must state:

• Your identity and the purposes of the processing.
• The legal basis (your legitimate interest).
• The categories of personal data held.
• The recipients of the data.
• The retention period.
• The person's rights.
• Unique to Article 14, the source of the data and whether it came from a publicly accessible source.

That last item is where teams fail even when they send a notice. "Obtained from a public register" is too vague. Name the actual source.

I got your professional details from your public profile on [named platform, e.g. GitHub], a publicly accessible source. I am [name] at [company], contacting you about a [role] opportunity. My lawful basis for holding your data is legitimate interest in recruitment. I keep sourced contact data for up to 6 months unless you join our talent pool with your consent. You can ask me to access, correct, or delete your data, or to stop contacting you, at [contact/opt-out link]. Full privacy notice: [link].

The clocks: retention and request-response deadlines as a reference table

Every candidate record carries at least one clock, and the standard sets fixed figures for each. Retention is anchored to the discrimination-claim limitation period; request-response deadlines are set by statute. Post these numbers where the team can see them.

Retention is where sources genuinely disagree, and the standard's job is to name a figure rather than gesture at a range. Guidance from the ICO and the EDPS is consistent that unsuccessful candidate data should be kept no longer than 6 to 12 months. The justification is the statutory claim window: under the UK Equality Act 2010, an unsuccessful applicant alleging discrimination must bring a claim within six months, so records should survive at least that long. Germany's AGG sets a three-month window, though most agencies add a buffer. The ICO's own schedule uses six months, citing the Limitation Act 1980.

Two operational traps sit inside these clocks. First, on CCPA, note that the exemptions for employees, job applicants, independent contractors, and B2B contacts applied only before 2023 and have since sunset, so candidate and B2B data are now in scope. Second, an opt-out is not a request-based right on the 45-day track; it runs on its own 15-business-day clock and must take effect promptly. Conflating the two guarantees late opt-outs.

Suppression: one durable record, checked at send time

A do-not-contact request must create one durable record that every tool reads, and every outbound event must be checked against it before it leaves. This is the criterion that keeps an opt-out from being honored in one system and ignored in another.

The mechanics are specific. One event - an unsubscribe, a STOP reply, a do-not-call request - creates one record in a single durable store, keyed on normalized email and phone. Every send, call, or audience sync checks that store before it goes out. Suppression is channel-specific (email versus SMS versus calls) and reason-specific (opt-out versus hard bounce versus wrong number), so the record carries both dimensions.

The seam where this breaks is not the unsubscribe button. It is enrichment. A monthly refresh or a list import will happily overwrite the do-not-contact flag unless a filter runs first. The fix is a pre-import suppression filter that matches on normalized email and phone and excludes suppressed records before anything lands in the ATS, CRM, email, or SMS tool. For enrichment specifically, store the complete opted-out list and run a look-up in every future prospecting workflow so you never re-enrich or re-engage a suppressed contact.

Building the store is a one-time effort; keeping the sourcing side of it fed with correctly tagged, correctly sourced records is the ongoing work. Refolk lets you run sourcing queries in plain English and see where each profile came from, which makes the source-tagging step in the procedure below far less manual. Because Refolk returns the origin of each match, the classification and Article 14 source-line work start from real data rather than guesswork.

The procedure: from raw source to a graded record

Run these eight steps in order. The first three answer the crime, contract, and basis questions once per program; the rest apply per record and per request.

How this goes wrong: failure modes and false positives

The most valuable part of a standard is the list of records that look compliant and are not. Each of these is a false positive a naive grader would pass. Check for each one explicitly.

Two of these deserve extra weight. The Article 14 "sent late but sent" case is subtle because the notice looks fine on the day it arrives; only the acquisition timestamp reveals the breach. This is exactly the pattern the CNIL has fined. The enrichment re-adds a suppressed person case is where most real incidents originate, because one-way syncs and refreshes silently overwrite the flag. Neither is visible unless you check the specific artefact named in the right-hand column.

A seventh trap belongs here too: treating consent as a licence for indefinite storage. Once a documented retention period expires, your lawful basis disappears unless you renew it. Talent-pool records sitting past 24 months without renewed consent are non-compliant even though someone once said yes. This is another reason the standard prefers legitimate interest with a hard retention clock over open-ended consent.

The verification checklist

Run this before calling any record, or any sourcing program, compliant. Each item is checkable against a specific artefact, so two people will grade it the same way.

Keeping the standard current

A sourcing standard decays because the law moves and the tools change, not because the criteria were wrong when written. Set two recurring reviews so the document stays gradeable rather than becoming decorative.

First, re-check the moving figures. The retention windows are anchored to limitation periods that vary by country, and jurisdiction scope shifts - the CCPA candidate and B2B exemptions sunsetting after 2023 is the recent example, and the ICO audited AI recruitment tools in November 2024 and found some retaining applicant data indefinitely without candidates' knowledge. Describe the mechanism in your policy (the discrimination-claim window drives retention; the acquisition date drives the Article 14 clock) so that when a number changes you know which clause to update.

Second, re-run the sample grade on a schedule. The point of the final procedure step is not a one-time audit; it is a standing control. Pull a fresh random sample each quarter, grade every record pass or fail with a reason against the checklist, and delete or fix the failures. If a whole category keeps failing the same criterion, that is a signal to fix the workflow, not the records - most often at the enrichment seam or the opt-out routing. The scarcity of GDPR-skilled owners in the market means the control has to live in the process, not in a person's head.

The standard works when a sourcer, a recruiter, and a lawyer looking at the same record reach the same verdict without a meeting. That is the test to hold it to.