Back to Details

dsar-response

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/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]
  1. 加载 
    ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
    → DSAR流程（系统清单、验证方法、服务水平协议SLA）。
  2. 执行以下工作流。
  3. 对请求类型进行分类。检查升级触发条件——若触发任何条件，先转介再继续处理。
  4. 逐步执行：验证身份 → 梳理系统清单 → 豁免分析 → 草拟回复。
  5. 输出回复草稿。请勿发送——需经人工审核后发送。
  6. 根据内部流程记录该DSAR请求。
粘贴请求前须知：请求将包含数据主体的个人身份信息（PII）。请确认你的会话和输出存储符合数据处理要求。编辑掉不需要的内容（如ID附件、无关邮件线程）。请勿将主体姓名存储在文件名中。
/privacy-legal:dsar-response
[paste the request email]

DSAR Response Drafting

DSAR回复草拟

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
.
事项背景。查看业务级CLAUDE.md中的
## Matter workspaces
部分。若
Enabled
为
✗
（内部用户默认设置），则跳过本段剩余内容——技能将使用业务级背景信息，事项机制不可见。若已启用且无活跃事项，请询问：“这属于哪个事项？请运行
/privacy-legal:matter-workspace switch <slug>
或说明‘业务级’。”加载活跃事项的
matter.md
以获取特定事项的背景信息和覆盖规则。将输出写入事项文件夹：
~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/
。除非
Cross-matter context
开启，否则切勿读取其他事项的文件。

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.
DSAR请求有截止期限（由适用法规设定）、固定流程（验证、定位、评估豁免、回复），且存在诸多可能出错的环节。本技能将引导完成每个步骤并草拟回复。

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.
本分析基于配置中指定的管辖范围。隐私规则、回复期限和合法依据因管辖权差异显著（如GDPR vs. 美国州级消费者隐私法 vs. 行业特定法规）。若数据主体、处理活动或控制者所在管辖权与配置不同，本分析可能无法直接适用。

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.
读取
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
→ 
## DSAR process
部分。该部分包含：
  • 系统清单（用户数据存储的所有位置）
  • 身份验证方法
  • 回复SLA
  • 常规请求与升级请求的处理人员
若系统清单为空或过时，请标记——若不知道数据存储位置，无法完成完整的DSAR处理。

Workflow

工作流

Step 1: Classify the request

步骤1：请求分类

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.
确定数据主体主张的权利类型。常见类别：
  • 访问——其数据副本 + 处理相关信息
  • 删除/擦除——移除其数据（受豁免情形限制）
  • 可携带性——以机器可读格式提供其数据
  • 更正/修正——修复不准确数据
  • 异议——停止特定处理（通常为营销活动）
  • 限制——暂停处理直至争议解决
  • 退出销售/共享/自动化决策——特定法规下的权利
继续处理前请研究适用规则。针对每项主张的权利，确定适用的管辖法规（GDPR、UK GDPR、CCPA/CPRA、其他美国州级隐私法、行业特定法规）。引用具有精准指向的控制性法规或条例——具体条款/章节、权利范围、任何例外情况。注意生效日期；数据主体权利经常修订（每年立法会议都会出台新的州级法律）。若存在不确定性，请标记并升级至律师验证，切勿陈述未确认的规则。
禁止补充未核实内容。若向配置的法律研究工具发起的查询对该管辖权的权利、豁免或期限返回结果极少或无结果，请报告已发现内容并停止。未经询问，请勿通过网络搜索或模型知识填补空白。请说明：“搜索从[工具]返回[N]条结果。[法规/权利]的覆盖范围似乎有限。选项：(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]
。分层可明确实际验证工作——若要求验证所有内容，等于无需验证。切勿移除或合并标签。
部分请求为组合类型——“删除我的账户并先发送我的数据”属于删除+可携带性请求。需作为两个关联请求处理。

Step 2: Verify identity

步骤2：身份验证

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:
markdown
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.
按照
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
中的方法执行。常见方式：
  • 登录验证：请求来自已认证会话 → 身份确认
  • 邮箱匹配：请求来自存档邮箱 → 通常足以处理低风险请求
  • 额外验证：针对高价值账户或删除请求 → 质询问题、电话验证、身份证件
