The Access-Request Response for a Cold-Sourced Contact

A person you sourced but never spoke to emails and asks to see everything you hold on them and where you got it. This guide is for recruiting operations, revenue operations, and anyone answerable for how the data was gathered, and it runs the right-of-access response from receipt to a defensible disclosure pack. It is built for the case the generic online guides miss: the subject never applied, so the hard parts are proving where cold-sourced data came from, disclosing the retention basis, and redacting the third parties who appear in your enrichment and outreach records.

An access request is disclosure, not erasure. Most operations playbooks cover deletion, scheduled purges, first-contact notice, and legitimate-interest assessments. None of those help you here. Answering "show me what you hold and where you got it" has its own clock, its own required contents, and its own traps, and a cold contact makes each one harder because there is no application form to anchor the record.

What an access request is and why cold sourcing makes it harder

A right-of-access request asks you to disclose the personal data you hold about someone plus a defined set of supplementary information, within a statutory deadline. It is not a deletion request and it is not a first-contact notice. The job is to show the subject their data and explain its origin, recipients, and retention.

Cold sourcing changes the difficulty in three specific ways. First, there is no applicant-provided origin, so the source field is the only evidence of where the data came from, and Article 15(g) makes that disclosure mandatory. Second, the record is scattered: a sourced contact leaves traces in the ATS, the CRM, enrichment logs, outreach sequences, team inboxes, and screening tools. Third, cold outreach names other people. Every colleague, referrer, and hiring manager mentioned in your sequences becomes a third-party redaction decision.

The volume pressure is real and rising. Sourced hires are cited as eight times more likely to be hired than inbound applicants, and rediscovered candidates made up 46% of sourced hires in 2026, up from 26% in 2021. More long-lived cold records means more files that can each trigger an access request.

What the deadline is and when the clock starts

Under GDPR and UK GDPR Article 12(3), you must respond without undue delay and at the latest within one calendar month of receipt. That is one month, not thirty days: a request received on January 15 is due February 15. The clock starts the day the request arrives, not the day you read it, forward it, or get around to it.

You can extend by up to two further months where the request is genuinely complex or where there are numerous requests, but only if you inform the requester of the extension and its reasons within the first month. A late extension notice is itself a breach. Under CCPA and CPRA the response period is 45 days, extendable by a further 45.

There is one nuance that separates a met deadline from a missed one, and it hinges on the difference between two mechanisms.

Identity verification delays when the clock starts. Clarification pauses a clock that is already running. The two work independently. Where identity proof is genuinely necessary, the UK position is that the response timescale does not begin until you receive that proof. But you cannot exploit this: you must request ID as soon as possible, and waiting two weeks does not let you restart from day fourteen. The clock can be treated as starting when you receive sufficient information to verify identity, only if you asked promptly.

The UK regime also moves. On 7 April 2026 the ICO amended its subject access guidance to reflect Part 5 of the Data (Use and Access) Act 2025, which commenced 5 February 2026. Treat statutory guidance as something to re-check against the current ICO text rather than a fixed value you memorise once.

What Article 15 requires you to disclose

Article 15 requires more than the raw records. Alongside a copy of the personal data, you must disclose the purposes of processing, the categories of data, the recipients or categories of recipient (in particular any third-country recipients), the envisaged storage period or the criteria used to set it, the right to rectification, erasure, restriction and objection, the right to complain to a supervisory authority, any available information as to the source where the data was not collected from the subject, and the existence of any automated decision-making.

For a cold-sourced contact, the source line is the load-bearing one. The right is explicitly not limited to data collected from the data subject: where it came from other sources, any available information as to source must be provided. Because your contact never applied, the enrichment log or mined-commit field is the only evidence of origin you have. Enrichment tools return contact data with claimed verification rates of 85 to 95%, but with variable provenance, so the source is often the one field never captured at ingestion. If you did not record it then, you cannot honestly disclose it now.

CCPA and CPRA frame the same instinct differently. The right to know discloses categories over a lookback and can be requested up to twice in a 12-month period: the categories of personal information collected (back to January 1, 2022), the categories of sources, the business or commercial purpose, and the categories of third parties the information was shared with. Where a subject asks for named recipients rather than categories, the name of the recipient must be disclosed if requested.

For a cold contact the source field is not a footnote. It is the disclosure the whole request turns on.

Find every system the record lives in

The month is usually consumed by search, not by disclosure. A cold-sourced contact's data is spread across a dozen systems with no single view, and if you start looking only after the request lands you have already lost days. Build the data map before a request arrives: identify every system where candidate data is stored, who has access, and how to export from each.

For a sourced contact, the following record types are typically in scope. This taxonomy is not authoritatively established in a single public source, so treat it as a working checklist to adapt to your own stack rather than a closed list.

• The record in the ATS, including any resume you attached and stage history
• Notes, tags, and scoring in the CRM
• Enrichment logs holding verified emails and phone numbers, and critically the source of each
• Outreach sequences and the messages sent, which name other people
• Team inboxes and shared mailboxes
• Screening or scoring data from any AI tool
• Scheduling-platform records

