iiuniversitet.ruЦентр обучения нейросетямОткрыть каталог

Ответ на запрос субъекта данных

Ведёт по обработке запроса на доступ, удаление, переносимость или исправление данных и готовит два письма: подтверждение и ответ по существу.

СкиллAnthropicClaudeApache-2.0Нужен терминалПроверка не требуется
Что делает
Ведёт по обработке запроса на доступ, удаление, переносимость или исправление данных и готовит два письма: подтверждение и ответ по существу.
Когда брать
Когда пришёл запрос человека на доступ к его данным, удаление, перенос или исправление и нужно проверить личность, найти данные по системам и оценить исключения.
Когда не брать
Если запрос обрабатывает ваш клиент, а вы лишь обработчик: перешлите его владельцу данных. Скилл не лезет в системы сам, не решает спорные исключения и ничего не отправляет.
Пример запроса
Пришёл запрос «хочу получить все мои данные и удалить аккаунт»: вот письмо, подготовь ответ.
Нужно подключить
доступ к файлам (папка настроек плагина)
Работает лучше с
инструмент юридического поиска (Westlaw, EUR-Lex)

Входит в плагин privacy-legal. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

  1. Скачайте архив и распакуйте его.
  2. Положите папку dsar-response в ~/.claude/skills/.
  3. Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.

Текст

---
name: dsar-response
description: >
  Проведи через обработку запроса субъекта данных (Data Subject Access Request, DSAR; а также запроса
  на удаление, переносимость или исправление данных) и составь ответ: проверь личность, найди данные
  по системам одну за другой, оцени исключения, подготовь письмо с подтверждением получения и письмо
  с ответом по существу. Используй, когда пришёл DSAR, когда пользователь вставляет запрос на доступ,
  удаление, переносимость или исправление данных либо говорит «пришёл DSAR», «запрос на доступ»,
  «право на забвение» или «кто-то хочет получить свои данные».
argument-hint: "[paste the request, or describe it]"
---

/dsar-response

  1. Загрузи ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → процесс обработки DSAR (список систем, способ проверки личности, срок ответа — SLA).
  2. Выполни рабочий процесс ниже.
  3. Определи тип запроса. Проверь триггеры эскалации: если хоть один сработал, передай дело дальше до продолжения.
  4. Пройди по шагам: проверка личности → обход списка систем → анализ исключений → черновик.
  5. Выдай черновик ответа. НЕ отправляй: проверяет и отправляет человек.
  6. Занеси DSAR в журнал по принятому у вас порядку.

Перед тем как вставлять запрос: в запросе будут персональные данные субъекта. Убедись, что ваша сессия и хранение результатов отвечают вашим требованиям к обращению с данными. Удали всё лишнее (вложенные удостоверения личности, посторонние цепочки писем). Не используй имя субъекта в именах файлов.

/privacy-legal:dsar-response
[вставь письмо с запросом]

Подготовка ответа на DSAR

Контекст дела

Контекст дела. Загляни в раздел ## Matter workspaces в CLAUDE.md уровня практики. Если 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, другие законы штатов США о приватности, отраслевые режимы). Цитируй определяющий закон или нормативный акт с точными ссылками: конкретная статья или раздел, объём права, любые исключения. Отмечай даты вступления в силу: права субъектов данных часто меняются (новые законы штатов появляются с каждой законодательной сессией). Неуверенность отмечай и эскалируй на проверку юристом, а не излагай правило, которое не подтверждено.

