# The Sourced-Candidate Access Request Runbook: Clock, Trace, Disclose, Close

*Take one access request from someone you sourced but never hired, set the right deadline, trace every field and recipient by name, and send a packet plus search log.*

- Canonical URL: https://www.refolk.ai/guides/sourced-candidate-access-request-runbook
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-10-28
- Last reviewed: 2026-10-28
- Reading time: 21 min
- Keywords: how to respond to a subject access request from a sourced candidate, candidate DSAR response recruiting, where did you get my data recruiter request, CCPA right to know request job candidate, GDPR access request source of personal data, subject access request search log template

## Key takeaways

- Under the CCPA the 45 calendar days run from receipt even while you verify identity, so a three-day ID chase uses about 7% of the window, while under UK GDPR Article 12A the clock only starts once requested ID arrives.
- The CJEU in C-154/21 held that controllers must disclose the actual identity of recipients, so "shared with clients" fails wherever you know which client, hiring manager, or vendor received the profile.
- C-487/21 requires a faithful and intelligible reproduction of all the data, so a summary table of fields is not a copy; include the raw outreach messages and notes extracts.
- Tool audit logs cannot stand in for a search log: one common CRM's standard audit log keeps 30 days against the CCPA's 24-month record requirement, a roughly 24-fold gap.
- In Refolk's index, US staffing firms show about 143 recruiting-ops people per privacy or DPO title against 3.6 in the UK, so in US agencies recruiting ops usually owns these requests with little privacy support.
- When a sourced person asks for erasure, keep a minimal hashed suppression entry, or the next enrichment refresh will re-source them.

This runbook is for the recruiting or revenue ops owner who has to answer a data access request from someone they sourced and messaged but who never applied. It takes one request from receipt to a sent response packet, a search log showing what you searched and what you left out, and a clean handoff to deletion or suppression. It covers EU GDPR, UK GDPR, and the CCPA.

## Why is a sourced-person access request harder than a normal DSAR?

A sourced-person request is harder because the record was assembled, not submitted. Its fields came from public profiles, code hosts, enrichment lookups, and outreach tools, and the profile may have gone to several clients. A data subject access request (DSAR) is a person's legal request to see the personal data an organisation holds about them. Most DSAR checklists assume that data sits in one HR or account system.

A sourced person never filled in a form. Someone found their public profile, maybe pulled activity from the public GitHub graph, ran an enrichment lookup for an email address, loaded them into a sequencer, and forwarded the profile to a hiring manager. Each of those steps left data in a different system, and each one is something you may have to disclose.

Three things set this case apart:

- **Every field needs a provenance.** You have to say how and from which source each piece of data was obtained, and "LinkedIn" is often the wrong answer.
- **Every recipient needs a name.** Each submittal to a client creates a new recipient, and named recipients are the default, not categories.
- **Every system needs a log row.** If the person complains to a regulator, your defence is a record of what you searched, what you excluded, and why.

#### Where a sourced person's data lives

1. **Recipients** - Clients, hiring managers, and vendors who received the profile
2. **Outreach** - Sequencer messages, inbox threads, Slack forwards
3. **Working copies** - Spreadsheets, ATS or CRM notes fields, shortlists
4. **Enrichment** - Emails and phone numbers added by lookups, with export history
5. **Origin** - The public profile, code host, or referral where the record began

*A sourced record is built in layers, and an access response has to reach every one of them, from the clients who received the profile down to the platform the first field came from.*

If a reply to your outreach asks "where did you get my data?", treat it as a possible access request and log it that day. Deciding later that it wasn't one costs nothing. Missing the clock costs you a complaint.

## Which deadline applies under GDPR, UK GDPR, and the CCPA?

EU and UK GDPR give one month to respond, which you can extend by two more months for complex requests. The CCPA gives 45 calendar days from receipt, plus one 45-day extension, and requires an acknowledgement within 10 business days. What trips teams up is when each clock starts.