根据风险调整验证强度。过度验证会将DSAR流程变为障碍（易引发监管机构不满）。验证不足则可能将他人数据交给欺诈者。
若无法验证身份：
markdown
我们无法验证该请求来自所涉数据的主体。如需继续，请[验证步骤]。对于无法验证的请求，我们无法提供个人数据。
这可能会暂停期限计算，但请勿拖延——需在数日内回复说明需要验证，而非等到第29天。

Step 3: Locate the data

步骤3：定位数据

Walk the systems list from 
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
. For each system:
SystemQueried?Data found?What
Production database
Analytics (e.g., Mixpanel, Amplitude)
Support tickets (e.g., Zendesk)
CRM (e.g., Salesforce, HubSpot)
Email marketing (e.g., Marketo)
Logs
Backups(note: usually exempt from deletion — see below)
Third-party processors(they may need to be notified for deletion)
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."
梳理
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
中的系统清单。针对每个系统：
系统是否已查询？是否找到数据？数据内容
生产数据库
分析工具（如Mixpanel、Amplitude）
支持工单（如Zendesk）
客户关系管理系统（如Salesforce、HubSpot）
邮件营销工具（如Marketo）
日志
备份（注：通常可豁免删除——见下文）
第三方处理者（可能需通知其执行删除操作）
对于B2B处理者：“数据主体”通常是你的客户的终端用户。请确认这是否实际为客户需处理的DSAR请求，而非你的请求。许多处理者的数据处理协议（DPA）规定“将DSAR请求转发给控制者”。

Step 4: Exemption analysis

步骤4：豁免分析

Not everything gets produced or deleted. Research the applicable rule before proceeding. For each item, identify every exemption that plausibly applies under the regime in scope (e.g., third-party privacy, privilege, trade secret, security, legal obligation to retain, establishment/defense of legal claims, transactional necessity, backup rotation accommodations, freedom of expression). Cite the controlling statute, regulation, or case with a pinpoint cite. Exemption scope varies by jurisdiction and regime — verify currency and flag uncertainty.
Don't narrow the list on a subjective call. The skill proposes exemptions where a good-faith basis exists and flags the uncertain ones; the attorney narrows the list before the response goes out. Dropping an exemption that later turns out to apply is costly — once material is disclosed, the exemption is functionally gone. Over-asserting a plausible exemption is correctable by the attorney in review. Prefer the recoverable error.
Every proposed exemption carries an explicit note: "proposed — requires attorney review before asserting. Regulators scrutinize blanket exemption claims, so the attorney narrows this list; the skill does not."
Common recurring questions to work through:
  • Does the record contain data about other people that needs to be redacted before production?
  • Is there a specific legal retention obligation that blocks deletion? Cite it.
  • Is there an active litigation hold covering this individual's data?
  • Are there backup rotation or technical-feasibility accommodations that need to be documented (not used as a general excuse)?
Document every exemption claimed. If a regulator asks why you didn't delete something, "we had a legal obligation" needs a citation.
并非所有数据都需提供或删除。继续处理前请研究适用规则。针对每项内容，确定适用法规下可能适用的所有豁免情形（如第三方隐私、特权、商业秘密、安全、法定保留义务、法律主张的建立/辩护、交易必要性、备份轮换调整、言论自由）。引用具有精准指向的控制性法规、条例或判例。豁免范围因管辖权和法规而异——请验证时效性并标记不确定性。
请勿主观缩小豁免清单。本技能会在存在合理依据时提出豁免建议，并标记不确定项；律师会在回复发出前缩小清单。遗漏后续被证明适用的豁免代价高昂——一旦披露内容，豁免将实际失效。过度主张合理豁免可由律师在审核中纠正。优先选择可挽回的错误。
每个拟议豁免均需附带明确说明：“拟议内容——主张前需经律师审核。监管机构会严格审查笼统的豁免主张，因此由律师缩小清单，本技能不执行此操作。”
需解决的常见问题：
  • 记录是否包含需在提供前编辑的其他人员数据？
  • 是否存在阻止删除的特定法定保留义务？请引用。
  • 该个人的数据是否处于活跃诉讼保留状态？
  • 是否需要记录备份轮换或技术可行性调整（不得作为通用借口）？
