What Is a DSAR? Data Subject Access Requests Explained

A DSAR, or data subject access request, is a person's legal right to ask an organization for a copy of the personal data it holds about them, along with information about how and why that data is used. It is one of the core rights granted by modern privacy laws such as the GDPR in Europe and the CCPA in California, and it puts an obligation on the organization to find, compile, and disclose the relevant data within a set deadline.

This article is general information, not legal advice. It explains what a DSAR is, who can make one, what you have to provide, and how a request typically moves from intake to response.

What a DSAR gives the requester

At its core, a DSAR is about access. The person making the request, often called the data subject, is entitled to more than a raw data dump. Depending on the law that applies, a complete response usually includes:

• A copy of the personal data the organization holds about them.
• The purposes for which that data is processed.
• The categories of data involved, such as contact details, transaction history, or support tickets.
• Who the data has been or will be shared with, including third parties and processors.
• How long the data is kept, or the criteria used to decide.
• The source of the data if it was not collected directly from the person.

The right is broad, but it is not unlimited. Third-party personal data must be protected, and some material is exempt or subject to a legal hold. We cover that in detail in the guide to DSAR exemptions.

Who can make a DSAR, and how

A DSAR can come from almost anyone whose data you process: a customer, a former customer, an employee, a job applicant, or a member of the public. It does not have to be formal. Under the GDPR a request can arrive by email, through a web form, over the phone, or even in a social media message, and it does not have to use the words "data subject access request" to count. That is one reason intake is harder than it looks: a valid request can land in any inbox. Requests from staff are their own case, because the file spans HR records, manager emails, and performance notes, and the employee subject access request guide covers what has to come out and what can be withheld.

Because a request can arrive anywhere, having a single point of privacy request management matters. If requests are scattered across support queues and personal inboxes, the deadline clock is already running before anyone logs them.

Verifying who is asking

Before you disclose anyone's personal data, you have to be reasonably sure the requester is who they claim to be. Handing personal data to an impostor is itself a data breach. Identity verification should be proportionate: enough to be confident, but not so demanding that it blocks a legitimate request. In practice this means matching a request to known account details or asking for limited confirming information, which is where identity verification fits into the workflow.

The deadline starts sooner than you think

Every access right comes with a statutory clock. Under the GDPR you have one month from receipt, extendable by two further months for complex or numerous requests. Under the CCPA you have 45 days, extendable by a further 45 with notice. The clock generally starts when the request is received, not when you get around to it, so a request sitting unlogged in an inbox is quietly burning time. The details are covered in the DSAR response deadline guide.

What responding actually involves

Fulfilling a DSAR is mostly a discovery and review problem. You have to find every place a person's data lives, decide what is in scope, remove anything you are not allowed to share, and package the rest into a response the requester can understand. The main stages look like this.

The step that surprises most teams is discovery. Personal data rarely lives in one place. It is spread across your CRM, help desk, billing system, marketing tools, backups, and spreadsheets. Automated personal data discovery is what turns a scramble into a repeatable process, and a full walkthrough is in the DSAR process guide.

Common misconceptions about DSARs

A few beliefs about access requests trip teams up. Clearing them up early prevents mistakes later.

• "It has to be a formal request." It does not. A valid DSAR can arrive as a casual email or a chat message and need not use any legal wording.
• "We can always charge for it." Access is free in the ordinary case; you can charge only where a request is manifestly unfounded or excessive.
• "We just export everything and send it." You must protect other people's data and withhold exempt material, so a raw export is rarely a safe response.
• "The deadline starts when we open the request." It generally starts on receipt, so an unlogged request is already consuming time.

Why DSARs are worth taking seriously

Ignoring or fumbling a DSAR carries real consequences: complaints to a regulator, reputational damage, and potential fines. But the deeper reason to handle them well is trust. A person exercising their access right is telling you they care about how you treat their data, and a clear, on-time, well-redacted response is a chance to demonstrate that you take that seriously. Teams that treat DSARs as a fire drill tend to miss deadlines; teams that treat them as a standard process handle them calmly.

Ready to see how a request moves from intake to a reviewable response? Run one through Obtainer and watch it discover where a person's data lives across your systems, then compile it into a single manifest. The DSAR automation workflow keeps you in control: you review, redact, and approve everything before it is disclosed.