How to handle a Data Subject Access Request under GDPR Articles 12 and 15 — a six-step workflow that fits inside the one-month window, identity verification without overreach, when the two-month extension is defensible, and how to refuse a manifestly unfounded request without losing the case.
One-month response windowArticles 12 & 15 GDPR Register required for every request
Tracker is free and saves locally in your browser. The document template adds your company name, designated contact, and country-specific supervisory authority.
The DSAR procedure in five sentences
Article 15 GDPR gives every data subject the right to confirmation, a copy of their personal data, and a specified information set about how it is processed — without cost, in a commonly used electronic format where requested electronically.
Article 12(3) sets the response window: one month from receipt, extendable by a further two months for complex or numerous requests provided the subject is informed within the first month.
Identity verification under Article 12(6) is proportionate to the relationship — match against existing account information first; demand identity documents only where reasonable doubt remains and is documented.
Article 12(5) permits refusal of manifestly unfounded or excessive requests on a documented rationale — the bar is high and the refusal letter must include the right to complain to the supervisory authority.
Every request, including those where you hold no data on the subject, gets a response inside the one-month window — Article 12(4) makes silence the most common ground for complaint.
1. What counts as a DSAR — and what doesn't
A Data Subject Access Request is any communication, in any form, through any channel, in which a data subject exercises the right of access under Article 15 GDPR. The shape that matters is substantive, not formal — "please send me all the personal data you hold on me" is a DSAR; so is "what data do you have about me?" in a chat support transcript; so is a paragraph in an angry complaint email asking what is on file. EDPB Guidelines 01/2022 explicitly reject any requirement that the request use specific words, cite Article 15, or arrive on a specific channel.
What it is not: a request for someone else's data (no standing under Article 15 unless the requester has a documented authorisation), a generic policy question (handled by reference to the privacy notice, not as a DSAR), or a request scoped to non-personal information. The classification step is the first one in the workflow because it determines what procedure runs.
Article 15 sits inside a wider rights set the subject can invoke alongside or instead of access:
Article 15 — right of access (the DSAR proper)
Article 16 — right to rectification of inaccurate or incomplete data
Article 17— right to erasure (the "right to be forgotten")
Article 18 — right to restriction of processing
Article 20 — right to data portability (a subset of Article 15 in machine-readable form)
Article 21 — right to object to processing on certain bases
The procedural rules — receipt logging, one-month clock, extension, refusal — are common across all six. The substantive content of the response differs. A single request often invokes more than one right at the same time, which is why the scoping step in the workflow exists before the assembly step.
2. The one-month clock and the two-month extension
Article 12(3) sets a single deadline: the controller provides information on action taken without undue delay and in any event within one month of receipt of the request. The clock starts on the day the request is received — day zero — and the response is due by the corresponding day of the following month (or the next working day if that falls on a weekend or holiday).
Receipt is receipt — wherever the request lands
The clock does not pause because the request landed in the wrong inbox. A DSAR sent to support@, sales@, or a named employee's personal address is validly received the day it was sent, and the receiving party is obliged to forward to the procedure owner. Internal training so every customer-facing role recognises a DSAR is the most cost-effective control against the "forgotten ticket" failure mode.
The two-month extension
Article 12(3) permits a further two months where necessary, taking into account the complexity and number of requests. Two procedural rules apply rigidly:
The subject must be informed of the extension and the reasons for it within the first month — silent extensions are not permitted.
The reason must be substantive: volume of export, complex redaction across multiple datastores, parallel handling of multiple rights from the same subject. Staffing constraints, holiday periods, and processing prioritisation are not defensible reasons.
The default rule when the timeline is tight:extend within the first month rather than miss the one-month deadline. A documented extension is procedurally clean; a late response with no extension notice is the textbook Article 12 violation.
3. Identity verification without overreach
Article 12(2) requires the controller to facilitate the exercise of the right. Article 12(6) only permits the controller to request additional information necessary to confirm identity where reasonable doubts exist. Read together, these provisions rule out demanding identity documents reflexively — that is itself an Article 12 failure when the relationship already provides a verification path.
The proportionate verification ladder has three rungs. Stop at the lowest rung that resolves reasonable doubt; document the stopping point in the case file:
Rung 1 · Existing relationship
Match the request against information already on file: request email vs. account email, signed-in session, recent customer interaction, an answer to a security question already used. Sufficient for the majority of consumer DSARs.
Rung 2 · Out-of-band confirmation
Ask the requester to confirm a piece of non-public account information — last invoice number, last login location, a transaction reference. Used where the request arrives from an unfamiliar address but plausibly relates to a known subject.
Rung 3 · Identity documents
Government ID copy with sensitive fields redacted. Used only where rungs 1 and 2 cannot establish identity — e.g. a former customer with a closed account requesting access from a different email address. The reason is documented in the case file.
The clock pauses only for the verification step.Article 12(3)'s "without undue delay" framing means the controller may not run the one-month period out before asking for verification — the request and the verification ask happen in parallel, not in series.
4. The six-step DSAR workflow
The workflow below is what the CookieSentry-generated DSAR Procedure operationalises. Each step has a defined window inside the one-month period, an owner, and a logged artefact that goes into the DSAR register. Run a stopwatch on the first DSAR you receive — most SMB requests close inside two weeks if the procedure is in place before the request arrives.
1
Receive and log
Day 0
Capture the request the moment it arrives — date received, channel, requester identifier, requested rights. Article 12(3) starts the one-month clock from this date, so a missed log entry is a missed deadline. The log lives in the DSAR register; a single source of truth for every request, open or closed.
2
Verify identity (proportionately)
Days 0–3
Match the requester against information already on file before asking for anything more. Where reasonable doubt remains, request the minimum additional information necessary under Article 12(6) — and pause the clock only for the brief period this verification step takes. Requesting passport copies from a long-standing signed-in customer is overreach; matching the request email against the account email is sufficient in most cases.
3
Scope the request
Days 3–7
Determine which rights are being exercised — Article 15 access, Article 16 rectification, Article 17 erasure, Article 18 restriction, Article 20 portability, Article 21 objection — and which datastores hold the subject's data. The ROPA processing-activity entries and the sub-processor list make this a five-minute exercise when they are current; a half-day investigation when they are not.
4
Assemble the response
Days 7–25
Pull the personal data from each system in scope, redact third-party identifying information under Article 15(4), and assemble the package. The Article 15 information set goes alongside the data: purposes of processing, categories of data, recipients, retention, source where not collected from the subject, and the subject's rights. PDF for the human-readable summary, CSV/JSON for the portable subset under Article 20.
5
Send and confirm receipt
By Day 30
Deliver the response to the requester through a channel that protects the data — encrypted attachment, secure portal link, or post where the subject prefers. Confirm receipt; if the subject does not acknowledge within a reasonable window, follow up. The deadline is met by sending — but a delivery that fails silently can become a complaint.
6
Close and record
After delivery
Close the DSAR log entry: response date, scope of personal data covered, any extension or refusal applied, and the rationale. Article 5(2) accountability requires the controller to evidence each response — the log entry is that evidence. Retention is typically three years for SMB; five for regulated industries.
5. What the response must include — Article 15 in full
The response is two things, packaged together: a copy of the personal data and the Article 15(1) information set about the processing. The information set is verbatim text from the regulation; the safest practice is to mirror the structure in your response letter so a supervisory authority reviewing the file can map it line-for-line:
(a) the purposes of the processing;
(b) the categories of personal data concerned;
(c) the recipients or categories of recipient to whom the personal data have been or will be disclosed (in particular recipients in third countries or international organisations);
(d) where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period;
(e) the existence of the right to request rectification, erasure, restriction, or to object;
(f) the right to lodge a complaint with a supervisory authority;
(g) where the personal data are not collected from the data subject, any available information as to their source;
(h) the existence of automated decision-making, including profiling, with meaningful information about the logic involved and the significance and envisaged consequences of such processing.
The copy of the personal data itself goes alongside in a commonly used electronic format under Article 15(3). The Article 20 portable subset (data the subject provided on a consent or contract basis, processed automatically) gets a structured machine-readable format — CSV or JSON. A single export package with both the human-readable summary and the machine-readable raw data satisfies both rights at once.
6. Refusing or charging for a manifestly unfounded request
Article 12(5) lets the controller refuse to act, or charge a reasonable administrative fee, where requests are manifestly unfounded or excessive — in particular because of their repetitive character. The bar is intentionally high, and the burden of demonstrating the manifestly unfounded or excessive character of the request lies on the controller.
EDPB Guidelines 01/2022 give a non-exhaustive list of the factors a supervisory authority will weigh when reviewing a refusal:
the same request repeated within an unreasonably short interval, with no material change in the underlying processing;
the request is part of a documented harassment campaign or has no apparent purpose other than to disrupt the controller's operations;
the volume of data requested is so high that providing it would be disproportionate (this is rare for SMBs and almost always defeated by the two-month extension first);
the data subject has been provided the same data within the recent past and no material change has occurred.
The refusal letter
Where the controller refuses, the response under Article 12(4) must include three things: the reasons for not acting, the right to lodge a complaint with the supervisory authority, and the right to seek a judicial remedy. The refusal letter is short — three paragraphs is sufficient — but the rationale on file is what the supervisory authority will examine if the subject complains. Refusal without that rationale gets reversed.
Charging is rare in practice
The fee option exists but is operationally heavier than it looks: the fee must reflect actual administrative cost (not a deterrent), the rationale for the amount must be on file, and the fee schedule itself becomes a regulatory artefact. Most SMBs never charge — a documented zero-fee policy is simpler than maintaining a defensible schedule.
Skip the drafting
The DSAR procedure, the register, and the response template — done.
CookieSentry generates the DSAR Procedure (incl. designated contact, the six-step workflow, the response template letter, the refusal letter, and the country-specific supervisory authority contact details) plus Privacy Policy, Cookie Policy, ROPA, Data Retention, DPA, and Breach Procedure. Counsel-redlinable Word + PDF, bilingual EN + DE / PL / LT.
Article 15(4) GDPR limits the right of access where it would adversely affect the rights and freedoms of others — typically, the third parties who appear in the subject's data. Two common shapes:
Email correspondence. The subject's email thread with a customer-success rep is the subject's personal data; the rep's identifying information beyond the role is the rep's. The surviving practice is to redact the rep's direct phone, personal details, and any commentary about other named individuals while preserving the message body.
Internal documents naming the subject. A performance review names the manager, an HR investigation names colleagues, a complaint refers to other customers. Article 15(4) supports redaction of those third-party identifiers; it does not support refusing the document as a whole.
Refusal of an entire document on Article 15(4) grounds is rarely defensible. The discipline is line-by-line redaction of the third-party identifiers, with the redaction visible (a black box, not a deletion) so the subject can see that material was withheld and exercise their Article 12(4) right to complain if they disagree with the scope.
The redaction tooling does not need to be sophisticated. A PDF with redaction layers, a Word document with the relevant text replaced, or a CSV with anonymised columns all satisfy the obligation as long as the redaction itself is irreversible in the delivered file.
8. Six DSAR scenarios, walked through
Customer asks for everything you hold on them
Standard
The most common DSAR shape. Verify against account email, run the export across the application database, the help-desk system, the email-marketing platform, and any third-party processors with the subject's data, redact third-party information, package as PDF + CSV. Most SMB DSARs fit comfortably inside the one-month window if the ROPA is current and the procedure is in place before the request arrives.
Former employee requests their full HR file
Edge
Procedurally identical, substantively heavier. The file may include performance reviews, written manager assessments, sick-leave records, and emails referring to the employee. Article 15(4) does not authorise blanket refusal; the discipline is to redact the third-party identifying information (the colleague who appears in a complaint, the manager named in an assessment) and provide everything else. Two-month extension is often warranted given the volume; document the reason.
Request received via a generic support inbox
Standard
A customer emails support@ with "please send me a copy of all my data". This is a validly received DSAR; the support team's job is to recognise it and forward to the procedure owner the same day. The clock started on the day support@ received it, not the day privacy@ saw it. Internal training is what makes this work — and the one-page DSAR recognition cheat-sheet on the team wiki is the durable artefact.
Repeat requester filing weekly identical DSARs
Refuse
Where the same subject has filed the same request multiple times within an unreasonably short interval, Article 12(5) permits refusal as manifestly excessive. The discipline: keep the request log, prior responses, and a written rationale on file. Notify the subject of the refusal and of their right to complain to the supervisory authority. Refuse the second or third repeat, not the first; refusal of a first request on "manifestly excessive" grounds is rarely defensible.
Subject requests data in a specific format the system cannot export
Edge
Article 15(3) requires a commonly used electronic form for electronic requests; it does not entitle the subject to a bespoke format your systems do not support. The surviving response: provide PDF + CSV (or PDF + JSON), explain the formats provided are commonly used and electronic, and offer a reasonable alternative if the subject has a specific access need (e.g. accessibility). Document the reasoning in the DSAR log.
Request from someone you don't actually have data on
Standard
Verify identity, search the systems, find no record. Article 12(4) requires a written response within one month explaining you hold no data on the subject and reminding them of the right to complain. The response is short — three sentences — but it must be sent. The most common failure mode is the request being filed and forgotten; the only acceptable artefact is a sent confirmation email.
9. Country notes — DE, PL, LT
Germany — BfDI and the Landesdatenschutzbehörden
The German supervisory authorities have been particularly active on DSAR enforcement. Bavarian BayLDA and Berlin BlnBDI have published multiple decisions where the failure was procedural rather than substantive — late response, no acknowledgement of receipt, identity verification framed as a barrier rather than a check. The recurring lesson: the procedure on file matters as much as the response. A controller that can show a documented DSAR procedure, a current register, and a sent acknowledgement defends well even when the substantive response was late; a controller that has none of those defends poorly even when the substantive response was perfect.
Poland — UODO
UODO complaints frequently turn on the channel question — the request landed somewhere other than the designated privacy contact and was lost. UODO's published guidance is unequivocal that any channel through which the controller communicates with the subject is a valid receipt point for a DSAR. Internal routing — every customer-facing role knows what a DSAR-shaped request looks like and where to forward it — is the single most cost-effective control.
Lithuania — VDAI
VDAI has a strong line on identity verification proportionality. Decisions consistently reject requests for ID documents where account-based verification was already available, framing the demand as itself an Article 12 failure. The verification step in the procedure should default to existing-relationship matching and only escalate to identity documents where reasonable doubt is documented in the case file.
10. Penalties under Article 83
Failures of the data subject rights regime — Articles 12 to 22 — sit in the higher fining tier under Article 83(5): up to €20 million or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher. The headline figure rarely lands on SMBs, but Article 83(5) is the tier that applies, and the supervisory authorities have used mid-five-figure fines on small businesses for procedural DSAR failures — late response, no acknowledgement, identity verification framed as a barrier.
The compounding risk is the same one that runs through every GDPR enforcement: the absence of a documented procedure, the absence of a register, and the inability to evidence why a given response was complete or why a refusal was justified. Each of those is its own administrative finding and they pile up. The procedure on file is the cheap insurance — and the DSAR register is the artefact a supervisory authority will ask to see during the very first round of correspondence.
11. Frequently asked questions
When does the one-month clock actually start?+
The clock under Article 12(3) starts the day the request is received — not the day the response team logs into the ticket, and not the day identity verification is completed. The only suspension recognised by the EDPB is the brief period during which you reasonably ask for additional information to verify identity under Article 12(6). Document the receipt date on every request as the first action; that single field is what the supervisory authority will examine if a complaint is filed.
What identity verification is reasonable, and what counts as overreach?+
Article 12(2) requires the controller to facilitate the exercise of the right; Article 12(6) only allows requests for additional information where the controller has reasonable doubts about the identity of the requester. The surviving rule is that you may match against information already on file (account email, last login from a known device, an answer to a security question already used), but you may not require ID documents from a customer who has been signed in for years. EDPB Guidelines 01/2022 explicitly call out passport copies and government-ID requests as disproportionate where the relationship already provides a verification path.
Can we extend the one-month deadline, and how?+
Yes — Article 12(3) permits a further two months where necessary, taking into account the complexity and number of requests. The mechanic is fixed: within the first month, you must inform the data subject of the extension and the reasons for it. The most defensible reasons are the volume of the export (multiple datastores, large attachments, archived records), the need to redact third-party personal data from the response, and parallel handling of multiple rights requests from the same subject. "We are short-staffed" is not defensible; "we are de-conflicting third-party rights from a 12-year customer history" is.
Do we have to give the data in a specific format?+
Article 15(3) entitles the data subject to a copy of the personal data undergoing processing. Where the request is made by electronic means, Article 15(3) requires the information to be provided in a commonly used electronic form unless the subject requests otherwise. The portable subset under Article 20 (data the subject provided on a basis of consent or contract, processed by automated means) must additionally be in a structured, commonly used and machine-readable format — typically CSV or JSON. Most SMBs satisfy both Article 15 and Article 20 with a single export package: PDF for the human-readable summary, CSV/JSON for the portable raw data.
What about employee DSARs — are they handled the same way?+
Yes — the procedural rights under Articles 12 and 15 apply identically to employees. The complications are substantive: the personal data file may include performance reviews, written assessments, and emails about the employee. Article 15(4) allows the controller to refuse copies that would adversely affect the rights and freedoms of others (typically the third parties named in those documents), but the surviving practice is to redact the third-party identifying information rather than to refuse the document outright. The grievance is the most common downstream complaint when employee DSARs are mishandled, and the redaction discipline is what defuses it.
Can we refuse a request that is being used to harass us?+
Article 12(5) lets the controller refuse to act on a manifestly unfounded or excessive request, or charge a reasonable fee taking into account administrative costs. The bar is high. EDPB Guidelines 01/2022 give a non-exhaustive list of factors: the same request repeated within an unreasonably short interval, requests with no apparent purpose other than to disrupt the controller's operations, and requests that are part of a documented harassment campaign. Refusal must be evidenced — keep the request log, the prior responses, and a written rationale on file. Refusal without that documentation is what gets reversed when the subject complains to the supervisory authority.
Can we charge a fee for handling a DSAR?+
The default position under Article 12(5) is that the response is free of charge. A reasonable fee is permitted only where the request is manifestly unfounded or excessive, or where the subject has requested further copies after the first under Article 15(3). The fee must reflect the actual administrative cost — not a deterrent number — and the rationale must be on file. Most SMBs never charge; a documented zero-fee policy is operationally simpler than maintaining a defensible fee schedule.
What if we don't actually hold any data on the requester?+
You still owe a response. Article 12(4) requires the controller, where it does not take action, to inform the data subject without delay and at the latest within one month of the reasons for not acting and on the possibility of lodging a complaint with a supervisory authority. The response is short, but it is mandatory. Silence — including the kind of silence that comes from the request landing in a generic info@ inbox and never being assigned — is the most common Article 12 failure the supervisory authorities act on.
Do we have to include data we received about the requester from a third party?+
Yes. Article 15(1) covers all personal data concerning the data subject, regardless of source. Where the data was obtained from a third party (a credit agency, a recruiter, an open-source intelligence provider), Article 14(2)(f) requires the source to be disclosed, and it appears in the DSAR response too. The redaction discipline still applies — if the third-party data also identifies an individual at the source organisation, that individual's identifying information is removed.
How long should we keep the DSAR log entry after we close the case?+
There is no fixed statutory retention period for DSAR records, but the controller must be able to evidence Article 5(2) accountability — that responses were timely, complete, and lawful. The surviving practice is to retain the DSAR log entry (request received, identity verified, response sent, any extension or refusal) for the limitation period of complaint to the relevant supervisory authority plus a margin: three years is the SMB norm, five years where regulated. The full copy of the export sent to the subject is generally not retained beyond the response — it is the subject's data, not the controller's record.
What's the right channel for receiving DSARs in the first place?+
The controller is free to designate a channel — typically a dedicated email address (privacy@ or dpo@) and a webform — but Article 12(2) prohibits making the right harder to exercise than other communications. A DSAR sent to a generic support inbox, to a sales contact, or to a named employee is still validly received; the receiving party is obliged to forward it to the procedure owner. Internal training that every customer-facing role recognises a DSAR-shaped request is what closes the gap that supervisory authorities most often cite.
Where do data subjects in Germany, Poland, and Lithuania complain if we get this wrong?+
Germany: the Landesdatenschutzbeauftragte of the Bundesland in which the controller is established (each Land has its own portal). Poland: UODO at uodo.gov.pl, with an online complaint form. Lithuania: VDAI at vdai.lrv.lt. The complaint can be lodged in any EU member state under Article 77, but the lead supervisory authority for cross-border cases is determined by Article 56 — typically the authority of the controller's main establishment.
The DSAR you respond to in two weeks, not the one you miss in two months
The DSAR Procedure, the six-step workflow, the response template, the refusal letter, and the country-specific supervisory authority contact details ship in your CookieSentry GDPR pack alongside Privacy Policy, Cookie Policy, ROPA, Data Retention, DPA, and Breach Procedure. Generate, redline with counsel where you want, ship.
This guide summarises GDPR Articles 5, 12, 15, 16, 17, 18, 20, 21, 83 and EDPB Guidelines 01/2022 for orientation. It is a practical reference, not legal advice; the application of these provisions to a specific request depends on facts only counsel familiar with your jurisdiction can assess. CookieSentry templates are drafted to current EU and national law and are intended for review by qualified counsel before publication.