| Regime | Acknowledge | Respond | Extension | Verification time |
|---|---|---|---|---|
| EU GDPR | none set | 1 month | +2 months | not codified |
| UK GDPR (Art. 12A) | none set | 1 month from "relevant time" | +2 months | clock starts at ID receipt |
| CCPA | 10 business days | 45 calendar days | +45 days (90 max) | counts inside the window |

How each clock works:

- **EU GDPR.** One calendar month from receipt. There is no separate acknowledgement period. If you need the extension, you have to tell the person within the first month.
- **UK GDPR.** Article 12A keeps the one-month period but counts it from the "relevant time". That is the latest of three dates: when you received the request, when you received any identity confirmation you asked for under Article 12(6), or when any fee was paid. Under the Article 12A(5) stop-the-clock rule, the time between asking for scoping information and getting it back does not count.
- **CCPA.** Confirm receipt within 10 business days. Respond within 45 calendar days of receipt, however long verification takes. One further 45-day extension is allowed, up to 90 days in total, if you give the person notice and a reason.

This asymmetry shapes how you run the identity check. In the UK, a slow ID check costs you nothing, because the clock hasn't started. Under the CCPA, the same three-day ID chase uses about 7% of the window (3 of 45 days). Start CCPA verification on day 0.

> **Rule:** CCPA deadlines come from the receipt date only
>
> Calculate the CCPA response date as receipt plus 45 calendar days and never move it when verification finishes. If you cannot verify the person within those 45 days, the regulations allow you to deny the request, but the date itself does not move.

### Re-checking the UK rules

Article 12A and the "reasonable and proportionate" search limit came in with the Data Use and Access Act (DUAA), switched on by commencement regulations. Sources disagree on when the search limit took effect: one dates it to Royal Assent, others to the main commencement of Part 5. Don't rely on either date from memory. Check the SI 2026/82 commencement table against the receipt date of the request in front of you. If more than one regime could apply to a person, I calendar the earliest deadline and meet the strictest content standard.

## What must the response packet contain?

The packet has two parts. The first is a faithful copy of the data itself. The second is the statutory explanation: under GDPR, the purposes, categories, named recipients, retention, and source; under the CCPA, the categories, sources, purpose, third parties, and specific pieces. A summary table is not a copy.

### GDPR and UK GDPR: Article 15(1)

The EDPB's summary of Article 15(1) lists what must accompany the copy:

- the purposes of processing
- the categories of personal data
- the recipients or categories of recipients
- the retention period, or the criteria used to set it
- relevant information on how, and from which source, the data was obtained

### CCPA: section 1798.110

A right-to-know request from a job candidate under the CCPA entitles them to:

- the categories of personal information collected
- the categories of sources
- the business purpose for collecting it
- the categories of third parties it was shared with
- the specific pieces of personal information held

### The copy itself

In C-487/21 the CJEU held that the person must get "a faithful and intelligible reproduction of all the data", which can include extracts from documents or databases where they are essential. CRIF, the controller in that case, had sent only a summary list. For a sourced person, that means the actual sequencer messages, the actual notes-field text ("strong Go background, poach from current team"), and the actual spreadsheet row. It does not mean a tidy table of field names.

### Recipients

In C-154/21 (Österreichische Post), the CJEU held that controllers must disclose the actual identity of recipients unless that is impossible or the request is manifestly unfounded or excessive. Categories are enough only where, for example, the specific recipients are not yet known. In that case the data had gone to advertisers, IT companies, mailing list providers, charities, NGOs, and political parties, and listing those types of organisation was the problem.

Courts haven't yet applied this to recruiting. My reading, which is inference and not settled law, is to name the client's legal entity, the individual hiring managers who received the profile, and each vendor the data passed through.

### Sources

Article 15(1) asks for the source. No published guidance says how "source" applies to sourcing tools, for example whether you name the enrichment vendor or the platform the vendor got the data from. My default is to name both layers per field: the tool that delivered the field to you, and the upstream platform where you know it.

> **Note:** Where the law is not settled
>
> Three points in this section are not established publicly: how "source" applies to enrichment tools, how C-154/21 applies to clients and hiring managers, and whether sub-processors must be named. Disclose more than less, and note your reasoning in the search log so a reviewer can see you made a deliberate choice.

