How to handle a DSAR under GDPR | Deadlines and process

How to handle a DSAR so it meets the GDPR deadline

When a data subject asks for a copy of their data, the clock starts on receipt, and the controller must provide the information on action taken within one month of receipt (Article 12(3)). The deadline can be extended by two further months only for complex or numerous requests, and only if the person is told of the extension and the reasons within the first month. The controller owns this response and its deadline. No fixed price or duration applies to every organization. Cost and effort depend on how many systems, processors and paper files hold the person's data, how well those systems are documented, and how many requests arrive in a period. Ask any provider for a quote built from a written scope that names those systems, rather than a generic per-request figure.

Only the controller answers the request. An implementation partner can help prepare the intake channel, the search procedure across systems, the templates for the response and the records that show what was done, but no outside party certifies the response to the requester or to a regulator. Confirm internally who signs off each reply, who has authority to extend the deadline, and who speaks for the organization if a supervisory authority asks questions. Those roles should be written down before the first request arrives, because the EDPB's 2024 coordinated action found that undocumented procedures were among the common challenges.

Plan for the situations that cost the most time: a request sent to an email address nobody monitors, a search that misses a legacy database or a shared drive, and a reply that cannot be proven to have been sent. Under Article 12(4), a controller that will not act must explain why within one month and say how the person can complain or seek a judicial remedy. Confirm with your legal team which channels you will accept, how you will log each request from receipt to answer, and how you will show the date you responded. Start with the EDPB guide for small business on respecting individuals' rights, then check the exact deadline rules in Article 12 of the GDPR.

The DSAR process from intake to documented answer

This sequence takes a access request from the moment it arrives to a documented answer that the controller can prove it sent. Each phase produces a specific output, and the one-month clock starts from the date of receipt.

Log the request at intake
Record the date the request is received through any channel, including email, post, a web form or a call to a staff member. Staff who may receive requests need training to recognize them, because the law does not require a particular wording or format and a requester does not have to give reasons. The output is a logged request with a receipt date, which starts the one-month period under Article 12(3). Confirm with your legal team how to treat requests received in unexpected places, such as support tickets or social media.
Verify the requester's identity
Check that the person making the request is the data subject or someone authorized to act for them. Ask for only the information needed to confirm identity, and avoid collecting more identity documents than the case requires. The output is either a confirmed identity recorded on the file or a documented reason for doubt. If you cannot identify the person, record that finding and the steps you took, since your response still has to be documented. The separate guide on verifying identity for DSARs covers proportionate checks in more detail.
Scope the request and any extension
Work out what the requester asked for, which rights are engaged, and whether the request is complex or numerous. If you need to extend the deadline by two further months, tell the requester within the first month and explain the reasons. The output is a written scope with the search criteria you will use, such as name, customer number and account identifiers, and a dated record of any extension notice. Keep the scope tied to what the requester asked for, while still meeting the Article 15 duty to provide a copy of the personal data.
Search every relevant system and filing system
Search all IT systems and non-IT filing systems where personal data about the requester may sit, using criteria that match how your data is structured. Use the record of processing and your system inventory to decide where to look, and ask processors for help where they hold data for you. The output is a search log listing each system, the criteria used, the person who ran the search and the number of records found. Note any system that could not be searched and why.
Assemble the copy and supporting information
Gather the personal data undergoing processing and the supporting information the requester is entitled to under Article 15, such as purposes, categories, recipients, retention periods and sources. Review the material for third-party data that must be redacted or withheld, and record each decision. The output is a reviewed response pack with a redaction log. A further copy may carry a reasonable fee, which should be stated in the response if you plan to charge.
Respond in the requester's format
Send the response through a channel the requester can use, generally the one they used or the one they asked for. Where the request was electronic, provide the copy in a commonly used electronic form unless the requester asks otherwise. Send it within one month of receipt, or explain the delay and the extension reasons within that first month. The output is a sent response with proof of delivery, such as a secure portal record or a dated email. Do not require a particular channel that makes access harder, since the EDPB guidance warns against this.
Pass results on to recipients where required
Where the request leads to rectification or erasure, or where recipients have received the data, check whether you must tell those recipients of the outcome and, where the requester asks, inform them of the recipients. Notify processors and any downstream recipients through your agreed process. The output is a list of notified recipients with dates, or a recorded reason why no notice was required.
Document the request and the answer
Close the file with a complete record: the intake log, identity decision, scope, search log, redaction decisions, response sent and any refusal with its reasons. The EDPB expects controllers to document requests, answers and reasons for refusals, and a controller must be able to prove it answered. Use the seven practices from the EDPB small business guide as a checklist: prepared systems and trained staff, easy channels, an up-to-date register of data flows, transparency, answers within one month, passing results to recipients, and documentation. The output is a closed file that an assessor or supervisory authority could review without asking the team to reconstruct events from memory.

