A user sends a message saying, "I want to know what data you have on me." There is no mention of the specific right being exercised, no user ID, and the email is from a generic Gmail account. Your organisation operates globally and is subject to both GDPR and CCPA.

What exactly is DSR? How to handle such vague DSR?

What is a Data Subject Request (DSR)?

A Data Subject Request (DSR) is a request an individual makes to know what data you have collected about them. At its core, a DSR is any communication from an individual asserting their rights over their personal data. 

These rights can include:

• Right of Access – Know what data an organization holds.
  
  
• Right to Deletion – Request the erasure of personal data.
  
  
• Right to Correction – Fix inaccurate or incomplete data.
  
  
• Right to Restrict or Object – Limit or stop processing.
  
  
• Right to Data Portability – Receive data in a usable format.
  
  

Steps to verify the identity of the requester.

Step 1: Analyze the Context of the Request

• Check the source of the request (e.g., email, contact form, logged-in portal).

• Determine what type of data is likely being requested and how it was originally collected.
  If the data was originally collected via email or account sign-up, you may treat the same source/email as valid unless risks suggest otherwise.

Step 2: Determine Sensitivity and Risk

• Ask: What type of data might be affected?
• Low sensitivity: e.g., contact info, user preferences → basic authentication sufficient.
• High sensitivity: e.g., health, financial, biometric → stricter verification required.

The more sensitive the data, the more thorough the authentication.

Step 3: Attempt Passive Authentication First

• Compare incoming request data (email address, headers) with existing records.
• If request comes from an email that matches an existing account:
  Accept as pre-verified, unless risks warrant otherwise.

Step 4: Use Existing Data to Confirm Identity

Instead of collecting new data, use information you already hold. For example:

• Ask the user to confirm details only they would know, such as:
• • Last order ID or service interaction
  • Partial phone number
  • User-generated identifiers (e.g., nickname or username)
    
    

Can we treat this as a formal DSR?

Yes we can treat this as a formal DSR. This is because under both GDPR and CCPA, a data subject does not need to cite specific laws or use legal terms for a request to be valid. A clear, plain language request like asking what data is held is sufficient. The organization must interpret it as a DSR, verify the requester’s identity, and respond within legal timelines. Dismissing it due to informality may lead to non-compliance with either regulation.

What will be your first response to such a vague request?

 Upon receiving a vague data subject request like, your first response should be: 

•  Acknowledge the request
•  Explain that identity verification is required
•  Ask for additional details such as the email or account used, or past interactions to confirm the requester’s identity.

This ensures compliance with GDPR and CCPA while protecting personal data from unauthorized disclosure. Avoid collecting unnecessary new data during verification.

Approach of handling vague DSR

1. Legal Requirements

• GDPR:- The GDPR addresses vague and problematic data subject requests (DSRs) primarily through Article 12.

Article 12 of GDPR is the main provision dealing with problematic requests. The controller shall not refuse to act on the request of the data subject for exercising his or her rights under Articles 15 to 22, unless the controller demonstrates that it is not in a position to identify the data subject.

Article 12 allows controllers to charge a reasonable fee or refuse to act on requests that are "manifestly unfounded or excessive, in particular because of their repetitive character."

A request may be manifestly unfounded if the individual clearly has no intention to exercise their right of access.The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.

For vague requests specifically, controllers can:

• Request additional information to identify the data subject and locate their personal data
• Ask for clarification if the request is unclear or overly broad
• Require the individual to demonstrate that the request is manifestly unfounded or excessive
• CCPA:- Under Code §1798.130, acknowledge receipt within 10 business days. Even if a request is unclear or vague, you must confirm receipt within 10 business days. Your acknowledgment should include general information about how the request will be processed. Always confirm receiving the request even if you’re unsure of the consumer's intent.

Businesses must verify the identity of the requestor before disclosing or deleting personal information. The level of verification depends on the sensitivity of the data and the nature of the request. A vague request triggers the need for identity verification before any action.

Once the identity is verified and the request clarified, you must respond within 45 days. You may extend this once by an additional 45 days (total 90), with notice and justification.

You cannot deny a request solely because it’s vague. You may deny a request only if:

•  You cannot verify identity,
•  The consumer fails to respond to clarification attempts, or
•  The request is manifestly unfounded or excessive.

 Practical Steps

1. Acknowledge the Request Promptly 

2. Initiate Identity Verification 

3. If the request is vague, ask for clarification

4. Locate and Review Relevant Data 

5. Prepare and Deliver the Response

  Risk Mitigation

1. Acknowledge Receipt Promptly

2. Verify Identity Carefully

3. Clarify Scope of Request (e.g., right of access, rectification, erasure, etc.)

4. Document Every Step

5. Apply Data Minimization (Avoid collecting more personal data than necessary.)

6. Train Your Team (Establish a SOP)

Final Thoughts

When dealing with vague or excessive requests the threshold for refusing requests is high as the GDPR essentially places the burden on controllers to engage with data subjects to clarify vague requests rather than simply dismissing them. Any dismissal without proper reasoning may be considered as non compliance. Controllers must first acknowledge the request and then verify the identity of the requester of such vague DSR. As the compliance standard is so high, internal teams should be well trained for handling such vague DSR requests.

References:-

1. GDPR:-     https://gdpr-info.eu/art-12-gdpr/
2. ICO:-https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/when-can-we-refuse-to-comply-with-a-request/
3. CCPA:-https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5
4. IAPP:-https://iapp.org/news/a/how-to-verify-identity-of-data-subjects-for-dsars-under-the-gdpr/

By Shantanu Date