> A field you cannot trace to a named source and a collection date is a field you cannot defend.

## Who owns the request, and how strict must the identity check be?

In most agencies recruiting ops owns the request, often with little in-house privacy support. The identity check depends on what the person asks for: two data points for CCPA categories, three plus a signed declaration for CCPA specific pieces, and formal ID in the UK only where it is necessary.

### Who actually owns it

**143:1 - Recruiting-ops people per privacy or DPO title at US staffing firms**

In Refolk's index the US figure is 143 to 1, against 3.6 to 1 in the UK, so US agencies should expect recruiting ops to carry access requests with little privacy support.

| Metric | US | UK |
|---|---|---|
| Recruiting-ops titles | 143 | 18 |
| Dominant title variant | "Recruiting Operations" (64% of 25-person sample) | "Recruitment Operations" (67% of 18) |
| Privacy/DPO titles in staffing firms | 1 | 5 |
| Ops-to-privacy ratio (derived) | 143:1 | 3.6:1 |

These counts come from Refolk's index of professional profiles. They match on exact titles and the numbers are small, so read them as direction, not census. The five UK privacy titles sit at firms including Michael Page, Staffline, and Galago Group. The single US one is at AMN Healthcare.

What this means in practice: if you run ops at a US agency, assume this runbook is yours and that the "privacy lead" in the steps below may be you, outside counsel, or a peer you consult. In the UK you are more likely to have a DPO down the hall.

If you need a peer who has handled these requests, searching by title alone misses about half the field. UK titles favour "Recruitment" and US titles favour "Recruiting", so a search on one variant drops the other. A plain-English ask to [Refolk](/) describes the role and the context rather than matching one exact title string, which gets around the variant problem.

