Dsar Response

/dsar-response

1. Load ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → DSAR process (systems list, verification method, SLA).
2. Run the workflow below.
3. Classify request type. Check escalation triggers — if any fire, route before proceeding.
4. Walk through: verify identity → walk systems list → exemption analysis → draft.
5. Output response draft. Do NOT send — human reviews and sends.
6. Log the DSAR per house process.

Before pasting the request: the request will contain the data subject's PII. Confirm your session and output storage meet your data-handling requirements. Redact anything you don't need (ID attachments, unrelated email threads). Do not store the subject's name in filenames.

/privacy-legal:dsar-response
[paste the request email]

DSAR Response Drafting

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /privacy-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

A DSAR has a deadline (set by the applicable regime), a process (verify, locate, assess exemptions, respond), and a bunch of places it can go wrong. This skill walks through each step and drafts the response.

Jurisdiction assumption

This analysis assumes the jurisdictional scope specified in your configuration. Privacy rules, response deadlines, and lawful bases vary materially by jurisdiction (GDPR vs. state consumer privacy laws vs. sectoral). If the data subject, processing activity, or controller is in a different jurisdiction than configured, this analysis may not apply as written.

Load the process

Read ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## DSAR process. That section has:

• The systems list (every place user data lives)
• Identity verification method
• Response SLA
• Who handles routine vs. who gets escalated

If the systems list is empty or stale, flag it — can't do a complete DSAR without knowing where to look.

Workflow

Step 1: Classify the request

Identify which right the data subject is invoking. Common categories:

• Access — copy of their data + information about processing
• Deletion / erasure — remove their data (subject to exemptions)
• Portability — their data in machine-readable format
• Correction / rectification — fix inaccurate data
• Objection — stop a particular processing (often marketing)
• Restriction — pause processing pending a dispute
• Opt-out of sale/share / automated decision-making — regime-specific rights

Research the applicable rule before proceeding. For each invoked right, identify the jurisdiction(s) whose law applies (GDPR, UK GDPR, CCPA/CPRA, other US state privacy laws, sectoral regimes). Cite the controlling statute or regulation with pinpoint references — the specific article/section, the scope of the right, any carve-outs. Note effective dates; data subject rights are amended frequently (new state laws each legislative session). Flag uncertainty and escalate for attorney verification rather than stating a rule you haven't confirmed.

No silent supplement. If a research query to the configured legal research tool returns few or no results for the jurisdiction's rights, exemptions, or deadlines, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / right]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources. Source attribution tiering. Tag every citation with its source. For model-knowledge citations, use one of three tiers rather than a single blanket "verify" tag: - [settled] — stable, well-known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 33, CCPA § 1798.100, FTC Act § 5, 45-day CCPA response window under § 1798.130(a)(2) as a concept). Still verify before filing, but lower priority. - [verify] — model-knowledge citations that are real but should be verified: specific implementing regulations, agency guidance, case holdings, thresholds, effective dates, post-2023 amendments. - [verify-pinpoint] — pinpoint citations (specific subsection letters, volume/page numbers, paragraph numbers, regulatory subpart references) carry the highest fabrication risk and should ALWAYS be verified against a primary source. Tool-retrieved citations keep their source tag ([Westlaw], [issuing authority site], or the MCP tool name); web-search citations remain [web search — verify]; user-supplied citations remain [user provided]. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags.

Some requests are combinations — "delete my account and send me my data first" is deletion + portability. Handle as two linked requests.

Step 2: Verify identity

Per the method in ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Common approaches:

• Logged-in verification: Request came from within an authenticated session → identity confirmed
• Email match: Request came from an email on file → usually sufficient for low-risk requests
• Additional verification: For high-value accounts or deletion requests → challenge question, phone verification, ID document

Calibrate to risk. Over-verifying turns the DSAR process into a barrier (bad look with regulators). Under-verifying risks handing someone else's data to a fraudster.

If identity can't be verified:

We were unable to verify that this request came from the individual whose data
is at issue. To proceed, please [verification step]. We cannot provide personal
data in response to a request we cannot verify.

This pauses the clock (arguably) but don't sit on it — respond to say you need verification within a few days, not on day 29.

Step 3: Locate the data

Walk the systems list from ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. For each system:

For a B2B processor: the "data subject" is usually your customer's end user. Check whether this is actually your customer's DSAR to handle, not yours. Many processor DPAs say "forward DSARs to the controller."

Step 4: Exemption analysis