记录所有主张的豁免。若监管机构询问未删除某内容的原因，“我们负有法定义务”需附带引用依据。

Step 5: Draft the response — TWO LETTERS

步骤5：草拟回复——两封信函

Research-connector pre-flight. Before emitting either letter or the internal exemption analysis, check whether a legal research connector is reachable for this session — Westlaw, an EUR-Lex / regulator-site connector, or any firm-configured research MCP. Collect this into the reviewer note per CLAUDE.md 
## Outputs
— the reviewer note sits on the INTERNAL exemption-analysis and cover memo, NOT on the outward-facing DSAR letters to the data subject. If no connector returns results in Step 1 (right classification), Step 4 (exemption analysis), or the Deadline management research step (or none is configured at run time), record it in the Sources: line of the internal reviewer note — e.g., 
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
. Per-citation 
[model knowledge — verify]
tags remain inline. Do not emit a standalone banner above the output.
Most regimes expect (or require) a prompt acknowledgment separate from the substantive response. Produce both; do not collapse them into one letter that waits until the 45-day deadline to go out.
  • Step 5a — Acknowledgment letter. Sent within days of receipt (target: same-day to 3–5 days, always well inside the regime's statutory window). Confirms receipt, states what the controller understands the request to be, states the response clock and the target date, asks for any identity-verification material still outstanding. Does NOT contain the substantive disclosure. A prompt acknowledgment is the first regulator-visible signal that the DSAR process is working; it also reduces the risk of a duplicate request or an early complaint.
  • Step 5b — Substantive response letter. The actual disclosure, deletion confirmation, or portability export. Goes out by the statutory deadline (or the internal SLA if tighter). Only after identity verification is complete and the Step 3 / Step 4 data location + exemption analysis is done.
Before proceeding to send either letter to the data subject: Read 
## Who's using this
in 
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
. If the Role is Non-lawyer:
Sending a DSAR response has legal consequences — the content, the exemptions claimed, and the omissions are all reviewable by a regulator, and misstatements become enforcement exposure. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
[Generate a 1-page summary: data subject, right invoked, applicable regime(s), what was located across the systems list, what is being withheld and under which exemption, identity verification posture, response deadline, and the three things to ask the attorney before the letter goes out.]
If you need to find a licensed attorney, solicitor, barrister, or other authorised legal professional in your jurisdiction: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).
Do not proceed past this gate without an explicit yes.
Note: Both DSAR letters are externally-facing deliverables sent to the data subject. Do not include the work-product header from 
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Outputs
on either letter. Internal notes, logs, and exemption analyses that accompany the letters are attorney work product — keep those separate and prepend the work-product header per 
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Outputs
(which differs by user role — see 
## Who's using this
).
Before sending either letter: This is a draft for attorney review, not a response to send. Sending commits the controller to a position, may waive exemptions, and may start a regulator's clock. A licensed attorney reviews, edits, and approves before either letter goes to the data subject. Do not send unreviewed.
研究连接器预检查。在生成任何信函或内部豁免分析前，请检查本次会话是否可访问法律研究连接器——Westlaw、EUR-Lex/监管机构网站连接器，或任何公司配置的研究MCP。根据CLAUDE.md的
## Outputs
部分将信息收集至审核者说明中——审核者说明置于内部豁免分析和封面备忘录中，而非发给数据主体的对外DSAR信函。若步骤1（权利分类）、步骤4（豁免分析）或期限管理研究步骤中无连接器返回结果（或运行时未配置连接器），请在内部审核者说明的**来源：**行中记录——例如
未连接——引用来自训练知识；主张的豁免、回复期限和延期机制尤其容易出现伪造内容，在向数据主体或监管机构主张任何豁免前请验证
。每个引用的
[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回复会产生法律后果——内容、主张的豁免和遗漏内容均需接受监管机构审查，不实陈述会引发执法风险。你是否已与律师审核过此内容？若是，请继续。若否，请准备以下摘要提交给律师：
[生成1页摘要：数据主体、主张的权利、适用法规、系统清单中定位的内容、拟扣留的内容及依据的豁免、身份验证状态、回复期限，以及信函发出前需向律师询问的三个问题。]
若你需要在所在辖区寻找持牌律师、事务律师、出庭律师或其他授权法律专业人士：所在辖区的专业监管机构推荐服务是最快的起点（美国为州律师协会，英格兰和威尔士为SRA/律师标准委员会，苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚为律师协会，或所在辖区的等效机构）。
未经明确确认，请勿继续。
注意：两封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
）添加工作产品页眉。
发送任何信函前：此为供律师审核的草稿，并非可直接发送的回复。发送后控制者将承担相应立场，可能放弃豁免权，并可能启动监管机构的期限计算。需由持牌律师审核、编辑并批准后，方可向数据主体发送任何信函。请勿发送未审核的内容。

Step 5a — Acknowledgment letter template

步骤5a——确认函模板

markdown
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]
Clock-start rule. The response clock starts on receipt of the request, not on completion of identity verification — unless the applicable regime says otherwise. Do not tacitly toll the clock on verification. If a regime has a different trigger, cite it; do not assume.
markdown
主题：我们已收到你的隐私请求 —— [公司名称] —— [日期]

