DSAR Support for Organisations: Expert Response & Compliance Services

DSARs trigger a statutory one-month deadline under UK GDPR, regardless of internal capacity.

> Legal, HR and IT diverted from core priorities
> Manual document review consumes significant internal hours
> Follow-up queries extend operational disruption
> No clear internal DSAR ownership across departments

Personal data is rarely stored in one place, and poor scoping increases risk.

> Data spread across email, HR systems, CRM platforms and shared drives
> Legacy systems and archives complicate searches
> Difficulty defining what is genuinely “in scope”
> Excessive data retrieval increases review and redaction burden​

DSAR mismanagement carries measurable regulatory and reputational exposure.

> Failure to meet statutory response deadlines
> Incorrect reliance on exemptions
> Poor documentation of response methodology
> Escalation to ICO complaints or investigation
> Damage to employee or customer trust​

Redaction errors are one of the most common causes of DSAR complaints.

> Risk of disclosing third-party personal data without a lawful basis
> Inconsistent application of UK GDPR exemptions
> Over-redaction triggering disputes or escalation
> Under-redaction exposing the organisation to regulatory risk
> No defensible audit trail of decision-making

A data subject access request (DSAR) is a written or verbal request to an organisation from an employer, business, individual or supplier (or any other ‘data subject’) for a copy of the personal data held, which they are entitled to ask for under UK GDPR. When a subject submits a request for personal data, organisations have a legal obligation to send a copy unless there are exemptions.

Article 12 of the UK GDPR requires controllers to respond to a SAR without undue delay and, in any event within one month. This means that the clock starts ticking on the day the request is received and ends on a corresponding day the following month. That said, the clock will only start once the controller is in receipt of ID (if this is required).

In terms of the end date, if the following month does not have a corresponding day because that month has fewer days, the end date is the last day of the month. For example, if a request is received on 30^th January, the response would need to be provided by 28^th February. In view of this, some organisations prefer to apply a 28-day response time for operational purposes.

No extra time is allowed if the request arrives on a weekend or bank holiday although, if the end date falls on a weekend or bank holiday, the response would not be required until the next working day.

Whilst the deadline is strict, it can be extended in some circumstances.

Your organisation should have a Data Protection Policy that outlines the process of responding to DSARs. If you do not have a policy, you should consider creating one, this is something Evalian can help you with.

It is the responsibility of the controller of the personal data, to respond to the request, not the processor. However, individuals may not realise this and may submit their applications to the processor. Therefore, controllers should ensure that they have appropriate arrangements in place with their processors to ensure that they are notified promptly should this situation arise. In the same vein, processors must ensure they have appropriate controls in place to identify requests and assist controllers with the handling of SARs, without delay. The Information Commissioner’s Office (“ICO”) has issued guidance on controllers and processors.

Individuals making a SAR are entitled to their own ‘personal data’. This is any information from which they can be identified, either directly or indirectly.

In terms of whether an individual can be identified directly from the information in question, this is often quite straightforward. For example, a name is often sufficient to identify someone.  That said, just because a document contains someone’s name does not automatically mean that the document will contain that person’s personal data.

Learn more by referring to our blog, Part 1: Understanding Subject Access Requests.

If the individual has submitted the request electronically, the response should be made using a commonly used electronic format (e.g. encrypted email or secure portal). If the request has been made verbally or by letter, the response can be in any commonly used format, electronic or hard copy. It is best practice to ask the individual, at an early stage, how they would like to receive the material.

Whatever method is used, the controller must ensure that the disclosure is secure. For example, controllers may wish to share electronic disclosures via a secure portal with the data being encrypted and send hard copies by recorded delivery.

There may be occasions when organisations have a good reason not to respond to a SAR. Under Article 12(5) of the UK GDPR, organisations can lawfully refuse to process a SAR, if it is deemed to be “manifestly unfounded or excessive”.

A request may be regarded as “manifestly unfounded” if the individual making the request has no genuine desire to exercise their rights but has clearly submitted the SAR with malice or with the intention of causing disruption or harassment to an organisation.

A request may be regarded as “manifestly excessive” if it is clearly unreasonable. Reaching a decision on this would depend on various matters such as whether the request repeats previous requests made only a short while ago or overlaps with previous requests. For example, if an individual submits a SAR once a fortnight but the information being processed by the organisation has not changed since responding to the first SAR, this would be regarded as manifestly excessive.

Learn more about exemptions in our blog, Part 2: Refusing to comply.