Data Subject Access Requests: How to Handle Them Correctly
Most organisations fail these requests not because of legal complexity, but because they cannot locate the data across fragmented legacy systems and shadow IT.
A data subject access request allows an individual to ask for a copy of the personal data you hold about them. You must verify the requester’s identity, search all systems for that data, and provide it in a structured format within the statutory timeframe. Failure to respond accurately can trigger significant regulatory penalties and reputational damage.
The Mechanics of Data Subject Access Requests
Imagine a library where every book is indexed, but the catalogue only lists the titles, not the location of the shelves. When a patron asks for every book written by a specific author, the librarians must physically walk the aisles, check the archives, and even inspect the books returned by other patrons to see if they contain marginalia by that author. Data subject access requests function on this same principle of exhaustive retrieval. The requester is the patron, and your organisation is the library. The law requires you to produce every piece of information that identifies an individual, regardless of where it sits in your infrastructure.
| Aspect | Detail |
|---|---|
| Trigger | A clear request from an individual for their personal data. |
| Scope | All personal data held, processed or stored by the organisation. |
| Format | Electronic, structured and commonly used formats unless impractical. |
| Timeframe | One month, extendable by two months for complex cases. |
| Cost | Generally free, unless the request is manifestly unfounded. |
| Exemptions | Legal privilege, ongoing investigations or disproportionate effort. |
The mechanism relies on the principle that individuals have a right to transparency. You cannot hide data behind proprietary formats or internal jargon. If you hold a spreadsheet with an employee’s performance notes, that is personal data. If you hold an email chain discussing a customer’s complaint, that is personal data. The request forces you to map your data flows with precision. Most organisations struggle because their data maps are theoretical rather than practical. The gap between where data should be and where it actually lives is where these requests fail.
Who Is Affected by Data Subject Access Requests
The obligation extends beyond the obvious customer database. It affects any entity that processes personal data. This includes small businesses, charities, schools and public bodies. If you collect an email address for a newsletter, you are processing personal data. If you record a phone call for quality assurance, you are processing personal data. The scale of the operation does not grant immunity from the requirement to respond.
The definition of personal data is broad. It includes names, identification numbers, location data, online identifiers and factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of a person. This broad scope means that you must consider indirect identifiers. A unique user ID combined with a timestamp can constitute personal data if it allows for re-identification. You must also consider biometric data. Facial recognition logs or fingerprint scans are high-risk personal data. Their inclusion in a response requires careful handling to prevent secondary misuse.
Third-party processors are also in the chain. If you use a payroll provider, a cloud host or a customer support chat tool, they process personal data on your behalf. You remain the controller. You are responsible for ensuring they can produce their portion of the data. Your contract with them must include clauses that allow for this cooperation. If they cannot deliver, you are liable for the incomplete response.
How to Process Data Subject Access Requests
The process begins with verification. You must confirm that the person making the request is indeed the data subject. This prevents identity theft and unauthorised access. For simple requests, a standard ID check may suffice. For sensitive data, such as health records or financial details, you need stronger verification. You should have a standard operating procedure for this. Do not accept a request via an unsecured channel if the data is sensitive.
Once identity is confirmed, you must acknowledge the request. This starts the clock. You then initiate a search across all systems. This is the most labour-intensive step. You must search primary databases, email servers, file shares, collaboration tools and backup systems. You must also check with third-party processors. It is not enough to check the active database. Deleted items in the recycle bin, archived emails and file metadata may contain personal data. Metadata, such as author names or edit history, can reveal personal details even if the main document is redacted.
The next step is redaction. You often hold data about multiple individuals in a single record. You must remove the personal data of other people before sending the response. This is known as third-party redaction. It requires careful judgement. Over-redaction can render the data useless to the requester. Under-redaction breaches the privacy of others. You must strike a balance. The format of the delivery matters too. You should provide data in a machine-readable format, such as CSV or JSON, unless the requester asks for something else. Sending scanned PDFs of hundreds of pages is often considered non-compliant because it is not easily usable.
Common Mistakes in Handling Requests
Organisations frequently misunderstand the scope of the obligation. One common error is limiting the search to the primary customer relationship management system. This ignores the reality of modern data sprawl. Another mistake is refusing requests based on the volume of data. The law allows refusal if the request is manifestly unfounded or excessive, but this threshold is high. A request for all data is not excessive by default. You must demonstrate that the effort is disproportionate to the benefit.
Another frequent error is failing to inform the requester about their rights. The response must include information about the sources of the data, the recipients, the retention period and the right to lodge a complaint. This is part of the transparency obligation. Without this context, the data dump is incomplete. Some organisations also fail to update their privacy audits after a request. Each request reveals gaps in data mapping. Ignoring these findings leaves the organisation vulnerable to future failures.
Delays are another critical issue. The statutory period is strict. Extensions are possible only for complex requests, and you must inform the requester within one month of the reason for the delay. Silence is not a strategy. If you cannot meet the deadline, you must communicate proactively. Failure to respond within the timeframe is a breach in itself, regardless of whether you eventually provide the data.
Strategic Implications for Data Management
Handling these requests efficiently requires a shift in how you manage data. It is not just a legal compliance task. It is a test of your data hygiene. If you cannot find your data, you cannot protect it. This is why privacy by design is relevant. Building systems that allow for easy data retrieval reduces the friction of compliance. Tagging data at the point of entry helps in locating it later.
The cost of poor data management is high. Manual searches for data are expensive and error-prone. Automation tools can help, but they require clean data. If your data is messy, automation will amplify the errors. You need a clear data retention policy. Deleting data you no longer need reduces the scope of future requests. It also reduces risk. The less data you hold, the less you have to protect and the less you have to produce.
Consider the impact on your third-party relationships. Your vendors must be able to support your compliance efforts. If they cannot, you may need to change vendors. This is a business decision, not just a technical one. The ability to retrieve data quickly is a competitive advantage in a regulated market. It demonstrates control and transparency.
See also: CCPA Compliance Checklist: Inventory, Rights, and Vendor Management
The Role of Technology in Compliance
Technology can aid in processing requests, but it is not a silver bullet. Data subject access request management software can automate the intake, verification and notification steps. It can also help in searching for data across connected systems. However, these tools rely on accurate metadata and integration. If your systems are siloed, the software cannot bridge the gap.
You must ensure that your security measures do not hinder access. Encryption and access controls are vital for security, but they must allow for authorised retrieval. End-to-end encryption can make data inaccessible even to the organisation holding it. In such cases, you may need to decrypt data to respond to a request. This creates a tension between security and compliance. You must design your architecture to balance these needs.
The use of email aliases can complicate matters. If a user has multiple aliases, you must search for data associated with all of them. This requires a robust identity management system. Without it, you risk missing data linked to secondary addresses. The same applies to user accounts with different naming conventions. Consistency in identity management is key to accurate retrieval.
Navigating Complex Scenarios
Some requests are inherently complex. A request for all data from the last ten years, for example, may involve terabytes of information. In such cases, you can charge a reasonable fee or refuse the request if it is repetitive. The key is to document your reasoning. You must be able to show that the request is manifestly unfounded or excessive.
Another complex scenario involves data that is no longer in your direct control. If you have shared data with a partner, you must coordinate with them. The partner may have their own legal obligations. You must ensure that the data is returned or deleted if the relationship ends. This requires clear contractual terms. Without them, you are left with incomplete information.
The final aspect is the human factor. Employees must be trained to recognise these requests. A request may come via email, post or social media. It does not need to use the exact legal terminology. If it asks for personal data, it is a request. Front-line staff must know how to escalate these requests to the data protection team. Delay at the intake stage affects the entire process.
Conclusion of the Process
The process ends with the delivery of the data. You must ensure that the transfer is secure. Sending sensitive data via unencrypted email is a breach. Use secure file transfer protocols or password-protected archives. Confirm receipt with the requester. Keep a record of the request and the response. This record is your evidence of compliance. It protects you in case of an audit or investigation.
The cycle then repeats. Each request is an opportunity to improve your data management. Analyse the findings. Did you find data in unexpected places? Update your data map. Did the search take too long? Improve your tools. Continuous improvement is the only way to stay compliant. The landscape of data processing is dynamic. Your processes must be too.
Key takeaways
- Identity verification is mandatory before releasing any data to prevent unauthorised disclosure.
- You must search all systems, including backups and third-party processors, not just primary databases.
- Refusals must be justified by specific legal exemptions, not by inconvenience or cost.
Treat every data subject access request as a test of your data mapping accuracy. Audit your third-party contracts and internal data retention policies immediately to ensure you can locate and retrieve data within statutory limits.
Frequently asked questions
Can I refuse a data subject access request?
You can refuse if the request is manifestly unfounded or excessive, or if it infringes on the rights of others. You must provide a clear justification for the refusal.
How do I verify the identity of the requester?
Use proportionate measures based on the sensitivity of the data. For high-risk data, require additional proof of identity beyond standard identification.
Do I need to search backup tapes?
You must search all systems where personal data is held. If backups are the only source, you must restore and search them. However, you are not required to restore data if it is no longer necessary for the original purpose.
What if the data contains information about other people?
You must redact the personal data of other individuals before providing the response. Ensure the redaction is thorough and does not leave identifiable fragments.
How this guide was produced: written by the Vector Bulletin 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.
