The Data Access and Deletion Request Runbook

A candidate or prospect has emailed asking what personal data you hold on them, or asking you to erase it. This runbook is for the recruiting operations or revenue operations person answerable for the answer, and it takes you from the moment the request lands to a verified, defensible response delivered inside the legal deadline. It is scoped to the people and records a search operation actually holds: profiles, contact data, sourcing notes, and the CRM or ATS rows built from them.

This is not a general privacy explainer. It assumes you already have a retention schedule and a suppression register. What you need now is the sequence for a live incoming request with a statutory clock running against you.

What counts as a valid request, and when the clock starts

A rights request is valid the moment it is clear that a person is asking for their own information, and the response clock starts on the day you receive it. The requester does not have to use specific words, cite legislation, or send it to a named contact.

A person can make the request verbally or in writing, including through social media. It counts if it is clear they are asking about their own data. That breadth is the first trap: a request buried in a reply to an outreach email is still a request, and the day it arrives is day one.

The two regimes you are most likely to work under set different deadlines and, critically, treat identity verification in opposite ways.

Under UK GDPR you must respond without undue delay and within one month of receipt. That one month begins on the date the request was received, not the day after, so a request received on 3 September is due 3 October. You may extend by up to two further months where the request is genuinely complex or where you have received a number of requests from the same person, but you must tell the individual, with reasons, before the initial month expires.

Under CCPA and CPRA you must respond to a request to delete, correct, or know no later than 45 calendar days after receipt. A further 45 days is available, giving 90 in total, provided you give the consumer notice and an explanation. The regulator has signalled that extensions should not be routine, and systematic use may be treated as non-compliance.

Verify identity before you disclose anything

Your first substantive job is to be satisfied you know who the requester is and that the information relates to them. Sending one person's data to someone impersonating them is a breach, so verification is not a formality you can skip under deadline pressure.

The rule is reasonable and proportionate. Only ask for formal identification where there is genuine doubt. If a staff member or account holder your team already knows makes the request, demanding a utility bill is unreasonable and looks like a delaying tactic. The test is whether you can be confident, not whether you can collect the most paperwork.

Where the two regimes diverge is what verification does to your clock. Under UK rules, the response timescale does not start until you receive the information you asked for, so requesting ID early actually protects your time. Under CCPA the 45-day clock begins on receipt regardless of how long verification takes, and if you cannot verify within the period you may deny the request. A US operation cannot borrow the UK habit of pausing and waiting.

CCPA verification is tiered by what the person asked for. A request to know the categories of data needs two data points that match your records. A request for specific pieces of data needs three data points plus a signed declaration under penalty of perjury. Match the rigour to the sensitivity of what you are about to hand over.

This step is where most requests actually resolve, and it is worth internalising why. In one disclosed set of real outcomes, a large business received 45 requests to know and denied 27 of them for failure to verify identity, and received 143 deletion requests and denied 127 for failure to verify or confirm. Verification, not redaction and not exemptions, is the dominant reason requests do not proceed.

What a complete response actually contains

A response is more than a copy of the data. It confirms whether you are using the person's information, provides a copy of that information, and includes supplementary details about how and why you hold it.

The supplementary information covers the purposes you use the data for, the categories of data, who it is shared with, how long it is kept, where it came from, and whether any automated decision-making applies. In a sourcing operation, "where it came from" is a real question: if a profile was built from public LinkedIn and Crunchbase records or the public GitHub graph, say so.

The recipient disclosure has tightened. You must now disclose specific recipients, not just categories of recipient, and categories are only acceptable where naming specific recipients would be genuinely impossible. For a sourcing team this means you must be able to name the enrichment or outreach providers you passed the data to. If you cannot, that is a data-mapping gap to fix before the next request, not an excuse in this one.

For a deletion request, the scope is wider than access. Under CCPA, deletion has no lookback period and the obligation extends to all data you hold unless an exception applies. A team that applies the access-request twelve-month window to an erasure request will under-comply. Search everything and remove or suppress it, applying exceptions item by item.

Dear [name],

Following your request received on [date], I confirm that [organisation] holds personal data about you.

Enclosed is a copy of that data. This letter also sets out the supplementary information you are entitled to:
- Purposes we use your data for: [purposes]
- Categories of data held: [categories]
- Recipients your data was shared with: [named recipients]
- How long we keep it: [retention]
- Source of the data: [source, e.g. public professional profiles]
- Automated decision-making: [none / description]

Some information has been redacted where it relates to other individuals, in line with Article 15(4) and section 45 of the Data Protection Act 2018.

