What is a DSAR?
Privacy, security and identity
A DSAR is a Data Subject Access Request. In UK practice it is usually called a subject access request, or SAR. It lets an individual ask whether an organisation is processing their personal data, receive a copy of that data and receive key information about how it is used. In AI work, DSAR readiness depends on knowing where personal data enters tools, prompts, transcripts, logs and outputs.
What this means
A DSAR is a request from a person to access their own personal data. The person does not need to use formal wording, quote the UK GDPR or say "DSAR". If they ask for the information an organisation holds about them, that may be enough to trigger the right of access.
The ICO describes the right of access as the right to obtain a copy of personal information and supplementary information about how it is used. For operators, this means a DSAR is not just a legal inbox issue. It is a workflow test. Can you find the data, understand it, separate another person's information, explain the processing and respond within the required time?
AI adds a layer of practical difficulty because personal data may sit in places people do not think of as records: prompt history, meeting transcripts, generated summaries, retrieval indexes, support classifications, audit logs and exported model outputs.
Why it matters
DSARs matter because they turn data protection from a policy into an operational process. A person is entitled to know whether their personal data is being processed, see a copy of it and receive information about purposes, categories, recipients, retention, rights, sources and relevant automated decision-making.
For small and mid-sized organisations, the risk is usually not refusal. It is delay, incomplete searches, unclear ownership or accidental disclosure of someone else's data. AI-enabled workflows increase that risk when teams use tools informally or when vendors hold personal data on the organisation's behalf.
A good DSAR process also improves internal discipline. If a team can retrieve and explain its use of personal data, it is more likely to have sensible data minimisation, ROPA and supplier controls already in place.
How it works
A DSAR should be logged when it is received, even if it arrives through a normal customer service, HR or sales channel. The organisation should confirm what is being requested, verify identity where necessary and identify the systems and people likely to hold relevant data.
The ICO says organisations must comply without undue delay and at the latest within one month, with limited scope to extend by a further two months for complex requests or multiple requests from the same person. If clarification is reasonably required, the clock can pause while the organisation waits for it.
The response normally includes a copy of the requester's personal data and supplementary information. It should not automatically include confidential information about other people. Where another person's data is involved, the organisation needs to consider whether an exemption applies or whether redaction is required.
For AI workflows, the search plan should include source records and generated records. A support email, transcript or CRM note may be the source record. A model-created summary, label or recommendation may be a generated record. Both can matter, but they should not be treated as equally reliable. The response process should preserve context so the requester can understand what the data is and so the organisation can correct obvious errors before sending a confusing response.
Examples
In customer support, a person asks for all notes and emails about a complaint. The search may need to include the helpdesk, CRM, call recordings, AI-generated summaries and escalation notes. Generated summaries should be checked against the source because they may contain errors or opinions.
In HR, an employee asks for the data used in a performance review. The search might include manager notes, meeting transcripts, absence records, AI-generated action summaries and messages in collaboration tools. Sensitive internal commentary may require careful review before disclosure.
In marketing, a prospect asks what data is held about them. The organisation may need to retrieve CRM fields, consent status, campaign history, enrichment data, lead scores and records of any profiling used to prioritise follow-up.
Common misunderstandings
It only counts if the request says DSAR. It does not. Plain language requests can still be valid.
We can ignore broad requests. A broad request may be clarified where reasonable, but it cannot simply be ignored because it is inconvenient.
AI outputs are never personal data. They can be, if they relate to an identified or identifiable person. A generated summary about a customer, candidate or employee may need review.
The processor deals with it. Controllers are responsible for responding. Processors should assist, but they do not decide the response for the controller.
Search means every file everywhere. The ICO expects reasonable searches. The scope should be justified, documented and proportionate to the request.
Risks and boundaries
The first risk is missing data because AI workflows were never recorded. If teams use personal data in prompts or unofficial tools, the organisation may not know where to search. The second risk is over-disclosure, especially where case notes include another person's personal data or confidential business information.
The third risk is treating generated content as fact. AI summaries, classifications and sentiment labels may be personal data, but they may also be inaccurate. A DSAR process should include review by someone who understands the source workflow.
A DSAR response should not be improvised by one busy manager. It should have an owner, search plan, redaction step and sign-off. This article is not legal advice and does not replace case-specific guidance on exemptions.
What to do next
Create a simple DSAR playbook. It should say how requests are recognised, who owns them, how identity is checked, which systems are searched, how processors are contacted, how third-party data is reviewed and how the final response is approved.
Then add an AI-specific search checklist. Include prompt histories, approved assistants, meeting tools, transcript stores, RAG indexes, CRM notes, support summaries and vendor-held logs where they contain personal data. Connect the checklist back to your ROPA and data processing agreements so the process is not dependent on memory.
Run a tabletop test before a real request arrives. Pick one customer, employee or prospect record and ask how long it would take to locate relevant personal data across the CRM, inboxes, support tools, meeting tools, AI assistants and vendor-held systems. The gaps you find will usually be governance gaps, not just DSAR gaps.
FAQs
Is DSAR the same as SAR?
In everyday UK practice, SAR is the more common ICO term for subject access request. DSAR is widely used in compliance and technology settings, but the practical right is the same right of access.
Does a DSAR have to be in writing?
No. A request can be made in writing or verbally. The key point is whether the person is asking for access to their personal data.
How long does an organisation have to respond?
The ICO says organisations must respond without undue delay and at the latest within one month, subject to limited rules on identity checks, fees in certain circumstances, clarification and extensions for complex cases.
Can we charge a fee for every DSAR?
No. Fees are only available in certain circumstances, such as where a request is manifestly unfounded or excessive, or where an individual asks for further copies.
Do AI prompts and outputs need to be searched?
They may need to be searched if they contain personal data about the requester and are within the organisation's control or held by a processor on its behalf.