The right that arrives as an email
Of all the GDPR rights, the access request is the one you will handle most, and it usually arrives as an ordinary email: "please send me all the data you hold about me". From that moment you have one month. The work is not glamorous - verify who they are, find their data across your systems, package it, and hand it over without exposing anyone else's data. But a botched DSAR is a common, avoidable complaint, and the process is entirely learnable.
The access request, step by step 7 min live
A DSAR is a small pipeline: it comes in, you verify the person, you find the data, you respond - within a month. Each step has a rule attached.
LiveWhat you must provide + verify first3 min▶
- Provide (Art 15): confirmation you are processing their data, a copy of it, and the key details - the purposes, categories, recipients, retention, the source, and whether there is automated decision-making.
- Verify identity first. You must be reasonably sure the requester is who they say. Handing someone else's data to an impostor is itself a breach - but do not use verification as a stalling tactic.
- Do not expose third parties. If the person's record contains other people's personal data, redact or withhold that - you satisfy the requester's right without breaching others'.
- Free by default. Generally no charge; a reasonable fee (or refusal) only for manifestly unfounded or excessive requests, or extra copies.
LiveThe one-month clock3 min▶
- One month from receipt (Art 12(3)) to respond, without undue delay.
- Extendable by up to two further months for complex or numerous requests - but you must tell the person, with reasons, within the first month.
- The operational risk is the handoff. A request that lands in a support inbox and waits a fortnight for someone to notice has already half-spent the clock. A named owner and a single intake channel are the whole game.
Lumina's first DSAR. An EU user emailed asking for all their data and, separately, to have their account erased. Lumina verified the email against the account, pulled data from the app database, billing, and the support tool, redacted a colleague's name that appeared in a shared ticket, and responded in three weeks. The erasure followed the same clock. Because there was an owner, the month was never at risk.
The edges 8 min live
Most requests are routine. The judgment calls are when you may take longer, when you may refuse, and how the same pipeline serves erasure, portability, and objection requests.
LiveWhen you can extend or refuse3 min▶
- Extend by up to two months for genuinely complex or numerous requests - with notice and reasons inside the first month. Volume alone from one person can qualify; do not use it to buy time on an ordinary request.
- Refuse or charge only where a request is manifestly unfounded or excessive (for example, repetitive requests designed to disrupt). The bar is high - "it is a hassle" is not it.
- Document the decision. If you extend or refuse, record why. That record is your defence if the person complains to an authority.
Self-studyOne pipeline, many rights2 min read▶
The good news for a practitioner is that you do not build a separate machine for each right. Erasure (Art 17), portability (Art 20), objection (Art 21), and restriction (Art 18) requests all ride the same pipeline you just built for access: verify the person, act across the systems, respond within the one-month clock, document the outcome. What changes is the action at the "act" step - copy the data for access, delete it for erasure, export it in a machine-readable format for portability, stop the processing for an objection. So the investment you make in a clean intake channel, an owner, and a data map pays off across all the rights at once. When someone asks "can we handle a portability request?", the honest answer is "yes, if our access pipeline is solid, because it is the same pipeline with a different verb".
Build Lumina's DSAR workflow ★ 10 min · pen and paper
Turn the five steps into a workflow your team could actually run.
Intake. Define the single channel a request comes through (a dedicated address or form) and who is notified the instant it lands.
Verify. Write your identity-check rule - proportionate, not a stalling wall.
Locate. List the systems you would search for one person's data (app DB, billing, support, analytics, backups). This is your data map in miniature.
Respond. Set the internal deadline at three weeks, not four - leaving buffer against the one-month legal limit. Note who redacts third-party data and who approves the send.
Before session b5 ◐ 40 min total
- Draft your DSAR workflow (intake, verify, locate, respond) with a named owner and an internal three-week deadline.
- Time a mock access request against your systems - could you actually locate one person's data in every place it lives?
- Write your identity-verification rule and your extension/refusal policy, with a note to document each such decision.
- Read: GDPR Articles 15 and 12(3) - the access right and the response clock.
Official sources covered
Taught from the GDPR text. This page covers ~80% of the working content on access requests.
Three questions before you go 🎯 ◐ 90 seconds
1 · An access request lands. You have...
Article 12(3): respond within one month of receipt, extendable by up to two further months for complex/numerous requests, with notice to the person in the first month.
2 · A person's record contains a colleague's name. In your access response you should...
You satisfy the requester's right without breaching others'. Disclosing a third party's personal data would itself be a breach, so redact and provide the remainder.
3 · You may charge a fee or refuse a request only when it is...
The default is free and fulfilled. A fee or refusal is only for manifestly unfounded or excessive requests (e.g. repetitive, disruptive) - and you should document the decision.