dsar-response

/dsar-response

1. 加载 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → DSAR 流程（系统列表、验证方法、SLA）。
2. 执行以下工作流。
3. 对请求类型进行分类。检查升级触发条件——如有任何一项触发，先转交处理，再继续。
4. 按以下步骤进行：验证身份 → 遍历系统列表 → 分析豁免情形 → 起草回复。
5. 输出回复草稿。请勿发送——由人工审核并发送。
6. 按照内部流程记录 DSAR。

粘贴请求前： 请求中包含数据主体的个人身份信息（PII）。请确认你的会话和输出存储符合数据处理要求。删去不必要的信息（身份证件附件、无关邮件往来）。文件名中不要包含数据主体的姓名。

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

---

DSAR 回复起草

事项背景

事项背景。 检查实践级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（内部法务用户的默认值），请跳过本段其余内容——技能会使用实践级背景，事项工作区机制不可见。如果已启用且当前没有活动事项，请询问：“这是关于哪个事项的？运行 /privacy-legal:matter-workspace switch <slug>，或回复 practice-level。”加载活动事项的 matter.md，以获取事项专属背景和覆盖设置。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则不得读取其他事项的文件。

---

用途

DSAR 有截止日期（由适用的法规确定）、处理流程（验证、定位、评估豁免情形、回复），并且有许多可能出错的环节。本技能将逐步引导你完成各步骤并起草回复。

司法管辖区假设

本分析假设适用的司法管辖区范围与配置中指定的一致。隐私规则、回复期限和合法依据因司法管辖区而有实质差异（GDPR 与州消费者隐私法及行业法规之间均有差异）。如果数据主体、处理活动或控制者位于不同于配置所指定的司法管辖区，本分析可能不适用。

加载流程

读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## DSAR process。该部分包含：

• 系统列表（用户数据所在的所有位置）
• 身份验证方法
• 回复 SLA
• 日常请求的处理人员及需要升级处理的人员

如果系统列表为空或已过时，请标记出来——不知道该查找哪些位置，就无法完整处理 DSAR。

工作流

步骤 1：对请求分类

确认数据主体正在行使哪项权利。常见类别：

• 访问 — 获取其数据副本和有关处理的信息
• 删除／抹除 — 删除其数据（受豁免情形限制）
• 可携带性 — 以机器可读格式获取其数据
• 更正／纠正 — 修正不准确的数据
• 反对 — 停止特定的数据处理（通常是营销）
• 限制 — 在争议解决期间暂停处理
• 退出出售／共享或自动化决策 — 特定法律体系规定的权利

继续处理前，先研究适用规则。 对于每项被行使的权利，确定适用法律的司法管辖区（GDPR、UK GDPR、CCPA/CPRA、美国其他州的隐私法、行业法规）。引用具有约束力的法规，并精确到具体条款：权利的范围、任何例外。注明生效日期；数据主体权利经常修订（每个立法会期都有新的州法律）。标明不确定之处，并提交律师核实，不要陈述未经确认的规则。

不得悄然补充。 如果配置的法律研究工具针对相关司法管辖区的权利、豁免或期限返回的结果很少或没有，请报告已找到的内容并停止。未经询问，不得通过网络搜索或模型知识填补空缺。请这样说明：“该搜索从 [tool] 返回了 [N] 条结果。关于 [regime / right] 的资料似乎不充分。可选方案：(1) 扩大搜索查询范围，(2) 尝试其他研究工具，(3) 搜索网络 — 结果将标记为 [web search — verify]，依赖这些结果前应对照一手来源进行核实，或 (4) 标记为未经核实并停止。您希望采用哪种方案？” 是否接受可信度较低的来源，由律师决定。

来源归属分级。 每条引文都要标记来源。对于模型知识中的引文，使用以下三个级别之一，而不是统一标记为“核实”：

• [settled] — 稳定、广为人知、不太可能发生变化的法规和监管规定（例如 GDPR 第 33 条、CCPA § 1798.100、FTC 法案 § 5、CCPA § 1798.130(a)(2) 中 45 天响应期限这一概念）。提交前仍需核实，但优先级较低。
• [verify] — 模型知识中的引文，内容真实但应予核实：具体实施条例、机构指南、案件裁决、门槛、生效日期、2023 年之后的修订。
• [verify-pinpoint] — 精确到具体条款的引文（具体分款字母、卷／页码、段落编号、法规子部分引用）伪造风险最高，必须始终对照一手来源进行核实。

