Subject access requests: a simple process for small UK startups

Why SARs land on small teams

A subject access request (SAR) is when someone asks for a copy of the personal data you hold about them. Under the UK GDPR and Data Protection Act 2018, individuals have that right. Early-stage startups often assume SARs only hit larger firms. In practice they arrive from customers, trial users, ex-employees, freelancers, and sometimes job applicants.

You do not need a legal team to handle them well. You do need a clear, repeatable process so one person is not left guessing under a deadline.

This is general information for founders and ops leads, not legal advice. If a request is complex, contentious, or tied to a dispute, speak to a solicitor or a qualified data protection specialist.

What counts as a valid request

A SAR does not have to use formal language or mention “GDPR”. It can arrive by email, support ticket, web form, or even a message on a product chat tool. It can come from the individual or from someone acting for them (with appropriate authority).

You should treat it as a SAR when someone asks for:

• confirmation that you process their personal data
• a copy of that data
• related details (purposes, categories, recipients, retention, sources, and their rights)

You can ask for proof of identity if you are not sure who is writing. Keep that step proportionate. Do not use ID checks to stall a straightforward request from a logged-in user whose email already matches the account.

The clock and the calendar

You normally have one month to respond from the day you receive the request. You can extend by a further two months if the request is complex or you have received several from the same person, but you must tell them within the first month and explain why.

Build the deadline into whatever tool you already use: a shared inbox label, a simple tracker, or your existing task board. Missed deadlines create avoidable risk and eat time later.

A practical workflow for teams of 1–20

1. Log it immediately

Record the date received, channel, requester identity, and a short summary. Assign one owner. If you use a shared ops inbox, agree who triages privacy mail so requests do not sit unread.

2. Confirm scope

Read the message carefully. People sometimes want “everything”, a single invoice trail, or chat logs from a date range. If the request is broad, you may ask them to clarify. You still need to progress the parts you can identify.

3. Pause deletion where needed

If you were about to delete accounts or purge logs as part of normal retention, stop for data that may fall inside the request until you have responded. Coordinate with whoever runs your product database and backups.

4. Search the places you actually store data

Map your search to how your startup really works, for example:

• product database and admin tools
• email and support desk
• billing provider
• analytics or CRM (only personal data, not aggregate stats)
• shared drives and HR folders
• Slack or similar, if you store personal data there
• laptop exports or spreadsheets used by founders

You are looking for personal data about the requester, not every internal document that merely mentions a surname in passing with no link to them.

5. Filter what you should not send

Do not disclose other people’s personal data without a lawful basis or heavy redaction. You may withhold limited material where a specific exemption applies (for example certain confidential references or legal privilege). Exemptions are narrow. If you rely on one, document why and consider professional advice.

Also strip true secrets that are not personal data about the requester (API keys, other customers’ records, security credentials).

6. Package a clear response

Send:

• the data (commonly PDF or CSV, in a locked file if appropriate)
• a plain explanation of what you process and why, in everyday language
• how long you keep it, and who you share it with (processors, key tools)
• a reminder of their other rights (rectification, erasure, objection, complaint to the ICO)

If you refuse part or all of the request, say so plainly, explain the reason, and tell them they can complain to the ICO or seek judicial remedy.

7. Close the loop internally

Note what you sent, what you withheld, and where you searched. That record helps if there is a follow-up and shows you took a reasoned approach.

Fees, refusals, and pushy volume

You usually cannot charge a fee. You may refuse or charge a reasonable fee only when a request is manifestly unfounded or excessive. That bar is higher than “this is annoying” or “we are busy”. Repeated copy-paste demands can sometimes meet it; a single detailed request rarely does. Document your reasoning if you go down this path.

Reduce future pain without building a bureaucracy

A few habits cut SAR effort for small teams:

• Keep a light data map: systems, types of personal data, owners.
• Write short retention rules and actually delete on schedule.
• Avoid dumping unnecessary personal data into shared chat and open spreadsheets.
• Make sure your privacy notice matches what you do, so expectations are clearer.
• Train anyone who reads support mail to spot SARs and escalate on day one.

If you already use StartupDocs for policies and registers, store your SAR log and data map next to your other compliance records so they stay findable when someone is on leave.

When to get help

Bring in a solicitor or specialist if the requester is in a live dispute, asks for CCTV-style material you do not usually handle, involves children, spans multiple group entities, or if you plan to rely on an exemption at scale. For most routine customer or user SARs, a calm internal process and honest search are enough.

Handle the first one slowly and write down what you did. The second one will be faster, and your startup will look organised rather than caught out.