25 мая 2018 года начинает действовать General Data Protection Regulation. До этой даты – полтора месяца, и времени на раскачку нет. Многие российские компании до сих пор считают, что регламент ЕС их не касается. Это ошибка: GDPR работает по территориальному принципу обработки данных граждан ЕС, а не по месту регистрации оператора. Если вы продаёте товары европейским клиентам, ведёте сайт с приёмом заказов из ЕС или обрабатываете данные сотрудников европейских филиалов – регламент распространяется на вас. Штрафы реальные: до 20 млн евро или 4% мирового годового оборота.

Кого это затрагивает в России

Под действие GDPR попадают три типичные категории. Первая – экспортёры и интернет-магазины, принимающие заказы и платежи из стран ЕС. Вторая – ИТ-компании и интеграторы, которые обрабатывают данные по заказу европейских клиентов, то есть выступают процессорами. Третья – российские подразделения международных групп, где циркулируют данные европейских сотрудников и партнёров.

Важно не путать GDPR с 152-ФЗ. Российский закон вы, скорее всего, уже выполняете, но требования регламента шире: явное и отзываемое согласие, право на удаление и переносимость данных, обязательное уведомление о компрометации в течение 72 часов. Базовый разбор отличий мы давали в материале о готовности к GDPR – теперь к нему добавились финальные требования и сроки.

Что успеть до 25 мая

Действовать нужно по короткому, но жёсткому списку.

  • Инвентаризация данных. Составьте реестр обработки: какие персональные данные собираете, где они хранятся, кому передаёте, на каком основании. Без этой карты остальные шаги бессмысленны.
  • Правовые основания. Для каждого процесса зафиксируйте основание – согласие, договор, законный интерес. Согласие должно быть активным действием, а не предзаполненной галочкой.
  • Реализация прав субъектов. Подготовьте процедуры на запросы доступа, исправления, удаления и экспорта данных. На ответ у вас 30 дней.
  • Процесс реагирования на инциденты. Регламент требует уведомить надзорный орган за 72 часа. Это вопрос не юристов, а архитектуры мониторинга и логирования.
  • Назначение DPO. Если обработка систематическая или крупномасштабная, нужен ответственный за защиту данных.

Отдельно про технику. Регламент прямо называет шифрование и псевдонимизацию как меры по умолчанию (privacy by design). Это требование к архитектуре, а не к политике на бумаге. На монолитных системах сегментировать доступ к данным и изолировать чувствительные потоки сложнее – мы разбирали этот компромисс в сравнении микросервисов и монолита. Сервисная декомпозиция упрощает изоляцию персональных данных и точечное логирование доступа.

Где обычно проваливаются

Типичная ошибка – свести GDPR к обновлению политики конфиденциальности на сайте. Регламент проверяет фактическую обработку, а не декларации. Вторая ловушка – игнорировать субподрядчиков и облачных провайдеров: ответственность за их нарушения остаётся на вас как на операторе, и нужны соглашения об обработке данных (DPA).

Третья проблема – данные, которые компания собирает «про запас» и нигде толком не учитывает. Минимизация данных в GDPR не пожелание, а принцип: храните только то, что нужно для конкретной цели. Здесь стоит трезво оценивать и аналитические инициативы – модели машинного обучения часто требуют больших массивов, и эту потребность придётся согласовывать с принципом минимизации, о чём мы писали в материале про внедрение глубокого обучения в бизнесе.

Вывод

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