The reason to capture the source field per record, not once per person, is Article 15(g). Each exported field should map to a documented origin. A record disclosed without its source breaches the article even if the record itself is complete.

The privacy owner who runs this is not evenly available across markets. In Refolk's index of professional profiles, the United Kingdom shows 712 Data Protection Officer or Privacy Officer profiles, the United States 472, and Germany 206.

A multi-country recruiting operation cannot assume a local privacy owner exists to run each response. That 3.46x gap between the UK and Germany is why a documented playbook, rather than headcount, is the control that scales. When you do need to find or brief the person who owns this, describing the role precisely matters more than volume.

Run the response start to finish

The procedure below runs the request from receipt to delivery inside one month. The day ranges are a working schedule for a moderate-volume request; compress or extend them to your own load, but keep the order.

Redact third parties without over-redacting

When outreach notes and CRM records name other people, you decide each one against the ICO three-question balancing test. The obligation is to provide information, not documents, so you can redact a document where third-party information does not form part of what was requested.

You are not obliged to seek consent; the ICO is explicit about that. If you have no consent and are not satisfied disclosure is reasonable, withhold the third party's identity but still provide as much of the requested information as you can. Harrison v Cameron [2024] confirmed the controller has a wide margin of discretion, but it must be exercised reasonably and the reasoning documented. That documentation is the point: an undocumented redaction decision is indistinguishable from a guess when challenged.

Redaction volume scales with cold outreach, not with the candidate. A single sourced contact's file can name colleagues, referrers, and hiring managers across multiple sequences, so expect dozens of balancing decisions per file, each logged.

Where you refuse the whole request, the bar is high. Article 12(5) permits refusal or a reasonable fee only where a request is manifestly unfounded or excessive, and the burden of proving that threshold is on you. Manifestly means it must be obvious. Examples of manifestly unfounded requests include ones showing no intention to exercise the right, such as offering to withdraw for payment, or ones that are malicious or harassing. There is currently no regulation setting a fee cap, so any charge must be a reasonable rate you can justify. If you refuse, you must give the reasons and be able to demonstrate them to the person and, if asked, to the ICO.

How this goes wrong

The failure modes below are where defensible responses turn into breaches. Each has a false positive: something that looks correct in your own records but is not.

Clock started late. Filing the request in a shared inbox and dating it from when someone opened it. The false positive is a register that shows "responded within a month" measured from the wrong day. Check the receipt timestamp against the register, not the read date.

ID request used to stall. Asking for identity proof two weeks in to buy time. The false positive is an apparently paused clock. Waiting two weeks before asking for ID does not let you restart the clock from day fourteen.

Clarification abused as delay. Sending a clarification query to a request that was already clear. The clarification must be reasonable and specific and cannot be a tactic to delay. A clock stopped by an unnecessary clarification is a clock that never legitimately stopped.

Visual-only redaction. This is the most dangerous error. Drawing black rectangles over text creates an illusion of redaction while the data remains fully extractable underneath. The false positive is a pack that looks redacted on screen and leaks in full when the text layer is copied.

Redacting names but leaving identifiers. Removing a name while leaving enough surrounding detail that the requester can still work out who it was. Redaction is about removing identifiability, not just the string.

Generic recipient categories. Listing "partners" when the subject asked for names. The name of the recipient must be disclosed if the subject requests it.

Blanket "manifestly excessive" labelling. Applying a standing policy that treats a class of requests as excessive. Guidance warns against a blanket policy; you must be prepared to justify each case if challenged.

Missing the enrichment source field. Disclosing the record but not where it came from, breaching Article 15(g). Check that every exported field maps to a documented source before delivery.

The exposure behind these is not theoretical. UK fine exposure is cited at up to £17.5 million or 4% of global turnover, and access requests make up roughly a third of complaints reaching EU supervisory authorities. The failure modes above are the ones most likely to convert a routine request into one of those complaints.

Deliver a defensible pack and keep the process current

Before you send, verify the pack against a fixed checklist rather than trusting your own memory of what you did. Delivery in a commonly used electronic format is required where the request came in electronically.

Two habits keep the process current. First, keep the data map alive: every time you add a sourcing tool, enrichment source, or outreach platform, add it to the map and confirm the source field is captured at ingestion. The cheapest access response is one where provenance already exists. A tool like Refolk that returns the person alongside the public source of the record makes the Article 15(g) disclosure a captured field rather than a forensic reconstruction after the fact.

Second, re-check the statutory position rather than memorising values. The UK moved with the Data (Use and Access) Act 2025 commencing 5 February 2026 and the ICO amending its subject access guidance on 7 April 2026. Deadlines, fee rules, and verification guidance change by regulation and guidance, so treat the ICO's current subject access text and the relevant supervisory authority as the source of truth on the day you respond, not this document.

A documented playbook is the control that scales when privacy-owner supply does not. With 712 DPO profiles in the UK against 206 in Germany, you cannot rely on a local owner in every market. The register, the data map, and the exemption log turn a right-of-access request into a repeatable procedure any RecOps owner can run inside the deadline.