A data subject access request allows an individual to ask for the personal data you hold about them. You must verify their identity, locate the data across your systems, and provide it in a commonly used format. You can refuse if the request is repetitive or burdensome, provided you explain why.
What exactly is a data subject access request?
A data subject access request is a formal inquiry where an individual asks an organization to confirm whether their personal data is being processed and to receive a copy of that data. This right stems from privacy regulations like the GDPR and similar frameworks globally. It is not merely a courtesy; it is a legal obligation for entities that process personal information.
The request can cover data held in databases, email archives, and even physical records. You do not need to provide data belonging to other individuals unless they have consented or it is anonymized. Understanding the scope helps you prepare your response strategy.
Who is legally allowed to submit one?
Only the individual whose data is being processed, or their lawful representative, can submit a valid request. A third party cannot request data about someone else without proper authorization. This protection prevents unauthorized surveillance or data harvesting by competitors or malicious actors.
If a parent submits a request for a child’s data, you must consider the child’s capacity to understand the implications. This aligns with the principles discussed in our guide on children's online privacy risks. When in doubt, verify the relationship and the legal basis for the representative’s involvement.
How do I verify the identity of the requester?
You must verify the requester’s identity before releasing any data to prevent unauthorized disclosure. The verification method should be proportionate to the sensitivity of the data and the risk of harm. For low-risk data, asking for a government ID may be sufficient. For high-risk data, you may require additional proof or legal documentation.
Do not ask for more information than is necessary to confirm identity. Over-collection during verification can itself be a privacy violation. Balance security with convenience to maintain trust while ensuring compliance.
What data must I include in the response?
You must provide all personal data you hold about the individual, including metadata that identifies them. This includes data from CRM systems, HR files, and customer support logs. You must also disclose the sources of the data, the purposes of processing, and any third parties with whom you have shared it.
Data hidden in online tracking cookies or server logs counts as personal data if it can be linked to an individual. You should check your analytics platforms and ad tech stacks. Refer to our guide on ad blockers for context on how much data these systems collect.
Can I charge a fee for processing the request?
Generally, you cannot charge a fee for standard access requests. The cost of compliance is considered part of your operational overhead. Charging for routine requests can be seen as obstructing the individual’s rights.
You may charge a reasonable fee if the request is manifestly unfounded or excessive. This is rare and requires careful justification. You must inform the requester of the fee before processing. Excessive requests might involve asking for data spanning many years or requesting copies of entire databases.
How long do I have to respond?
You typically have one month to respond to a valid request. This clock starts when you receive the request, provided you have all necessary information to verify identity and scope. You can extend this period by two additional months if the request is complex.
You must inform the requester of any extension within the first month. Failure to respond within the deadline can result in significant penalties. Plan your internal workflows to handle this timeline consistently.
What if the request is too broad or unclear?
You can ask the requester to specify the request if it is vague or overly broad. This is known as seeking clarification. You are not required to search every corner of your organization for data that is not reasonably accessible.
If the request remains manifestly unfounded or excessive after clarification, you can refuse it. You must explain your reasons for refusal. Documenting this decision is critical for regulatory audits.
How should I handle data belonging to third parties?
You must not disclose personal data about other individuals without their consent. If the requested data contains third-party information, you must redact or anonymize it before release. This protects the privacy of others while honoring the requester’s rights.
In some cases, you may be able to provide the data if the third party has already consented or if it is publicly available. Balancing these rights requires careful judgment. Review our guide on encrypted messaging apps for examples of data sharing complexities.
| Scenario | Action Required | Reason |
|---|---|---|
| Request is vague | Ask for clarification | Ensure you understand the scope |
| Identity unclear | Request additional proof | Prevent unauthorized access |
| Third-party data included | Redact or anonymize | Protect other individuals’ privacy |
| Request is excessive | Charge fee or refuse | Prevent abuse of the process |
Can I deny a request entirely?
Yes, you can deny a request if it is manifestly unfounded or excessive. This includes repetitive requests made in bad faith or requests that impose a disproportionate burden on your resources. You must provide a clear explanation for the denial.
Denial is not a free pass to ignore rights. It must be justified and documented. If the requester disputes the denial, they have the right to lodge a complaint with a supervisory authority.
What format should I provide the data in?
You must provide the data in a commonly used, machine-readable format. CSV or JSON files are standard choices. This allows the individual to use the data with other software or services.
If the individual requests a specific format, you should comply if it is feasible. Electronic transmission is preferred for efficiency and security. Consider using encrypted cloud storage for large data transfers to ensure confidentiality during transit.
How do I manage requests for deleted data?
If you have already deleted the data in response to a right to erasure request, you must inform the requester that the data no longer exists. You cannot provide data that you do not hold.
However, you must check backup systems. Data in backups may still exist for disaster recovery purposes. You should have a process to ensure backups do not retain personal data longer than necessary. This technical challenge is often overlooked but is critical for full compliance.
Key takeaways
- Identity verification must be proportionate to the risk of unauthorized disclosure.
- Automated systems often miss data stored in backups or unstructured logs.
- Denial is a valid option for manifestly unfounded or excessive requests.
Treat every request as a legal obligation with a strict deadline. Build automated workflows to locate, verify, and deliver data consistently.
Frequently asked questions
Do I need a lawyer to handle these requests?
Not necessarily, but legal counsel is advisable for complex cases or high-risk data. Routine requests can be handled by trained staff with clear procedures.
What if the requester uses a fake email?
You must verify identity through additional means. Do not release data based solely on an email address. Use multi-factor verification or official ID checks.
Can I use an automated tool to process requests?
Yes, automation helps with speed and consistency. Ensure the tool can handle edge cases and human review is available for complex scenarios.
What happens if I miss the deadline?
You risk regulatory fines and reputational damage. Supervisory authorities take missed deadlines seriously. Implement calendar alerts and escalation paths.
How this guide was produced: written by the DataSafe Times editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
