Day Zero for Data Requests: A Runbook for UK Client Teams

Client contacts rarely send data requests in a tidy format. A request may arrive as a forwarded email, a passing comment in a review meeting, or a formal letter copied to several people. The operational risk is not usually a deliberate failure. It is a request that sits in a shared inbox while everyone assumes someone else has picked it up.

Under the UK GDPR and the Data Protection Act 2018, most subject access, correction, and deletion requests must be handled within one month of receipt. That period can be extended in limited circumstances, but the extension is not a substitute for a working process. The practical answer is a runbook that starts on day zero and ends with a signed record of what was done, why, and by whom.

Start the file before you decide anything

Create a single request file as soon as a request is recognised. Do not wait for confirmation that it is valid. The file should record the date of receipt, the channel, the requester, their relationship to the organisation, the type of request, the deadline, the assigned owner, and the current status. A shared inbox is not a register. A spreadsheet or case-management tool is.

Use a reference that will survive staff changes. Record the request in the requester's own words where possible, then summarise the scope in neutral language. If the request is ambiguous, note what you understood and what you have asked the requester to clarify. This prevents the scope from drifting later.

Acknowledge receipt where it is sensible to do so. A short holding reply does not stop the clock, but it reduces the chance of duplicate requests and gives the requester a route for corrections. Keep the acknowledgement factual: you have received the request, you are reviewing it, and you will respond by the deadline or sooner.

Confirm the requester before you search

Identity checks should be proportionate to the sensitivity of the data and the risk of disclosure. For an established client contact, a call-back to a known number may be enough. For a new contact or a request that could expose sensitive information, ask for evidence that is reasonable in the circumstances. Do not ask for a passport simply because it feels thorough.

If someone is acting on behalf of a data subject, record the authority. If the request comes from a client organisation rather than an individual, separate the organisation's request from any personal data request. They are not the same thing and should not be handled in the same file unless the link is clear.

Where clarification is needed, seek it promptly and record the date. The one-month period should not be allowed to drift while messages are exchanged. Set a follow-up date in the file and keep the original deadline visible.

Define the search perimeter

The most common failure in a data request is an incomplete search. The second most common is an excessive one. Define the perimeter before opening systems: which custodians, which systems, which date range, and which search terms. Include email, CRM records, shared drives, finance systems, support tickets, call notes, and any relevant project folders. Consider archived material and backups only where they are reasonably accessible and relevant.

Record negative results as well as positive ones. A note that a system was searched and returned nothing is useful evidence if the response is later questioned. Keep the search log with the request file.

Do not provide commentary or internal opinion unless it forms part of the personal data requested. The requester is entitled to their personal data, not to a narrative about how the team feels about them. Extract the relevant material, review it, and keep the extraction consistent with the scope recorded at intake.

Redact third-party information

Before documents are released, review them for information about other people. Names, contact details, and identifying comments may need to be redacted where disclosure would breach another person's data protection rights or where an exemption applies. Redaction should be recorded in a redaction map: document name, page or field, what was removed, and the reason.

Use proper redaction tools. Drawing black boxes over text in a PDF is not redaction if the text remains underneath. Check metadata, tracked changes, comments, and hidden columns before sending. A second reviewer should check the redacted set, particularly where the request is sensitive or the documents are numerous.

Do not redact material simply because it is awkward or because it refers to a difficult client conversation. If the information is the requester's personal data and no exemption applies, it should be disclosed. Record the basis for every redaction so that legal and operations can review the decision without reconstructing it from memory.

Handle correction and deletion requests

A correction request is not always a demand to overwrite a record. If you agree the data is inaccurate, correct it and tell relevant recipients where required. If you do not agree, record the reasons and consider adding a supplementary statement so the requester's position is noted. Keep the original record where retention rules or audit requirements require it.

Deletion requests are rarely absolute. Retention obligations may arise from tax, contract, regulatory, or legal-claims requirements. Create a short retention conflict memo: the data concerned, the retention policy, the retention period, the reason deletion cannot be completed in full, and the reviewer who approved the decision. If some data can be deleted and some must be retained, say so clearly and explain the difference.

Keep legal and operations aligned

A short sign-off template is more useful than a long policy that nobody reads. The file should be capable of being reviewed by legal, operations, and the client owner without a meeting. A practical template includes:

• Request reference and requester
• Date received and statutory deadline
• Scope agreed and clarification sought
• Systems and custodians searched
• Redactions applied and reasons recorded
• Retention conflicts and decision
• Response issued, date, and method
• Owner and approver sign-off

Use one approver for routine requests and an escalation route for requests involving sensitive data, large document sets, or disputed retention. The approver should sign the file, not just the response letter.

Close the file, then learn from it

Send the response securely and record the date and method. Update the register. If an extension was used, record the reason and the new deadline. If a request revealed a gap in record-keeping, note it without turning the request file into a general audit.

Review the register quarterly. Look at volume, turnaround time, redaction effort, and the number of retention conflicts. A team that can see those patterns can fix the causes: duplicate client records, unclear retention rules, or documents that are harder to search than they should be. The thirty-day file is not only a compliance artefact. It is a practical test of how well the organisation knows its own client information.