SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdsar-response

dsar-response

Data & analytics

View repository

Updated 10-15 20:29

About this skill

/dsar-response
  1. Load ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → DSAR process (system inventory, verification method, SLA).
  2. Execute the following workflow.
  3. Classify the request type. Check escalation triggers — if triggered, route first, then continue.
  4. Execute step by step: verify identity → traverse the system inventory → exemption analysis → draft.
  5. Output the draft response. Do not send — send after human review.
  6. Log this DSAR per internal process.

Before pasting the request: The request will contain the data subject's PII. Confirm that your session and output storage meet data handling requirements. Delete what you don't need (ID attachments, irrelevant email threads). Do not store the subject's name in file names.

/privacy-legal:dsar-response
[粘贴请求邮件]
DSAR Response Drafting (Data Subject Rights Request Handling)

Matter Context

Matter context. Check ## 事项工作区in the practice-level CLAUDE.md. If 已启用 is ✗(the default for legal users), skip this section — the skill uses practice-level context and the matter mechanism is not visible. If enabled and there is no active matter, ask: "Which matter is this? Run /privacy-legal:matter-workspace switch <slug> or say 实践级." Load the active matter's matter.md to get matter-specific context and overrides. Write output to the matter folder ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/matters/<matter-slug>/. Never read files from other matters unless 跨事项上下文 is 开启.

Destination Check

Before generating output, check the output destination. If the user specified a destination (channel, distribution list, opposing party, "everyone"), ask whether it is within the confidentiality circle. Public channels, company-wide lists, opposing parties/opposing counsel, vendors, and clients (with respect to work product) waive protection. When the destination appears to be outside the circle, flag it and offer (a) a legal-only confidential version, (b) a sanitized version for broader channels, or (c) both — do not silently add a confidentiality header and then help paste it somewhere that header cannot protect. See ## 共享护栏 → 目的地检查。

Purpose

Data subject rights requests have deadlines (set by the applicable regime), a process (verify, locate, assess exemptions, respond), and many points where things can go wrong. This skill executes each step and drafts the response.

Jurisdiction Assumption

This analysis assumes the jurisdictional scope specified in your configuration. Privacy rules, response deadlines, and legal bases vary by jurisdiction (PIPL vs. GDPR vs. other jurisdictions). If the data subject, processing activity, or processor is located in a jurisdiction different from the configuration, this analysis may not directly apply.

Load Process

Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## DSAR 流程. This section contains:

  • System inventory (every location where user data resides)
  • Identity verification method
  • Response SLA
  • Who handles routine requests vs. who handles escalated requests

If the system inventory is empty or outdated, flag it — you cannot do complete data subject rights request handling without knowing where the data is.

Workflow

Step 1: Classify the request

Identify which right the personal information subject is exercising. Common categories (PIPL Articles 44-50) [法条原文]：

  • Access(Article 45) — obtain a copy of their personal information + processing-related information
  • Copy(Article 45) — obtain a copy of their personal information (portable)
  • Deletion/account cancellation(Article 47) — delete their personal information (subject to exemption conditions)
  • Correction(Article 46) — correct inaccurate data
  • Explanation(Article 48) — request an explanation of the personal information processing rules
  • Refusal/Restriction — restriction of processing under the framework of the right to know and the right to decide in Article 44 of the PIPL

Retrieve the applicable rules before proceeding. For each right being exercised, identify the applicable jurisdiction and its legal basis. Cite currently effective laws or administrative regulations with precise citations — the specific article number, the scope of the right, any exceptions. Note effective dates; personal information subject rights are adjusted as new laws are introduced. When uncertain, flag and escalate for lawyer verification rather than stating unconfirmed rules.

No silent supplementation. If the retrieval query returns few or zero results, report what was found and stop. Do not fill gaps from web search or model knowledge without asking. Say: "The search returned [N] results. Coverage appears weak. Options: (1) broaden the search query, (2) try a different retrieval tool, (3) search the web — results will be marked as [联网检索 — 需复核], (4) flag as unverified and stop. Which do you want to choose?" The lawyer decides whether to accept lower-credibility sources.