Никаких тихих дополнений. Если запрос к настроенному инструменту юридического поиска возвращает мало результатов или не возвращает ничего по правам, исключениям или срокам юрисдикции, сообщи, что нашлось, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели без вопроса. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [режим / право], похоже, скудное. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент, (3) поискать в вебе: результаты получат пометку [web search — verify], и их нужно сверить с первоисточником, прежде чем полагаться на них, или (4) пометить как непроверенное и остановиться. Что выберете?» Принимать ли источники с меньшей достоверностью, решает юрист. Градация источников. Помечай каждую ссылку её источником. Для ссылок по знаниям модели используй одну из трёх градаций вместо единой общей пометки «проверить»: - [settled] — устойчивые, хорошо известные ссылки на законы и нормативные акты, которые вряд ли изменились (например, GDPR ст. 33, CCPA § 1798.100, FTC Act § 5, 45-дневное окно ответа по CCPA по § 1798.130(a)(2) как понятие). Перед подачей всё равно проверить, но с меньшим приоритетом. - [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 в барьер (плохо выглядит перед регуляторами). Недостаточная проверка рискует отдать чужие данные мошеннику.

Если личность подтвердить не удаётся:

Нам не удалось подтвердить, что этот запрос пришёл от человека, чьи данные
затрагиваются. Чтобы продолжить, пожалуйста, [шаг проверки]. Мы не можем
передавать персональные данные в ответ на запрос, который не удалось проверить.

Это (по крайней мере, в теории) приостанавливает отсчёт срока, но не тяни: сообщи, что нужна проверка, в течение нескольких дней, а не на 29-й день.

Шаг 3: Найди данные

Пройди по списку систем из ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. По каждой системе:

СистемаЗапрос выполнен?Данные найдены?Что
Рабочая база данных
Аналитика (например, Mixpanel, Amplitude)
Обращения в поддержку (например, Zendesk)
CRM (например, Salesforce, HubSpot)
Почтовый маркетинг (например, Marketo)
Логи
Резервные копии(примечание: обычно исключены из удаления, см. ниже)
Сторонние обработчики(возможно, их нужно уведомить об удалении)

Для B2B-обработчика «субъект данных» — обычно *конечный пользователь вашего клиента*. Проверь, не должен ли этот DSAR обрабатывать ваш клиент, а не вы. Во многих DPA обработчиков записано «пересылать DSAR оператору данных».

Шаг 4: Анализ исключений

Не всё выдаётся или удаляется. Изучи применимое правило, прежде чем продолжать. По каждому элементу определи все исключения, которые правдоподобно применимы по режиму в области (например, приватность третьих лиц, привилегия, коммерческая тайна, безопасность, юридическая обязанность хранить, установление и защита правовых притязаний, необходимость для сделки, учёт ротации резервных копий, свобода выражения мнения). Цитируй определяющий закон, нормативный акт или судебное дело с точной ссылкой. Объём исключения зависит от юрисдикции и режима: проверяй актуальность и отмечай неуверенность.

Не сужай список по субъективной оценке. Скилл предлагает исключения там, где есть добросовестное основание, и отмечает неуверенные; список сужает юрист перед отправкой ответа. Отказ от исключения, которое потом окажется применимым, обходится дорого: после раскрытия материала исключение фактически потеряно. Излишнее заявление правдоподобного исключения юрист может исправить при проверке. Предпочитай ошибку, которую можно исправить.

Каждое предлагаемое исключение сопровождается явной пометкой: «предложено — требует проверки юристом до применения. Регуляторы внимательно изучают огульные ссылки на исключения, поэтому этот список сужает юрист, а не скилл».

Типичные повторяющиеся вопросы:

  • Содержит ли запись данные о *других* людях, которые нужно удалить из выдачи?
  • Есть ли конкретная юридическая обязанность хранения, которая блокирует удаление? Процитируй её.
  • Действует ли судебный запрет на уничтожение данных (litigation hold) в отношении данных этого человека?
  • Есть ли учёт ротации резервных копий или технической невозможности, которые нужно задокументировать (а не использовать как общую отговорку)?

Документируй каждое заявленное исключение. Если регулятор спросит, почему вы что-то не удалили, фразе «у нас была юридическая обязанность» нужна ссылка.

Шаг 5: Составь ответ — ДВА ПИСЬМА

Проверка подключения исследовательских инструментов. Прежде чем выдавать любое из писем или внутренний анализ исключений, проверь, доступен ли в этой сессии инструмент юридического поиска — Westlaw, коннектор к EUR-Lex или сайтам регуляторов, либо любой настроенный фирмой MCP для исследований. Собери это в заметку для проверяющего по разделу CLAUDE.md ## Outputs: заметка для проверяющего прикрепляется к ВНУТРЕННЕМУ анализу исключений и сопроводительной записке, а НЕ к исходящим письмам субъекту данных по DSAR. Если ни один коннектор не вернул результатов на шаге 1 (определение права), шаге 4 (анализ исключений) или на шаге исследования в разделе «Управление сроками» (или ни один не настроен на момент запуска), запиши это в строку 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 (то есть: не подключено, ссылки взяты из знаний модели; заявленные исключения, сроки ответа и механизмы продления особенно склонны к выдумке, проверь, прежде чем ссылаться на любое исключение перед субъектом данных или регулятором). Пометки [model knowledge — verify] у отдельных ссылок остаются в тексте. Не выводи отдельный баннер над результатом.

Большинство режимов ожидают (или требуют) быстрого подтверждения получения отдельно от ответа по существу. Составь оба письма; не своди их в одно письмо, которое уйдёт только к 45-дневному сроку.

  • Шаг 5а — письмо с подтверждением получения. Отправляется в течение нескольких дней после получения (цель: в тот же день и до 3–5 дней, всегда с запасом внутри законного срока режима). Подтверждает получение, излагает, как оператор данных понял запрос, называет срок ответа и целевую дату, просит о недостающих материалах для проверки личности. НЕ содержит раскрытия по существу. Быстрое подтверждение — первый видимый регулятору признак того, что процесс DSAR работает; оно же снижает риск повторного запроса или ранней жалобы.
  • Шаг 5б — письмо с ответом по существу. Само раскрытие, подтверждение удаления или экспорт для переносимости. Уходит к законному сроку (или к внутреннему SLA, если он жёстче). Только после завершения проверки личности и после шагов 3 и 4 (места данных и анализ исключений).

Перед отправкой любого письма субъекту данных: прочитай ## Who's using this в ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Если роль — Non-lawyer (не юрист):

Отправка ответа на DSAR имеет правовые последствия: содержание, заявленные исключения и пропуски может проверить регулятор, а неточные утверждения становятся риском правоприменения. Вы согласовали это с юристом? Если да, продолжайте. Если нет, вот краткая справка, с которой стоит к нему прийти: [Составь резюме на одну страницу: субъект данных, реализуемое право, применимые режимы, что найдено по списку систем, что удерживается и по какому исключению, состояние проверки личности, срок ответа и три вопроса юристу до отправки письма.] Если вам нужно найти лицензированного юриста, адвоката (solicitor, barrister) или иного уполномоченного специалиста в вашей юрисдикции, быстрее всего начать со справочной службы вашего профессионального регулятора (коллегия адвокатов штата в США, 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).

Перед отправкой любого письма: это черновик для проверки юристом, а не ответ к отправке. Отправка фиксирует позицию оператора данных, может лишить его исключений и может запустить отсчёт срока у регулятора. Лицензированный юрист проверяет, правит и утверждает оба письма до того, как они уйдут субъекту данных. Не отправляй непроверенное.

Шаг 5а — шаблон письма с подтверждением получения
Тема: Мы получили ваш запрос по персональным данным — [Компания] — [дата]

Здравствуйте, [Имя]!

Мы получили ваш запрос ([доступ / удаление / переносимость / исправление]) [дата получения].

**Ваш запрос в том виде, как мы его поняли:** [пересказ одним предложением — например, «копия всех персональных данных, которые мы храним в связи с вашей учётной записью, вместе с категориями третьих лиц, которым мы их передаём, и удаление вашей учётной записи после того, как мы предоставим копию».]

**Что будет дальше:**
- Целевая дата ответа по существу: [дата — не позднее законного срока режима; если внутренний SLA жёстче, берите его]. [Если проверка личности не завершена: «Прежде чем мы сможем продолжить, нам нужно [конкретный шаг проверки]. См. ниже».]
- Если нам потребуется больше времени из-за сложности запроса или потому, что вы одновременно направили другие запросы, мы сообщим вам об этом до первоначального срока и объясним причину. [Если режим допускает продление, процитируй определяющее положение.]
- За этот запрос плата не взимается. [Или: плата взимается, только если режим это допускает и запрос явно необоснован или чрезмерен — процитируй положение.]

[Если проверка личности не завершена:]
**Чтобы подтвердить вашу личность,** пожалуйста, [конкретный шаг проверки — например, ответьте на это письмо с адреса, который у нас в базе, и укажите последние 4 цифры способа оплаты, который у нас записан]. Это не приостанавливает наш срок: мы продолжаем работать параллельно.

Если у вас есть вопросы, свяжитесь с [контакт по приватности].

[Отправитель]

Правило начала отсчёта. Срок ответа начинается с получения запроса, а не с завершения проверки личности, если применимый режим не говорит иное. Не приостанавливай отсчёт срока негласно из-за проверки. Если у режима другой момент начала отсчёта, процитируй его; не предполагай.

Шаг 5б — шаблоны письма с ответом по существу

Ответ на запрос доступа:

Тема: Ваш запрос на доступ к данным — [Компания] — [дата]

Мы получили ваш запрос [дата] на копию персональных данных, которые мы о вас храним.

**Что мы нашли:**

Мы храним следующие категории персональных данных, связанных с [идентификатор]:

| Категория | Источник | Цель | Срок хранения |
|---|---|---|---|
| [Данные учётной записи: имя, адрес электронной почты] | Вы, при регистрации | Управление учётной записью | До удаления учётной записи |
| [Данные об использовании] | Наш сервис | Аналитика, улучшение продукта | [срок] |
| [Переписка с поддержкой] | Вы | Поддержка клиентов | [срок] |

**Ваши данные приложены** в формате [формат]. [Примечание о защищённой доставке: архив с паролем,
защищённая ссылка с ограниченным сроком действия и т. д.]

**Третьи лица:** мы передаём данные следующим обработчикам: [список или ссылка на страницу
субпроцессоров].

**Ваши другие права:** вы также можете запросить [удаление / исправление / переносимость].
Для этого [способ].

**Данные, которые мы не включили:**
- [Категория] — [исключение и причина, например: «внутренние журналы безопасности — раскрытие
  поставило бы под угрозу меры безопасности»]
- [Данные о других лицах удалены из переписки с поддержкой]

Если у вас есть вопросы по этому ответу, свяжитесь с [контакт по приватности].

Ответ на запрос удаления:

Тема: Ваш запрос на удаление данных — [Компания] — [дата]

Мы получили ваш запрос [дата] на удаление персональных данных, которые мы о вас храним.

**Что мы удалили:**

| Категория | Система | Дата удаления |
|---|---|---|
| [Учётная запись и профиль] | Рабочая система | [дата] |
| [События аналитики] | [Amplitude и т. п.] | [дата] |
| [и т. д.] | | |

**Что мы сохранили и почему:**

| Категория | Причина | Срок хранения |
|---|---|---|
| [Записи о транзакциях] | Юридическая обязанность (хранение налоговых записей, [ссылка на закон]) | [дата] |
| [Резервные копии] | Будут удалены при следующей ротации | [дата] |

**Сторонние обработчики:** мы поручили [список] удалить ваши данные из
их систем.

Ваша учётная запись закрыта. Если у вас есть вопросы, свяжитесь с [контакт по приватности].

Шаг 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 и отметь юридическую границу.

Если понадобится продление, отправь уведомление «нам нужно больше времени» заметно раньше первого срока. Продление в последний день выглядит плохо.

Чего этот скилл не делает

  • Не обращается к системам напрямую. Он проводит по контрольному списку; сами запросы выполняет человек (или подключённый инструмент).
  • Не принимает решения об исключениях в спорных случаях. Он передаёт их юристу.
  • Не отправляет ответ. Черновик, проверка, отправка человеком.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/privacy-legal/skills/dsar-response, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском
---
name: dsar-response
description: >
  Walk through a Data Subject Access Request (or deletion, portability, correction
  request) and draft the response — verify identity, locate data system-by-system,
  assess exemptions, draft the acknowledgment and substantive response letters.
  Use when a DSAR comes in, the user pastes an access/deletion/portability/correction
  request, or says "DSAR came in", "access request", "right to be forgotten", or
  "someone wants their data".
argument-hint: "[paste the request, or describe it]"
---

# /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:

```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.

### Step 3: Locate the data

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

| System | Queried? | 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."

### Step 4: Exemption analysis

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

> **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.

#### Step 5a — Acknowledgment letter template

```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.

#### Step 5b — Substantive response letter templates

**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].
```

### Step 6: Log it

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.

## 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

## 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.

## 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.

Источник: anthropics/claude-for-legal / privacy-legal / dsar-response ↗. Ссылка проверена 2026-10-10.