Data Subject Access Requests (DSAR): How to manage without loosing control

A Data Subject Access Request, usually called a DSAR or access request, is a request by an individual to know whether an organisation processes their personal data and to receive access to that data and related information.

The individual is entitled to a copy of their personal data and the information required by Article 15 GDPR. Unless exceptions apply, it may require extracts from documents, database records or correspondence where that context is necessary to understand the personal data.

The right of access remains a regulatory priority. The EDPB’s 2024 coordinated enforcement action, published in January 2025, focused on how controllers implement the right of access in practice and highlighted recurring weaknesses in procedures, awareness and response handling.

Reading time: 8 minutes.
Last updated: February 2025

What is the GDPR DSAR process?

The data subject access request process consists of five (5) main steps:

1. Collect and log requests.
2. Verify the subject’s identity and validate the scope of the request.
3. Search, gather and review the data.
4. Provide the data in a suitable and secure format.
5. Record the outcome, improve your process, and prepare for contingencies.

Step 1: Collect and log requests

Ideally, your organisation has a structured and uniform way to collect, register and organise DSARs. Maybe you have a specific web form or other system support, e-mail, chat agent, phone extension or in-person request. Irrespectively, you need to specify the input needed to process the request.

However, individuals do not have to use your preferred channel. A valid DSAR can be made by email, letter, chat, phone, social media, customer support or in person. It does not need to include the words “DSAR”, “GDPR” or “subject access request”.

The practical risk is that the request lands with the wrong person. Front-line teams should therefore know how to recognise an access request and where to escalate it.

Each request should be logged with:

• date received;
• identity of the requester;
• channel received;
• scope of the request;
• systems and teams involved;
• deadline;
• decisions made;
• response date; and
• any exemptions or limitations relied on.

Step 2: Verify the subject’s identity and validate the request.

Before disclosing personal data, the organisation must be satisfied that the requester is the right person.

The identity check should be proportionate. A logged-in customer asking for ordinary account information may not need the same verification as an employee asking for HR records or a patient asking for health data.

Do not ask for more ID than necessary. Collecting copies of passports or identity documents for every DSAR may create unnecessary risk and additional personal data.

Requests can also be made by a representative, such as a lawyer, union representative or family member. In that case, the controller should check that the representative has the authority to act for the individual.

If the request is unclear, ask the individual to clarify what they are looking for. This can help reduce unnecessary searches and avoid disclosing irrelevant material.

Step 3: Search, gather and review the data

This is where many DSAR processes fail. The organisation should identify which systems, vendors and teams may hold relevant personal data. Depending on the request, this may include:

• customer accounts and CRM systems;
• support tickets and chat logs;
• email and collaboration tools;
• HR, payroll and recruitment systems;
• finance, billing and payment systems;
• product usage logs;
• security, fraud and access logs;
• marketing systems;
• data warehouses and analytics tools;
• supplier platforms and outsourced service providers; and
• archived systems or backups, where relevant and reasonably accessible.

The review should distinguish between:

• the requester’s personal data;
• information about other individuals;
• confidential business information;
• legally privileged material;
• trade secrets or intellectual property;
• internal assessments that may require context or redaction; and
• material that falls outside the scope of the request.

A DSAR does not automatically give the individual a right to every document where their name appears. The right is to personal data and Article 15 information. In many cases, extracts or structured summaries may be more appropriate than disclosing full documents, especially where the document also contains third-party data or confidential information. That said, organisations should not take an artificially narrow approach. If context is necessary for the individual to understand the personal data, it may need to be included.

Step 4: Provide the data in a suitable format.

The response should be concise, transparent, intelligible and easy to access. The individual should receive:

• confirmation whether you process their personal data;
• a copy of the personal data in scope;
• the purposes of processing;
• categories of personal data; recipients or categories of recipients;
• retention periods or criteria used to determine them;
• information about their rights;
• the right to complain to a supervisory authority;
• information about the source of the data, where it was not collected from the individual; and
• information about automated decision-making where relevant.

Where the individual makes the request electronically, the response should generally be provided in a commonly used electronic format, unless the individual asks otherwise.

Security matters. Customer account information may be suitable for a secure portal. Sensitive HR, health, financial, child-related or special category data may require stronger safeguards. Emailing large files or sensitive records without appropriate protection can create a new incident while trying to solve the first one.

Step 5: Record the outcome and improve the process

A DSAR file should show what the organisation did and why.

At a minimum, keep a record of:

• when the request was received;
• how identity was verified;
• how scope was interpreted;
• which systems and teams were searched;
• what data was included;
• what was excluded or redacted;
• which exemptions or limitations were applied;
• when and how the response was provided; and
• any follow-up, complaint or escalation.

This record is important if the individual complains to a supervisory authority or challenges the response. It is also useful for improving the process.

