Back to Blog
DSAR

What is a DSAR and how do you respond to one in 72 hours?

10 June 20267 min readBy EmberHound

A Data Subject Access Request (DSAR) gives individuals the right to see every piece of personal data you hold about them. Here's the practical IT admin's guide to responding on time.

A Data Subject Access Request (DSAR) is a formal request from an individual asking your organisation to tell them what personal data you hold about them, why you hold it, and who you've shared it with. Under GDPR Article 15, you must respond within one calendar month — but 72 hours is the window most compliance teams aim for to avoid last-minute scrambles.

GDPR gives individuals the right to obtain a copy of all personal data you process about them, free of charge, within one month of the request (Article 12(3)).

Who can submit a DSAR?

Any living individual whose data you process can submit a DSAR — employees, customers, ex-customers, website visitors, or even third parties whose details appear in your records. Requests don't need to use the phrase 'data subject access request'. Any email, letter, or web form submission asking what personal data you hold is legally a DSAR and starts the clock.

What must your response include?

Your response must cover every system in scope, not just your CRM. Under Article 15, you must provide:

  • Confirmation that you process the subject's personal data
  • A copy of the data itself (in a commonly used electronic format if requested)
  • The purposes of processing
  • The categories of data held
  • Recipients or categories of recipients the data has been shared with
  • The retention period (or criteria used to determine it)
  • The subject's rights to rectification, erasure, and restriction
  • The right to lodge a complaint with a supervisory authority
  • The source of the data, if not collected directly from the subject

Why 72 hours matters in practice

The legal deadline is one calendar month, extendable by two more months for complex or numerous requests. But most DSAR failures don't happen because teams run out of time — they fail because identifying and gathering the data takes too long. Endpoint devices are the most commonly overlooked source. Files on laptops, shared drives, and email archives regularly contain names, email addresses, national ID numbers, and financial details that were never catalogued anywhere.

Setting an internal 72-hour discovery target gives you the remaining 25+ days to review, redact third-party data, and format the response properly. Teams that don't have a discovery process in place are the ones submitting extension notices at day 29.

A practical 72-hour DSAR workflow

  1. 1Verify the requester's identity. You may ask for reasonable verification, but don't delay unreasonably. A follow-up email to their account address is usually sufficient for customers.
  2. 2Log the request formally. Record the date received, the requester's identity, and any identifiers they've provided (email, employee ID, account number). This record is itself subject to retention obligations.
  3. 3Identify every system that might hold the subject's data. Work from your Record of Processing Activities (ROPA). Common sources: CRM, HR system, email, ticketing, analytics, shared file storage, and endpoint devices.
  4. 4Search endpoint devices and file shares. This is where most teams hit their bottleneck — unstructured data on laptops is rarely indexed. A data discovery tool that scans endpoints for PII can compress this from days to hours.
  5. 5Gather and review the data. Redact any personal data relating to third parties before including it in the response. If you're uncertain whether data is in scope, err on the side of inclusion.
  6. 6Draft and send the response. Include all required Article 15 fields. Use plain language — avoid legal jargon where possible.
  7. 7Close and document the request. Record the outcome, any exemptions you relied on, and the date of your response. Retention: keep this record for at least three years.

What exemptions can you rely on?

You may withhold or redact data where disclosure would adversely affect the rights and freedoms of others (e.g. other employees' personal data), where legal professional privilege applies, or where the request is manifestly unfounded or excessive. You must inform the subject that you're withholding data and give them the right to challenge that decision. Exemptions are narrow — 'it would be inconvenient' is not a legal basis.

Common mistakes to avoid

  • Forgetting endpoint devices and file shares — most DSAR failures involve unstructured data on laptops
  • Treating verbal requests as informal — any channel starts the clock
  • Delaying identity verification for more than a few days
  • Redacting so heavily that the response is useless
  • Failing to keep a record of the request and response
  • Missing data held by processors on your behalf — their data is your responsibility

How endpoint scanning helps

Manual DSAR responses at scale are operationally painful. For organisations with more than 50 employees or regular B2C customer contact, automated discovery is effectively a requirement. An agent running on each endpoint can surface every file containing a given email address, name, or ID number within minutes — turning the 72-hour discovery target from a stretch goal into a routine process.

See what personal data your endpoints are hiding

EmberHound scans your devices for GDPR and PCI data automatically — no manual discovery required.

We use cookies to improve your experience and analyse site usage. Privacy policy.