If you are unhappy with this response you may complain to us directly, and you may complain to the supervisory authority.

Run the request start to finish

This is the procedure. Run it in order. Each stage names who acts, a rough window, and what "done" looks like so you can hand the request between people without losing the thread.

On the search step, be honest about where a sourcing operation actually keeps data. It is rarely one system. Searches should cover the ATS, the CRM, shared email, and professional social channels where activity is in a commercial or professional context. Log each system you queried, because the defensibility of your response rests on showing the search was reasonable, not on it being exhaustive.

If your operation has no dedicated privacy owner, this is the point where the runbook earns its keep. In Refolk's index there are 691 UK profiles titled Data Protection Officer against 79 in the US, an 8.7x gap. US revenue operations teams therefore far more often handle rights requests without a DPO in the building, which raises the value of a written procedure and a known escalation contact you can reach with Refolk when a hard exemption call lands on your desk.

Redaction, third parties, and when you can refuse

The individual is entitled only to their own personal data, so you must remove or redact other people's data before disclosing. The right is to information, not to your documents, which means you can redact a document where the third-party content does not form part of what was requested.

Work the three-step third-party test on each item:

• Can you comply without disclosing the third party's data? If yes, do that.
• Has the third party consented to disclosure? If yes, you may disclose.
• Is it reasonable to disclose without consent? This is the judgement call, weighing the third party's rights against the requester's.

The subtle failure here is redaction that does not actually hide anyone. Removing a name does not always make a person unidentifiable. There will be situations where you can reasonably assume the requester will work out whose name was masked from the surrounding context. Apply a "reasonably known to the requester" test, not a "did I black out the name" test.

Refusal is narrow and must be defensible. Under UK rules you can only refuse where an exemption or restriction applies, such as a request being manifestly unfounded or excessive. "Manifestly" means it must be obvious or clear. A request could be excessive if it repeats or overlaps recent requests from the same person, but it is not excessive simply because a large amount of data is asked for. In that case you ask the person to narrow the scope rather than refusing.

If you do refuse, you must tell the person the reasons and be able to demonstrate them to the person and, if asked, to the regulator. A refusal you cannot evidence is a refusal you will lose.

How this goes wrong

Most requests do not fail on the hard legal calls. They fail on procedure and on false assumptions carried over from the wrong regime. These are the failure modes to check yourself against before you send.

• Starting the clock wrong. Teams log the deadline as the day after receipt and miss by a day. The limit begins on the date received.
• Treating volume as complexity. Extending to three months just because there is a lot of data. A request is not complex merely because it involves a large volume of information.
• Over-asking for identification. Demanding a passport from a logged-in account holder your team already knows. Match the ID request to genuine doubt, not to habit.
• Assuming CCPA pauses for verification. A widespread false belief. The CCPA clock begins on receipt regardless of how long verification takes.
• Redaction that does not hide identity. Removing names when the requester can still work out who was masked. Apply the "reasonably known" test.
• Routine extensions. Systematic use of the extension may itself be treated as non-compliance.
• Deleting only recent data. Applying the access lookback to a deletion request. There is no lookback period for CCPA deletion.
• Refusing because there is a live dispute. Being in a grievance, tribunal claim, complaint, or dispute does not invalidate a request.

The accountability record and keeping the runbook current

The response is not finished when you hit send. You have to be able to show what you did and why, which means the accountability record is a deliverable in its own right, not an afterthought.

CCPA is prescriptive: keep records of consumer requests and how you responded for at least 24 months. Those records can live in a ticket or log capturing the date of the request, its nature, how it was made, the date and nature of your response, and the basis for any denial. Under UK rules, if you relied on an exemption you must justify and document what the exemption relates to and why you used it.

The defensibility of your redactions lives in this internal record, not in the cover letter. The letter can simply state that third-party data was redacted per Article 15(4) and section 45 of the Data Protection Act 2018. You do not have to justify each redaction to the requester, but your internal log must contain the detail. A thin log is the single most common accountability failure point.

Keep the runbook current by re-checking two things on a schedule rather than trusting a snapshot. First, the statutory clocks and supplementary-information requirements change; confirm the current deadline rules and the list of required supplementary fields against the regulator's own guidance before you rely on this document for a live request. Second, your recipient list drifts as you add or drop enrichment and outreach providers; keep the data map that lets you name recipients up to date, because the day a request lands is the wrong day to discover you cannot say where the data went.

Run the procedure the same way every time, log as you go, and the hard part stops being the law and starts being the discipline. That is exactly what a runbook is for.