Most companies think they are handling DSARs well. Then they get their first ICO investigation notice and realize their “process” was three people forwarding emails to each other and hoping for the best. DSAR volumes across the US, UK, and EU have climbed sharply in the last few years, and regulatory patience for sloppy compliance has gone in the opposite direction.
If your organization does not have a structured, documented response workflow right now, you are already behind. This blog breaks down what a Data Subject Access Request (DSAR) actually is, what the law requires, where companies consistently go wrong, and how to build a process that holds up under scrutiny.
Data Subject Access Requests are a legal process through which anyone can approach any organization to find out the personal information that an organization stores on him or her. This includes not only whether the organization holds the information but what it actually holds, for what purpose, and with whom it has been shared.
This right exists because of data privacy regulations that now cover most of the world’s major economies:
The DSAR meaning itself is not complicated. People have a right to their own data. What is complicated is actually fulfilling that right properly, at scale, across a modern data environment where personal information is scattered across dozens of systems, tools, and third-party vendors.
Under GDPR, you have one calendar month from the date of receipt to respond. That window can stretch to three months for complex or high-volume requests, but only if you tell the requester within the first month that you need more time. Under CCPA, the window is 45 days, extendable by another 45. These deadlines are firm. They do not care about your team’s workload or the state of your data infrastructure.
A compliant DSAR response covers quite a bit of ground. You will need to find out whether you are processing personal data about the individual in question, supply the data, indicate on what grounds you are processing that data, mention any transfers to third parties, state how long you retain the data, and point out the rights available to that individual.
That is a lot to pull together quickly, especially if you have never thought carefully about where all your data actually lives.
The penalties under GDPR go up to 20 million euros or 4% of global annual turnover, whichever is the larger number. That ceiling is not theoretical. The UK ICO and EU supervisory authorities have issued fines specifically for DSAR failures, separate from data breach penalties. And complaints from individuals trigger regulatory attention that frequently expands into wider audits of your data governance practices. One poorly handled request can open a door you really did not want opened.
But most DSAR failures are not dramatic. They are mundane. Here is where organizations actually go wrong.
Requests that go unrecognized: A DSAR does not need to use the phrase “data subject access request.” It does not need to come through a designated portal. If someone emails your customer support team asking what data you hold on them, that is a DSAR and your response clock just started. Many organizations miss requests entirely because they land in general inboxes and get treated as ordinary customer queries. By the time someone realizes what they are looking at, the deadline is two weeks away.
Identity verification that creates its own problems: You do need to confirm who is making the request. You do not need to demand a passport, utility bill, and a signed declaration. Asking for disproportionate documentation is a compliance issue in itself. The bar is proportionate verification, and the line between reasonable and excessive is one regulators take seriously.
Incomplete data pulls: This is probably the most common substantive failure. A single customer’s personal data might live in your CRM, your email platform, your support ticketing system, your marketing automation tool, and with two or three external processors. If your DSAR response only covers what is in the CRM, you are non-compliant, even if that was an honest oversight. Incomplete data subject requests responses are treated the same as no response in some jurisdictions.
Redaction errors in both directions: DSAR responses frequently include information that relates to third parties, and that data needs to be redacted before the response goes out. But organizations sometimes over-redact, withholding data they are actually required to disclose. Getting redaction right is a legal judgment call, not a Ctrl+F exercise. The redaction process requires people who understand both what the regulation requires and what the exemptions actually cover.
Treating every DSAR as a one-off: Organizations that handle each request from scratch, with no repeatable DSAR workflow, burn through enormous amounts of legal and administrative time. When volumes are low, this feels manageable. At 50 or 100 requests a month, it falls apart completely. And volumes are going up across the board.
There is no single system that works for every organization, but the core stages of a solid DSAR process are consistent. Here is what a properly structured response looks like in practice.
Log it immediately: The moment a request comes in, it needs a reference number, a timestamp, and an assigned owner. It does not matter whether it arrived via your privacy portal, a customer service email, or a social media DM. Logging is your evidence that you took the request seriously from day one.
Verify identity proportionately: Match your verification approach to the risk level of the data involved. A logged-in customer asking about their purchase history needs less verification than an anonymous request for sensitive health data. Whatever you do, document it.
Clarify scope if the request is genuinely vague: You can ask for clarification, and doing so pauses the clock in some jurisdictions. But this only works if the request is actually unclear. Using clarification requests as a delay tactic is the kind of thing that looks very bad in a regulatory complaint. Be straightforward about what you need and why.
Search every relevant system: This is where the real work is. Your search should cover your CRM, HR platform, email archives, marketing tools, support systems, cloud storage, and any third-party processors who handle personal data on your behalf. If you have done proper data mapping before a request arrives, this step is manageable. If you have not, it is a significant undertaking under time pressure.
Review, redact, compile: Go through everything you have found. Pull out what is relevant, redact what needs to come out, and build a response package that covers all the required disclosure elements. This step needs legal oversight, not just administrative effort.
Respond within the deadline: The response should come in a commonly used electronic format unless the individual has asked for something else. You generally cannot charge a fee unless the request is clearly excessive or unfounded. Send it, log that you sent it, and keep the record.
Document the whole process: Every decision, every search, every redaction call, every communication with the requester. Your documentation is your compliance defense if anything is ever challenged. This is not paperwork for its own sake.
When you are handling a handful of requests a month, a spreadsheet and a shared drive can get you through. That stops being true somewhere around the point where your business starts scaling, a privacy story hits the news, or a regulatory complaint triggers a spike.
The best tools for managing data subject access requests do a few things well. They centralize intake so nothing gets lost in a general inbox. They automate data discovery across your connected systems, which removes the manual search burden and reduces the risk of missing data. They build configurable DSAR workflow stages so the right teams handle the right steps, with deadlines tracked automatically. And they maintain audit logs that give you a defensible record of every action taken on every request.
Established platforms like OneTrust, TrustArc, and Exterro are widely used for enterprise-level DSAR management. DataGrail has built a strong following for its API-first approach to automated data discovery across SaaS environments. The right tool depends on your data infrastructure, your volume, and your compliance posture across jurisdictions.
But here is the thing about technology in this space: it does not fix a broken process. It automates and scales whatever you already have. If your data governance is fragmented, if your data map is two years out of date, if nobody has actually defined who owns incoming requests, the software will systematize that mess rather than resolve it. Organizations that buy DSAR tools without doing the underlying process work first usually find that within six months, they have an expensive platform and the same compliance gaps they started with.
This gap between tooling and process is exactly why DSAR services from specialist LPO providers have become a serious option for organizations that want to get this right without building the capability entirely in-house.
Legal Process Outsourcing is not a new concept, but its application to data subject request compliance has grown considerably as DSAR volumes have increased and the regulatory environment has tightened.
The core appeal is expertise without the infrastructure cost. Running an in-house DSAR function properly requires people with data protection law knowledge, data discovery skills, redaction experience, and solid documentation discipline. Hiring for all of that is slow and expensive. An LPO provider brings those capabilities immediately, already built into a functioning process.
Scalability is the other major factor. DSAR volumes do not grow in a straight line. A product launch, a press story about your data practices, or a complaint to a regulator can create a spike that overwhelms an in-house team in days. LPO providers can absorb volume increases without the lead time that comes with hiring and training new staff.
For businesses operating across multiple jurisdictions, the cross-regulatory expertise matters a lot. GDPR DSAR obligations are not identical to CCPA obligations, and UK GDPR sits in its own space post-Brexit. Keeping track of those differences and applying the right framework to each incoming request requires current regulatory knowledge that a specialist provider maintains as a core function rather than a side responsibility.
There is also the documentation question. LPO providers build compliance records into their process by default. Every request, every search, every decision is logged in a way that holds up to regulatory scrutiny. For organizations that have historically treated DSAR responses as something to get through rather than something to evidence, this shift in approach is significant.
And then there is the simple question of what your internal legal and privacy team is actually for. If they are spending their time chasing down data from IT, reviewing redactions, and sending acknowledgment letters, they are not doing the strategic work that actually shapes your compliance posture over time. Outsourcing the operational side of DSAR compliance frees up that capacity.
At Aeren LPO, we work with organizations across the US, UK, and Europe on exactly this. Whether that means handling the full end-to-end process or slotting into specific stages of your existing workflow, the work is done by people who know what compliance looks like and can demonstrate it.
The regulatory direction of travel is clear. Privacy rights are expanding, not contracting. Enforcement is becoming more active, not less. And individuals in the US, UK, and EU are increasingly aware that these rights exist and that they can use them.
A well-built DSAR process is not a compliance checkbox. It is operational infrastructure for a regulatory environment that is only going to get more demanding. Organizations that have invested in getting it right are in a genuinely better position, both in terms of cost and risk, than those still managing it ad hoc.
If you are not sure how your current process would hold up, test it honestly. Pick a request, run through your actual workflow, and see how long it takes and how complete the output is. That exercise usually tells you everything you need to know about where the gaps are.
The good news is that none of this has to be built from scratch. The frameworks, the tools, and the expertise already exist. The question is just whether you are using them.
No. There is no required format or magic wording. An email to your support team asking "what data do you have on me?" is a valid DSAR. Your clock starts the moment it arrives, regardless of where it lands.
We use cookies and similar technologies for analytics and personalization. You can accept, reject, or customize your cookie settings at any time.