工具检索到的引文保留其来源标签（[Westlaw]、[issuing authority site] 或 MCP 工具名称）；网络搜索引文保留 [web search — verify]；用户提供的引文保留 [user provided]。分级能明确真正需要核实的内容——什么都核实的读者，最后往往什么都没核实。切勿删除或合并这些标签。

有些请求包含多项权利 — “先删除我的账户并把我的数据发给我”同时涉及删除和可携带性。应作为两个相关联的请求处理。

步骤 2：核实身份

按照 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的方法进行。常见做法：

• 已登录状态核实： 请求来自经过身份验证的会话 → 身份已确认
• 电子邮件匹配： 请求来自档案中留存的电子邮件地址 → 对于低风险请求通常足够
• 额外核实： 对于高价值账户或删除请求 → 质询问题、电话核实、身份证明文件

根据风险调整核实程度。 过度核实会让 DSAR 流程变成一道障碍（在监管机构眼中观感不佳）。核实不足则可能导致把他人的数据交给诈骗者。

如果无法核实身份：

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.

这（可能）会暂停计时，但不要搁置请求 — 应在几天内回复并说明需要核实身份，而不是等到第 29 天才回复。

步骤 3：定位数据

按照 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的系统列表逐一检查。对于每个系统：

系统	是否已查询？	是否发现数据？	内容
生产数据库
分析工具（例如 Mixpanel、Amplitude）
支持工单（例如 Zendesk）
CRM（例如 Salesforce、HubSpot）
邮件营销（例如 Marketo）
日志
备份			（注意：通常可豁免删除 — 见下文）
第三方处理方			（可能需要通知他们执行删除）

对于 B2B 处理方：“数据主体”通常是你客户的最终用户。确认这是否实际上应由你的客户而不是你来处理其 DSAR。许多处理方 DPA 规定“将 DSAR 转交给控制者”。

步骤 4：豁免分析

并非所有内容都需要提供或删除。继续之前，请先研究适用规则。 对于每个项目，找出在适用制度下所有可能适用的豁免（例如，第三方隐私、特权、商业秘密、安全、依法保留义务、确立或抗辩法律主张、交易必要性、备份轮替安排、言论自由）。引用具有约束力的法规、条例或判例，并提供精确引注。豁免范围因司法辖区和制度而异 — 请核实其时效性并标明不确定之处。

不要凭主观判断缩减清单。 只要有善意依据，此技能就会提出豁免并标明不确定之处；律师会在发出答复前缩减清单。遗漏了后来证实适用的豁免，代价高昂 — 一旦披露材料，该豁免实际上就不复存在。对合理可能适用的豁免作出过度主张，律师可以在审阅时纠正。优先选择可补救的错误。

每项拟议豁免都必须附有明确说明：“拟议 — 主张前须由律师审阅。监管机构会仔细审查一概主张豁免的做法，因此由律师缩减清单；此技能不会这样做。”

需要逐一分析的常见问题：

• 记录是否包含其他人的数据，需要在提供前进行删节？
• 是否存在阻止删除的具体法定保留义务？请引用相关规定。
• 是否存在涵盖该个人数据的有效诉讼保全令？
• 是否需要记录备份轮替安排或技术可行性方面的处理方式（不得将其当作一般性借口）？

记录所主张的每项豁免。 如果监管机构询问为何未删除某项内容，“我们有法定义务”必须附上引文。

步骤 5：起草答复 — 两封信

