Skip to the article
ComplyVox Start your free check

Blog

Have you received a Subject Access Request (DSAR)? A step-by-step guide

6 min read ComplyVox
  • gdpr
  • data subject rights
  • right of access

Subject access requests are the single biggest source of complaints to Ireland's Data Protection Commission (DPC). With the introduction of AI, they have increased in volume and complexity. Many of those requests have a background story, nothing to do with GDPR: a dispute at work, or a customer who feels ignored. That does not change your obligations. No matter what the reason, you need to answer it properly and on time, it's the law.

This guide sets out a practical process to ensure you get it right. This post is general information, not legal advice. If a request involves litigation, an employment dispute or sensitive data, take advice specific to your situation.

What is a subject access request?

Article 15 GDPR gives people the right to know what information you hold "about them", including information they may not have had sight of, and to receive a copy of it. A request can be made by any method of communication, including phone, post or in person. A request sent to your sales inbox or mentioned to a support agent still counts, so everyone who deals with customers or staff should know how to spot one and where to send it.

The deadline: One month

Under Article 12(3), you must respond within one month of receiving the request. The clock starts when the request reaches your organisation, not when it reaches the right person.

If the request is very complex or if you get a high volume of requests, you can extend by up to two further months.

Step 1: Log and acknowledge the request

Record the date received, the channel, who is asking, what they want and your deadline. A spreadsheet or ticket is enough to start with. Send a short acknowledgement so the person knows when to expect an answer. If appropriate, phone them. This can often deescalate the situation and uncover the real reason for the SAR. Do not expect or ask for the request to be withdrawn unless they specifically say so. If it is not clear what information someone is asking for, you can ask at the acknowledgement stage, for example about timeframes or subject matter.

Step 2: Confirm who is asking

You must not hand personal data to the wrong person. Where you have reasonable doubts about identity ask for ID, permission or relevant assurance. Article 12(6) lets you ask for the information you need to confirm it.

When someone asks on another person's behalf

Requests from solicitors, family members or carers are common. A close relationship is not, on its own, legal authority. In one DPC case, a residential care facility refused to give copies of an adult resident's records to a family member who was one of their primary carers, because the family member did not have legal authority to act for them. The facility offered a meeting to talk through the records instead, and the DPC considered that approach appropriate.

Step 3: Find the personal data

Search every system where the person's data might be: your CRM and product database, inboxes and shared drives, chat tools, support tickets and call recordings, HR systems for staff requests, and data held for you by processors. Your record of processing activities under Article 30 should tell you where to look.

If the data no longer exists

You cannot provide data you no longer hold. In another DPC case, a hospital was asked for video and audio recordings from a medical study, but both had been deleted after two weeks under an automatic process. The DPC found the hospital had responded in full, but criticised it for not telling participants about that retention period at the outset.

So if data has gone, say so clearly in your response. And make sure your Privacy Notice and Employee Notice explain how long you keep each type of data, including short-lived recordings that sit outside your general retention periods. Your Retention Policy and Retention Register are key to maintaining a clear and transparent record and, remember, if you do not have it, you do not have to spend hours searching and disclosing.

Step 4: What to include

The person is entitled to a copy of their personal data, why you have it and how long you plan to retain it. They are entitled to know who you have shared it with and why, whether internally or externally such as a hosting provider, CRM, HR management system and where they are hosting eg inside or outside the EEA. You must state they have the right to contact the DPC if they feel you have not adequately answered their request. Much of this sits in your privacy notice, but tailor it to the person. The DPC's annual report notes that organisations still need to give fuller, more meaningful information in their responses.

Step 5: "All" doesn't always mean all

Review the documents and redact other people's personal data where disclosure would impact on their privacy. Legal privilege - documents prepared in contemplation of litigation or if disclosure would prejudice an ongoing investigation. Commercially sensitive information, where disclosure would adversely affect the rights or future plans of the organisation.

Step 6: Refusals and exemptions

Most requests should be answered in full. Restrictions or refusals have a high threshold with the DPC.

"We're too small" is not a reason to refuse. In one DPC case, an independent publisher refused a broad request as manifestly unfounded and excessive, citing its size and the work involved. The DPC was clear that a large volume of records, and the resources needed to review them, is not a valid reason to refuse under Article 12(5). It advised the company to release records in batches while reviewing the rest. The two sides then agreed a narrower scope, and the request was fulfilled.

Step 7: Send the response securely

Give the information with a clear response. Respond in the same way as they requested, unless they say otherwise eg if they request by post, respond by post.

Step 8: Keep a record

The accountability principle in Article 5(2) means you must be able to show what you did. Record when the request arrived and when you replied, how you verified identity or authority, which systems you searched, what you released, redacted or withheld and why, and any extension or fee with your reasons. A shared spreadsheet is fine to begin with; what matters is that it is kept up to date. Set a retention period for these records rather than keeping them indefinitely.

Subject access request checklist

  • ☐ Request logged with date received and one-month deadline
  • ☐ Acknowledgement sent
  • ☐ Identity checked where there are reasonable doubts
  • ☐ Legal authority confirmed if someone is acting for another person
  • ☐ All relevant systems and processors searched
  • ☐ Any data that no longer exists noted, with an explanation
  • ☐ Third-party data reviewed and redacted where needed
  • ☐ Any refusal, restriction or exemption justified in writing
  • ☐ Article 15 supporting information prepared and tailored
  • ☐ Extension notified within one month, if needed
  • ☐ Response sent securely, in the way the person asked
  • ☐ Record of the request and response kept

Make the next one easier

The first request is the hardest because you are building the process as you go. After that, a log, a list of systems to search and a template cover letter make it routine. The DPC's controller guide and the EDPB guidelines are both worth reading in full.

If you would like a clear picture of where your business stands, start with a free GDPR check: one conversation, and a list of what is in place, what needs work and what is missing.