Recurring DSAR issues often reveal broader governance gaps: unclear data ownership, poor retention hygiene, weak system mapping, unsupported manual workarounds, or lack of coordination between legal, product, HR, support and IT.

What is the deadline for responding to a DSAR?

Controllers must respond without undue delay and in any event within one month of receiving the request.

That period may be extended by a further two months where the request is complex or where the organisation has received a large number of requests. If you rely on an extension, you must inform the individual within the first month and explain the reason for the delay.

The one-month deadline is short in operational terms. It leaves little time for internal confusion, unclear ownership or manual searching across multiple systems. The best DSAR processes are therefore built before the difficult request arrives.

How can an individual make an access request?

The individual can ask for information and access to their personal information in a variety of ways. Both written or verbal requests are valid. However, the only criterion is that the individual must make it clear they are requesting access to their data.

As the Swedish DPA highlights in its recent decision against Klarna Bank, it does not matter if you provide the individual with a specific process for making such a request. The individuals may request access to their personal information in any form or manner they wish. As a result, the controller must always respond to access requests. It doesn’t matter who the data subject asks or which department receives a request. Also, every staff member should learn how to recognise a claim for access and to whom to direct it.

Standard forms for sending Subject Access requests

You can establish standard forms that data subjects can use to submit requests. As a result, this makes it easier for staff to recognise access requests and helps the data subject include all required information. There is also a greater chance that the team member who deals with the requests receives them. You must also manage access requests sent without using an established standard form within the stipulated one month.

Providing Access to the Data Subject

Controllers must respond to access requests as soon as possible and within one month. As a general rule, this service should be free of charge. If the data subject makes many requests of the controller, the controller may charge a fee. The fee can be actualised if the request is complicated or the data subject asks for more copies shortly after the first request.

Confirming the Data Subject’s Identity

One problem that arises when you receive an access request is confirming that it is the right person to make the request. You do not want to send out personal information to the wrong individual.

Accordingly, you must take “reasonable measures” to verify the identity of the data subject. These steps are particularly relevant in the context of online services and online identifiers. An example is login data sent to a data subject’s email if they forgot their password.

Requests can also come from a third party. In these cases, controllers must be somewhat sure that the third party can act on the data subject’s behalf. It is the third party who must prove that the data subjects have authorised him or her to act on their behalf. An example of such evidence is a document signed by the data subject granting the third party the right to request their personal information.

If you deny a request, you must explain why

Controllers can also refuse to fulfil very complicated access requests if they choose. When you decide to deny an access request from an individual, you must inform the data subject of why you chose to do so. You must also inform them that they can file a complaint with the supervisory authority.

How to provide access to the individual

How to best fulfil the access request depends on how the data subject asks for it. For example, customer reference numbers can be sent by email, but medical records are more sensitive and demand more security when sending. In the latter case, you could provide encrypted, remote access.

The best practice, according to GDPR, is providing data subjects with remote access to a secure self-service portal. Controllers should make sure that this option does not endanger the rights and freedoms of others. It should not compromise trade secrets or infringe on any intellectual property rights either.

Information to the Data Subject

To comply with the right to access, the controller needs to be able to provide information regarding:

• whether you process personal data about them;
• the right to access;
• the purpose of the processing; and
• the categories of data concerned.

There is a list in Article 15 of GDPR that is non-exhaustive, with examples of information the controller should provide. Still, the data subject may need more information in a particular case. The controller needs to provide as much information as necessary. The reason for this is to ensure that the processing is fair and transparent. Controllers must also inform data subjects about their rights to erasure, restriction, and objection when asked for access.

For efficient guidance regarding the right to access, visit the website of the DPA of the UK and see their comprehensive guide ICO. On ICO’s website, you can see a checklist of what they think you should have prepared and need to do for handling an access request from a data subject.

Can you refuse a DSAR?

Yes, but refusal should be handled carefully.

A controller may refuse to act on a request where it is manifestly unfounded or excessive, in particular because of its repetitive character. The controller may also charge a reasonable fee in those circumstances, taking into account the administrative cost of responding.

In practice, this threshold should not be treated as a routine escape route. A request is not excessive simply because it is inconvenient, wide-ranging or time-consuming.

Access may also be limited where necessary to protect the rights and freedoms of others, including the personal data of third parties, confidentiality, trade secrets or intellectual property. The correct response is often targeted redaction or partial disclosure rather than outright refusal.

If you refuse all or part of a request, explain the reason clearly and inform the individual of their right to complain to a supervisory authority and seek a judicial remedy.

What happens if you do not respond to a DSAR?

Failure to respond properly can lead to complaints, supervisory authority investigations, reprimands, orders to comply and administrative fines.

The Swedish DPA’s decision against Klarna is a useful reminder. IMY found that Klarna had not handled an access request without undue delay and within the one-month period required by Article 12(3) GDPR. The issue was not only whether the organisation eventually responded, but whether the request was recognised and handled correctly when received. IMY issued a reprimand.