Tiered source provenance labels. Mark the source for each citation. For model knowledge citations:

  • [已确定] — stable, well-known statutory citations unlikely to have changed (e.g., the personal information subject rights provisions in PIPL Articles 44-50)
  • [需验证] — model knowledge citations are genuine but should be verified: specific implementing rules, regulatory guidance, case positions
  • [需验证——精准引用] — precise citations carry the highest risk of fabrication and should always be verified against primary sources

Some requests are composite requests — "delete my account and send me the data first" is deletion + access. Handle as two related requests.

Step 2: Verify identity

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

  • Logged-in verification: the request comes from within a verified session → identity confirmed
  • Email match: the request comes from the email in the file → usually sufficient for low-risk requests
  • Additional verification: for high-value accounts or deletion requests → ask verification questions, phone verification, identity documents

Calibrate by risk. Over-verification turns the application process into an obstacle (which looks bad before regulators). Under-verification risks handing someone else's data to fraudsters.

If identity cannot be verified:

我们无法验证本请求发自相关数据的个人信息主体本人。要继续处理，请[验证步骤]。我们无法在回应未经核实之请求时提供个人信息。

This pauses the time limit (which is disputed) but do not delay — respond within a few days to say verification is needed, rather than dragging it out to day 29.

Step 3: Locate the data

Go through the system inventory in ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md . For each system:

System Queried? Data found? What data
Production database
Data analytics platform
Customer support ticketing system
CRM
Email marketing
Logs
Backups (Note: deletion usually exempted — see below)
Processors/third parties (may need to notify them upon deletion)

For B2B processors: the "data subject" is usuallyyour customer'send user. Check whether this is actually your customer's DSAR to handle, not yours. Many processor DPAs say "forward data subject rights requests to the processor."

Step 4: Exemption analysis

Not all data must be provided or deleted.Retrieve the applicable rules before proceeding. For each item, identify every exemption that may exist under the applicable regime (such as third-party privacy, legal privilege, trade secrets, security, statutory retention obligations, litigation preparation, backup cycle arrangements). Cite currently effective provisions with precise citations. Exemption scope varies by jurisdiction and regime — verify currency and flag uncertainty.

Do not narrow the list based on subjective judgment. The skill proposes exemptions where a good-faith basis exists and flags uncertain exemptions; the lawyer narrows the list before the response is sent. Waiving an exemption later found to apply is costly — once material is disclosed, the exemption is effectively gone. Over-asserting a plausible exemption can be corrected by the lawyer on review. Prefer recoverable errors.

Each proposed exemption carries a clear annotation:"Proposed — requires lawyer review before assertion. Regulators scrutinize blanket exemption claims, so the lawyer narrows this list; the skill does not do so."

Common questions to clarify:

  • Does the record contain data aboutotherpeople that must be redacted before provision?
  • Is there a specific statutory retention obligation preventing deletion? Cite it.
  • Is there a litigation hold covering that personal data?
  • Is there a backup cycle or technical feasibility arrangement that must be documented (it cannot be used as a general excuse)?

Document each claimed exemption. If a regulator asks why certain data was not deleted, "we have a legal obligation" needs a cited basis.

Step 5: Draft the response — two letters

Retrieval connector pre-check. Before outputting the acknowledgment letter, substantive response letter, or internal exemption analysis, check whether legal retrieval connectors are accessible in this session. Collect this information into the review notes under CLAUDE.md ## 输出 — review notes go on the internal exemption analysis and cover memo, not on the DSAR letter sent externally to the data subject. If no connector returned results in Step 1 (rights classification), Step 4 (exemption analysis), or the deadline management retrieval step, record it in the **Sources:** line of the internal review notes — e.g., 未连接——引用来自训练知识；所主张的豁免、回复期限和延期机制特别容易造假，在向个人信息主体或监管机关主张任何豁免前必须验证. Per-item [模型知识 — 需验证] labels stay inline. Do not emit a separate banner above the output.

