Российская компания может подпасть под действие GDPR, даже если у нее нет офиса, сотрудников и серверов в Евросоюзе. Риск возникает, например, если SaaS-сервис предлагает интерфейс на языке страны ЕС, принимает оплату в евро, организует доставку в ЕС или системно анализирует поведение посетителей из Союза. Гражданство пользователя здесь не главный критерий: значение имеет то, находится ли человек в ЕС в момент предложения услуг или наблюдения за его поведением.
GDPR — Общий регламент ЕС по защите данных — не отменяет российские требования к персональным данным. Российскому IT-бизнесу нередко приходится одновременно учитывать российское законодательство, условия договоров с заказчиками и нормы GDPR, если продукт ориентирован на пользователей в ЕС или отслеживает их действия.
Когда GDPR касается компании из России
Экстерриториальное действие GDPR закреплено в статье 3 Регламента. Компания без учреждения в ЕС может попасть в сферу его применения в двух основных ситуациях.
Предложение товаров или услуг лицам в ЕС
Сам по себе доступ к сайту из Германии, Франции или другой страны ЕС еще не означает применения GDPR. Важны признаки того, что компания сознательно работает с этим рынком. Среди них:
- локализация сайта или приложения на языки стран ЕС;
- цены в евро или другой валюте государства ЕС;
- маркетинг, направленный на аудиторию в ЕС;
- доставка, поддержка или договорные условия для клиентов из ЕС;
- национальные домены, телефонные номера и локальные каналы продаж;
- привлечение пользователей через представителей или партнеров на территории ЕС.
Например, российский разработчик продает подписку на облачный сервис компаниям из Польши и Чехии, публикует условия использования на английском и польском языках, выставляет счета в евро и запускает рекламу для этих рынков. При такой модели вероятность применения GDPR заметно возрастает.
Мониторинг поведения лиц в ЕС
Вторая типичная ситуация — отслеживание поведения пользователей, находящихся в ЕС. Речь идет не о любом сборе технических логов, а о систематическом анализе действий: профилировании, поведенческой рекламе, формировании сегментов, оценке интересов, использовании cookies и идентификаторов устройств для прогнозирования или анализа поведения.
Отдельной проверки требуют системы аналитики, рекламные пиксели, SDK мобильных приложений и сервисы записи пользовательских сессий. Компании важно понимать, какие данные передаются каждому поставщику, где они хранятся и вправе ли поставщик использовать их в собственных целях.
Почему российской политики конфиденциальности недостаточно
Политика конфиденциальности — только один из необходимых документов. GDPR требует, чтобы обработка была законной, прозрачной, ограниченной конкретной целью и не избыточной. Текст на сайте не устранит проблему, если продукт собирает ненужные сведения, хранит их бессрочно или передает подрядчикам без понятных договорных условий.
Для каждой операции обработки нужно определить правовое основание. На практике чаще всего используют:
- исполнение договора — например, создание аккаунта, предоставление доступа к сервису, обработка платежа;
- законную обязанность — хранение отдельных данных, если этого требует применимое право;
- законный интерес — например, противодействие мошенничеству или обеспечение безопасности, если интересы компании не перевешивают права пользователя;
- согласие — прежде всего для необязательных cookies, маркетинговых рассылок и других процессов, которые нельзя обосновать договором или законным интересом.
Согласие по GDPR должно быть свободным, конкретным, информированным и однозначным. Предварительно отмеченная галочка, общее согласие «на все» или отказ в доступе к основной услуге из-за нежелания получать рекламу могут не соответствовать этим требованиям. Компания должна уметь подтвердить факт и содержание согласия, а его отзыв не должен быть сложнее предоставления.
Какие процессы обычно требуют доработки
| Процесс | Практический риск | Что проверить |
|---|---|---|
| Регистрация в сервисе | Сбор лишних полей | Нужны ли дата рождения, телефон, должность и другие сведения для предоставления функции |
| Cookies и аналитика | Запуск необязательных трекеров до выбора пользователя | Категории cookies, механизм согласия, возможность отказа, перечень получателей данных |
| Поддержка | Передача обращений внешнему helpdesk-сервису | Роли сторон, договор на обработку данных, доступы сотрудников и сроки хранения тикетов |
| Маркетинг | Рассылки без надлежащего основания | Источник контакта, доказательства согласия, отдельная ссылка на отписку |
| Разработка | Доступ подрядчиков к production-данным | Минимизация доступа, тестовые обезличенные наборы, NDA и условия обработки |
Права пользователей и продуктовые сценарии
GDPR дает субъектам данных право запросить доступ к сведениям, исправить неточные данные, получить их копию, возразить против отдельных видов обработки, потребовать удаления в предусмотренных случаях или ограничить обработку. Для цифрового продукта эти права не должны оставаться только в юридическом документе: потребуются рабочие процедуры в службе поддержки, CRM, базе данных, резервных копиях и инструментах аналитики.
Удаление аккаунта не всегда означает немедленное уничтожение всех записей. Часть информации может сохраняться, если это необходимо для исполнения юридической обязанности, разрешения спора или защиты от злоупотреблений. Но срок, основание и объем такого хранения нужно определить заранее, а не оставлять данные «на всякий случай».
Полезно составить карту потоков данных: какие категории сведений собираются, в каких системах они находятся, кто имеет к ним доступ, кому они передаются, в какой стране работает поставщик и каков срок хранения. Она пригодится и при ответе на запрос пользователя, и при due diligence со стороны европейского клиента.
Договоры с клиентами, подрядчиками и облачными сервисами
Если российская IT-компания обрабатывает персональные данные по поручению заказчика из ЕС, она обычно выступает процессором, а заказчик — контролером. В договоре следует разграничить роли сторон и предусмотреть условия, характерные для статьи 28 GDPR: предмет и срок обработки, ее цель, виды данных и категории субъектов, документированные инструкции контролера, конфиденциальность персонала, меры безопасности, порядок привлечения субпроцессоров, помощь с запросами субъектов и аудитами.
Особое внимание стоит уделить цепочке субподрядчиков. Хостинг, облачная инфраструктура, сервис рассылок, инструменты сбора ошибок, платежный провайдер и подрядчик поддержки могут быть субпроцессорами. Заказчика обычно нужно заранее информировать о них и соблюдать предусмотренный договором порядок возражений при смене поставщика.
Договор на разработку или сопровождение ПО должен соответствовать реальной архитектуре продукта. Общая фраза о «соблюдении всех применимых законов» не отвечает на вопрос, кто настраивает cookie-баннер, удаляет данные, уведомляет об инциденте или оценивает новый аналитический модуль.
Трансграничная передача и российская локализация
Передача данных из ЕС в Россию может считаться трансграничной передачей по GDPR. Для нее необходим предусмотренный Регламентом механизм и оценка конкретной структуры обработки. Европейские контрагенты нередко запрашивают договорные гарантии, сведения о технических и организационных мерах защиты, а также понятную информацию о доступе к данным.
Одновременно российской компании нужно учитывать российские правила локализации персональных данных граждан РФ. Инфраструктура в ЕС или договор с иностранным заказчиком не освобождают от обязанности отдельно оценить требования российского права к данным российских пользователей. Архитектура с единой базой для всех может оказаться неудобной и с юридической, и с операционной точки зрения, если не разделить потоки и роли.
Безопасность и инциденты
GDPR не устанавливает единый обязательный набор технологий, но требует мер, соразмерных риску: разграничения прав доступа, многофакторной аутентификации, шифрования, когда оно оправдано, журналирования, резервного копирования, регулярной проверки уязвимостей и обучения сотрудников. Подход должен учитывать характер продукта: требования к сервису заметок и к платформе, обрабатывающей большие массивы идентификационных данных, будут различаться.
При нарушении безопасности персональных данных контролер в ряде случаев обязан уведомить надзорный орган без неоправданной задержки и, если возможно, не позднее 72 часов с момента обнаружения. Процессор должен оперативно сообщить об инциденте контролеру. Поэтому в договоре и внутреннем регламенте стоит закрепить, что считается инцидентом, кто принимает решения, какие сведения собирают в первые часы, кто взаимодействует с заказчиком и как сохраняют доказательства.
Представитель в ЕС и ответственность
Компания без учреждения в ЕС, которая подпадает под GDPR, в ряде случаев должна письменно назначить представителя в ЕС. Исключения возможны, в частности, если обработка носит эпизодический характер, не связана с обработкой специальных категорий данных или данных о судимостях в крупном масштабе и вряд ли создает риск для прав лиц. Формально применять это исключение рискованно: регулярный сервис для европейских пользователей обычно трудно назвать эпизодической обработкой.
Нарушения GDPR могут повлечь предписания, ограничения обработки, требования изменить продуктовые процессы и административные штрафы. Их верхняя граница зависит от состава нарушения и может достигать 20 млн евро или 4% мирового годового оборота группы — применяется более высокая величина. Для российского поставщика последствия часто выражаются и в договорных требованиях, блокировке закупки или отказе европейского клиента от сотрудничества.
Практический порядок проверки
- Определить, есть ли целевое предложение услуг пользователям в ЕС или мониторинг их поведения.
- Составить реестр обработок и карту всех систем, включая внешние SDK, аналитику и облачные сервисы.
- Для каждой цели зафиксировать категории данных, срок хранения, правовое основание и получателей.
- Проверить интерфейсы согласий, формы регистрации, рассылки и механизм исполнения запросов пользователей.
- Пересмотреть договоры с заказчиками, процессорами и субпроцессорами.
- Подготовить процедуру реагирования на инциденты и назначить ответственных.
- Оценить необходимость представителя в ЕС и механизмов трансграничной передачи.
Для небольшого B2B-сервиса практичным первым шагом будет таблица из пяти колонок: система, категория данных, цель, получатель, срок хранения. В нее стоит включить не только основную базу пользователей, но и логи, резервные копии, почтовые сервисы, CRM, аналитику и тестовые среды. Именно эти вспомогательные контуры чаще всего не попадают в описание обработки.
Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию. Применимость GDPR зависит от географии продукта, способов привлечения пользователей, договорных ролей, видов данных и фактической архитектуры обработки.