Legal playbook · AI Employee: Lex

Data Subject Request Routing

DSAR SLA maintained

Install this playbookBack to marketplace
The problem

Data-subject requests arrive at every possible entrance: privacy web form, support inbox, sales rep who was CC'd, a compliance address that nobody watches. Each has a regulatory clock (30 days GDPR, 45 days CCPA, 15 days LGPD). Half never reach legal in time; the ones that do often lack the identity verification or scope clarity to act on. Regulatory reporting requires knowing what's overdue; the picture is blurry.

At a glance
Trigger
Form
Approvals
Privacy counsel review on edge cases
What it does
Writes to your systems
Systems
Privacy tool · CRM · Data lake
How it feels in production

An hour-by-hour walkthrough.

A support agent in Zendesk sees a ticket subject: "delete my account." It doesn't match a support template — this is a DSAR. Lex detects it (keyword + intent classifier) within 2 minutes of ticket creation, extracts the requester's identity (email in the ticket, verified to the customer of record), classifies as GDPR erasure (customer is in Germany), and routes to legal's DSAR case queue with a 30-day clock starting from ticket-creation time. Legal reviewer sees the new case: requester identity + jurisdiction + regulation + deadline + originating source. They verify identity per policy (in-app confirmation link + government ID for regulated jurisdictions), scope the request (delete profile only vs. all data), and either accept-in-scope or challenge-out-of-scope ("we can delete your profile but not your invoices, which we're required to retain for 7 years for tax purposes"). On acceptance, Lex hands off to the security/privacy-data-deletion playbook for execution. On challenge, Lex drafts the response to the requester, tracks the reply, and if the requester agrees to reduced scope proceeds; if the requester escalates, the case routes to the DPO / GC. Every DSAR is tracked to closure: intake, verification, scoping, execution, certificate. Regulatory reporting draws from this record; no more "how many DSARs did we get last year, and how many did we complete on time?" being an open question.
How it works

Step by step.

  1. 01

    Detect DSARs at every entry point

    Web form (direct), support inbox (Zendesk / Intercom keyword + intent), legal inbox, privacy@ alias. Detection classifier trained on real DSARs: 'delete my account,' 'send me my data,' 'access request,' plus regulatory keywords.

    Zendesk · Intercom · Email · Web form · Classifier
  2. 02

    Verify identity + classify jurisdiction + regulation

    Requester identity verification (email confirm, in-app confirm, ID check per policy). Jurisdiction from customer profile + IP; regulation applies (GDPR, CCPA, LGPD, PIPL, others). Deadline computed from receipt time.

    Identity verification · Customer profile · Regulation database
  3. 03

    Scope the request + surface exceptions

    Access vs. deletion vs. correction vs. portability. Full-scope vs. specific-data. Regulatory exceptions applicable (invoices under tax retention, records under legal hold, active fraud investigation).

    Retention policy · Legal-hold database · DSAR scope model
  4. 04

    Legal accept / challenge / escalate

    Legal reviewer accepts in scope (routes to execution), challenges out of scope (draft response to requester), or escalates to DPO / GC for complex jurisdiction issues or high-profile requesters.

    Web UI · Slack · Email · DPO / GC escalation
  5. 05

    Track to closure + report regulatorily

    Every DSAR tracked: receipt, verification, scoping, execution, certificate. Regulatory report drawable at any time: how many by regulation, average time to close, breaches. Auditor-ready.

    Case management · Audit log · Regulatory reporting
Systems and wiring

What you connect to make this run.

Zendesk · Intercom · Email · Web form

read+write

Every intake surface. Classifier watches all channels; identified DSARs move to the DSAR queue with the original ticket linked. Support agents get a template response with the case reference.

Salesforce · HubSpot · Customer profile

read

Customer profile for identity verification + jurisdiction resolution. Purchase history for scoping (what data types apply to this requester).

OneTrust · TrustArc · Ethyca · Case management

read+write

DSAR case management platform. Writes case metadata + progress + closure. Reads deadlines + workflow status. Regulatory reporting drawn from these records.

Legal-hold database · Retention policy

read

Exceptions applicable to the request. Legal-hold trumps deletion; tax retention applies to invoices; fraud investigations retain data. Surfaces exceptions in scoping step.

What changes

Before and after, honestly.

DSARs detected within 24 hours of receipt
Before
40-70% (missed at non-privacy entry points)
After
98%+ (multi-channel classifier)
Time from receipt to legal case opened
Before
3-14 days
After
Under 2 hours
% of DSARs completed within regulatory deadline
Before
70-88%
After
99%+
Regulatory reporting effort per audit
Before
1-3 weeks (spreadsheet reconstruction)
After
Under 1 hour (draws from case management)
Related

Playbooks that pair with this one.

Security

Privacy / Data Deletion

Execution playbook for the deletion cases routed here.

Legal

Privacy Review for New Features

New features touching PII must be scoped in the DSAR handling before launch.

Legal

Legal Hold / Litigation Hold

Legal hold and DSAR both consult retention exceptions; often interact.

Frequently asked

Answers about this playbook.

What if the requester isn't actually a customer (opted out, was a lead)?

DSAR applies regardless of contract status if the personal data is held. Lex handles ex-customers and leads with the same flow; execution scope adjusts (no billing records for a lead who never purchased).

How does it handle requests via third parties (lawyer, family member, authorised agent)?

Third-party requests require authorisation proof per policy (power of attorney, signed authorisation form). Lex requests the proof; case pauses until received. Some jurisdictions have specific rules on agent authority.

What about deceased-user requests?

Deceased-user handling per jurisdiction — some jurisdictions grant next-of-kin rights, others treat data as extinguished with the person. Lex routes to legal per your policy; execution depends on jurisdictional rules.

How is malicious volume (attacker submitting many DSARs) handled?

Rate limiting per requester + jurisdiction; policy caps on refusal for manifestly unfounded / excessive requests. Legal reviewer sees the pattern + can invoke the manifestly-excessive exception.

What if the customer changes their mind mid-DSAR?

Withdrawn requests supported. Case marked withdrawn with the requester's confirmation. If deletion had partially executed, the record notes what was already deleted (cannot be undone).

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Legal playbooks