Most regimes expect (or require) a timely acknowledgment letter, separate from the substantive response. Produce two; do not collapse them into a single letter sent only at the statutory deadline.

  • Step 5a — Acknowledgment letter. Issued within days of receiving the request (target: same day to 3-5 days, always well within the statutory/regulatory time limit). Confirm receipt, state the data subject's understanding of the request, state the response deadline and target date, and ask for any identity verification materials still outstanding. It contains no substantive disclosure. A prompt acknowledgment is the first signal a regulator sees that the DSAR process is working; it also reduces the risk of duplicate requests or premature complaints.
  • Step 5b — Substantive response letter. The actual disclosure, deletion confirmation, or access/copy export. Issued within the statutory deadline (or a stricter internal SLA). Issued only after identity verification is complete and the data location + exemption analysis in Steps 3/4 is complete.

Before sending either letter to the data subject: Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md in ## 谁在使用. If the role is non-lawyer:

Sending a data subject rights response has legal consequences — the content, asserted exemptions, and omissions may all be reviewed by a regulator, and misstatements create enforcement exposure. Have you had a lawyer review it? If so, proceed. If not, here is the brief you bring to the lawyer:

[Generate a 1-page summary: data subject, right exercised, applicable regime, data found by cross-system inventory search, what was withheld and under which exemption, identity verification status, response deadline, and the three things you should ask the lawyer before sending.]

If you need to find a practicing lawyer or other authorized legal professional: the bar association in your region or the judicial bureau's lawyer lookup system is the fastest starting point.

Do not cross this gate without explicit consent.

Note: Both DSAR letters are external documents sent to the data subject.Do notinclude the ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md ## 输出 work-product heading on either letter. Internal notes, logs, and exemption analyses accompanying the letters are attorney work product — keep these separate and marked with the work-product heading.

Before sending either letter: This is a draft for lawyer review, not a response ready to send. Sending makes the processor responsible for a position, may waive exemptions, and may start a regulator's clock. Only after a practicing lawyer reviews, edits, and approves it may the letter be sent to the data subject. Do not send an unreviewed letter.

Step 5a — Acknowledgment letter template

主题：我们收到了您的个人信息请求 — [公司] — [日期]

尊敬的[姓名]：

我们于[收到日期]收到了您的[查阅 / 删除 / 复制 / 更正]请求。

**您请求的内容，按我们的理解：** [一句话重述——例如："获取我们持有的与您账户关联的全部个人信息副本，以及我们与之共享的第三方类别，并在我们提供副本后删除您的账户。"]

**接下来会发生什么：**
- 我们的实质回复目标日期为[日期——不晚于制度法定期限；如内部 SLA 更严格则使用 SLA]。 [如身份验证未完成："我们需要[具体验证步骤]才能继续——见下文。" ]
- 如果我们因请求复杂或同时收到您的其他请求而需要更多时间，我们将在初始期限前告知您并解释原因。[如制度允许延期，引用相关条款。]
- 本请求不收费。[或：仅在制度允许且请求明显无依据或过度时收费——引用相关条款。]

[如身份验证未完成：]
**为验证您的身份，** 请[具体验证步骤——例如：使用档案中的邮箱地址回复本邮件，并附上我们档案中记录的支付方式的后4位]。这不暂停我们的期限；我们并行继续工作。

如有疑问，请联系[隐私联系人]。

[发件人]

Deadline calculation rules. The response deadline runs from receipt of the request, not from completion of identity verification — unless the applicable regime provides otherwise. Do not imply a tolling of the clock on verification issues. If a regime has a different trigger rule, cite it; do not assume.

Step 5b — Substantive response letter template

