Subject Access Request: UK GDPR Guide for Organisations

A subject access request is a formal request from an individual asking an organisation to confirm whether it holds personal data about them and, if so, to provide a copy of that data along with supplementary information about how it's being used.

The right sits in Article 15 of the UK GDPR and is one of eight data subject rights under UK data protection law. It exists so individuals can understand what data organisations hold about them, verify that it's being processed lawfully, and check its accuracy.

Does a SAR need to be formal?

An individual doesn't have to use the phrase 'subject access request,' reference any legislation, or submit a specific form. If someone asks 'what information do you hold about me?' or 'please send me all my data,' that's a valid SAR.

The ICO has confirmed that requests made verbally, by email, via social media, by post, or in person are all valid, and the response clock starts from the date of receipt regardless of format.

What personal data is covered?

A SAR covers any personal data an organisation holds about the individual, across all systems, formats and locations. That includes structured data in databases, CRM systems and HR platforms; unstructured data in emails, documents and file stores; data held by third-party processors acting on the organisation's behalf; and historical records held alongside current data.

The scope is broad. Organisations relying on fragmented systems or manual processes often discover the true scale of their data holdings only when a SAR arrives.

DSAR stands for Data Subject Access Request, and it means exactly the same thing as a SAR. The term became common in compliance and legal teams as a way of distinguishing data subject rights requests from other types of access requests, such as Freedom of Information requests.

The ICO itself uses SAR as its preferred term. In updated guidance published in January 2026 reflecting the Data (Use and Access) Act 2025, the UK's recent data protection reform legislation, the regulator consistently uses 'SAR' rather than 'DSAR.' In practice, both terms get used interchangeably across organisations, legal teams and software platforms.

For compliance purposes, treat SAR and DSAR as identical. The legal obligations, timelines and consequences stay the same regardless of which term gets used.

SAR vs DSAR: is there a practical difference?

Front-line staff need to understand that a request phrased as a SAR, a DSAR, or simply 'can I see my data?' all trigger the same legal obligation and the same response clock.

Any living individual whose personal data an organisation holds can make a SAR. There's no restriction based on nationality, employment status, or the nature of the relationship. Customers, employees, former employees, job applicants, website visitors and members of the public can all submit valid requests.

Third-party requests

An individual can authorise a third party to make a SAR on their behalf: a solicitor submitting a request for a client, a parent or guardian requesting data for a child, or a relative or carer acting for someone unable to make the request themselves.

Before responding to a third-party SAR, the organisation must be satisfied that the third party is authorised to act. The ICO expects evidence of this, such as written permission signed by the data subject or a power of attorney document, and compliance depends on that evidence arriving first.

Children

The right of access belongs to the child. Where a child is capable of understanding their rights, they can make a SAR themselves; where a parent or guardian requests on a child's behalf, the organisation needs to consider whether the child is mature enough to understand the implications and whether disclosure to the parent serves the child's interests. The ICO updated its guidance on children and SARs on 7 April 2026.

What Requesters Don't Need to Provide

A requester doesn't need to give a reason for making the request, use any particular form of words, submit through a specific form or method, or address it to a named individual or department.

The bar for a valid SAR is deliberately low: any communication that clearly asks for personal data is enough. Organisations need processes that catch these requests wherever they land, including customer service inboxes, social media accounts and reception desks.

A SAR response combines a copy of the individual's personal data with a defined set of supplementary information that explains how and why it's being processed, under Article 15 of the UK GDPR.

Required supplementary information

Alongside the personal data, the response must confirm:

1. Purposes: the purposes for which the data is being processed
2. Categories: the categories of personal data held
3. Recipients: the recipients or categories of recipients data has been or will be disclosed to
4. Retention: the retention period, or the criteria used to determine it
5. Rights: the individual's rights to rectification, erasure, restriction of processing and objection
6. Complaints: the right to lodge a complaint with the ICO
7. Source: where data wasn't collected directly from the individual, information about its source
8. Automated decisions: whether automated decision-making, including profiling, takes place and, if so, meaningful information about the logic involved

Format, delivery and redaction

The response must arrive in a concise, transparent, intelligible and easily accessible form. Where the request came in electronically, the response should go out electronically too, unless the individual asks otherwise. In most cases, the response is free of charge.

Where the personal data held about the requester also contains personal data about other people, redaction becomes necessary. The ICO expects organisations to weigh whether the third party has consented to disclosure and whether it's reasonable to disclose without consent, and this redaction step is one of the most time-consuming parts of a complex SAR response.

The obligation is to run a reasonable and proportionate search for the data actually held. The ICO's updated guidance makes clear that the burden sits with the organisation to justify why any search was unreasonable or disproportionate.

Organisations must respond to a SAR without undue delay and, at the latest, within one calendar month of receiving the request. This is a legal deadline that sits above any internal target.

The clock starts on the day the request is received, regardless of when it's processed or assigned to someone. A SAR received at 11pm on a Friday starts the clock from that Friday.

When does the clock actually start?

The response period begins once an organisation has received all three of the following: the request itself, proof of identity where reasonably requested, and any clarification requested about the scope of the request.

Identity checks need to happen as soon as possible after the SAR arrives. Delaying the identity check to buy extra time invites ICO scrutiny, which expects organisations to request ID documentation promptly.

Extending the deadline

The response period can extend by a further two months if the request is complex or if multiple requests have arrived from the same individual, for a total of three months from receipt.

