A Data Subject Access Request is a request a data subject makes to a controller asking what personal data is held about them, and to receive a copy. It's the most commonly exercised right under GDPR (and equivalents in CCPA, UK GDPR, etc.).
What the controller must do
Under Article 15, the controller must provide:
- Confirmation that personal data about the requestor is being processed.
- A copy of the personal data.
- Information about the purposes of processing, categories of data, recipients, retention period, the source if not collected from the data subject, and the existence of any automated decision-making.
Response is due within one month, extendable by two more months for complex requests. The first copy is free; further copies can be charged at a reasonable administrative cost.
The controller must verify the requestor's identity but cannot demand more information than necessary to do so.
Where vendors come in
Most controllers don't store all their personal data in one place — it's scattered across SaaS vendors, internal databases, backups, ticketing systems, marketing platforms, analytics tools, payment processors. To respond to a DSAR fully, the controller has to:
- Know which vendors hold data about the requestor.
- Have a process for instructing each vendor to surface or extract that data.
- Aggregate the responses into a coherent reply.
A processor that can't service a DSAR within the controller's response window is a structural problem. When you onboard a vendor, the practical question to ask is: how do we get a specific data subject's records out of your system, in a reasonable format, within ten working days?
Vendors that say "submit a request via our public web form" when their actual customer is the controller, not the data subject, are setting up a flow that will fail under load.