A DSAR lets anyone ask a company for a copy of their personal data and how it is used. Here is what it means, how it works and how long you have to reply.
Under the GDPR, this is commonly called the right of access. A person can generally ask whether an organization is processing their personal data, request a copy of that data, and obtain certain supplementary information about how it is being processed.
A DSAR is different from requests to correct, delete, restrict, object to, or port personal data. Those are separate data-protection rights, although an individual may exercise several rights in the same request.
Organizations need an effective DSAR process for receiving requests, verifying identity where necessary, locating relevant information, reviewing it for applicable exemptions or third-party information, and responding securely within the applicable legal deadline.
DSAR stands for Data Subject Access Request.
The term is widely used in privacy and data-protection programs to describe a person's request for access to their personal information.
Depending on the jurisdiction, the same or similar right may be called:
Under UK GDPR guidance, for example, the ICO describes the right of access as the right to obtain a copy of personal information and other supplementary information.
A DSAR is the simplest way for a person to find out what a company knows about them. It shows what data is held, why it is used and who it is shared with. For many people, it is the first step before they ask a company to correct, delete or stop using their data.
Under Article 15 of the GDPR, a person can ask a company three things:
That third part usually covers:
This is why a DSAR is more than a data export. The person gets a clear picture of what is happening with their data and can check that the company is using it lawfully.
In India, the same idea applies under the DPDPA, where a Data Principal can ask a Data Fiduciary for information about their personal data.
The right to access personal data exists in most privacy laws, but the name, deadline and process are different in each one. There is no single global DSAR deadline.
Read more on our GDPR compliance page.
UK organisations should follow the latest ICO guidance, as the rules on deadlines and ID checks have been updated.
Read more on our UK GDPR compliance page.
California has its own terms, exemptions and process, so a GDPR workflow cannot simply be copied.
Read more on our CCPA compliance page.
Under the DPDPA, a Data Principal has the right to obtain information about their personal data from the Data Fiduciary, subject to the conditions in the Act and the DPDP Rules.
Read more on our DPDPA compliance page.
Your DSAR process should detect where the person is based and apply the right rule and deadline automatically. A single global deadline will cause missed or late replies.
Last reviewed: October 2026
A typical DSAR workflow looks like this:
The individual submits a request through an available channel.
A request does not necessarily need to use the words “DSAR” or “Article 15.”
An organization should have a process for recognizing requests that amount to an exercise of the right of access.
The organization may need to verify that the requester is the person whose data is being requested.
Identity verification should be reasonable and proportionate.
The ICO's current guidance emphasizes that organizations should not automatically demand formal identification where identity is already sufficiently established.
The organization should determine what systems and categories of information may be relevant.
If a request is genuinely unclear or broad enough that clarification is reasonably required, the organization may seek clarification.
However, clarification should not be used simply to make the request unnecessarily difficult.
The organization should perform an appropriate search for the requested personal data. A privacy scanner can help show where a website collects personal data.
Depending on the business, this can involve:
Before disclosure, the organization should review the information for:
The response should provide the personal data and required supplementary information in an appropriate, understandable format.
The organization should use a secure method for delivering personal information to the requester.
The organization should maintain appropriate records of:
This creates an audit trail for demonstrating how the request was handled.
DSAR and SAR are often used interchangeably.
The term SAR is especially common in UK privacy practice.
The underlying concept is the individual's right of access.
The ICO explicitly uses “subject access request (SAR)” for requests made under the right of access.
A Data Subject Rights Request (DSR) or Data Subject Request is a broader concept than a DSAR.
A rights request may concern:
A DSAR specifically focuses on access.
This distinction is useful for privacy teams because a single incoming message may contain multiple rights.
For example:
“Tell me what data you have about me, correct my address, and delete my marketing profile.”
This communication potentially contains:
The organization should identify and process each applicable right.
No.
A DSAR is primarily an access request.
A deletion request asks an organization to erase personal data where the applicable legal right exists.
These rights are separate.
For example:
“Please provide the personal data you hold about me.”
“Please delete my personal data where I have the right to request erasure.”
“Please correct inaccurate personal data.”
“Please provide applicable personal data in a portable format.”
A single communication can contain several requests, so an organization's intake process should be able to identify and route each applicable right.
A data portability request is different from a DSAR.
Both can involve providing personal data, but portability has additional conditions and a specific purpose.
Data portability generally concerns receiving certain personal data in a structured, commonly used, machine-readable format and, where technically feasible, transmitting it to another controller.
Not every DSAR qualifies as a portability request.
A privacy rights platform should therefore distinguish:
A DSAR is also different from consent withdrawal.
“I withdraw the consent I previously gave.”
“Give me access to my personal data and the applicable information about its processing.”
A person may exercise both rights, but they should not be confused.
For example, a user could withdraw marketing consent and separately request access to the personal data the organization holds about them.
The DSAR response time depends on the applicable privacy law.
Under the GDPR, organizations generally need to respond without undue delay and within one month of receiving a valid request.
The period may be extended by up to two additional months where necessary because of the complexity or number of requests. The requester must generally be informed about the extension and the reasons for it within the initial one-month period.
The UK's ICO currently describes the same general one-month rule under UK GDPR, with an extension of up to two further months for complex requests or multiple requests.
California privacy law uses a different framework and terminology.
For applicable consumer requests under the CCPA, the standard response period is generally 45 days, subject to applicable extensions and requirements.
This is one reason a DSAR platform should use jurisdiction-specific SLA rules rather than assuming that one deadline applies worldwide.
Important
There is no universal DSAR deadline.
A privacy-management system should determine the applicable deadline based on factors such as:
A person can generally ask an organization to provide access to their personal data.
For example, depending on the organization and the scope of the request, this could include:
The precise scope depends on the applicable law, the organization's processing activities, and any applicable exemptions or restrictions.
Under the GDPR right of access, the organization generally needs to provide:
The ICO summarizes the right of access as including confirmation of processing, a copy of personal information, and supplementary information.
The organization does not necessarily have to provide every internal document in its entirety if the legal right only requires disclosure of the requester's personal data and applicable supplementary information.
Potentially, but this requires careful review.
An organization's records may contain personal information about:
The organization should consider whether disclosure would improperly reveal another person's personal information.
This is one reason DSAR fulfillment often requires human review even when the initial collection process is automated.
Sometimes.
An organization may need to verify identity before disclosing personal information, particularly where there is a meaningful risk that information could be disclosed to the wrong person.
However, identity verification should be proportionate.
The ICO's current guidance says organizations should be reasonable about what identification they request and should not require formal identification where it is unnecessary.
A good DSAR workflow should therefore support:
Yes, depending on the applicable legal framework.
Under UK GDPR guidance, a subject access request can be made verbally or in writing, including through channels such as social media. The requester does not necessarily have to use a prescribed form or legal terminology.
This means organizations should train employees to recognize access requests even when they arrive through:
A DSAR process should not depend entirely on a single web form.
No.
An individual does not generally need to use the term “DSAR” for an organization to recognize a valid access request.
For example:
“Can you send me all the personal information you have about me?”
could constitute an access request even if the person never uses the term DSAR.
Organizations should therefore train customer-service, HR, support, and privacy teams to recognize requests based on their substance.
A right of access is not unlimited.
Depending on the applicable law, exemptions or restrictions may apply.
For example, the organization may need to consider issues involving:
An organization should not simply reject a request because it is inconvenient.
Where a request is refused or information is withheld, the organization should follow the applicable legal requirements concerning explanations, exemptions, and complaint or appeal rights.
The ICO's current guidance states that organizations can refuse access only where an exemption or restriction applies, including certain manifestly unfounded or excessive requests.
In many privacy regimes, individuals can exercise access rights without paying a standard fee.
For example, under UK GDPR guidance, organizations generally cannot charge a fee for responding to a subject access request.
A reasonable fee may be permitted in limited circumstances, such as certain manifestly unfounded or excessive requests or additional copies, depending on the applicable law.
The exact rule depends on the jurisdiction.
A DSAR can potentially include personal data associated with online activity.
Depending on the circumstances, relevant information might include:
Whether particular cookie or analytics information constitutes personal data depends on the applicable law and the context.
Organizations should therefore consider relevant online-data systems when performing DSAR searches rather than limiting the search to their CRM. A cookie scanner can show which cookies and trackers a website sets, which helps identify those systems.
Consent records can be relevant to a DSAR.
For example, an organization may hold information showing:
Where this information constitutes the individual's personal data and falls within the scope of the request, it may need to be considered during fulfillment.
This is why consent records and DSAR management should not always operate as completely separate systems.
Organizations frequently use third-party processors and service providers.
A DSAR may therefore require information to be located across:
The organization remains responsible for managing its access-right workflow under the applicable law, even where relevant data is stored or processed through third-party systems.
Manual DSAR handling can become difficult as the number of requests and data systems increases.
A DSAR management platform can automate DSAR intake and tracking along with other parts of the workflow, including:
Automation should support the privacy team rather than eliminate appropriate human review.
A mature DSAR workflow should include:
Correction, deletion, portability, objection, and access are separate rights.
Organizations should not make legitimate access requests unnecessarily difficult simply because the requester did not use a particular form.
Identity verification should be proportionate to the risk.
Personal data may exist across dozens of systems.
Relevant personal data may be held by cloud, marketing, analytics, support, or other service providers.
A request without an SLA clock is easy to overlook.
Personal information should be delivered through an appropriate secure mechanism.
DSAR responses require careful review where records contain third-party personal data.
Different jurisdictions have different rules and response periods.
Organizations should be able to demonstrate how the request was received, assessed, searched, reviewed, and fulfilled.
ConsentX gives privacy teams one place to receive requests, verify identity, track deadlines, collect data and keep proof of every step. Nothing gets lost, and every reply comes with an audit trail.
A typical workflow in DSAR & Grievance Management can be:
This helps privacy teams reduce the risk of:
The goal is not simply to automate email responses.
The goal is to create an auditable privacy-rights workflow.
ConsentX can help organizations manage DSAR and privacy-rights requests through a centralized process for request intake, identity verification, SLA tracking, fulfillment, and audit evidence.
Book a demo to see the workflow with your own requests.
Explore ConsentX