GDPR до 25 мая: итоговый технический чек-лист для систем клиентов

Три недели. Именно столько осталось до 25 мая, когда GDPR перестаёт быть темой конференций и становится живым регуляторным инструментом с реальными штрафами. За последние несколько месяцев мы прошли с клиентами через аудит данных, шифрование, процедуры breach notification - и сейчас видим, что картина неоднородная. У части клиентов 80% работы позади, у части - наоборот. Самое время зафиксировать финальный технический чек-лист и понять, что ещё реально успеть.

Реестр обработки - статья 30

Без этого всё остальное висит в воздухе. Record of Processing Activities (RoPA) - это обязательный документ для большинства организаций с обработкой ПДн граждан ЕС. Что туда идёт:

• цели обработки и правовое основание для каждого потока данных (согласие, договор, легитимный интерес - по статье 6);
• категории субъектов и категории данных - без формулировок «прочие»;
• получатели - третьи стороны, которым передаются данные, включая облачных провайдеров и аналитические платформы;
• сроки хранения - не «до достижения целей», а конкретные периоды или критерии удаления;
• технические меры защиты - ссылка на то, что реально реализовано.

Типичная ошибка - RoPA заполняется юристами без участия технической команды и содержит то, как процессы понимает юрист, а не то, как они работают. Обнаруживается это в момент, когда регулятор задаёт конкретный вопрос о потоке данных.

Cookie consent и веб-трекинг

Здесь разрыв между реальным состоянием и требованиями самый заметный. Несколько вещей, которые надо проверить прямо в браузере на своём сайте:

Аналитика до согласия. Google Analytics, Yandex.Metrica, пиксели Facebook - если они грузятся до того, как пользователь нажал «принять», это нарушение. Конкретно: открываем DevTools, идём в Network, чистим историю и загружаем страницу - видим запросы к аналитическим сервисам до любого взаимодействия с баннером согласия? Вот это и нужно исправить.

Отказ должен быть так же доступен, как принятие. Кнопка «Принять все» крупным шрифтом и «Настроить» мелко серым - это не равный выбор. Регуляторы это видят.

Категории по типу назначения. Необходимые, аналитические, маркетинговые, таргетинговые - разделить и дать возможность отключать по группам, а не «всё или ничего».

Хранение согласия. Запись должна содержать дату, версию политики, выбранные категории. Не «галочка в localStorage» без метаданных.

Шифрование и технические меры - статья 32

О деталях мы писали в марте, но для чек-листа ключевые пункты:

• TLS на всех эндпоинтах - включая внутренние сервисы, не только публичные. HTTP внутри периметра под GDPR - это риск, который нужно обосновать или закрыть.
• Шифрование данных в покое - для баз с ПДн. LUKS или TDE в СУБД в зависимости от стека; ключи хранятся отдельно от данных.
• Псевдонимизация в аналитике - если аналитические витрины содержат прямые идентификаторы без необходимости, это точка роста.
• Управление доступом к ПДн - кто конкретно имеет SELECT к таблицам с персональными данными и почему. Принцип минимальных привилегий на уровне СУБД, не только на уровне приложения.

Права субъектов - технический слой

Статьи 15-21 дают субъектам ряд прав: доступ к своим данным, исправление, удаление, ограничение обработки, переносимость. Это звучит как юридические требования, но реализовать их нужно технически.

Право на удаление (статья 17) - самое сложное. Проблема почти всегда не в основной БД, а в том, что данные давно расползлись: резервные копии, аналитические витрины, очереди сообщений, логи, CDN-кеши, данные у третьих сторон. Полного «физического» удаления из всего этого добиться крайне тяжело - GDPR допускает псевдонимизацию как альтернативу удалению в случаях, когда данные нужны для других целей. Но у каждого такого решения должно быть обоснование.

Право на доступ и переносимость - возможность отдать субъекту его данные в машиночитаемом формате (статья 20: «в структурированном, широко используемом и машиночитаемом формате»). Если такого экспорта нет - нужно его реализовать. Минимум: скрипт, который выгружает все данные конкретного пользователя по его идентификатору.

Процедура breach notification

Об этом подробно - в посте про статью 33. Технический минимум для чек-листа:

• Алертинг на аномалии доступа к ПДн - необычный объём выгрузки, доступ в нерабочее время, запросы с нетипичных адресов;
• Логирование с достаточным retention - чтобы в момент обнаружения инцидента можно было восстановить что и когда произошло, а не гадать;
• Зафиксированная цепочка эскалации - кто звонит кому в пятницу в 23:00.

DPA с третьими сторонами

Статья 28 требует заключить Data Processing Agreement с каждым обработчиком данных - то есть с каждым сервисом, которому передаются ПДн граждан ЕС. Это облачные провайдеры, аналитические платформы, CRM-системы, рассылочные сервисы, платёжные шлюзы. Крупные игроки - AWS, Google Cloud, Mailchimp, Salesforce - DPA предоставляют по запросу или уже опубликовали стандартные. Меньшие субподрядчики - вопрос открытый.

Проверить список третьих сторон по RoPA и убедиться, что DPA есть или запрошен - это пункт, который часто «висит» на юристах, но задача технической команды - предоставить актуальный список получателей данных, включая те SDK и пиксели, которые стоят в продукте.

Что реально успеть за три недели

Не всё. Если реестр обработки только начинается, полноценный DPA с каждым субподрядчиком и техническая реализация права на удаление за три недели - нереально. Но есть вещи, которые можно закрыть быстро:

Первое - cookie consent. Баннер с правильной логикой загрузки скриптов - это работа нескольких дней для фронтенда.

Второе - TLS везде. Если HTTP ещё присутствует на каком-то внутреннем сервисе - закрыть.

Третье - зафиксировать то, что уже сделано. Если шифрование и псевдонимизация реализованы, но не задокументированы в RoPA - документировать. Регулятор видит документы, а не код.

Четвёртое - определить DPO или контактное лицо. Даже если формально назначать DPO не обязательно, контакт для коммуникаций с регулятором должен быть определён.

Работаем по аудиту ПДн в режиме предфинального прохода с несколькими клиентами прямо сейчас. 25-е - это не конец, а начало нового режима работы с данными.