尊敬的[姓名]：

我们于[收到日期]收到你的[访问/删除/可携带性/更正]请求。

**我们对请求的理解**：[一句话重述——例如：“提供与你的账户相关的所有个人数据副本，以及与之共享数据的第三方类别，并在提供副本后删除你的账户。”]

**后续流程**：
- 我们的实质性回复目标日期为[日期——不得晚于法规规定的期限；若内部SLA更严格，则使用内部SLA]。[若身份验证未完成：“我们需要[具体验证步骤]才能继续——见下文。”]
- 若因请求复杂或同时收到你的其他请求而需要更多时间，我们将在初始期限前告知你并说明原因。[若法规允许延期，请引用控制性条款。]
- 本次请求不收取费用。[或：仅在法规允许且请求明显无依据或过度时收取费用——请引用相关条款。]

[若身份验证未完成：]
**为验证你的身份**，请[具体验证步骤——例如：从存档邮箱回复此邮件，并提供我们存档的支付方式后四位数字]。此步骤不会暂停我们的期限；我们将同步推进工作。

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

[发件人]
期限启动规则。回复期限从收到请求时开始计算，而非身份验证完成时——除非适用法规另有规定。请勿默认因验证而暂停期限。若法规有不同触发条件，请引用；切勿假设。

Step 5b — Substantive response letter templates

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

Access request response:
markdown
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].
Deletion request response:
markdown
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].
访问请求回复：
markdown
主题：你的数据访问请求 —— [公司名称] —— [日期]

我们于[日期]收到你索要我们持有的关于你的个人数据副本的请求。

**我们找到的内容**：

我们持有与[标识符]相关的以下类别的个人数据：

| 类别 | 来源 | 用途 | 保留至 |
|---|---|---|---|
| [账户信息：姓名、邮箱] | 你在注册时提供 | 账户管理 | 账户删除时 |
| [使用数据] | 我们的服务 | 分析、产品改进 | [期限] |
| [支持通信记录] | 你提供 | 客户支持 | [期限] |

**你的数据已附后**，格式为[格式]。[安全交付说明——密码保护存档、带过期时间的安全链接等。]

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

**你的其他权利**：你还可请求[删除/更正/可携带性]。操作方式为[方法]。

**未包含的数据**：
- [类别]——[豁免及原因，例如：“内部安全日志——披露会损害安全措施”]
- [支持通信记录中已编辑其他人员的数据]

如有疑问，请联系[隐私联系人]。
删除请求回复：
markdown
主题：你的删除请求 —— [公司名称] —— [日期]

我们于[日期]收到你索要删除我们持有的关于你的个人数据的请求。

**已删除内容**：

| 类别 | 系统 | 删除日期 |
|---|---|---|
| [账户和个人资料] | 生产系统 | [日期] |
| [分析事件] | [Amplitude等] | [日期] |
| [其他] | | |