Access request response:

主题：您的个人信息查阅请求 — [公司] — [日期]

我们于[日期]收到了您请求获取我们持有的关于您的个人信息副本的请求。

**我们查找到的数据：**

我们持有与[标识符]关联的以下类别的个人信息：

| 类别 | 来源 | 目的 | 保留至 |
|---|---|---|---|
| [账户信息：姓名、邮箱] | 您，注册时 | 账户管理 | 账户删除时 |
| [使用数据] | 我们的服务 | 数据分析、产品改进 | [期间] |
| [客服往来记录] | 您 | 客户服务 | [期间] |

**您的数据已附在** [格式]。 [安全交付说明——密码保护的压缩包、带有效期的安全链接等。]

**第三方：** 我们与以下处理者共享数据：[列表或链接至处理者页面]。

**您的其他权利：** 您还可以请求[删除 / 更正 / 复制]。为此，请[方式]。

**我们未包含的数据：**
- [类别] — [豁免及理由，例如"内部安全日志——披露将危及安全措施"]
- [关于其他个人的数据已从客服往来记录中删除]

如对本回复有疑问，请联系[隐私联系人]。

Deletion request response:

主题：您的个人信息删除请求 — [公司] — [日期]

我们于[日期]收到了您请求删除我们持有的关于您的个人信息的请求。

**我们已删除：**

| 类别 | 系统 | 删除日期 |
|---|---|---|
| [账户和个人资料] | 生产环境 | [日期] |
| [分析事件] | [数据分析平台] | [日期] |
| [等] | | |

**我们保留的内容及原因：**

| 类别 | 原因 | 保留至 |
|---|---|---|
| [交易记录] | 法定义务（税务记录保留，[引用法律]） | [日期] |
| [备份快照] | 将在下一次循环时删除 | [日期] |

**受托处理者/第三方：** 我们已指示[列表]从他们的系统中删除您的数据。

您的账户现已关闭。如对本回复有疑问，请联系[隐私联系人]。

Step 6: Recordkeeping

Data subject rights requests are audited. Record:

  • Date received
  • Date of identity verification
  • Date of response
  • What was provided/deleted
  • Exemptions asserted and their basis
  • Handler

If your team uses a data subject rights request tracking tool, create a record there. If not, a log file works.

Escalation triggers

Per ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → escalation table, escalate if:

  • The requester is (or may be) a plaintiff, opposing counsel, or a journalist
  • Request scope anomaly ("all data including my internal communications")
  • Litigation hold exists that overrides this personal data (deletion request + litigation hold = conflict, attorney decision)
  • Requestor disputes a prior data subject rights request response
  • Any supervisory authority copied or referenced

Deadline management

Two-letter rule. Each data subject rights request yields an acknowledgement letter (promptly — target same day to within 3-5 days) and a substantive response letter (before the statutory deadline). Most regimes expect or require the prompt acknowledgement independent of the substantive response; a single combined letter sent on the last day is a process failure even if the substance is correct.

Look up the specific right being exercised and the currently effective response deadline under the applicable jurisdiction. Check whether an extension mechanism exists, how much extra time it can grant, and what notice must be sent to the data subject to use the extension. Identify when the clock starts (receipt vs. verification vs. other triggering rules — the default is receipt; verify per regime). Cite the currently effective rule with precise citation. Watch effective dates — data protection response deadlines are frequently amended and new laws introduce their own deadlines.

If ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## DSAR 流程 records an internal SLA tighter than the statutory deadline, use the internal SLA and note the statutory floor.

If you will need an extension, send the "we need more time" notice well before the initial deadline arrives. An extension on the last day looks bad.

What this skill does not do

  • Does not query systems directly. It walks you through the checklist; a human (or connected tooling) performs the actual queries.
  • Does not make exemption determinations on borderline cases. It flags them for attorney judgment.
  • Does not send responses. Drafted, reviewed, human sends.