To extend, an organisation must notify the individual within one month of receiving the request, explain why the extension is necessary, and do so before the original one-month deadline expires. The ICO expects organisations to explain specifically what makes the request complex when giving that notice, a higher bar than simply asserting complexity.

The stop-the-clock rule

Under the Data (Use and Access) Act 2025, the response clock can pause while an organisation waits for the requester to provide clarification about the scope of their request.

The clock pauses on the day clarification is requested and resumes the day after it's received. It can only pause to seek clarification about the scope of the information requested; format and delivery preferences don't qualify.

Organisations must request clarification as soon as possible after receiving the SAR. If clarification is requested and received on the same day, the clock doesn't pause at all.

Stopping the clock is a tool for genuinely scoping a complex request. Using it to manage workload risks ICO scrutiny.

Organisations can't decline a SAR simply because responding is inconvenient, time-consuming or commercially sensitive. The bar for refusal sits deliberately high, with two routes: the request is manifestly unfounded or excessive, or a specific legal exemption applies.

Manifestly unfounded requests

A SAR is manifestly unfounded when it's clear the individual has no genuine intention of exercising their right of access. Two scenarios point strongly to this: the individual offers to withdraw the request in exchange for some benefit from the organisation, and requests that are malicious in intent, designed to harass staff or disrupt operations rather than access personal data.

Abusive language in a request doesn't, on its own, make it manifestly unfounded. Each request needs individual assessment.

Manifestly excessive requests

A SAR is manifestly excessive when it's clearly or obviously unreasonable, assessed by weighing the burden of compliance against the importance of providing access. Relevant factors include whether the request largely repeats a previous SAR where a reasonable interval hasn't elapsed, the nature and volume of the information requested, the organisation's available resources, and whether the request overlaps with other active requests.

Volume alone isn't grounds for refusal. An individual requesting all the data an organisation holds about them, even where that's substantial, isn't automatically making an excessive request.

Where a request is manifestly unfounded or excessive, organisations can charge a reasonable fee that reflects the administrative cost of complying, often the more proportionate response to a borderline request.

Applying exemptions

A number of specific exemptions under Schedules 2 and 3 of the Data Protection Act 2018 allow organisations to withhold specific categories of information.

Exemptions apply on a case-by-case basis. Blanket policies that refuse categories of information without individual assessment fall short of compliance.

What organisations must do when refusing

Whether refusing in full or withholding specific information, organisations must inform the individual of the decision without undue delay and within one month of receiving the request, explain the reasons for refusal, tell the individual about their right to complain to the ICO and to seek a court order, and record the reasoning internally.

The burden of proof sits with the organisation. If the ICO investigates, documented evidence is what justifies the decision.

Most organisations still handle SARs manually: a spreadsheet to track requests, email chains to chase data from different departments, a shared drive for collating responses, and a calendar reminder for the deadline. It works, until the volume or complexity outpaces it.

The failures rarely show up on simple requests. They show up on volume, complexity, and anything that requires cross-system data retrieval under time pressure.

Where manual processes break down

1. Missed requests: a SAR can arrive through any channel, including a social media comment or a verbal conversation at a service desk, and organisations relying on manual intake routinely miss requests or log them late while the clock keeps running
2. Incomplete data retrieval: personal data spreads across CRM systems, HR platforms, email archives, finance systems and third-party processors, and manually querying each one, reconciling results and catching everything is slow and error-prone
3. Redaction at scale: every document containing third-party personal data needs manual review, and for a complex employment SAR covering years of correspondence that alone can take days
4. Deadline management: tracking individual deadlines, extension notifications and stop-the-clock periods across a spreadsheet when multiple SARs run at once is a material risk, and one missed deadline is an ICO reportable failure
5. Audit trail gaps: manual processes rarely produce the kind of documented trail, showing what was searched, found, disclosed and withheld, that satisfies regulatory scrutiny

SAR volumes are rising across regulated sectors as individuals grow more aware of their data rights, and organisations in financial services, legal and healthcare face particular exposure given the volume and sensitivity of the personal data they hold. Privacy teams handling SARs manually spend real time on administration that adds no analytical value and creates compliance risk at every step.

Purpose-built data privacy software addresses the structural weaknesses of manual SAR handling by bringing intake, workflow, deadline tracking and audit trail into a single managed process.

What that looks like in practice

1. Centralised intake and triage: every SAR gets captured regardless of channel, logged immediately, with ownership assigned and the response clock starting automatically
2. Automated deadline tracking: every deadline, extension status and stop-the-clock period gets tracked automatically, with alerts before deadlines are breached and a complete record of every timeline decision
3. Workflow and task management: tasks route to the right people across IT, HR, legal and customer services, with bottlenecks surfaced before they become deadline risk
4. Audit trail and evidenced decision-making: every action from intake to final disclosure gets recorded automatically, with refusal reasoning and exemption decisions documented against the specific data withheld
5. Integration with data maps: the system surfaces relevant data locations based on the individual's relationship with the organisation, cutting the time spent on manual discovery

SureCloud's Data Privacy Management platform includes purpose-built SAR workflow management, automated deadline tracking and a full audit trail, so a privacy team can handle rising volumes without adding headcount. In SureCloud's own customer data, organisations using the platform report 50% faster DSAR completion and 80% less time spent finding evidence during audits, replacing manual administration with a governed, repeatable process.

Organisations building a broader privacy programme can also draw on SureCloud's Privacy Control Framework, a practical foundation for managing data subject rights alongside wider compliance obligations. For a closer look at what to prioritise in a platform, see how to choose the best DSAR management software.