Which intake channels to offer and why an online form helps

The EDPB's guidance treats intake channels as a design choice with legal consequences: the controller should make rights easy to exercise, but it cannot force a requester into one route. The cards below cover the online form, the fallback channels, and the answer-routing and proof duties that follow from whichever channel is used.

Online form as the primary channel

The EDPB's small business guide suggests offering an online form for rights requests. A form captures the fields your team needs to search systems, such as name, customer number and the right being exercised, and it time-stamps receipt, which starts the one-month clock. Check that the form is reachable without an account or a chargeable number, and that it does not demand more identity data than the request requires. Confirm where form submissions are stored and who can read them.

Email and post as fallbacks

Email and post should stay open for people who cannot or will not use the form. Route both into the same case register as form submissions so that every request has one record, one identifier and one deadline. Set a named mailbox owner and a daily triage step, because a letter sitting in an unmonitored inbox still counts as received. Record the date of receipt for postal letters from the date they arrive at your organization, not from the date they were opened.

No mandatory format or channel

Data subjects need not give reasons for an access request, and there is no required format. Controllers should offer user-friendly channels but cannot insist that people use them. A request sent to a sales contact, a support ticket or a social media message can still count, so train front-line staff to recognize a rights request and forward it. Confirm with your DPO how staff are briefed on this.

Avoiding obstructive channels

The Spanish DPA fined Securitas Direct EUR 100,000 under Article 12(2) for directing people to a chargeable telephone number to exercise their rights, and ordered the notices replaced within 12 months. The lesson for your intake design is that every channel you publish must be free, reachable and clearly described. Audit your privacy notice, website footer and contact pages for any route that adds cost or friction.

Answering through the same channel

Responses should generally follow the channel the request used or the one the person asked for. Where the person submitted through the form and asked for an electronic copy, answer in a commonly used electronic form unless they request otherwise. Do not send personal data to a new address without confirming it is the one on record. Note the chosen channel in the case file so the reply can be traced later.

Proof that the answer was sent

The EDPB recommends answering in writing, including electronically, because a controller must be able to prove that it answered. Keep the sent message or the postal tracking record, the date and time of dispatch, the recipient address and a copy of the content as sent. Store these with the request record and set retention for them in line with your schedule. Confirm with your DPO how long proof must be kept and who can retrieve it on request.

Searching every system: what the EDPB expects

The controller must search every IT system and every non-IT filing system that may hold the requester's data, not only the main customer database. EDPB Guidelines 01/2022 on the right of access say the search criteria should mirror how the data are structured, so a team that stores records by customer number needs to search by customer number as well as by name, and a team that keeps paper or scanned files indexed by case reference needs to search those indexes too. A search that only checks the system the request desk happens to open is the gap assessors look for first. Before the search starts, confirm which identifiers each system uses, including email addresses, account IDs, device identifiers and any pseudonymous keys that link back to a person.

