Мини-модуль. Data Privacy & Compliance (152‑ФЗ, GDPR, DPIA, PIA, Data Residency)
Цель модуля
Научить участников формализовывать и встраивать требования приватности и комплаенса в ТЗ: классифицировать данные, определять правовые основания обработки, управлять согласием, проводить DPIA/PIA, обеспечивать локализацию/трансграничные передачи, выстраивать процессы по запросам субъектов данных (DSAR) и реагировать на инциденты.
Результаты обучения
Участник умеет:
- Классифицировать данные (PII/спецкатегории/чувствительные) и назначать меры защиты.
- Определять правовые основания обработки (GDPR Art. 6 / 152‑ФЗ) и документировать их.
- Вести реестр операций по обработке (ROPA) и ретеншн‑политику.
- Проводить DPIA/PIA, оценивать риски и согласовывать меры.
- Настраивать процессы DSAR (доступ, удаление, ограничение, переносимость и т. п.).
- Соблюдать data residency (локализация по 152‑ФЗ) и оформлять трансграничные передачи (GDPR: SCC/BCR/adequacy, DTIA).
- Обеспечивать Privacy by Design & by Default в архитектуре данных, пайплайнах и BI.
- Формализовывать метрики и SLA приватности, реагировать на инциденты и вести журнал аудита.
Глоссарий и роли
Ключевые термины
- PII (персональные данные) — любая информация, относящаяся к прямо или косвенно определяемому лицу.
- Специальные категории ПДн (GDPR Art. 9 / 152‑ФЗ) — здоровье, биометрия, политические взгляды и пр.
- Controller / Оператор — лицо, определяющее цели и средства обработки.
- Processor / Обработчик — лицо, обрабатывающее данные по поручению оператора.
- DPO (Data Protection Officer) — ответственный за защиту данных (GDPR).
- ROPA (Records of Processing Activities) — реестр операций обработки.
- DPIA (Data Protection Impact Assessment) — оценка воздействия на защиту данных (GDPR Art. 35).
- PIA (Privacy Impact Assessment) — более широкий/гибкий формат оценки рисков приватности.
- Data Residency — требование локализации хранения/обработки данных.
Роли и ответственность (пример RACI)
|
Процесс / Артефакт |
Оператор (Controller) |
Обработчик (Processor) |
DPO |
ИБ |
Юридическая служба |
Data Steward |
|---|---|---|---|---|---|---|
|
Определение целей обработки |
R |
C |
C |
C |
A |
C |
|
ROPA |
A |
C |
R |
C |
C |
C |
|
DPIA/PIA |
A |
C |
R |
C |
C |
C |
|
DSAR (запросы субъектов) |
A |
C |
R |
C |
C |
C |
|
Уведомления надзорных органов |
A |
C |
R |
C |
R |
C |
|
Локализация / трансграничные передачи |
A |
C |
C |
C |
R |
C |
A — accountable, R — responsible, C — consulted.
Правовые основания обработки (GDPR Art. 6, 152‑ФЗ)
GDPR (минимум фиксируем в ТЗ)
- Consent (согласие) — документируемо, отзыв в любой момент.
- Contract — обработка необходима для исполнения договора.
- Legal obligation — обязательство по закону.
- Vital interests — защита жизненно важных интересов.
- Public task — общественный интерес/власть.
- Legitimate interest — интерес организации, не нарушающий права субъекта (нужен balancing test).
152‑ФЗ (РФ)
- Определение оператора ПДн и согласия субъекта (или иных оснований).
- Локализация ПДн граждан РФ (первичный сбор/запись на территории РФ).
- Уведомление/регистрация в Роскомнадзоре (в ряде случаев).
- Требования к согласиям, обезличиванию, передаче третьим лицам, меры безопасности.
В ТЗ: для каждой сущности/поля PII:
- правовое основание, ссылка на регламент/договор/согласие,
- срок хранения и порядок удаления,
- роли и ответственность.
Инвентаризация и классификация данных
Реестр операций обработки (ROPA)
Минимальные поля:
- Цель обработки.
- Категории субъектов (клиенты, сотрудники, партнёры).
- Категории данных (PII, спецкатегории).
- Правовое основание.
- Получатели (третьи лица / страны).
- Сроки хранения.
- Меры защиты (шифрование, маскирование, RLS/CLS).
- DPIA (нужно/не нужно, статус, дата).
- DPO/ответственные.
Матрица классификации данных (пример)
|
Поле |
Категория |
Основание |
Уровень доступа |
Меры защиты |
Ретеншн |
Ответственный |
|---|---|---|---|---|---|---|
|
PassportNumber |
PII (чувств.) |
Consent / Legal |
Restricted |
Шифрование, маскирование, RLS/CLS |
5 лет |
DPO / ИБ |
|
BirthDate |
PII |
Contract |
Confidential |
Маскирование, TTL |
5 лет |
Data Steward |
|
Region |
Non-PII |
Legit. interest |
Internal |
— |
7 лет |
Product Owner |
Управление согласием и правами субъектов (DSAR)
Согласие
- Форма, дата, цель, правовые основания, способы отзыва.
- Версионирование текстов согласия (чтобы понимать, на какой версии субъект соглашался).
- Double opt‑in (при необходимости).
- Хранение подтверждений (лог, электронная подпись и т. п.).
Запросы субъектов (DSAR) — SLA и процедуры
GDPR: 30 дней на ответ (возможна пролонгация ещё на 60 при сложности).
152‑ФЗ: сроки определяются законом и локальными регламентами (зафиксируйте в ТЗ строго).
В ТЗ фиксируем (минимум):
- Каналы подачи (веб‑форма, email, бумага).
- Проверка личности (KYC/KYB).
- SLA по типам запросов: доступ, исправление, удаление, ограничение, переносимость, возражение, автоматизированные решения.
- Хранение журналов DSAR.
- Исключения: когда удаление невозможно (закон, бухгалтерия, суд и т. п.).
Шаблон реестра DSAR:
| ID | Тип запроса | Субъект | Дата запроса | SLA (дата) | Статус | Решение | Комментарии |
Retention & Deletion (политика хранения и удаления)
Фиксируем:
- Для каждой категории ПДн — срок хранения (закон/внутренняя политика).
- Процесс анонимизации/обезличивания по истечении срока.
- Удаление из бэкапов: политика, сроки, исключения.
- Автоматизация: оркестратор, задания purge/ttl, отчёты о выполнении.
- Аудит: регулярные отчёты о соответствии ретеншн‑политике.
Data Residency & трансграничная передача
152‑ФЗ (локализация)
- Первичный сбор/запись ПДн граждан РФ — на территории РФ.
- Регламентация передачи за рубеж — с учётом требований к защите.
GDPR (трансграничные передачи)
- Механизмы: SCC (standard contractual clauses), BCR (binding corporate rules), адекватность (adequacy decision), DTIA (data transfer impact assessment).
- Schrems II: требуется оценка законодательства третьей страны и доп. меры (технические/организационные).
В ТЗ:
- Указать все страны и механизм передачи данных.
- Приложить DTIA чек‑лист: правовая защита, возможности доступа органов, шифрование end‑to‑end, key management.
- Определить ответственных за мониторинг изменений законодательства.
DPIA / PIA — формальные процедуры
Когда нужен DPIA (триггеры)
- Большой объём ПДн / масштабная систематическая обработка.
- Спецкатегории ПДн / дети.
- Профилирование, автоматизированные решения с юридическими последствиями.
- Трансграничные передачи в страны без адекватности.
- Новые технологии, повышающие риск приватности.
Процесс DPIA (шаги)
- Идентификация обработки: цели, объёмы, категории данных, субъектов, технологии.
- Оценка необходимости и соразмерности (purpose limitation, data minimization, storage limitation).
- Оценка рисков для прав и свобод субъектов.
- Меры снижения: технические (шифрование, псевдонимизация), организационные (политики, обучение).
- Консультация с DPO/надзорным органом (при высоком остаточном риске).
- Решение/подпись (go/no go), план ремедиации.
- Регулярный пересмотр (например, ежегодно или при изменении процесса).
Структура DPIA‑документа (шаблон)
- Контекст и описание обработки.
- Цели и правовые основания.
- Описание данных, субъектов, потоков, архитектуры.
- Оценка необходимости/соразмерности.
- Риски и их вероятность/влияние.
- Меры контроля и их эффективность.
- Остаточные риски и решение.
- План пересмотра.
- Подписи (Controller, DPO, ИБ, Юристы).
PIA vs DPIA
- PIA — более широкий формат; может применяться и вне GDPR (например, корпоративные стандарты приватности).
- DPIA — формально требуемый GDPR инструмент в конкретных случаях повышенного риска.
Privacy by Design & by Default
Закладываем в архитектуру и ТЗ:
- Data minimization — собираем и храним только то, что нужно.
- Псевдонимизация/анонимизация (k‑anonymity, l‑diversity, t‑closeness, DP).
- Шифрование на хранении и в движении (TDE, KMS, TLS 1.2+).
- RLS/CLS в хранилищах и BI.
- Разделение сред (dev/test — без реальных ПДн, только синтетика/обезличка).
- Лимит доступа по умолчанию (deny by default).
- Журналирование и аудит всего доступа к ПДн.
- Автоматические проверки в CI/CD (скрипты, линтеры, stat. analysis на PII‑поля).
Инциденты и уведомления (Breach Response)
GDPR: уведомление надзорного органа — без необоснованной задержки, но не позднее 72 часов после обнаружения, если нарушение может привести к рискам для прав и свобод субъектов. Уведомление субъектов — если риск высокий.
152‑ФЗ: уведомление Роскомнадзора и субъектов ПДн — в сроки и порядке, определённые законом и подзаконной базой (формализуйте во внутренних регламентах).
Внутренние SLA: обнаружение (MTTD), реакция (MTTR), фиксация в журнале, пост‑инцидентный отчёт (postmortem, без поиска виноватых).
Шаблон плана реагирования:
- Обнаружение (кто и как).
- Классификация инцидента (тип ПДн, объём, критичность).
- Изоляция и остановка утечки.
- Уведомления (DPO, ИБ, юристы, надзорные органы, субъекты).
- План ремедиации (устранение уязвимости, закрытие доступа, ротация ключей).
- Пост‑инцидент (уроки, улучшения, обновление ТЗ/процессов).
Договоры и документы
- DPA (Data Processing Agreement) — между оператором и обработчиком (GDPR Art. 28).
- SCC/BCR — для трансграничных передач.
- Joint Controller Agreement — если две стороны совместно определяют цели и средства.
- Политика приватности (Privacy Policy) — публичный документ.
- Политика по куки / трекерам (если применимо).
- Процедуры согласия и withdrawal (отзыва) согласия.
- Уведомления надзорных органов (при необходимости).
Метрики, SLA/SLO и аудит
Метрики (примеры)
- % запросов субъектов (DSAR), выполненных вовремя (цель ≥ 99%).
- Среднее время удаления данных по истёкшей ретенции.
- % систем, где реализована маскировка/шифрование для PII.
- Время отзыва доступа (IAM) — ≤ 4 часов.
- # инцидентов (по категориям), среднее MTTR.
- % процессов, покрытых DPIA/PIA (при необходимости).
- % полей с корректной классификацией (PII/Non-PII).
Аудит и контроль
- Периодические privacy‑аудиты (внутренние/внешние).
- Журналы доступа (WORM, ретеншн ≥ 2 лет).
- Ежегодный обзор/пересмотр DPIA, ROPA, политик ретенции и согласий.
- Тестовые выборки: проверка RLS/CLS, попытки обхода, инъекции.
- Quality gates: запрет релиза без заполненного блока Privacy в ТЗ.
Как это ложится в структуру ТЗ
Добавьте отдельный раздел “Data Privacy & Compliance” (или подробные подразделы внутри НФТ/безопасности):
- Правовые основания и цели (по каждому типу данных).
- ROPA / Каталог операций (ссылка на артефакт).
- Классификация PII / Спецкатегории / Маскирование / RLS/CLS.
- Согласие и DSAR: SLA, процедуры, журнал.
- Retention / Deletion: сроки, автоматизация, отчётность.
- Data residency / Cross-border: страны, механизмы, DTIA.
- DPIA/PIA: триггеры, статус, шаблоны, сроки пересмотра.
- Инциденты и уведомления: SLA, последовательность действий, роли.
- Метрики приватности, аудит и отчётность.
- Артефакты, шаблоны, ответственные (RACI).
Практические примеры (фрагменты формулировок для ТЗ)
Пример 1. Основание и срок хранения
«Поля PassportNumber, BirthDate обрабатываются на основании согласия субъекта (версия 2.1 от 2024‑06‑15) и договора №123. Ретеншн — 5 лет с даты расторжения договора. По истечении периода данные автоматически анонимизируются (маска XXXXXXX####) с формированием отчёта в Confluence и логированием в SIEM.»
Пример 2. DSAR SLA
«Запросы на доступ/удаление персональных данных обрабатываются в течение 30 дней (GDPR) / 30 календарных дней (152‑ФЗ — фиксируем в политике компании). В сложных случаях — до 90 дней с уведомлением субъекта. Регистрация, SLA и статус — в системе ITSM “Privacy Desk”. Аутентификация субъекта — через KYC-процедуру.»
Пример 3. DPIA триггеры
«DPIA требуется при: (1) внедрении модели кредитного скоринга с автоматизированным принятием решений; (2) обработке профилей клиентов для таргетирования рекламы; (3) трансграничной передаче ПДн граждан РФ в страну без адекватной защиты. DPIA пересматривается раз в 12 месяцев или при изменении технологий/целей.»
Пример 4. Data Residency
«Все ПДн граждан РФ записываются первично на серверах в ЦОД РФ. Репликации за рубеж — только в обезличенном виде. Для любых трансграничных передач применяются SCC + DTIA, ключи шифрования хранятся в KMS в РФ.»
Практическое задание
Задача:
На базе вашего ТЗ (или учебного кейса) подготовьте и приложите раздел Data Privacy & Compliance:
- ROPA для минимум 3 операций обработки (таблица).
- Матрицу классификации полей (PII/спецкатегории/маскирование/ретеншн/основание).
- Соглашение по DSAR: SLA, процесс, журнал.
- Политику ретенции + автоматизация удаления/анонимизации.
- Механизм трансграничной передачи (если есть): SCC/BCR/DTIA, данные о странах.
- Шаблон DPIA (и заполните минимум 1 DPIA для обработки с повышенным риском).
- Метрики приватности (SLO/SLA) + кто их измеряет и где мониторим.
- Инцидент‑response план с SLA/ролью/шагами и формой уведомления.
- RACI по приватности (Controller/Processor/DPO/ИБ/Юристы/Data Steward).
Рубрика оценки (макс. 30 баллов)
|
Критерий |
0 |
1 |
2 |
3 |
|---|---|---|---|---|
|
ROPA / Инвентаризация |
Нет |
Частично |
Полный, но без мер защиты/оснований |
Полный, с мерами/основаниями/ретеншном |
|
Классификация данных |
Нет |
Частично |
Есть, но без мер (маскирование, RLS) |
Полная матрица + меры и ответственные |
|
Правовые основания |
Нет |
Частично |
Есть, но без связки с полями |
Полная связка «поле → основание → срок» |
|
DSAR / Согласия |
Нет |
Есть SLA без процесса |
Есть процесс, но без журнала/аудита |
Полный процесс, SLA, логирование |
|
Retention / Deletion |
Нет |
Описано без автоматизации |
Есть автоматизация, но без отчётности |
Полная автоматизация + отчёты + аудит |
|
Data Residency / Cross-border |
Нет |
Частично |
Есть механизм, но без DTIA |
Полный механизм + DTIA + страны/роли |
|
DPIA / PIA |
Нет |
Триггеры без шаблона |
Есть шаблон без примеров/пересмотра |
Полный процесс, пример, пересмотр |
|
Privacy by Design |
Нет |
Частично |
Есть меры, не встроены в CI/CD |
Полная интеграция: RLS/CLS, KMS, CI/CD чекеры |
|
Инциденты и уведомления |
Нет |
Общие слова |
Есть план, но без SLA/форм |
Полный план, SLA, формы, роли |
|
Метрики и аудит |
Нет |
Частично |
Есть метрики без SLO/SLA |
Полный набор SLO/SLA, мониторинг, аудит |