研究连接器预检。 在输出任何一封信或内部豁免分析之前，先检查本次会话是否能连接到法律研究连接器 — Westlaw、EUR-Lex／监管机构网站连接器，或任何由律所配置的研究 MCP。按照 CLAUDE.md ## Outputs 的要求，将此信息纳入审阅者备注 — 审阅者备注应附在内部豁免分析和封面备忘录中，而不是发给数据主体的对外 DSAR 信函中。如果步骤 1（正确分类）、步骤 4（豁免分析）或截止日期管理研究步骤均未返回结果（或运行时未配置任何连接器），请在内部审阅者备注的 Sources: 行中记录 — 例如，未连接 — 引文来自训练知识；所主张的豁免、答复期限和延期机制尤其容易出现编造，请在向数据主体或监管机构主张任何豁免前核实。每条引文旁的 [model knowledge — verify] 标签仍须保留。不要在输出内容上方单独添加提示横幅。

大多数制度期望（或要求）尽快发出一封确认函，并将其与实质性答复分开。请同时提供两封信；不要合并成一封等到 45 天期限才发出的信函。

• 步骤 5a — 确认函。 收到请求后数日内发送（目标：当天至 3–5 天内，且始终远早于该制度规定的法定期限）。确认已收到请求，说明控制者对请求内容的理解，告知答复时限和目标日期，并询问是否仍有待提供的身份验证材料。不包含实质性披露内容。及时确认是监管机构可见的首个信号，表明 DSAR 流程正在运作；同时也能降低重复提交请求或过早投诉的风险。
• 步骤 5b — 实质性答复函。 实际披露、删除确认或可携带性导出内容。须在法定期限内（或更严格的内部 SLA 内）发出。只有在完成身份验证，且完成步骤 3 / 步骤 4 的数据位置与豁免分析后，才能发出。

在继续向数据主体发送任一函件之前： 阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的 ## Who's using this。如果角色是非律师：

发送 DSAR 答复会产生法律后果——函件内容、主张的豁免以及遗漏内容都可能接受监管机构审查，错误陈述还可能引发执法风险。你是否已与律师审阅此事？如果是，请继续。如果否，请准备以下简报供律师参考：

[生成一页摘要：数据主体、援引的权利、适用的制度、在系统清单所列各系统中找到的内容、扣留的内容及所依据的豁免、身份验证情况、答复截止日期，以及发函前需要向律师询问的三件事。]

如果你需要在所在司法管辖区寻找持牌律师、事务律师、大律师或其他获授权的法律专业人士，最快的起点是向专业监管机构寻求转介服务（美国的州律师协会、英格兰和威尔士的 SRA / Bar Standards Board、苏格兰 / 北爱尔兰 / 爱尔兰 / 加拿大 / 澳大利亚的 Law Society，或所在司法管辖区的同等机构）。

未经明确同意，不得越过此关卡继续操作。

注意： 两封 DSAR 函件都是发送给数据主体的外部交付文件。不要在任何一封函件中加入 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md ## Outputs 中的工作成果标头。随函附上的内部备注、日志和豁免分析属于律师工作成果——应单独保存，并按 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md ## Outputs 的要求添加工作成果标头（具体内容因用户角色而异，参见 ## Who's using this）。

发送任一函件之前： 这是一份供律师审阅的草稿，并非可直接发送的答复。发送函件意味着控制者确认某一立场，可能放弃豁免，并可能启动监管机构的时钟。持牌律师必须先审阅、编辑并批准，才能将任一函件发送给数据主体。不得发送未经审阅的函件。

步骤 5a — 确认函模板

Subject: We received your privacy request — [Company] — [date]

Dear [Name],

We received your [access / deletion / portability / correction] request on [date received].

**Your request, as we understand it:** [one-sentence restatement — e.g., "a copy of all personal data we hold associated with your account, along with the categories of third parties with whom we share it, and deletion of your account after we provide the copy."]