The record of processing and a current system inventory decide how long the search takes. If the record lists every system, its purpose, its data categories and the processors that host it, the team can build a search plan in hours. If the record is out of date, the team must rediscover systems during the one-month window, which is where deadlines slip. Ask who owns the register, when it was last reviewed against the actual estate, and whether it names shadow tools such as shared spreadsheets, collaboration channels and exported reports. Where a processor holds data for you, the processor must help you find and retrieve it, so write that duty into the contract and confirm the processor's contact point and turnaround before you need it. Retain a dated list of the systems searched and the criteria used, since that list is part of the evidence that the search was complete.

Finding personal data across systems is covered in more depth on the sibling page, so this section sets the standard the search must meet. Use that page to design the data mapping and search runbook, then test the runbook against a sample request before you rely on it for a live one.

When the deadline can be extended or a request refused

A DSAR clock runs for one month, but the GDPR allows a controlled extension and a lawful refusal in narrow cases. Each path carries a notice duty, and a missed notice is itself a compliance failure. The cards below cover what triggers each route, what the notice must say, and where refusal and fee questions are handled in depth.

Two-month extension for complex requests

Article 12(3) allows the response period to be extended by two further months when a request is complex or when a controller has received numerous requests. Complexity is judged on the request itself and on the effort needed to search and redact records, not on internal inconvenience. Record the grounds at the time you decide to extend, so you can show an assessor why the extra time was needed.

Notice within the first month

An extension is valid only if the requester is told within the first month of receipt that the period is being extended and why. Missing that window removes the right to extend, so the request must be answered within the original deadline. Build a notice template and a reminder into the ticketing workflow so the extension decision is made on day one, not on day thirty.

Explaining why no action is taken

If you decide not to act on a request, Article 12(4) requires you to explain why without undue delay and within one month. The explanation must also tell the person they can complain to a supervisory authority and seek a judicial remedy. Keep a standard refusal letter that covers both points, and store it with the request record so the reasons can be produced later.

Complaint and remedy wording

The refusal notice must name the supervisory authority the person can contact and state that a judicial remedy is available. Confirm which authority is competent for your main establishment, since this changes with where you are established. Avoid generic wording that omits the remedy, because regulators treat incomplete notices as a failure of the procedure, not a technicality.

Refusal and fee rules

Refusing a request or charging a fee is a separate decision, governed by the manifestly unfounded or excessive test and the burden of proof that falls on the controller. The sibling topic on excessive requests sets out how to calculate a reasonable fee, what evidence supports a refusal, and the enforcement case on obstructive request channels. Read it before any refusal leaves your team.

Documenting extension and refusal decisions

Each extension, refusal and fee decision should be logged with the date of receipt, the ground relied on, the date the notice was sent, and the approver. Under the accountability principle, you must be able to prove that you answered, so these records matter as much as the response itself. Check that your DSAR tool keeps timestamps and outgoing notices in a tamper-evident form.

Who owns each part of a DSAR response

The controller owns the legal outcome of every request. Its team decides whether a request is valid, whether identity checks are proportionate, which data falls within scope, whether an exemption or refusal applies, and whether an extension is justified. The controller also signs the answer and carries the one-month deadline under Article 12(3). Staff who receive requests in email, post or phone calls must recognise them and route them quickly, so the team needs written procedures and training.

Decision and sign-off: a named owner approves each response, refusal or extension and records the reasons.
Deadline tracking: the team logs the receipt date and tracks the one-month clock and any extension notice.
Recipient notices: the team decides when and how to inform recipients of rectification or erasure.
Staff training: frontline staff know how to spot a rights request in any channel.
Records: the controller keeps the request, the answer and the reasons for any refusal.

Check that your procedure names an accountable owner for each step and that your data protection officer, where one is designated, is involved in refusals and complex cases.

What must be in place before the first request arrives

A DSAR process only works if the pieces are ready before the clock starts. The cards below cover the documents, people, records and tools that must exist, with a check for each one. Running a test request end to end is the fastest way to show whether they connect.