The operational lesson is clear: it is not enough to publish a privacy inbox or preferred form. Organisations need internal routing, training and accountability so that requests received through other channels are still recognised and escalated.

Who is responsible for a DSAR?

The controller is responsible for responding to a DSAR.

Internally, responsibility should be assigned clearly. Legal or privacy teams may own the interpretation and final response, but they usually cannot complete the process alone. A good DSAR workflow often requires input from:

• customer support;
• HR;
• IT and security;
• product and engineering;
• finance;
• sales and account management;
• data owners;
• procurement or vendor management; and
• the Data Protection Officer, where applicable.

The DPO does not need to personally handle every request, but should be involved where the request is sensitive, disputed, high-risk, complex or likely to lead to a complaint.

Can a Company submit a DSAR?

No. A DSAR is a right for individuals regarding their personal data.

A company cannot use Article 15 GDPR to request access to corporate information. However, a person acting on behalf of a company may make a DSAR in their individual capacity, for example, as a customer contact, employee, contractor, director or shareholder, if the request concerns their own personal data.

Organisations should be alert to mixed-purpose requests. A DSAR should not be ignored just because it arises in a commercial dispute, employment dispute or customer complaint. But the response should remain focused on the individual’s personal data, not broader document disclosure.

Standard forms and self-service portals

Standard forms can be useful. They help individuals provide the information needed to process the request and help staff identify and route DSARs correctly.

Self-service portals can also be effective, especially for customer account data. The EDPB recognises that remote access to a secure system may be a suitable way to provide access, provided it does not adversely affect the rights and freedoms of others.

However, forms and portals should support the right of access, not restrict it. A controller must still handle valid access requests submitted through other channels.

DSAR is Subject to Several Sanctions

One of the fundamental principles of all privacy and data protection regimes is the principle of transparency. That principle is included in the GDPR’s Article 5. Also, it connects to many of the primary obligations of the controller. For instance, the right to access in Article 15 of the GDPR. For more on the principle of transparency, read our article on What does transparency in the GDPR mean.

According to Article 15 of GDPR, the data subject has the right to access his or her data. This privilege includes that the controller must inform the individual that the controller processes his or her data. Also, the controller must give information that provides for, e.g. what purposes, which data, and with whom the controller shares the data.

Failure to give the data subject access to its data has been subject to several sanctions since the GDPR came into force.

Failure to meet the stipulated time

A relevant case is the reprimand from the Swedish DPA against Klarna Bank in March 2021. In this case, the data subject received both information about the processing and a copy of the personal data that Klarna processed. Yet, the response was almost five months late. Klarna had received the access request to the “wrong” e-mail address and not to the address indicated in, e.g. its privacy policies.

The Swedish DPA concluded that Klarna did not handle the access request without undue delay and within the stipulated time limit in Article 12(3) of the GDPR. Also, Klarna failed to inform the individual about the delay and the reasons for it. As a result, Klarna violated the GDPR. But, the DPA only issued a reprimand since the incident was a “minor infringement”.

The case also concerned a second access request. In that case, the DPA concluded that Klarna did not violate the GDPR as it did respond within the stipulated timeframe. It did not matter that the individual claimed not to have received the response from Klarna. According to the case, Klarna did request a correct e-mail address from the individual who never responded.

When the controller processes no data

One recent example of this came from Italy in August 2020. The case concerned the failings of a controller to respond to such a request. The catch was that the controller did not even process the data subject’s data. Accordingly, the controller could easily have conveyed this information to the data subject. As a result, the Italian DPA fined the controller and set the penalty at EUR 3,000.

Deletion of data is also a violation

Another example is a sanction decision from the Danish Data Protection Agency against the company JobTeam. In this case, it was a more blatant violation where the person in charge deleted the data subject’s data in connection with the person in charge of receiving his access request. The whole thing resulted in a sanction of EUR 6,700, corresponding to about 2.4% of its total turnover.

Practical DSAR checklist for controllers

A mature DSAR process should answer the following questions before a request arrives:

• Who owns DSAR intake?
• Which teams must recognise and escalate requests?
• Where are requests logged?
• Who verifies identity?
• Who decides scope?
• Which systems are searched?
• How are vendors involved?
• Who reviews data for redaction and exemptions?
• How is the response securely delivered?
• Who signs off the response?
• How are decisions documented?
• How are lessons fed back into data governance?

For technology companies and data-driven businesses, DSAR readiness is not just a compliance matter. It is a test of whether the organisation understands where personal data sits, who owns it, how it flows and how quickly it can act under regulatory pressure.

The organisations that handle DSARs well tend to have better data governance overall. They do not treat access requests as one-off legal admin. They treat them as operational signals.