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
- Log the request the day it arrives, with the date received — the deadline runs from then.
- Verify who the requester is, proportionately. Do not demand a passport for a simple case, and do not send data to the wrong person.
- Clarify the scope if the request is very broad, but do not use clarification as a delaying tactic.
- Search every system on your list, including email, chat and any shared drive.
- Review what you found for other people's data — third parties appearing in the same emails need consideration before disclosure.
- Apply any exemptions your regime provides, and record why each was applied.
- Send the response in a readable format with the accompanying explanation of purposes, recipients and retention.
- 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.
Frequently asked
What is a subject access request?
A request from an individual for a copy of the personal data an organisation holds about them, plus information about how it is used, shared and retained.
Does it have to be in writing or use a specific form?
Generally no. An informally worded message to any member of staff can be valid, which is why everyone needs to recognise one.
How long is there to respond?
Regimes differ — commonly around a month, sometimes extendable for complex requests. Check the rules that apply to you and log the date received.
Do emails count as personal data?
Usually yes. Emails and messages about an identifiable person are typically within scope, not just formal records.
What about other people appearing in the same documents?
Their data needs separate consideration before disclosure — redaction or withholding may be required. This is the part that takes the time.
Can a request be refused because it is awkward?
Inconvenience is not a ground for refusal. Narrow exemptions exist in most regimes; deleting data to avoid disclosure is a serious matter.
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.