收到 DSAR 时用：分类权利、核验身份、逐系统定位数据…

当收到访问、删除、可携带、更正、反对、限制或选择退出等数据主体权利请求时，按司法辖区和配置流程处理并起草确认信与实质回复信。

适用场景

解决思路

1. 加载 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` 的 `## DSAR process`，获取系统清单、身份核验方法、响应 SLA、常规与升级处理人。
2. 运行 DSAR 工作流：先分类请求类型；检查升级触发条件，任一触发则先按升级路径分流再继续。
3. 按顺序走：核验身份 → 遍历系统清单 → 豁免分析 → 起草回复。
4. 输出回复草稿；不要发送，必须由人工审阅并发送。
5. 按内部流程记录 DSAR。
6. 粘贴请求前：请求会包含数据主体 PII；确认会话和输出存储满足数据处理要求。
7. 涂黑不需要的内容，例如身份证附件、无关邮件线程；不要把数据主体姓名存进文件名。
8. 检查 practice-level CLAUDE.md 的 `## Matter workspaces`；若 `Enabled` 为 `✗`，这是 in-house 默认，跳过后续 matter 机制，使用 practice-level 上下文。
9. 若 matter 已启用且没有活跃 matter，询问：Which matter is this for? Run `/privacy-legal:matter-workspace switch <slug>` or say `practice-level`.
10. 加载活跃 matter 的 `matter.md`，获取 matter 特有上下文和覆盖项。
11. 将输出写入 matter 文件夹 `~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/`；除非 `Cross-matter context` 为 `on`，绝不读取另一个 matter 的文件。
12. 读取 `## DSAR process` 中的系统清单、身份核验方法、响应 SLA、谁处理常规与升级；若系统清单为空或过期，标记出来，因为不知道去哪里找就无法完成 DSAR。
13. 先做司法辖区假设检查：分析假设使用配置中指定的辖区；如果数据主体、处理活动或控制者不在配置辖区，按写成的内容可能不适用。
14. Step 1 分类请求：识别数据主体行使的权利，包括 access、deletion/erasure、portability、correction/rectification、objection、restriction、opt-out of sale/share 与 automated decision-making 等 regime-specific 权利。
15. 对每项被主张权利，在继续前研究适用规则：识别适用法律辖区，包括 GDPR、UK GDPR、CCPA/CPRA、其他美国州隐私法、行业性 regime。
16. 引用控制性 statute 或 regulation 并给 pinpoint references：具体 article/section、权利范围、carve-outs。
17. 记录生效日期；数据主体权利经常修订，每立法季有新州法；标记不确定性并升级请律师核验，不要陈述未确认规则。
18. 无静默补充：如果对配置的法律研究工具查询某辖区权利、豁免或期限返回很少或没有结果，报告找到的内容并停止。
19. 不要未经询问就用网页搜索或模型知识填补缺口；应说明：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? 由律师决定是否接受低置信来源。
20. 对每条引用做来源分层标记：模型知识引用用 `[settled]`，包括稳定、知名 statutory 或 regulatory references，如 GDPR Art. 33、CCPA § 1798.100、FTC Act § 5、45-day CCPA response window under § 1798.130(a)(2) as a concept；仍须 filing 前核验但优先级较低。
21. 用 `[verify]` 标记真实但应核验的模型知识引用：具体 implementing regulations、agency guidance、case holdings、thresholds、effective dates、post-2023 amendments。
22. 用 `[verify-pinpoint]` 标记 pinpoint citations，包括具体 subsection letters、volume/page numbers、paragraph numbers、regulatory subpart references；这类伪造风险最高，必须始终对照 primary source 核验。
23. 工具检索引用保留来源标签，包括 `[Westlaw]`、`[issuing authority site]` 或 MCP tool name；网页搜索引用保持 `[web search — verify]`；用户提供引用保持 `[user provided]`；绝不要删除或合并标签。
24. 组合请求处理为两个关联请求，例如 delete my account and send me my data first 是 deletion + portability。
25. Step 2 按 CLAUDE.md 的方法核验身份；常见方式：logged-in verification，即请求来自已认证会话，身份确认。
26. Email match：请求来自在档邮箱，对低风险请求通常足够。
27. Additional verification：高价值账户或删除请求，使用 challenge question、phone verification、ID document。
28. 按风险校准：过度核验会把 DSAR 变成障碍，对监管者观感差；核验不足会把他人数据交给欺诈者。
29. 如果无法核验身份，使用回复：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.
30. 无法核验时这会可争辩地暂停时钟，但不要拖延；在几天内回复说需要核验，不要等到第 29 天。
31. Step 3 遍历 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` 中的系统清单；对每个系统填表：System、Queried?、Data found?、What。
32. 系统包括：Production database。
33. 系统包括：Analytics，例如 Mixpanel、Amplitude。
34. 系统包括：Support tickets，例如 Zendesk。
35. 系统包括：CRM，例如 Salesforce、HubSpot。
36. 系统包括：Email marketing，例如 Marketo。
37. 系统包括：Logs。
38. 系统包括：Backups，注意通常豁免删除。
39. 系统包括：Third-party processors，删除时可能需要通知他们。
40. 对 B2B processor：数据主体通常是客户公司的终端用户；检查这实际上是客户的 DSAR 还是你的；许多 processor DPA 说 forward DSARs to the controller。
41. Step 4 豁免分析：不是所有东西都产出或删除；在继续前研究适用规则。
42. 对每个条目识别 regime 下所有可能适用的豁免，例如 third-party privacy、privilege、trade secret、security、legal obligation to retain、establishment/defense of legal claims、transactional necessity、backup rotation accommodations、freedom of expression。
43. 引用控制性 statute、regulation 或 case 并给 pinpoint cite；豁免范围因辖区和 regime 而异，核验时效并标记不确定性。
44. 不要凭主观判断缩小豁免列表：有善意依据就提出豁免并标记不确定项；律师在回复发出前缩小列表。
45. 丢掉后来发现适用的豁免代价高：材料一旦披露，豁免实际消失；过度主张可成立的豁免可由律师审阅纠正；优先选择可恢复错误。
46. 每个提议豁免附注：proposed — requires attorney review before asserting. Regulators scrutinize blanket exemption claims, so the attorney narrows this list; the skill does not.
47. 逐项处理常见问题：记录是否含他人数据，产出前需涂黑。
48. 逐项处理常见问题：是否有具体法律保留义务阻止删除，引用它。
49. 逐项处理常见问题：是否有针对该个人数据的活跃 litigation hold。
50. 逐项处理常见问题：是否有 backup rotation 或 technical-feasibility accommodations 需要记录，不能当作通用借口。
51. 记录每个主张的豁免；如果监管者问为何没删，we had a legal obligation 需要引用。
52. Step 5 起草回复，两封信。研究连接器 pre-flight：在输出任一封信或内部豁免分析前，检查本会话是否有法律研究连接器可达，包括 Westlaw、EUR-Lex/regulator-site connector 或任何 firm-configured research MCP。
53. 将连接器状态收集进 reviewer note，按 CLAUDE.md `## Outputs`；reviewer note 放在 INTERNAL exemption-analysis 和 cover memo 上，NOT 放在面向数据主体的 DSAR letters 上。
54. 如果 Step 1 权利分类、Step 4 豁免分析或 Deadline management 研究步骤中无连接器返回结果，或运行时未配置，在内部 reviewer note 的 **Sources:** 行记录，例如 `not connected — cites from training knowledge; claimed exemptions, response deadlines, and extension mechanisms are especially fabrication-prone, verify before asserting any exemption to a data subject or regulator`。
55. per-citation `[model knowledge — verify]` 标签保留 inline；不要在输出上方单独发 banner。
56. 大多数 regime 期待或要求 prompt acknowledgment 与 substantive response 分开；两封都产出，不要合并成一封拖到 45 天 deadline 才发。
57. Step 5a 确认信：在收到后数日内发送，目标 same-day 至 3–5 天，始终远早于 regime 法定窗口；确认收到，说明控制者理解请求是什么，说明响应时钟和目标日期，询问仍缺少的身份核验材料；不包含实质披露。及时确认是监管者看到的第一个 DSAR 流程运作信号，也降低重复请求或提前投诉风险。
58. Step 5b 实质回复信：实际披露、删除确认或可携带导出；在法定 deadline 或更紧的内部 SLA 前发出；仅在身份核验完成且 Step 3/4 数据定位与豁免分析完成后发出。
59. 在向数据主体发送任一封信前：读取 `## Who's using this`；若 Role 是 Non-lawyer：提醒发送 DSAR 回复有法律后果，内容、主张的豁免和遗漏都可被监管者审查，错误陈述会成为执法风险；问是否已与律师审阅；是则继续，否则生成 brief。
60. 为律师生成 1 页摘要：data subject、right invoked、applicable regime(s)、systems list 上找到什么、withheld 什么及依据哪个 exemption、identity verification posture、response deadline、以及信件发出前要问律师的三件事。
61. 如需要找 licensed attorney、solicitor、barrister 或 other authorised legal professional：从你辖区的职业监管机构转介服务开始，例如美国 state bar、英格兰及威尔士 SRA/Bar Standards Board、苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚 Law Society 或同等机构。未获得明确 yes 不得越过此 gate。
62. 两封 DSAR 信都是对外交付物，发送给数据主体；不要在任一封信上包含 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` `## Outputs` 中的 work-product header。伴随信件的内部 notes、logs 和 exemption analyses 是 attorney work product，需分开并加上 work-product header，按 `## Outputs`，因用户角色而异，见 `## Who's using this`。
63. 发送任一封信前：这是供律师审阅的草稿，不是要发送的回复；发送会让控制者承诺立场，可能放弃豁免，并可能启动监管者时钟；licensed attorney 审阅、编辑并批准后，任一封信才能发给数据主体；不要发送未经审阅内容。
64. Step 5a 确认信模板字段：Subject: We received your privacy request — [Company] — [date]；Dear [Name]；收到 [access/deletion/portability/correction] 请求日期。
65. 确认信写：**Your request, as we understand it:** 一句话重述，例如 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.
66. 确认信写：**What happens next:** 实质回复目标日期，不晚于 regime 法定 deadline；内部 SLA 更紧则用内部 SLA；若身份核验未完成，写 We need [specific verification step] before we can proceed — see below.
67. 确认信写：如因请求复杂或同期收到其他请求需要更多时间，会在初始 deadline 前告诉你并解释；若 regime 允许延期，引用控制性条款。
68. 确认信写：本请求不收费；或费用仅在 regime 允许且请求明显无根据或过度时适用，并引用条款。
69. 确认信写：若身份核验未完成，**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.
70. 确认信写：如有问题联系 [privacy contact]；[Sender]。
71. Clock-start rule：响应时钟从收到请求开始，不是从身份核验完成开始，除非适用 regime 另有规定；不要默默用核验停表；若 regime 有不同触发点，引用它，不要假设。
72. Step 5b access request response 模板字段：Subject: Your Data Access Request — [Company] — [date]；收到请求日期；**What we found:** 表格 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]。
73. Access response：**Your data is attached** in [format]；安全交付说明，例如 password-protected archive、带到期时间的 secure link。
74. Access response：**Third parties:** 与以下 processors 共享：[list or link to subprocessor page]。
75. Access response：**Your other rights:** 也可请求 [deletion / correction / portability]；方法 [method]。
76. Access response：**Data we did not include:** [Category] — [exemption and reason，例如 internal security logs — disclosure would compromise security measures]；[Data about other individuals has been redacted from support correspondence]。
77. Access response：如有问题联系 [privacy contact]。
78. Step 5b deletion request response 模板字段：Subject: Your Deletion Request — [Company] — [date]；收到请求日期。
79. Deletion response：**What we deleted:** 表格 Category、System、Deleted on，示例 Account and profile / Production / [date]；Analytics events / [Amplitude/etc.] / [date]；[etc.]。
80. Deletion response：**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]。
81. Deletion response：**Third-party processors:** 已指示 [list] 从他们系统删除你的数据。
82. Deletion response：你的账户现已关闭；如有问题联系 [privacy contact]。
83. Step 6 记录：DSAR 会被审计；记录 Date received、Date identity verified、Date responded、What was produced/deleted、Exemptions claimed and basis、Who handled it。
84. 若团队使用 DSAR tracking tool，在那里创建记录；否则 log file 即可。
85. 按 `CLAUDE.md` → Escalation table 升级：请求者或可能请求者是 plaintiff、opposing counsel 或 journalist。
86. 按升级触发条件：请求范围异常，例如 all data including internal communications about me。
87. 按升级触发条件：对该个人数据有 litigation hold，删除请求加 lit hold 等于冲突，律师决定。
88. 按升级触发条件：请求者正在质疑之前的 DSAR 回复。
89. 按升级触发条件：任何 regulator 被 cc 或提到。
90. Deadline management 两封信规则：每个 DSAR 产出一封确认信，prompt，目标收到后 same-day 至 3–5 天，和一封实质回复信，法定 deadline 前；大多数 regime 要求或期待 prompt acknowledgment 与 substantive response 分开；第 45 天单独合并信是流程失败，即使实体正确。
91. 研究当前有效的响应 deadline，针对具体主张权利和适用辖区；检查是否存在 extension mechanism、能多买多少时间、调用它要给数据主体什么通知。
92. 识别时钟何时开始，包括 receipt、verification 或其他触发；默认 receipt；按 regime 核验；引用控制性 statute 或 regulation 并给 pinpoint references；记录生效日期；数据保护响应时间线经常修订，新州法引入自己的时钟。
93. 如果 `CLAUDE.md` → `## DSAR process` 记录的内部 SLA 比法律 deadline 更紧，使用内部 SLA 并注明法律 backstop。
94. 如果需要延期，远早于第一个 deadline 发送 we need more time 通知；当天延期观感差。
95. 本技能不直接查询系统；它走 checklist；由人工或已连接工具执行实际查询。
96. 本技能不对疑难案件做豁免决定；它标记给律师。
97. 本技能不发送回复；起草、审阅、人工发送。

适用边界 · 注意事项

• 当数据主体、处理活动或控制者不在配置的司法辖区时，不要按本技能的分析照搬；需先重新确认适用法律。
• 当没有可用的法律研究连接器且无法确认适用权利、豁免或 deadline 时，不要从模型知识或网页搜索静默补足；标记未验证并停止，等待律师决定。
• 本技能不直接查询系统、不对疑难的豁免做决定、也不发送回复；缺少人工或连接工具查询，或缺少律师审阅时不适用。