A written DSAR procedure

Write down who receives a request, who searches which systems, who approves the response and who signs off any refusal. The procedure should name the intake channels you accept and state how you calculate the one-month deadline from the day of receipt. Check it by asking two people outside the privacy team to walk through it, and confirm that each step has a named owner and a place where the outcome is recorded.

Trained staff and clear routing

Requests often arrive at a general inbox, a support desk or a sales contact, not the privacy team. Front-line staff need to recognize a rights request, log it and forward it the same day, even when the requester does not mention GDPR. Check this by sending a test request to each public channel and measuring how long it takes to reach the person who owns the response.

An up-to-date register of processing

The record of processing and your system inventory tell you where personal data sits and which processors hold it. Without them, a search misses systems and the response is late or incomplete. Check the register against your actual cloud accounts, SaaS tools and internal databases, and confirm that each entry names an owner who can say what the system holds.

A request log with reasons

Keep one record per request that shows the date received, the channel used, the identity checks performed, the systems searched, the extension notice if one was sent, and the final answer. The log also records reasons for any refusal, because you must be able to prove what you did. Check that the log can be exported for an assessor or supervisory authority without manual reconstruction.

Identity verification rules

Decide in advance when you need to confirm who is asking and what proportionate checks look like for each channel, such as a logged-in account session or a matching email address on file. Avoid blanket demands for government ID. Check the rules by listing each request type and writing down the minimum check for it, then confirm that support staff can apply them without escalating every request.

Tested export tooling

Access requests need a copy of the personal data in a commonly used electronic form, so the export must work on real records before a request arrives. Test search by the criteria your systems use, such as name, customer number or email, and check that the output is readable and complete. Run one test request end to end, from intake to delivery, and time each step to find where the process stalls.

What regulators have penalized in access request handling

Regulators have already tested how access requests fail in practice. In its 2024 coordinated action on the right of access, the EDPB reviewed responses from 1,185 controllers across 30 data protection authorities, and about two thirds of those authorities rated compliance as average to high. The two challenges named most often were undocumented procedures and excessive identification demands. For intake design, a request channel is only as sound as the written process behind it. Document who receives requests, how each one is logged, which identity steps apply, and when the one-month clock started. A supervisory authority reviewing a complaint will look for that paper trail first. (EDPB news on the 2024 action)

The identification finding is a design decision in its own right. If an intake form requires a copy of a passport or other identity document by default, the controller collects more personal data than the request needs and invites a proportionality complaint. Set the minimum fields required to locate records, such as name, email address or customer number, and document a short escalation path for the cases where the controller has reasonable doubt about identity. The verification steps themselves are covered in the identity section of this guide. The undocumented procedure finding is fixed by a written runbook that states the channel, intake fields, triage owner, log entries and deadlines, and that staff follow every time. Confirm with your DPO or counsel that the runbook matches what your team actually does.

The Securitas Direct decision shows what happens when the channel itself becomes the obstacle. The Spanish supervisory authority fined the company EUR 100,000 under Article 12(2) because people were directed to a chargeable telephone number to exercise their rights, and it ordered the notices replaced within 12 months. The final decision dated from 1 February 2023, and the EDPB published it on 22 September 2026, so enforcement from earlier years can surface long after the conduct was examined. For intake design, every published route must be free. Check the privacy notice, web form, autoresponder and call script, and ask counsel whether any chargeable or premium-rate number appears where a customer might find it. (EDPB news on the Securitas Direct fine)

DSAR questions buyers ask before hiring outside help

How long does a data subject access request take to answer under the GDPR?

The controller must give information on action taken within one month of receiving the request, under Article 12(3). The clock starts on receipt, not when the team logs the ticket or confirms identity, so intake routing matters. The period can be extended by two further months for complex or numerous requests, but only if the requester is told of the extension and the reasons within the first month. Routine requests should not be treated as complex by default. Confirm with your data protection lead how your team defines receipt and who owns the deadline, because that definition sets the real working time you have.

