
Short answer: The GDPR right of access in Article 15 lets anyone ask whether you process their personal data and, if you do, get a free copy plus key facts about how it is used. You must normally answer within one month, verify identity proportionately, and search every system, including logs, support tools and analytics.
Related guides:
- GDPR data subject rights
- Data controller vs data processor: differences explained
- GDPR compliance checklist
Key takeaways
- Article 15 has three layers: confirmation that you process the person's data, a copy of that data, and supplementary information such as purposes, recipients and retention.
- The clock is one month from receipt, extendable by two further months only where necessary, and the first copy is free.
- Verify identity proportionately. Asking for a passport scan from a logged-in user is usually excessive.
- Processors assist, controllers answer. If you are a SaaS vendor processing customer data, your job is usually to help your customer respond, not to reply to the individual yourself.
- The hard part is engineering. Personal data lives in logs, backups, support tools and analytics, so you need a data map.
What does GDPR Article 15 give individuals?
Article 15 of the GDPR gives a data subject the right to confirmation, a copy of their personal data, and a defined set of supplementary information. Our broader guide to the 8 GDPR data subject rights covers every right at a glance. This post goes deep on access alone.
A complete response has three parts:
- Confirmation of whether you process personal data about the person at all. A "no" is still an answer you must give.
- A copy of the personal data you process (Article 15(3)). The first copy is free. For further copies you may charge a reasonable fee based on administrative costs. If the request arrives electronically, answer in a commonly used electronic form unless the person asks otherwise.
- Supplementary information listed in Article 15(1)(a) to (h):
| Article 15(1) | What you must tell the requester |
|---|---|
| (a) | The purposes of the processing |
| (b) | The categories of personal data concerned |
| (c) | The recipients or categories of recipients, especially in third countries or international organisations |
| (d) | The envisaged retention period, or the criteria used to set it |
| (e) | The existence of the rights to rectification, erasure, restriction and objection |
| (f) | The right to lodge a complaint with a supervisory authority |
| (g) | Any available information on the source, where the data was not collected from the person |
| (h) | The existence of automated decision-making, including profiling, with meaningful information about the logic involved and its consequences |
Article 15(2) adds that, where data is transferred to a third country or international organisation, the person has the right to be told about the transfer safeguards.
Article 15(4) protects other people. The copy must not adversely affect the rights and freedoms of others, so redact third parties' data, such as another customer's name in a shared ticket. It does not justify refusing the whole request.
The EDPB Guidelines 01/2022 on the right of access, adopted in final form (version 2.0) on 28 March 2023 after public consultation, add detail: the requester need not give a reason, the copy should be complete, and raw codes may need explaining.
How long do you have to answer a DSAR, and can you charge?
You must respond without undue delay and at the latest within one month of receipt, and in most cases you cannot charge. The rules sit in Article 12 of the GDPR:
- Article 12(3), deadline: one month from receipt. You may extend by two further months where necessary, taking into account the complexity and number of requests, but you must tell the person about the extension, with reasons, within the first month.
- Article 12(5), fees and refusals: responses are free of charge. Only where a request is manifestly unfounded or excessive, in particular because it is repetitive, may you charge a reasonable fee or refuse to act. The burden of showing that sits with you, and the EDPB guidelines say these concepts must be interpreted narrowly.
Per the EDPB guidelines, the month runs from the date you receive the request, and your answer should reflect the data held at that point. Deleting data to shrink a response is not allowed.
How should you verify the requester's identity?
Verify identity only as far as you have reasonable doubts, and use the least intrusive method that works. Article 12(6) lets a controller with reasonable doubts about who is asking request additional information to confirm identity. It does not license blanket ID collection.
The EDPB guidelines say requesting a copy of an identity document is generally not an appropriate method, and is disproportionate when the person is already authenticated, for example through their existing account login. A sensible approach for SaaS products:
- Logged-in users: accept the request through an authenticated channel, such as in-app settings.
- Email-only requests: send a confirmation link to the email address on file.
- Higher-risk data: where misdirected disclosure could cause real harm, add a second factor without collecting more data than you need.
- Third-party requests: if a lawyer or relative asks on someone's behalf, ask for evidence of authority.
Record what you checked and why.
Who answers the DSAR: controller or processor?
The controller is responsible for answering; the processor must help. Under Article 28(3)(e), the processor contract must require the processor to assist the controller, through appropriate technical and organisational measures, in responding to requests from data subjects exercising their rights.
For a B2B SaaS company this usually means two roles at once:
| Your role | Example data | Who replies to the individual |
|---|---|---|
| Controller | Your own customer contacts, website leads, employees | You |
| Processor | End-user records your customers store in your product | Your customer, with your help |
If an end user of a customer's account writes to you directly, do not hand over their data yourself. Forward the request promptly to the customer, as your data processing agreement specifies, and give them the tools to export what they need.
How to respond to a DSAR: a step-by-step workflow
A repeatable workflow keeps you inside the deadline and leaves an audit trail. This is the sequence we suggest for small teams.
| Step | What to do | Owner | Target timing |
|---|---|---|---|
| 1. Log | Record the request, channel and date received. Calculate the due date. | Privacy or ops lead | Day 1 |
| 2. Triage | Decide whether you are controller or processor. If processor, forward to the customer. | Privacy lead | Day 1 to 2 |
| 3. Verify | Confirm identity proportionately if you have reasonable doubts. | Support | Day 1 to 5 |
| 4. Scope | If you hold a large volume of data, you may ask the person to specify what they want, but you still owe a full answer if they decline. | Privacy lead | Day 3 to 7 |
| 5. Collect | Query every system on your data map and export results. | Engineering | Day 5 to 18 |
| 6. Review and redact | Remove other people's data and protected information. Explain internal codes. | Privacy lead, legal | Day 18 to 24 |
| 7. Assemble | Combine the copy with the Article 15(1)(a) to (h) information in a clear, electronic format. | Privacy lead | Day 24 to 27 |
| 8. Deliver | Send through a secure channel and confirm receipt. | Support | Before day 30 |
| 9. Record | Keep a record of what was searched, sent and redacted, and why. | Privacy lead | Same day |
If you need an extension, decide by week two and notify the requester with reasons inside the first month. One register for all requests also helps you spot repetitive ones.
Where is personal data hiding in your systems?
Personal data is rarely only in your primary database, so build your DSAR search around a data map, not memory. The EDPB guidelines note that activity logs and search history can be personal data. These are the places engineering teams most often miss:
- Application logs and observability tools. Request logs often contain emails, user IDs and IP addresses. Know which indexes you can query by user ID and how long each keeps data.
- Backups. Data that remains in backups is still held by you. Document in your DSAR process and retention policy how backups are handled and when they expire.
- Support and CRM tools. Ticket threads, call notes and chat transcripts hold rich personal data and often mention third parties who need redaction.
- Product analytics and event pipelines. Events keyed to a user ID or device ID count. Keep a mapping from account to every pseudonymous identifier you use.
- Data warehouses. Copies made for reporting or machine learning are easy to forget.
- Email, shared drives and vendors. Attachments, notes and data your own processors hold for you are all in scope.
Engineering tips: use a stable internal subject ID across services and log it instead of raw emails, build an export job per system keyed to that ID, tag each data store with owner and retention period, and test the runbook on a staff account before a real request arrives.
What changes when the request involves health data?
Health data raises the stakes on security and accuracy, but the requester's right to a full, free first copy stays the same. Article 4(15) defines data concerning health broadly, covering physical or mental health information, including healthcare services, that reveals someone's health status. It is a special category under Article 9.
The Court of Justice confirmed in Case C-307/22, FT v DW (26 October 2023) that a patient is entitled to a first copy of their medical record data free of charge, whatever their reason for asking. The Court also said the copy must be a faithful and intelligible reproduction, which can mean copies of whole documents from the record where needed to understand the data.
For HealthTech teams this means:
- Stronger identity checks proportionate to the harm a misdirected disclosure could cause.
- Encrypted delivery, such as a secure download portal with expiring links, rather than plain email attachments.
- Clinical context. Lab codes and abbreviations may need explanation.
- Clear role mapping. If you process patient data for clinics, the clinic is usually the controller.
If you also serve US customers, HIPAA has its own individual access rules with different timelines, so keep a separate runbook for them.
How SecureSlate helps
SecureSlate includes GDPR as a built-in framework alongside HIPAA, SOC 2 and ISO 27001, so DSAR controls map once across the frameworks you hold. You can add your own DSAR controls, such as the response register and identity verification procedure, through custom controls. Vendor risk management tracks the processors that hold personal data, with vendor entries created from connected integrations, and agentless read-only cloud integrations connect the cloud accounts where much of that data lives. The trust center lets you publish policies and subprocessor lists to customers with public or restricted access.
Start your free SecureSlate trial
FAQ
Does a DSAR have to be made in writing or use a specific form?
No. The GDPR does not require a specific form or wording. Requests can arrive by email, chat or support ticket, so train frontline staff to recognise and log them.
Can we refuse a DSAR because the person is in a dispute with us?
Not on that ground alone. The EDPB guidelines say the requester does not need to give reasons and that "manifestly unfounded or excessive" must be read narrowly. You carry the burden of showing a request meets that bar.
Do we have to include data in backups?
Data you still hold is in scope. Document how backups are handled in your process, and rely on a clear retention policy so expired data is actually deleted. Data already deleted under your retention policy cannot be provided.
What if we only process the data for a customer?
Then you are usually a processor. Forward the request to your customer, the controller, without delay and help them respond as your data processing agreement requires.
Disclaimer (legal note)
This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds