A subject access request under UK GDPR starts a one-month clock the moment it lands in your inbox, and the ICO does not care that it arrived on a Friday afternoon. This guide walks through the exact steps to verify, scope, search, and deliver a compliant response before that deadline hits.
Why this matters
A subject access request (SAR) is a legal right under Article 15 of UK GDPR. Anyone can ask what personal data you hold on them, why you hold it, and who you've shared it with.
Miss the one-month deadline and the requester can complain straight to the ICO. That complaint can turn into a full audit of your data handling, not just the one request.
Most small businesses don't fail SARs because they refuse to comply. They fail because nobody owns the process, records live in five different systems, and the deadline passes while someone tries to remember where the CRM export button is. The best GDPR compliance software for UK small businesses exists precisely to close that gap.
What you'll need
- A named owner for every SAR that comes in — one person, one inbox, no ambiguity
- An identity verification process (photo ID, account login, or a security question you already store)
- A map of every system holding personal data: CRM, HR platform, email, ticketing tool, paper files
- A template response letter you can adapt in minutes, not hours
- A redaction process for third-party data mixed into the same records
- Roughly 3-6 hours of staff time for a straightforward request; far more for a complex one
The steps
1. Confirm receipt and start the clock
Log the date the request arrived — not the date you noticed it. The one-month deadline under UK GDPR runs from receipt, and "I didn't see the email until Tuesday" is not a valid extension.
Acknowledge the request in writing within a day or two. This isn't legally required, but it stops the requester escalating to the ICO out of frustration while you work.
Common mistake: starting the clock from when the request is "assigned" internally rather than when it physically arrived.
2. Verify the requester's identity
You cannot hand over someone's personal data to whoever happens to email you claiming to be them. Ask for a form of ID that matches records you already hold — an account login, a matching email address, or a photo ID for higher-risk cases.
This step protects you from a second, worse GDPR breach: disclosing data to the wrong person. It also gives you a defensible paper trail if the ICO asks how you verified the request.
Expected outcome: identity confirmed within 2-3 business days, or the clock pauses until it is.
3. Scope the request
Read the request carefully. Some are broad ("all data you hold on me"), others are narrow ("the emails between me and your support team in March 2026").
If the request is genuinely unclear, ask for clarification — this is one of the few situations where you can pause the one-month clock while you wait for a reply. Don't use this as a delay tactic; the ICO expects a proportionate, good-faith question, not a stalling email.
4. Search every system that holds personal data
This is where a documented record of processing activities for GDPR pays for itself. If you already know which systems process which categories of data, you search five places instead of guessing across fifteen.
Check the obvious systems — CRM, HR platform, email — and the less obvious ones: shared drives, Slack DMs, call recordings, and paper files in a filing cabinet nobody's opened since 2024.
Common mistake: searching only the system the request seems to reference and missing personal data that migrated into a spreadsheet somewhere along the way.
5. Review for third-party data and exemptions
Emails and case notes often mention other people. You must redact their personal data unless they've consented to disclosure or the data is genuinely about the requester alone.
Check for statutory exemptions too — legal privilege, ongoing negotiations, or data that would reveal a whistleblower's identity can be lawfully withheld. Document why you withheld anything; an unexplained gap looks worse than an explained one.
6. Compile and redact the response
Build the response as a single package: the personal data itself, plus a plain-English summary covering why you hold it, who you've shared it with, and how long you'll keep it. Retention detail matters here, and it should match what your policy actually says — see how to build a GDPR data retention policy if that document doesn't exist yet.
Redact third-party names, account numbers that aren't the requester's own, and any exempted material, then double-check the redactions actually render as redacted in the final file. A black box in a PDF that still lets you copy-paste the text underneath is not a redaction.
Common mistake: sending a raw data export instead of a readable, organised response — technically compliant, practically useless, and it invites a complaint anyway.
7. Deliver the response and log it
Send the response through a secure channel — encrypted email or a password-protected file, not a plain attachment. Confirm delivery and log the date, method, and what was included.
That log matters if the same requester comes back in six months claiming they never received anything, or if the ICO asks you to evidence the response.
Automate your SAR evidence trail
Centralise where personal data lives so every request gets answered inside the one-month window.
Troubleshooting
The request is manifestly excessive or repetitive. You can charge a reasonable fee or refuse, but you must explain your reasoning in writing and be ready to justify it to the ICO if challenged.
You can't verify identity. Pause the clock and ask for more proof rather than guessing. A wrongly disclosed record is a worse outcome than a slightly delayed one.
Data is spread across paper files with no index. Treat this as a one-off audit trigger — once you've searched it manually this time, build a digital record of processing activities so the next request takes hours, not days.
Third-party data is tangled through every record. Redact by exception rather than trying to rebuild each document from scratch — mark what must come out, then export.
The request arrived via a social media DM or a personal WhatsApp message. It still counts. The clock starts from receipt regardless of channel, so route it to your named SAR owner immediately.
An employee submits a SAR during a live grievance or dispute. Handle it exactly like any other request — the timing of a dispute doesn't change the legal deadline or the scope of what you must disclose.
Tools and resources
- A documented record of processing activities so you know where data lives before a request arrives
- A written data retention policy that matches what you actually tell requesters
- A named SAR owner with a clear escalation path
- Encrypted delivery method for the final response
- A logging system that timestamps receipt, verification, and delivery for every request
OneClickComply centralises the evidence and process documentation that SAR responses depend on, so the record of processing activities you need in step 4 already exists rather than getting built from scratch under deadline pressure.
What to do next
A SAR response is reactive by nature — something lands, you have one month. The businesses that handle these smoothly in 2026 are the ones that did the unglamorous groundwork beforehand: mapped their data, documented retention, and assigned ownership before the first request ever showed up.
If a SAR response also surfaces something that looks like a personal data breach — data sent to the wrong person, records exposed longer than they should have been — that's a separate clock entirely, and it starts the moment you become aware of it.
Frequently asked questions
One last thing
The fastest SAR responses in 2026 don't come from faster searching — they come from never having to search blind in the first place. Businesses with a current record of processing activities routinely answer requests in under a week; businesses without one burn most of the one-month window just figuring out where the data lives.