Can a small team run DSAR handling without an outside partner?

Yes, a small team can run the process in-house if it has a documented procedure, trained staff, an up-to-date record of where personal data sits, and a way to log each request and its answer. The EDPB's small business guide lists these as the practices a controller should prepare in advance. The harder question is whether anyone can search every system and processor within the deadline. A partner is most useful where the data map is incomplete, systems are self-hosted and hard to query, or the team has not yet tested an end-to-end export. Your own environment decides this, so test one request from intake to answer before you decide.

What makes the effort and cost of a DSAR programme go up or down?

Cost depends on how many systems hold personal data, how well those systems are documented, how many requests you receive, and how often requests are complex. The main cost components are the time of staff who search and review data, engineering work to build exports or query tools, legal review of the response, and any external help. Setup work is largely one-time, while handling each request and keeping the data map current recur. The EDPB's guidance does not set a price or staffing level, so ask a partner to show how each cost driver in your environment was estimated and which items are fixed scope.

What does the business owner need to provide before a partner starts?

The business owner needs to supply a few things that no partner can invent. These usually include:

A list of systems, SaaS tools, data stores and processors that hold personal data, with an owner for each
The current record of processing and any retention schedules
Decisions on who approves responses, how identity is checked and which channels are offered
Access to test accounts or a non-production copy so exports can be checked safely

Without these inputs, scoping takes longer and the fixed-scope agreement is harder to write. Agree in advance who signs off each response, because the controller remains responsible for the answer.

Can an outside partner send the DSAR response to the requester?

A partner can prepare the search results, the copy of personal data and the supporting information, but the controller should decide what is sent and send it under its own name. The GDPR places the duty to answer on the controller, and the EDPB's guidance expects the controller to be able to prove that it answered, in writing and in a suitable electronic form where appropriate. Clarify in the contract who drafts, who reviews and who transmits, and how the response is logged. DeployOpen plans, implements and documents systems and evidence for these processes. It does not issue legal responses or act as the controller's representative to data subjects.

What should a quote for DSAR support include?

A useful quote states the scope in writing before work starts. Ask for:

The list of systems and processors covered, and any that are excluded
The deliverables, such as a request procedure, intake form, search runbook, export templates and a request log
Who performs each step and what the controller must review or approve
Testing performed with sample requests and the evidence produced
What is one-time setup and what is an ongoing retainer for upgrades, retesting and support
Assumptions about data volume and request numbers, and the change process if they differ

DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing. A quote follows from that written scope. Ask any provider to confirm that it does not certify or attest your compliance, since only independent assessors issue those outcomes.

How DeployOpen prepares DSAR systems and evidence

DeployOpen plans, implements and documents the self-hosted open-source systems that hold personal data, so access requests can be found, assembled and answered within the GDPR deadline. The organization keeps ownership of its controls and decisions, and an independent auditor or certification body issues any reports or certificates.

How we scope

Engagements are fixed-scope, with the systems, deliverables and timelines agreed in writing before work starts.
The written scope lists which systems, data stores and processors are in the request search and which are out.
Scope also names intake channels, response roles and the documentation the organization will keep for each request.

How we build

Systems are configured so request intake, identity checks and case tracking are logged in one place.
Search criteria such as name, email and customer number are tested against each data store in the inventory.
Export routines produce the copy in a commonly used electronic form, and each run is recorded for later proof.

How we hand over

Deliverables include a DSAR runbook, system inventory mapping and the request log template the team will use.
Test requests run end to end, and the results are documented so the organization can show how a response was produced.
Staff receive a walkthrough of the process, and the organization confirms the final evidence set before handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Changes to systems or processors can be fed back into the inventory and search criteria under the retainer.
Organizations should confirm with their assessor or counsel which evidence they need before scoping begins.