**What happens next:**
- Our target date for the substantive response is [date — no later than the regime's statutory deadline; use internal SLA if tighter]. [If identity verification is outstanding: "We need [specific verification step] before we can proceed — see below."]
- If we need more time because the request is complex or we receive other requests from you at the same time, we will tell you before the initial deadline and explain why. [If the regime allows an extension, cite the controlling provision.]
- No fee applies to this request. [Or: the fee applies only if the regime permits it and the request is manifestly unfounded or excessive — cite the provision.]

[If identity verification is outstanding:]
**To verify your identity,** please [specific verification step — e.g., reply to this email from the address on file with the last 4 digits of the payment method we have on file]. This does not pause our deadline; we continue to work in parallel.

If you have questions, contact [privacy contact].

[Sender]

时限起算规则。 除非适用制度另有规定，答复时限从收到请求时开始计算，而非从完成身份验证时开始。不得默默暂停身份验证期间的时限。如果某项制度规定了不同的起算条件，请注明该规定；不要自行假设。

步骤 5b — 实质性答复函模板

访问请求答复：

Subject: Your Data Access Request — [Company] — [date]

We received your request on [date] for a copy of the personal data we hold about you.

**What we found:**

We hold the following categories of personal data associated with [identifier]:

| Category | Source | Purpose | Retained until |
|---|---|---|---|
| [Account info: name, email] | You, at signup | Account management | Account deletion |
| [Usage data] | Our service | Analytics, product improvement | [period] |
| [Support correspondence] | You | Customer support | [period] |

**Your data is attached** in [format]. [Secure delivery note — password-protected
archive, secure link with expiry, etc.]

**Third parties:** We share data with the following processors: [list or link to
subprocessor page].

**Your other rights:** You may also request [deletion / correction / portability].
To do so, [method].

**Data we did not include:**
- [Category] — [exemption and reason, e.g., "internal security logs — disclosure
  would compromise security measures"]
- [Data about other individuals has been redacted from support correspondence]

If you have questions about this response, contact [privacy contact].

删除请求答复：

Subject: Your Deletion Request — [Company] — [date]

We received your request on [date] to delete the personal data we hold about you.

**What we deleted:**

| Category | System | Deleted on |
|---|---|---|
| [Account and profile] | Production | [date] |
| [Analytics events] | [Amplitude/etc.] | [date] |
| [etc.] | | |

**What we retained and why:**

| Category | Reason | Retained until |
|---|---|---|
| [Transaction records] | Legal obligation (tax record retention, [cite law]) | [date] |
| [Backup snapshots] | Will be deleted on next rotation | [date] |

**Third-party processors:** We have instructed [list] to delete your data from
their systems.

Your account is now closed. If you have questions, contact [privacy contact].

步骤 6：记录

DSAR 会接受审计。请记录：

• 收到日期
• 身份验证日期
• 答复日期
• 已提供 / 删除的内容
• 主张的豁免及其依据
• 处理人员

如果团队使用 DSAR 跟踪工具，请在其中创建记录。否则，使用日志文件即可。

升级触发条件

根据 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → 升级表，出现以下情况时升级处理：

• 请求方是（或可能是）原告、对方律师或记者
• 请求范围不寻常（“包括所有涉及我个人的内部通信在内的所有数据”）
• 此人的数据受到诉讼保全令约束（删除请求 + 诉讼保全令 = 存在冲突，由律师决定）
• 请求方对之前的 DSAR 回复提出异议
• 有监管机构被抄送或提及

截止日期管理

两封信规则。 每个 DSAR 都要发送一封确认函（及时回复——目标是在收到请求当天至 3–5 天内发送）和一封实质性回复函（在法定期限内发送）。大多数制度要么要求，要么预期在实质性回复之外及时发送确认函；即使内容正确，如果直到第 45 天才发送一封合并函，也属于流程失误。

研究所涉具体权利及适用司法辖区当前生效的回复期限。 检查是否存在延期机制、可延长多久，以及数据主体必须收到什么通知才能启动延期。明确期限从何时开始计算（收到请求、完成身份验证，还是其他触发条件——默认规则是收到请求；须按具体制度核实）。引用具有约束力的法规或条例，并提供精确条款引注。注明生效日期——数据保护回复期限经常修订，新的州法律也会设定自己的期限。

如果 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## DSAR process 记录的内部 SLA 比法定期限更严格，则应遵守内部 SLA，并注明法定兜底期限。

如果需要延期，应尽早发送“我们需要更多时间”的通知，不要等到首个截止日期当天才通知，这会显得不妥。

此技能不负责的事项

• 不会直接查询系统。它会引导你完成清单；实际查询由人工（或已连接的工具）执行。
• 不会对边界案例作出豁免决定，而是将其标记并交由律师处理。
• 不会发送回复。先起草并审核，再由人工发送。