I ran this search: `Data protection officers at recruitment firms in the United Kingdom` - [see the full result list](https://www.refolk.ai/s/v0h0j8v6k6).

*Returns named DPO and privacy-lead profiles at UK recruitment and staffing firms, the people most likely to have run sourced-candidate access requests before.*

### How strict the identity check must be

| Request | Standard | Evidence |
|---|---|---|
| CCPA categories | reasonable certainty | 2 data points |
| CCPA specific pieces | reasonably high certainty | 3 points plus signed declaration |
| UK SAR | proportionate | formal ID only if necessary |

For a sourced person, the strongest match is usually something you already hold. If the request comes from the email address you sent outreach to, that address is a data point, and the profile URL and employer you recorded are more. Under UK GDPR, ask for formal ID only if you need it. Under the CCPA, a request for specific pieces needs the three-point match plus a declaration signed under penalty of perjury, and you keep that declaration with the request record.

If the request arrived as a social media message, don't reply with the data there. The ICO says social media is not a secure delivery channel, so ask for an email address or another delivery route.

### When you can refuse

A request is manifestly excessive only if it is "clearly or obviously unreasonable". It is not excessive just because it asks for a lot of data. The DUAA dropped the proposed "vexatious" refusal ground. A sourced person asking for everything you hold is making an ordinary request.

## The runbook: intake to close, step by step

The runbook has eight steps, running from a calendared deadline on day 0 to an archived log and a suppression entry, with the packet reviewed by about day 20. The durations are my desk estimates, not measured benchmarks, and the owners are suggestions to adapt to your team.

#### Sourced-person access request, receipt to close

1. **Log receipt and tag the regime** - Day 0, about 30 minutes, recruiting ops. Record the receipt date, tag EU, UK, or CA, calendar the deadline, and for CCPA send the acknowledgement within 10 business days.
2. **Verify identity and scope only where needed** - Days 0 to 3, ops plus privacy lead. Match against data you hold, get the three-point match and signed declaration for CCPA specific pieces, and record a reason for any clarification request.
3. **Search every system on the logged list** - Days 1 to 7, ops. Search ATS or CRM, sourcing tool, enrichment, sequencer, inboxes, spreadsheets, and Slack, writing one search-log row per system.
4. **Trace every field to a named source** - Days 3 to 10, ops. Give each held field a named source and a collection date, using enrichment export history rather than assumption.
5. **Trace every recipient by name** - Days 3 to 10, ops plus account managers. List every client entity, hiring manager, and vendor that received the profile, including email and Slack forwards.
6. **Assemble the response packet** - Days 10 to 20, privacy lead. Combine the full copy, the Article 15(1) or section 1798.110 items, and each redaction with its reason, then review.
7. **Deliver over a secure, non-social channel** - Privacy lead. Send by email or a confirmed channel and record the date and channel.
8. **Close and hand off** - Ops. Route any erasure, objection, or suppression request, notify recipients of erasure, keep a hashed suppression entry, and archive the log.

### What goes on the logged system list

The logged system list is a standing inventory of every place a sourced person's data can land. You keep it before any request arrives and search it in full for each one. At minimum:

- ATS or CRM, including notes fields and attachments
- sourcing tools, including Refolk if it is in your stack, plus saved searches and shortlists
- enrichment tools, including export and lookup history
- the sequencer, including sent, scheduled, and bounced messages
- recruiter and account-manager inboxes, including sent mail
- spreadsheets and shared drives
- Slack or other chat, including direct messages

The requester's names, every email address you hold, and their profile URLs are the search terms. Log every term you used, because a search that missed a personal email address is incomplete.

### Deciding what to exclude

The ICO says controllers "must be able to show why a search is unreasonable or disproportionate", and the volume of information to be searched may now be taken into account. That makes a narrow exclusion defensible, but only on the record.

#### Search or document an exclusion

Horizontal axis runs from Low search volume to High search volume. Vertical axis runs from Unlikely to hold data to Likely to hold data.

| Quadrant | What it means |
| --- | --- |
| Likely, cheap to search | Search in full; these are your ATS, sequencer, and enrichment history |
| Likely, costly to search | Search anyway, with targeted terms, and log the method |
| Unlikely, cheap to search | Search it; one log row is cheaper than defending a gap |
| Unlikely, costly to search | Candidate for exclusion, with a written proportionality reason |

*Exclude a system from the search only when it is both unlikely to hold the person's data and costly to search, and write the reason in the log either way.*

The sources disagree on scope. Practitioners advise defining the scope before you search, while the ICO says you cannot force a narrower scope, and clarification cannot be sought on a blanket basis. I resolve it this way: ask only where the request is genuinely ambiguous, say why in the log, and if the person declines to narrow it, search everything.

### The search log

Your tools' own logs won't do this job. One widely used CRM's standard audit log keeps 30 days, while the CCPA requires request records for 24 months.

**24x - Gap between CCPA record retention and a standard 30-day tool audit log**

730 days of required retention against 30 days of default logging means tool logs vanish long before a regulator might ask, so keep a separate search log.

No regulator has published a list of search-log fields or approved a particular format. The template below follows the practitioner advice to record what you searched, what you left out, and why, and adds the source and recipient columns that sourced-person requests need.

**Subject access request search log, one row per system**

```
Request ID:
Requester name(s) and all identifiers used as search terms:
Regime (EU / UK / CA):
Receipt date:
Relevant time (UK only, with reason):
Deadline:
Extension notified (date and reason, or none):

System | Owner | Date searched | Searched by | Terms used | Records found | Fields found | Source per field | Collection date per field | Recipients found | Excluded? | Exclusion reason
```

*Copy into a spreadsheet; add rows for every system on your logged list, including excluded ones.*

### Tracing fields and recipients

For each field, work back from where it sits now to where it first entered your systems. An email address in the ATS was probably not typed in by hand: open the enrichment tool's export history for that record and find the lookup that produced it. A field you can't trace stays in the packet with "source not recorded" written against it. That beats a guess, and it shows you where your intake needs fixing.

For recipients, the ATS share log is the start, not the end. Search sent mail and Slack for the requester's name and profile URL, and ask each account manager directly which clients they sent the profile to. Record the client's legal entity, the people who received it, the date, and the channel.

**Response packet cover, sourced-person access request**

```
Dear [name],

You asked what personal data I hold about you, where it came from, and who it was shared with. This letter and the attached files answer that request, received on [date].

1. A copy of your data: attached as [file names], including outreach messages, notes, and records exactly as held.

2. Why I hold it (purposes): [e.g. identifying candidates for a specific role at a named client].

3. What I hold (categories): [e.g. name, work history, email address, messages].

4. Where each item came from (source and date):
   - [field]: [tool that delivered it], from [upstream platform if known], collected [date]
   - [field]: ...

5. Who received it (named recipients):
   - [client legal entity], sent to [hiring manager names] on [date] by [channel]
   - [vendor name], role: [e.g. email sequencing]

6. How long I keep it: [period, or the criteria used to decide].

GDPR / UK GDPR: you may also ask for correction, erasure, or restriction, object to processing, and complain to the data protection regulator.
CCPA: the categories of sources, categories of third parties, business purpose, and specific pieces are set out in items 1 to 5.

Redactions: [what was withheld and why, item by item, or "none"].
```

*Fill every line; delete the CCPA block for GDPR requests and the GDPR block for CCPA requests.*

## How does a sourced-person access response go wrong?

Most failed responses look complete. They list categories where names were required, credit the last tool instead of the real source, or run the wrong clock. Each failure below comes with the false positive that hides it and the check that catches it.

1. **Answering with categories instead of names.** False positive: "shared with clients". C-154/21 requires the actual identity of recipients whenever you know them. Check: every recipient row carries a legal entity name.
2. **Recording the last tool as the source.** False positive: "LinkedIn", when the email address actually came from an enrichment lookup. Check: open the enrichment tool's export history for each field.
3. **Sending a summary table instead of a copy.** This is exactly what CRIF was challenged over in C-487/21. Check: the packet includes the raw sequencer messages and extracts from the notes fields.
4. **Pausing the CCPA clock for verification.** False positive: a calendar entry reading "verified on day 20, due day 65". The 45 days run from receipt. Check: the deadline is calculated from the receipt date only.
5. **Using stop-the-clock on every UK request.** False positive: a clarification email sent on every request as routine. The ICO says clarification cannot be sought on a blanket basis. Check: the log records why the clarification was reasonably required.
6. **Missing recipient channels.** Profiles forwarded to hiring managers by email or Slack never show up in the ATS share log. Check: search sent mail and chat for the requester's name.
7. **Erasure that deletes the suppression record.** The person gets re-sourced by the next enrichment refresh and messaged again, which is often what triggers the complaint. Check: keep a minimal hashed suppression entry, which the CCPA regulations allow for exactly this purpose.
8. **Delivering the response over social DMs.** The ICO says social media is not a secure channel. Check: the delivery channel is recorded in the log, and it isn't a social platform.

> **Watch out:** The recipient list is where most responses fail
>
> Failures 1 and 6 compound: a team that answers in categories rarely searched sent mail, so the list is both too vague and incomplete. Build the recipient list from inboxes and chat first, then reconcile it against the ATS.

If you have to pick where to spend extra review time, spend it on failures 2 and 6. Those are the two a complainant can prove from their own evidence: an email address they only ever gave to one site, or a hiring manager who called them about a role they never applied for.

## Closing the request and keeping the runbook current

A request closes when the packet is delivered, any follow-on erasure or suppression request is routed, recipients are notified, and the record is archived for the retention period you've set. Then keep the runbook current, because the rules underneath it change through commencement orders and amended regulations.

#### From delivered packet to closed request

1. **Packet delivered** - Date and secure channel recorded in the search log
2. **Follow-on request routed** - Erasure, objection, or suppression logged as its own request
3. **Recipients notified** - Article 19 erasure notice sent to each named recipient
4. **Suppression entry kept** - Minimal hashed identifier blocks re-sourcing
5. **Record archived** - Log, packet, and any signed declaration retained

*Closing a sourced-person request means routing any deletion request, telling every named recipient, keeping a suppression entry, and archiving the evidence.*

### Handing off to erasure or suppression

Sourced people often follow an access request with a deletion request. Under GDPR, Article 19 requires you to communicate erasure to each recipient, which is one more reason the named recipient list from step 5 matters: it becomes your notification list. Under the CCPA, you may keep a record of the request to make sure the data stays deleted. Keep the suppression entry minimal, such as a hashed email address and profile URL, and make sure your sourcing and enrichment tools check against it before records are created.

### Retention

CCPA request records are kept for 24 months, and signed declarations must be kept as part of the record. One privacy-request platform retains request records for 730 days for this reason. GDPR and UK GDPR set no fixed retention period for DSAR records. Choose one, write down the reason, and apply it the same way every time.

### If the person complains

The new section 164A of the Data Protection Act 2018 requires controllers to acknowledge complaints within 30 days. Check the commencement table to confirm it applies on your request date. Your search log and packet are the evidence you'll hand over, so archive them in a form a reviewer can read without your tools.

### Keeping the runbook current

Review this runbook each time one of these sources changes, and at least once a year:

- the version number on the ICO's right of access guidance
- the SI 2026/82 commencement table, for any further DUAA provisions
- 11 CCR §7021 and the CPPA's regulations text, which have been amended before
- the EDPB's Guidelines 01/2022 and its case digest on the right of access

Update your logged system list whenever you add a sourcing, enrichment, or outreach tool. That list is your search scope, and a tool that isn't on it is a system you will forget to search.

#### Before you mark the request closed

- [ ] The deadline was calculated from the correct start date for the regime and met, or a notified extension covers it.
- [ ] Every system on the logged list has a search-log row, including excluded systems with a written reason.
- [ ] Every held field shows a named source and a collection date, or is marked "source not recorded".
- [ ] Every recipient is named as a legal entity or individual, with date and channel.
- [ ] The packet contains the raw copy of the data, not a summary table.
- [ ] Every redaction has a stated reason.
- [ ] The delivery channel is recorded and is not a social media message.
- [ ] Any erasure request has triggered Article 19 notices to each named recipient.
- [ ] A minimal hashed suppression entry exists and your sourcing tools check against it.
- [ ] The search log, packet, and any signed declaration are archived for your set retention period.

## Frequently asked questions

### Do I have to tell a sourced candidate where I got their data?

Yes. Under GDPR and UK GDPR, Article 15(1) requires relevant information on how and from which source the data was obtained, and the CCPA requires the categories of sources. For a sourced person that means saying which public profile, code host, enrichment lookup, or referral each field came from. No published guidance yet says whether to name the enrichment tool or the original platform, so name both where you can.

### Is "we shared your profile with clients" enough to answer a recipient question?

Not if you know who the clients were. In C-154/21 the CJEU held that controllers must disclose the actual identity of recipients, and that categories are enough only where the specific recipients are not yet known, disclosure is impossible, or the request is manifestly unfounded or excessive. For a submitted candidate you almost always know the client, so name the legal entity and the people it went to.

### Does the CCPA 45-day deadline pause while I verify the candidate's identity?

No. The 45 calendar days run from the day you receive the request, however long verification takes. You can take one further 45-day extension, up to 90 days in total, if you notify the person and give a reason. If you cannot verify them within the 45 days, the regulations allow you to deny the request, so start the ID check on day 0.

### Can I make the person narrow their request before I search?

You can ask, but you cannot force it. The ICO says you cannot require a narrower scope and that clarification cannot be sought on a blanket basis. Under UK GDPR the clock pauses only while you wait for clarification that was reasonably required. Record why you asked, and if the person declines to narrow it, search everything.

### What should a subject access request search log include?

At minimum: each system searched, who searched it, when, the search terms used, what was found, and every system left out with the reason. The ICO says you must be able to show why any search was unreasonable or disproportionate. No regulator has endorsed a specific set of log fields, so treat the template in this guide as a defensible floor rather than an approved format.

### If the candidate also asks me to delete their data, can I keep anything?

Keep a minimal suppression record and the request record itself. The CCPA regulations let a business keep a record of the request to make sure the data stays deleted, and request records must be kept for 24 months. Without a hashed suppression entry the next enrichment refresh will re-source the person. Under GDPR, send erasure notices to each recipient as Article 19 requires.

---

*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/sourced-candidate-access-request-runbook*