Subject access request: answering one without panicking

A subject access request — often shortened to SAR or DSAR — is someone asking you for a copy of the personal data you hold about them, along with an explanation of what you do with it. Under data protection regimes such as the GDPR it is a right, it comes with a deadline measured in weeks rather than months, and it can arrive from a customer, an employee, a former employee or someone you have never heard of.

The first one is always the worst, because the work is not the copying — it is discovering how many places personal data lives. The email archive, the CRM, the support tickets, the spreadsheet on somebody's laptop, the messages in the team chat. A request that takes three weeks unprepared takes an afternoon when you already know where to look.

What a subject access request actually covers

• Personal data you hold about the requester, in any system, including backups you can reasonably search.
• The purposes you use it for, and the legal basis where your regime requires one.
• Who you have shared it with, or the categories of recipient.
• How long you keep it, or how that period is decided.
• Where the data came from, if you did not collect it from them.
• A copy of the data itself, in an intelligible form.
• It is not limited to formal records: emails and messages about a person are usually personal data too.

The request does not have to be formal, does not have to use the phrase subject access request, and does not have to go to a specific address. An email to a colleague saying send me everything you hold on me can start the clock. That is why the intake step matters more than the template: everyone needs to recognise one and know where to forward it.

The steps that keep it manageable

1. Log the request the day it arrives, with the date received — the deadline runs from then.
2. Verify who the requester is, proportionately. Do not demand a passport for a simple case, and do not send data to the wrong person.
3. Clarify the scope if the request is very broad, but do not use clarification as a delaying tactic.
4. Search every system on your list, including email, chat and any shared drive.
5. Review what you found for other people's data — third parties appearing in the same emails need consideration before disclosure.
6. Apply any exemptions your regime provides, and record why each was applied.
7. Send the response in a readable format with the accompanying explanation of purposes, recipients and retention.
8. Record what was sent and when, and keep it — the record is your evidence of compliance.

The part that trips people up

Documents rarely contain one person's data. An email thread about a complaint may include the requester, a colleague who wrote about them, and a customer mentioned in passing. Handing over the raw thread discloses those other people; redacting everything makes the response useless. The judgement — what can be disclosed, what must be withheld or redacted — is the real work, and it is the reason a SAR takes longer than an export.

Two other common misunderstandings. First, a request can be inconvenient, badly worded or motivated by a dispute, and it is still valid. Second, deleting data after a request arrives, to avoid disclosing it, is a serious matter in most regimes — the correct response to an awkward request is to answer it properly.

Preparing before the first one arrives

The single highest-return preparation is a written list of every place personal data lives, with an owner for each. That list is useful for several other obligations too, and it converts the search from an archaeological exercise into a checklist. Second is telling the team what a request looks like and where to forward it, since the clock starts when it reaches anyone in the organisation, not when it reaches the right person.

Handling the intake

Ettex Forms works as the intake point: a short form on your site capturing who is asking, what they are asking for and how to reach them, with submissions landing in one place so nothing sits unnoticed in a personal inbox. That fixes the two failures that cost the most days — a request nobody logged, and a request nobody could find again.

It does no more than that. There is no deadline tracking, no search across your systems, no redaction tooling and no case management — the searching, the judgement about third-party data and the response are done by a person. Nothing here is legal advice either: the rights, exemptions and deadlines depend on the regime that applies to you, and for a contested or complex request that is a question for someone qualified in it.

Two things make a request answerable within the deadline. An information asset register tells you where personal data actually lives, and a data retention policy explains why some of it no longer exists — which is a legitimate answer only if the policy predates the request.

Log it the day it arrives, know in advance where personal data lives, budget the time for third-party review rather than the export, and keep a record of what you sent.