Table of contents
April 10, 2026
Data Subject Access Request (DSAR)
Confused about how to handle a data subject access request without exposing your organization to regulatory risk? You’re not alone. Most companies treat DSARs like admin tasks—until one request turns into a compliance audit trigger.
Here’s the truth: a DSAR is not a formality. It’s a legal stress test of your data governance framework.
This guide gives you a practical, step-by-step blueprint to handle DSARs under both GDPR and India’s DPDP Act—without guesswork, delays, or penalties.
What is a Data Subject Access Request (DSAR)?
A data subject access request (DSAR) is a legal right that allows individuals to request access to their personal data held by an organization, including how it is collected, used, stored, and shared.
Think of a DSAR as a “data X-ray request.” The individual isn’t asking politely—they are exercising a statutory right to inspect your data architecture.
- Under GDPR, it is called DSAR (Data Subject Access Request)
- Under DPDP Act, it aligns with DPAR (Data Principal Access Request)
Same intent. Different terminology. Same compliance pressure.
Why Do Companies Fail to Comply with DSAR Requirements?
Most companies fail to comply with data subject access request (DSAR) requirements due to operational gaps rather than legal ignorance. Inconsistent data mapping, siloed systems, delayed response workflows, and lack of ownership lead to incomplete or late responses—making DSAR compliance one of the most common triggers for regulatory complaints and enforcement actions.
A DSAR is where policy meets reality. It exposes gaps between what you claim in privacy policies and what your systems actually do.
Most organizations fail not due to lack of intent—but due to lack of operational readiness.
Ask yourself:
Can you locate all user data across systems within 30 days?
If the answer is unclear, your compliance fortress has cracks.
How to Handle a Data Subject Access Request (DSAR)?
To handle a data subject access request effectively, organizations must verify identity, locate all relevant personal data, assess exemptions, and respond within statutory timelines (30 days under GDPR, “reasonable time” under DPDP Act). A structured workflow is essential to avoid penalties and delays.
Let’s break this into a defensible blueprint.
1. Verify Identity Before Disclosure
Never disclose personal data without confirming the requester’s identity. A failed verification is not a minor error—it is a reportable data breach.
Organizations must implement robust identity verification mechanisms such as OTP-based authentication, government ID validation (KYC), or verified email confirmation. Under GDPR, controllers are explicitly required to take “reasonable steps” to verify identity before fulfilling a DSAR.
Translation: Identity verification is your first line of defence—it prevents unauthorized disclosures while demonstrating due diligence to regulators.
2. Map and Retrieve Personal Data
You cannot respond to a DSAR if you do not have full visibility of your data landscape. Incomplete retrieval equals non-compliance.
Organizations must maintain a comprehensive data inventory that spans all systems—CRM platforms, cloud storage, internal databases, email servers, and archived backups. This requires implementing data mapping and discovery tools to identify where personal data resides across fragmented environments.
Under GDPR, the response must clearly include:
- Categories of personal data processed
- Purpose of processing
- Details of third-party data sharing
3. Assess Legal Exemptions
Not all data collected must be disclosed—but exemptions must be applied carefully and lawfully. Misuse can trigger regulatory scrutiny.
Under GDPR, organizations may restrict disclosure in specific cases, such as:
- Protecting trade secrets or intellectual property
- Preventing disclosure that impacts third-party privacy rights
Similarly, the DPDP Act permits reasonable restrictions, provided they are grounded in legal justification and proportionality.
4. Format and Deliver the Response
The quality of your response determines whether your compliance is accepted or challenged. Clarity is not optional—it is expected.
Organizations must provide the requested data in a structured, commonly used, and machine-readable format, such as CSV or PDF. The response should include:
- A copy of the personal data
- The purpose of processing
- The data retention period
- Details of third-party disclosures, if applicable
Practical application: A well-structured DSAR response often includes a cover summary document explaining the data, followed by annexures with raw datasets.
5. Meet Timelines Without Fail
Timelines in DSAR compliance are legally binding obligations—not flexible targets. Missing them is one of the fastest ways to trigger regulatory action.
- Under GDPR, organizations must respond within 30 days, with a possible extension of up to 60 days for complex requests (with justification).
- Under the DPDP Act, responses must be provided within a “reasonable time,” though regulatory interpretation is still evolving.
Is DSAR and DPAR the Same?
A DSAR (Data Subject Access Request) under GDPR and a DPAR (Data Principal Access Request) under the DPDP Act are fundamentally the same in purpose—they both allow individuals to access their personal data held by organizations.
The difference lies in terminology and regulatory maturity: GDPR uses “data subject,” while DPDP uses “data principal,” and GDPR currently provides more detailed procedural clarity compared to the evolving framework under India’s DPDP Act.
How to File a Data Subject Access Request in India?
To file a data principal access request (DPAR) in India, individuals must submit a request to the data fiduciary through designated channels (email, portal, or grievance officer), specifying the data required. Organizations are obligated to respond transparently within a reasonable timeframe under the DPDP Act.
Here’s how it works in practice:
1. Identify the Data Fiduciary
Before filing a request, you must clearly identify the entity that controls and processes your personal data. Sending a request to the wrong entity delays your rights and weakens enforceability.
How to identify them in practice:
- Check the Privacy Policy or Terms of Service on the website/app
- Look for the Grievance Officer / Data Protection Officer (DPO) details
- Identify the legal entity name, not just the brand name
Practical insight:
If you’re using a food delivery app, the app company is the primary data fiduciary—not the restaurant.
2. Submit a Request
A DSAR/DPAR must be submitted through an official communication channel to ensure it is legally recognized and traceable. Informal requests (e.g., social media DMs) do not trigger compliance obligations.
Organizations typically provide multiple submission channels:
- Email: Sent to the designated privacy or grievance email ID
- Website Form: Many companies have a dedicated “Privacy Request” portal
- Grievance Redressal System: Mandatory under DPDP Act for Indian entities
Best practice:
- Use written, trackable communication
- Include subject line: “Data Access Request under DPDP Act / GDPR”
Practical insight:
Submitting through official channels creates a documented audit trail, which becomes critical if escalation is required.
3. Specify Your Request Clearly
Vague requests lead to incomplete responses. Precision ensures you receive meaningful and actionable information.
Your request should clearly define what you are asking for. At a minimum, include:
- Copy of Personal Data: All data the organization holds about you
- Purpose of Processing: Why your data is collected and used
- Third-Party Disclosures: Who your data is shared with
Optional but powerful additions:
- Request data retention period
- Ask for source of data (if not directly collected)
- Seek automated decision-making logic, if applicable
Compliance insight:
The more specific your request, the harder it is for organizations to respond with generic or incomplete disclosures.
4. Track Response Timeline
Once the request is submitted, tracking timelines becomes critical. Delayed responses are one of the most common compliance failures.
- Under GDPR, organizations must respond within 30 days
- Under the DPDP Act, responses must be provided within a reasonable time (interpretation evolving, but delay can still trigger complaints)
What you should do:
- Note the date of submission
- Set a follow-up reminder (e.g., 15–20 days)
- Maintain copies of all communication
If delayed:
- Send a formal follow-up reminder
- Escalate to the Grievance Officer or Data Protection Board (India) if required
Common DSAR Mistakes That Trigger Penalties
Most DSAR failures are predictable—and avoidable. Yet they happen repeatedly due to weak processes and poor ownership.
1. Treating DSAR as a Legal Task Only
A DSAR is not just a legal exercise—it is an operational process. Legal teams can interpret requirements, but they cannot retrieve or validate data without IT and operations support.
This leads to delays, incomplete responses, and coordination gaps, especially when data is spread across systems.
Fix: Build cross-functional workflows (Legal + IT + Ops)
2. Missing Data in Silos
Personal data is rarely stored in one place. It exists across CRMs, cloud systems, analytics tools, and internal communications.
If these systems are not connected, responses become fragmented and incomplete, which regulators treat as non-compliance.
Fix: Implement centralized data mapping
3. Delayed Responses
DSAR timelines are strict and enforceable. Delays usually happen due to unclear ownership, manual processes, and lack of tracking.
Even short delays can trigger complaints and regulatory scrutiny, especially if repeated.
Fix: Automate DSAR tracking workflows
4. Over-Disclosure
Sharing more data than required can create new privacy risks. Over-disclosure may expose third-party data or sensitive internal information.
DSAR responses must follow data minimization—share only what is necessary and relevant.
Fix: Apply data minimization principles
5. No Audit Trail
If you cannot prove compliance, you have not complied. Without proper records, organizations cannot demonstrate timelines, verification steps, or response accuracy.
This weakens your position during audits or investigations.
Fix: Maintain DSAR logs and documentation
Conclusion
A data subject access request is not just about giving data—it’s about proving control over your data ecosystem.
Build systems, not excuses.
Because when a DSAR arrives, regulators aren’t evaluating your intent—they’re evaluating your readiness.
And in compliance, readiness is the difference between a controlled response and a public violation.
Key Takeaways
- A data subject access request (DSAR) is a legal right that lets individuals access their personal data and how it is used.
- Most DSAR failures happen due to operational gaps like poor data mapping and siloed systems—not lack of legal knowledge.
- Effective DSAR handling requires a clear process: verify identity, retrieve data, assess exemptions, and respond on time.
- Identity verification is critical to prevent unauthorized data disclosure and potential breaches.
- Organizations must have full visibility of data across systems to avoid incomplete responses.
- DSAR and DPAR are similar rights with different terminology under GDPR and the DPDP Act.
- Filing a request requires identifying the correct organization and clearly specifying what data is needed.
- Delays, over-disclosure, and lack of documentation are key risks that can trigger regulatory action.
Related Blog
- https://www.privacyglobal.org/blog/how-to-write-privacy-notice
- https://www.privacyglobal.org/blog/consent-management-framework-dpdp-act
- https://www.privacyglobal.org/blog/privacy-by-design-and-privacy-by-default