**保留内容及原因**：

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

**第三方处理者**：我们已指示[列表]从其系统中删除你的数据。

你的账户现已关闭。如有疑问，请联系[隐私联系人]。

Step 6: Log it

步骤6：记录

DSARs get audited. Record:
  • Date received
  • Date identity verified
  • Date responded
  • What was produced/deleted
  • Exemptions claimed and basis
  • Who handled it
If your team uses a DSAR tracking tool, create the record there. If not, a log file works.
DSAR请求会被审计。请记录：
  • 收到日期
  • 身份验证日期
  • 回复日期
  • 提供/删除的内容
  • 主张的豁免及依据
  • 处理人员
若你的团队使用DSAR跟踪工具，请在其中创建记录。若未使用，日志文件即可。

Escalation triggers

升级触发条件

Per 
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
→ Escalation table, escalate when:
  • Requester is (or might be) a plaintiff, opposing counsel, or journalist
  • Request scope is unusual ("all data including internal communications about me")
  • There's a litigation hold on this individual's data (deletion request + lit hold = conflict, lawyer decides)
  • Requester is disputing a previous DSAR response
  • Any regulator is cc'd or mentioned
根据
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
→ 升级表，出现以下情况时需升级：
  • 请求者是（或可能是）原告、对方律师或记者
  • 请求范围异常（“所有数据，包括关于我的内部通信”）
  • 该个人的数据处于活跃诉讼保留状态（删除请求+诉讼保留=冲突，由律师决定）
  • 请求者对之前的DSAR回复提出异议
  • 任何监管机构被抄送或提及

Deadline management

期限管理

Two-letter rule. Every DSAR produces an acknowledgment letter (prompt — target same-day to 3–5 days after receipt) AND a substantive response letter (by the statutory deadline). Most regimes either require or expect a prompt acknowledgment separate from the substantive response; a single combined letter sent on day 45 is a process failure even if it is substantively correct.
Research the currently operative response deadline for the specific right invoked and the applicable jurisdictions. Check whether an extension mechanism exists, how much extra time it buys, and what notice the data subject must receive to invoke it. Identify when the clock starts (receipt vs. verification vs. some other trigger — default rule is receipt; verify per regime). Cite the controlling statute or regulation with pinpoint references. Note effective dates — data protection response timelines are amended frequently and new state laws introduce their own clocks.
If 
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
→ 
## DSAR process
records an internal SLA that is tighter than the legal deadline, use the internal SLA and note the legal backstop.
If you're going to need an extension, send the "we need more time" notice well before the first deadline. Day-of extensions look bad.
两封信函规则。每个DSAR请求需生成确认函（即时发送——目标为收到后当日至3-5天内）和实质性回复函（在法定期限前发送）。大多数法规要求或期望在实质性回复之外发送即时确认函；即使内容正确，在第45天发送合并信函仍属于流程失败。
研究所主张的特定权利和适用管辖权当前有效的回复期限。检查是否存在延期机制、可延长的时间长度，以及需向数据主体发出何种通知才能启用该机制。确定期限启动时间（收到请求 vs. 验证完成 vs. 其他触发条件——默认规则为收到请求；请根据法规验证）。引用具有精准指向的控制性法规或条例。注意生效日期——数据保护回复期限经常修订，新的州级法律会引入各自的期限。
若
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
→ 
## DSAR process
记录的内部SLA比法定期限更严格，请使用内部SLA并注明法定兜底期限。
若需要延期，请在首个期限前尽早发送“需要更多时间”的通知。当天申请延期会留下不良印象。

What this skill does not do

本技能不执行的操作

  • It doesn't query systems directly. It walks you through the checklist; a human (or a connected tool) does the actual queries.
  • It doesn't make exemption calls on close cases. It flags them for a lawyer.
  • It doesn't send the response. Draft, review, human sends.
  • 不直接查询系统。仅引导完成检查清单；实际查询需由人工（或连接的工具）执行。
  • 不对边界情形做出豁免决策。仅标记此类情形供律师处理。
  • 不发送回复。草拟、审核、人工发送。