Data subject request (DSR)
A user formally asking to see, export, correct, or delete their data, and the clock that starts the moment it lands in your inbox.
See it
What it is
The operational half of data subject rights: one person, one ask, one clock. Under GDPR it arrives however the user feels like sending it, through a form, a support ticket, a reply to a marketing email, or a public post at your account. There is no required wording, and that is the part teams get wrong. 'Delete my account and everything you have on me' is a valid erasure request even though it never says GDPR, and the clock started when it landed, not when someone recognized it. CCPA is stricter about the plumbing: you have to offer designated submission methods and run a verifiable consumer request process before you hand anything over, so the free-for-all intake rule is a GDPR rule, not a universal one.
The workflow is always the same four moves. Verify identity proportionately (a signed-in session beats a passport scan, and collecting new documents by reflex is itself a privacy problem, though you may ask for proportionate extra evidence when you have a real doubt). Find the person across every system: product database, replicas, warehouse, CRM, support tool, analytics, email platform, payment processor, backups. Act. Reply with what you did and why. Deadlines: one month under GDPR, extendable by two more for genuinely complex requests if you say so inside the first month, and 45 days under CCPA with one 45-day extension.
Gotcha: the expensive part is finding, not doing. A team with no data map burns a week per request grepping through vendors, and the first request always arrives on the worst possible day. Build export and delete as ordinary product features before you need them, and keep a request log with dates, decisions, and reasons, because proving you responded on time is the only defense that survives contact with a regulator.
Ask AI for it
Build a data subject request pipeline for this app. Create an intake route (form plus an inbox rule that files requests from privacy@ into the same queue) capturing request type (access, export, correction, deletion, opt-out), claimed identity, jurisdiction, and received timestamp. Verify identity using the existing session or a signed one-time email link first, and request proportionate additional evidence only when reasonable doubts about identity remain after that. Then implement fan-out: a registry module where each data source (postgres tables, S3 objects, warehouse, Stripe, the CRM, the analytics vendor, the email platform) registers a lookup, an export, and a delete handler for a given user, so adding a vendor means adding one adapter. Add a due-date field computed per jurisdiction (one calendar month from receipt under GDPR, extendable by two further months for complex requests; 45 days under CCPA) with reminders at 50 and 80 percent elapsed, an append-only audit log of every action and decision, and a templated response email that states what was done and what was retained with the legal reason. Include tests using a seeded user that exists in every source.