What is a Data Subject Access Request (DSAR)?
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.
What does DSAR mean?
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.
What is a DSAR under GDPR?
Under Article 15 of the GDPR, the right of access allows an individual to obtain confirmation of whether their personal data is being processed and, where applicable, access to that personal data and specified supplementary information.
The supplementary information can include matters such as:
- The purposes of processing
- Categories of personal data
- Recipients or categories of recipients
- The envisaged retention period, where applicable
- Information about the source of the data where it was not collected from the individual
- Information about relevant rights
- Information about automated decision-making where applicable
- Information concerning international transfers where applicable
A DSAR therefore provides more than simply a database export.
It helps the individual understand what personal data is being processed, why it is being processed, and how the organization handles it.
What information can someone request through a DSAR?
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:
- Account information
- Contact information
- Transaction records
- Customer-service records
- Employment information
- Communications
- Support tickets
- Profile information
- Device or online identifiers
- Certain marketing information
- Personal data contained in internal systems
- Personal data held by relevant processors or service providers
The precise scope depends on the applicable law, the organization's processing activities, and any applicable exemptions or restrictions.
Is a DSAR the same as a data deletion request?
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.
DSAR vs SAR
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.
How does a DSAR work?
A typical DSAR workflow looks like this:
- Request received
- request identified
- identity checked if necessary
- scope assessed
- data located
- information reviewed
- exemptions considered
- response prepared
- data delivered securely
- request recorded
Receive the request
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.
Verify identity where necessary
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.
Determine the scope
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.
Search relevant systems
The organization should perform an appropriate search for the requested personal data.
Depending on the business, this can involve:
- CRM systems
- Customer databases
- Support systems
- HR systems
- Marketing platforms
- Data warehouses
- Cloud applications
- Archived systems
- Relevant processors
Review the information
Before disclosure, the organization should review the information for:
- Third-party personal data
- Applicable exemptions
- Confidential information
- Privileged information where relevant
- Security considerations
- Scope of the request
- Applicable legal restrictions
Prepare the response
The response should provide the personal data and required supplementary information in an appropriate, understandable format.
Deliver securely
The organization should use a secure method for delivering personal information to the requester.
Record the request
The organization should maintain appropriate records of:
- When the request was received
- Who handled it
- Identity-verification steps
- Systems searched
- Information provided
- Exemptions considered
- Response date
- Any extensions
- Relevant communications
This creates an audit trail for demonstrating how the request was handled.
How long does a DSAR take?
The deadline depends on the applicable privacy law.
GDPR
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.
CCPA
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:
- Jurisdiction
- Applicable privacy law
- Type of request
- Identity verification
- Clarification requirements
- Complexity
- Extensions
- Applicable exemptions
Can an organization ask for identification?
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:
- Identity verification
- Risk-based verification
- Secure document handling where necessary
- Verification status
- Requester authentication
- Audit records
Can someone make a DSAR verbally?
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:
- Phone
- Live chat
- Customer support
- Social media
- In-person conversations
- Online privacy forms
A DSAR process should not depend entirely on a single web form.
Does a DSAR have to be called a DSAR?
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.
What does an organization have to provide?
Under the GDPR right of access, the organization generally needs to provide:
- Confirmation of whether personal data is being processed.
- A copy of the relevant personal data.
- The supplementary information required by the applicable law.
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.
Can a DSAR include information about other people?
Potentially, but this requires careful review.
An organization's records may contain personal information about:
- The requester
- Employees
- Customers
- Family members
- Business contacts
- Other third parties
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.
Can an organization refuse a DSAR?
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:
- Third-party rights
- Legal privilege
- Confidentiality
- Regulatory restrictions
- Law-enforcement considerations
- Manifestly unfounded or excessive requests
- Other statutory exemptions
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.
Are DSARs free?
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.
DSAR and data portability
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:
- Access
- Correction
- Deletion
- Portability
- Objection
- Restriction
- Other applicable rights
DSAR and the GDPR
The GDPR's Article 15 right of access is the primary legal basis for a GDPR DSAR.
The right helps individuals understand how their personal data is being processed and allows them to check whether the processing is lawful.
A well-designed DSAR process should therefore connect access requests with the organization's broader GDPR accountability program.
DSAR and UK GDPR
The UK GDPR contains a right of access broadly comparable to the GDPR.
UK organizations should follow current guidance from the Information Commissioner's Office (ICO) because detailed operational requirements and guidance can evolve.
In particular, organizations should account for current rules concerning:
- Response deadlines
- Extensions
- Clarification
- Identity verification
- Reasonable searches
- Exemptions
- Secure disclosure
- Complaints
The ICO updated its right-of-access guidance in 2025 and 2026, including guidance reflecting changes introduced by the Data (Use and Access) Act 2025.
DSAR and CCPA
California's privacy framework provides consumers with rights concerning their personal information, including rights to access information.
The CCPA uses its own terminology, procedures, exemptions, and deadlines, so organizations should not simply copy a GDPR DSAR workflow and assume that it satisfies California requirements.
A privacy-rights system should identify the applicable jurisdiction and route the request through the appropriate workflow.
DSAR and DPDPA in India
India's Digital Personal Data Protection Act (DPDPA) uses different terminology from the GDPR.
The DPDPA refers to the individual as the Data Principal, rather than the GDPR's “data subject.”
Organizations operating in India should therefore distinguish between:
- GDPR / UK GDPR data-subject rights
- CCPA consumer rights
- DPDPA Data Principal rights
A global privacy platform should use jurisdiction-specific workflows rather than treating every privacy request as a GDPR DSAR.
DSAR vs Data Subject Rights Request
A Data Subject Rights Request (DSR) or Data Subject Request is a broader concept than a DSAR.
A rights request may concern:
- Access
- Correction
- Deletion
- Restriction
- Objection
- Portability
- Other jurisdiction-specific rights
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:
- An access request
- A correction request
- A deletion request
The organization should identify and process each applicable right.
DSAR vs consent withdrawal
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.
DSAR and cookies
A DSAR can potentially include personal data associated with online activity.
Depending on the circumstances, relevant information might include:
- Online identifiers
- Account identifiers
- Cookie-linked information
- Advertising identifiers
- IP addresses
- Website activity
- Marketing profiles
- Preference records
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.
DSAR and consent records
Consent records can be relevant to a DSAR.
For example, an organization may hold information showing:
- When consent was collected
- What purposes were presented
- Which choices were made
- Which version of the notice was shown
- Which preferences were changed
- When consent was withdrawn
- Which identifiers were associated with the consent event
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.
DSAR and third-party processors
Organizations frequently use third-party processors and service providers.
A DSAR may therefore require information to be located across:
- CRM platforms
- Email providers
- Cloud storage
- Customer-support tools
- Marketing platforms
- Analytics systems
- HR platforms
- Payment systems
- Data warehouses
- Other processors
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.
How automation helps with DSARs
Manual DSAR handling can become difficult as the number of requests and data systems increases.
A DSAR management platform can automate parts of the workflow, including:
- Request intake
- Case creation
- Identity verification
- Request classification
- Deadline calculation
- SLA monitoring
- Assignment
- Internal notifications
- Data-source tracking
- Fulfillment workflows
- Secure delivery
- Audit logs
- Escalations
Automation should support the privacy team rather than eliminate appropriate human review.
DSAR automation checklist
A mature DSAR workflow should include:
Intake
- Centralized request intake
- Email and web-form support
- Manual request creation
- Automatic case numbering
Classification
- Access request detection
- Rights classification
- Jurisdiction detection
- Priority assignment
Identity verification
- Requester authentication
- Verification status
- Proportionate verification workflows
- Secure evidence handling
Deadline management
- Applicable SLA calculation
- Automatic deadline reminders
- Extension tracking
- Escalation alerts
Data discovery
- System inventory
- Search assignments
- Processor coordination
- Collection tracking
Review
- Duplicate removal
- Third-party information review
- Exemption review
- Human approval
Fulfillment
- Secure export
- Response generation
- Delivery tracking
- Request closure
Audit
- Complete activity history
- Timestamps
- Assigned users
- Search records
- Decisions
- Final response
- Evidence of completion
Common DSAR mistakes
Treating every privacy request as a DSAR
Correction, deletion, portability, objection, and access are separate rights.
Requiring a special form
Organizations should not make legitimate access requests unnecessarily difficult simply because the requester did not use a particular form.
Automatically demanding government ID
Identity verification should be proportionate to the risk.
Searching only the CRM
Personal data may exist across dozens of systems.
Ignoring processors
Relevant personal data may be held by cloud, marketing, analytics, support, or other service providers.
Missing deadlines
A request without an SLA clock is easy to overlook.
Sending data insecurely
Personal information should be delivered through an appropriate secure mechanism.
Disclosing another person's information
DSAR responses require careful review where records contain third-party personal data.
Treating GDPR deadlines as universal
Different jurisdictions have different rules and response periods.
Closing the case without an audit trail
Organizations should be able to demonstrate how the request was received, assessed, searched, reviewed, and fulfilled.
DSAR implementation checklist for businesses
- Define what counts as a DSAR.
- Train customer-facing employees to recognize requests.
- Provide accessible request channels.
- Verify identity where necessary and proportionately.
- Determine the applicable jurisdiction.
- Calculate the correct statutory deadline.
- Identify the scope of the request.
- Search relevant systems.
- Coordinate with processors where necessary.
- Review third-party personal information.
- Assess applicable exemptions.
- Prepare the response in an accessible format.
- Deliver information securely.
- Record the request and response.
- Track deadlines and extensions.
- Maintain evidence for audit purposes.
- Review the process regularly.
DSAR and ConsentX
ConsentX can help organizations manage DSAR and privacy-rights workflows through a centralized process for request intake, identity verification, SLA tracking, fulfillment, and audit evidence.
A typical workflow can be:
- Request
- identity verification
- jurisdiction/rule detection
- SLA timer
- data discovery
- review
- fulfillment
- secure response
- audit record
This helps privacy teams reduce the risk of:
- Missed deadlines
- Unassigned requests
- Manual tracking errors
- Incomplete request records
- Inconsistent fulfillment
- Poor auditability
The goal is not simply to automate email responses.
The goal is to create an auditable privacy-rights workflow.
Key takeaways
- A DSAR is a request for access to an individual's personal data.
- DSAR is also commonly called a Subject Access Request (SAR) or right-of-access request.
- A DSAR is distinct from requests for deletion, correction, portability, objection, or restriction.
- Under the GDPR, the right of access generally requires a response within one month, subject to qualifying extensions.
- UK GDPR guidance similarly provides a one-month period, with possible extensions for complex or multiple requests.
- CCPA access requests operate under different rules and deadlines.
- Identity verification may be appropriate, but it should be proportionate.
- Organizations should search relevant systems and consider data held by processors.
- DSAR responses may require review for third-party information and legal exemptions.
- Secure fulfillment and audit records are important parts of DSAR management.
- A DSAR platform should use jurisdiction-specific rules and SLA timers, not one global deadline.
- Automation can streamline intake, verification, discovery, fulfillment, and audit evidence.
Build an auditable privacy-rights workflow
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.