What is DSAR (Data Subject Access Request)?

DSAR began as GDPR shorthand for the Article 15 access right, but in practice the term (along with DSR, data subject request) now covers the whole request family: access ('what do you have on me'), deletion, correction, portability, restriction, objection, and US-style opt-outs. Whatever the flavor, the mechanics are the same — an individual asserts a right, and the organization must verify, execute, and respond on a statutory clock.

The workflow has four stages. Intake: requests can arrive through a web form, a privacy email address, or — under the CCPA — a toll-free number, and consumers cannot be forced to create accounts to submit them. Verification: the organization must confirm the requester is who they claim, calibrated to the sensitivity of the data — enough to stop impostors, not so much that verification becomes an obstacle. Fulfillment: locating the person's data everywhere it lives and executing the request. Response: within one month under GDPR (extendable by two months for complexity) or 45 days under CCPA (extendable once by 45), free of charge in the normal case.

Fulfillment is where organizations underestimate the work. A customer's data rarely lives in one system: it spreads across the commerce platform, email marketing, analytics, support desk, reviews, loyalty, shipping, and ad platforms. A deletion executed only in the primary database while nine SaaS tools keep their copies is a violation with an audit trail. This is why DSAR automation — connectors that propagate requests across the stack and log the evidence — has become its own product category.

Volume is rising: privacy-aware consumers, browser tooling, and authorized-agent services all generate requests, and each mishandled one is a complaint a regulator can pick up.