Резидентность данных в ЕС для маркетинговых инструментов: что на самом деле спрашивает ваш DPO

Я изучил множество опросников по безопасности, которые начинаются с одного и того же пункта: «Размещены ли данные клиентов в ЕС? Да / Нет». Вендор ставит галочку «Да». DPO подписывает обзор. Через шесть месяцев тот же DPO замечает, что каждое событие клика маршрутизируется через размещенный в США Meta Pixel и инстанс HubSpot в Калифорнии - оба запускаются в браузере пользователя еще до того, как европейский узел Elido увидит запрос.

Галочка была честной. Но ответ был неполным. Пометка «EU-hosted» на домашней странице вендора описывает, где находятся собственные серверы платформы. Она ничего не говорит о том, что делает с данными прикрепленный к этой платформе маркетинговый уровень, куда они уходят или какое правовое основание покрывает передачу. Именно эти вопросы на самом деле задает DPO, прочитавший GDPR Article 3 и Schrems II.

Этот пост - версия разговора между маркетологом и DPO. Где начинается и заканчивается резидентность данных в ЕС, когда вы используете отслеживание ссылок и пересылку конверсий? Что меняется с юридической точки зрения при переходе от клиентских пикселей к серверным API конверсий? И что на самом деле должно быть в чеклисте для закупок?

Сопутствующий пост - GDPR для сокращателей ссылок - подробно описывает обязательства на уровне статей. Я буду давать на него ссылки, где это уместно, чтобы не повторяться.

Краткое содержание#

• «EU-hosted» относится к плоскости данных вашего вендора. Это не покрывает маркетинговые скрипты на стороне клиента, запускаемые в браузерах ваших пользователей до выполнения редиректа.
• Schrems II и GDPR Articles 44–49 налагают реальные требования на данные, поступающие в размещенные в США рекламные и аналитические платформы. Серверная пересылка конверсий переносит передачу на уровень «сервер-сервер», но не отменяет обязательство по оформлению передачи.
• Article 28(2) требует наличия письменного списка субобработчиков. Пять субобработчиков с указанными регионами - это поддается аудиту; сорок с расплывчатыми записями - это юридическая ответственность.
• Приведенный ниже чеклист по закупкам закрывает большинство вопросов DPO за один ознакомительный звонок.

Правовой стек простыми словами#

Четыре законодательных акта выполняют основную работу. Вы можете цитировать их без юридического образования; номера статей короткие.

GDPR Article 3 - территориальная сфера действия. Article 3(2) применяет GDPR к любой обработке данных субъектов из ЕС контроллером или обработчиком, находящимся за пределами ЕС, если обработка связана с предложением товаров или услуг субъектам из ЕС или мониторингом их поведения. «Мониторинг их поведения» - это отслеживание кликов. Аналитический вендор из США без представительства в ЕС обрабатывает персональные данные субъектов из ЕС каждый раз, когда срабатывает ваш линк с их пикселем. Article 3 гласит, что GDPR применяется к этому вендору независимо от его местонахождения. Вопрос резидентности касается того, куда данные уходят после того, как обязательство по обработке уже возникло.

GDPR Article 28 - обязательства обработчика. Article 28 регулирует договор между контроллером и каждым обработчиком в цепочке. Ваша платформа для сокращения ссылок, ваш аналитический инструмент, ваш почтовый провайдер - каждый должен подписать DPA, который покрывает восемь обязательств от (a) до (h). Вендор, который не предоставляет заранее подписанный DPA, просит вас взять на себя их риски по комплаенсу. Подпункт (2) специально требует, чтобы обработчик получил разрешение контроллера перед привлечением субобработчиков и наложил на этих субобработчиков эквивалентные обязательства по контракту.

GDPR Articles 44–49 - передача данных в третьи страны. Глава V GDPR запрещает передачу персональных данных в третью страну, за исключением случаев, когда применяется один из перечисленных механизмов: решение об адекватности, Стандартные договорные условия (SCCs), Обязательные корпоративные правила или исключения, указанные в Article 49. Для передачи на платформы, размещенные в США, механизмом по умолчанию с момента принятия EU-US DPF в 2023 году являются SCCs, дополненные сертификацией DPF - или сама Рамочная программа по защите конфиденциальности данных между ЕС и США (EU-US Data Privacy Framework), если получатель в США сертифицирован. Ни один из этих механизмов не отменяет необходимость оформления передачи; они описывают, как ее осуществить законно.

Schrems II - CJEU C-311/18. Решение по делу Schrems II аннулировало Privacy Shield в июле 2020 года и установило, что передача данных на основе SCCs требует проведения оценки воздействия на передачу (Transfer Impact Assessment, TIA), чтобы оценить, не лишит ли законодательство страны назначения о слежке субъектов из ЕС эффективных средств правовой защиты. Бремя TIA реально и постоянно. Рамочная программа EU-US Data Privacy Framework, принятая на основании решения Комиссии об адекватности в 2023 году, предоставляет текущий механизм для сертифицированных в DPF получателей в США, но она является предметом ожидающих рассмотрения судебных разбирательств - NOYB заявила о намерении оспорить ее, и рекомендации EDPB по дополнительным мерам (01/2020) остаются актуальным руководством для команд, которым нужен режим передачи, устойчивый к следующему решению по делу Шремса. Покупатели в регулируемых секторах все чаще заключают контракты на обработку данных только в ЕС в качестве структурной защиты от изменений законодательства.

Где маркетинговая аналитика обычно нарушает резидентность в ЕС#

Разрыв между «наш сокращатель ссылок размещен в ЕС» и «наши данные остаются в ЕС» возникает на клиентском маркетинговом уровне. Шесть распространенных точек утечки.

Meta Pixel (на стороне клиента). Стандартная реализация пикселя отправляет GET-запрос из браузера пользователя к connect.facebook.net, точке CDN, обслуживаемой инфраструктурой Meta в США. Этот запрос содержит полный URL (включая ваши UTM-метки), а также IP-адрес пользователя, идентификаторы cookie и фингерпринт браузера. Данные покидают территорию ЕС в браузере пользователя еще до того, как ваш сервер обработает клик. Meta зарегистрирована в Ирландии для целей ЕС и заявляет о законности передачи на основании SCCs. Это утверждение является предметом двух существенных решений DPA (решение ирландского DPA по Facebook Ireland 2022 года и приказ об обеспечении соблюдения SCCs 2023 года). Сам пиксель по-прежнему отправляет данные на серверы в США; правовое основание оспаривается.

Google Tag / GA4 (на стороне клиента). Сниппет gtag.js срабатывает из браузера пользователя и обращается к google-analytics.com и analytics.google.com, которые разрешаются в серверы Google в США, если только вы не настроили маршрутизацию Google Analytics 4 в ЕС с помощью data_collection_endpoint, направленного на region1.google-analytics.com. Даже с конечной точкой в ЕС Google документирует, что некоторая обработка происходит в инфраструктуре США. По умолчанию реализация однозначна: на стороне браузера, размещение в США.

Salesforce CRM. Резидентность данных Salesforce Marketing Cloud зависит от того, в каком «поде» (pod) находится ваш аккаунт. Клиенты из ЕС на европейских подах обрабатывают данные об атрибуции событий кликов в ЕС - если вы настроили это явно. По умолчанию используется американский под с размещением в США. Большинство команд в сегменте малого и среднего бизнеса, которые я видел, не выполнили эту настройку; у них есть инстанс Salesforce, созданный администратором из США на американском поде, который с тех пор пересылает данные CRM субъектов из ЕС через Атлантику.

HubSpot. Пиксели отслеживания электронной почты HubSpot обслуживаются инфраструктурой HubSpot в США. Резидентность данных в ЕС доступна как дополнение для клиентов уровня Enterprise; она не является настройкой по умолчанию. Пиксель отслеживания, который срабатывает, когда контакт открывает маркетинговое письмо, в конфигурации по умолчанию отправляет идентификатор субъекта из ЕС (адрес электронной почты, закодированный в URL пикселя) на конечную точку в США.

Отслеживание открытий писем сторонними сервисами. Помимо HubSpot - Mailchimp, Brevo, Customer.io, ActiveCampaign - применима та же схема. URL-адреса пикселей отслеживания размещаются на CDN провайдера; большинство CDN по умолчанию используют американские PoP (точки присутствия) для исходного трафика; срабатывание пикселя в почтовом клиенте пользователя из ЕС направляется в инфраструктуру США. Опции регионов ЕС существуют в некоторых тарифных планах, но они не включены по умолчанию.

Сам сокращатель как транзит. Если сокращатель ссылок не размещен в ЕС, запрос на перенаправление проходит через инфраструктуру за пределами ЕС. Событие клика логируется за пределами ЕЭЗ. Это именно тот уровень резидентности, для которого предназначена галочка «EU-hosted shortener», и это самая маленькая из шести утечек, так как редирект обычно занимает 2–5 мс, а лог клика - единственные постоянные данные, которые создает сокращатель.

Типичные риски для маркетинговой команды среднего бизнеса, использующей стандартные инструменты: от трех до пяти вышеуказанных сценариев активны одновременно без проведения оценки воздействия на передачу (TIA) для любого из них, а запись в Реестре операций по обработке данных (RoPA) согласно Article 30 называет «Google Analytics, Meta Pixel» без документирования механизма, покрывающего передачу.

Серверное решение: что меняется юридически, а что нет#

Серверная пересылка конверсий - когда европейский узел сокращателя ссылок пересылает события кликов и конверсий в серверный API рекламной платформы вместо того, чтобы позволить браузеру пользователя запустить пиксель - является частичным решением. Вот что это меняет, а что оставляет без изменений.

Что меняется: Браузер пользователя больше не отправляет данные на конечную точку в США напрямую. Путь запроса выглядит так:

1. Пользователь кликает по короткой ссылке
2. Европейский edge Elido (регион ЕС) получает запрос, локально логирует событие клика
3. Европейский узел Elido пересылает сигнал о конверсии по схеме «сервер-сервер» в Meta CAPI / GA4 Measurement Protocol
4. Рекламная платформа получает событие на своем сервере в США

Meta Conversions API - каноническая реализация этой схемы для Meta. GA4 Measurement Protocol - аналог от Google. Браузер пользователя взаимодействует только с европейским узлом Elido; он никогда не обращается напрямую к аналитической конечной точке в США.

Что не меняется: Данные по-прежнему передаются обработчику, размещенному в США. Европейский узел Elido инициирует эту передачу. Обязательство по оформлению передачи согласно Articles 44–49 по-прежнему действует - вам все еще нужно покрытие SCCs или DPF для цепочки с Meta или Google. Что меняется, так это фактический контроль контроллера над этой передачей: она происходит на сервере, которым вы управляете, с использованием ваших учетных данных и с применением хэширования идентификаторов (SHA-256 для адресов электронной почты, как требует Meta CAPI), а не в скрипте браузера, который вы почти не можете контролировать или аудировать.

Это существенное улучшение с точки зрения минимизации данных и безопасности. Это не является полным освобождением от режима передачи данных. Ваш DPO должен четко понимать это различие перед подписанием обзора закупок.

Юридическое последствие серверной пересылки: ваша запись в RoPA согласно Article 30 для «Meta CAPI» теперь документирует передачу «сервер-сервер» под вашим контролем с хэшированием идентификаторов перед тем, как они покинут инфраструктуру ЕС. Это значительно более чистая запись, чем «Meta Pixel - на стороне клиента, инициировано браузером, основание для передачи уточняется». Это не «нулевая передача», а документированная, контролируемая передача.

Статья 28(2): почему количество субобработчиков имеет значение#

Article 28(2) требует, чтобы обработчик получил предварительное разрешение контроллера перед привлечением субобработчиков - либо конкретное (для каждого вендора), либо общее (на основе уведомления с правом на возражение). Каждый серьезный контракт SaaS использует общее предварительное разрешение с 30-дневным окном уведомления. Контроллер подписывает DPA; DPA включает список субобработчиков; добавление в список запускает уведомление и 30-дневное окно для возражений.

Список субобработчиков - это артефакт, который ваш DPO действительно будет читать. Что включает в себя пригодный для использования список:

• Название субобработчика
• Место обработки данных (регион гиперскейлера, а не просто страна)
• Роль в цепочке обработки
• Категории передаваемых персональных данных
• Правовое основание для любой передачи в третьи страны
• Дата добавления
• Канал уведомления о будущих добавлениях

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

Список субобработчиков Elido включает пять вендоров - покрывающих compute и инфраструктуру в ЕС, email в ЕС, платежи и CDN - опубликован по адресу /legal/subprocessors. Это число невелико намеренно. Каждый субобработчик увеличивает площадь поверхности программы конфиденциальности контроллера; каждое добавление субобработчика запускает цикл уведомлений и потенциальное окно возражений. Вендор, который может запустить промышленный сокращатель ссылок на базе пяти субобработчиков, сделал осознанный выбор в отношении обоснованности каждой сторонней зависимости.

Сравните это с платформой маркетинговой аналитики, у которой 35–40 субобработчиков. Список поддается аудиту в принципе; на практике сотрудник по защите данных контроллера проверяет сорок DPA и сорок оценок воздействия на передачу (TIA), некоторые из которых будут отсутствовать. Число в пять вендоров - это не маркетинговое заявление. Это операционный выбор с реальными последствиями для вашей нагрузки по комплаенсу.

Чеклист по закупкам для маркетолога#

Восемь вопросов. Письменные ответы. Если вендор может предоставить их на первом ознакомительном звонке, цикл закупок сокращается на несколько недель. Если нет - это о многом говорит.

1. Каков конкретный регион хостинга для новых данных клиентов на уровне региона гиперскейлера? (Ожидаемый ответ: названный регион в ЕС - например «AWS eu-central-1» или эквивалентный регион дата-центра в ЕС, а не просто «ЕС» как неподкрепленное заявление.)
2. Закреплен ли регион хостинга в ЕС контрактными обязательствами в стандартном договоре с клиентом, или это операционная практика, которую вендор может изменить без уведомления? (Ожидаемый ответ: юридически обязывающее условие, специфичное для стандартного контракта, не требующее специального дополнительного соглашения.)
3. Включает ли стандартный контракт заранее подписанный DPA, покрывающий обязательства согласно Article 28 от (a) до (h)? (Ожидаемый ответ: да, заранее подписан, доступен до завершения звонка по продажам.)
4. Сколько субобработчиков в стандартной цепочке обработки? Может ли вендор назвать их всех с указанием регионов обработки данных? (Ожидаемый ответ: полный список, поименно, с регионами, доступный публично по URL-адресу, который вы можете указать в своем RoPA.)
5. Использует ли вендор серверную пересылку конверсий на рекламные платформы или отслеживание конверсий происходит на стороне клиента в браузере пользователя? (Ожидаемый ответ для вендора, ориентированного на приватность: серверная пересылка с хэшированием идентификаторов до того, как данные покинут инфраструктуру ЕС.)
6. Какая настройка усечения IP-адресов используется по умолчанию для логирования событий кликов? (Ожидаемый ответ: усечение /24 для IPv4, /48 для IPv6 перед сохранением - то есть полный IP-адрес не хранится.)
7. Каков SLA по удалению данных субъектов и достижим ли он операционно для хранилища событий кликов? (Ожидаемый ответ: 30 дней или менее, распространяется на аналитическое хранилище данных, подтверждается вебхуком или сертификатом.)
8. Какими независимыми аттестациями соответствия обладает вендор и когда был закрыт последний аудит? (Ожидаемый ответ: актуальный сертификат ISO 27001; SOC 2 Type II завершен или находится в процессе с целевой датой; для нагрузок, связанных со здравоохранением, наличие BAA в соответствующем тарифном плане.)

Эти восемь вопросов закрывают основные опасения DPO без необходимости юридической экспертизы на этапе ознакомления. Вендор, который отвечает на все восемь вопросов письменно в тот же день, готов к закупке. Вендор, который передает вопрос в юридический отдел, прежде чем ответить на третий вопрос, - нет.

Инструментарий в Elido#

Специфика, для справки.

Привязка региона на уровне воркспейса. Новые воркспейсы по умолчанию создаются в регионе ЕС. Воркспейсы планов Business и Enterprise могут быть привязаны к востоку США или Азиатско-Тихоокеанскому региону для каждого воркспейса. Привязка обеспечивается на уровне маршрутизации - это не настройка в дашборде, которую можно переопределить изменением конфигурации без внесения изменений в контракт на уровне воркспейса. Инфраструктура задокументирована на странице доверия.

Заранее подписанный DPA. DPA в соответствии с Article 28 включен в стандартный договор с клиентом. Для покупателей из ЕС, которым требуется стандартное покрытие по Article 28, не требуется никаких специальных переговоров. Контракты Enterprise с дополнительными правами на аудит, окнами одобрения субобработчиков или индивидуальными условиями хранения обсуждаются отдельно. Стандартный DPA доступен по адресу /legal/dpa.

Список субобработчиков. Опубликован на /legal/subprocessors. Пять вендоров. Добавления запускают 30-дневное предварительное уведомление по электронной почте, а также RSS-канал для мониторинга с помощью инструментов. Право на возражение в течение 30 дней закреплено в контракте, а не является административной процедурой.

Серверная пересылка конверсий. Учетные данные для Meta CAPI, GA4 Measurement Protocol и Mixpanel регистрируются один раз на уровне воркспейса. Elido выполняет хэширование SHA-256 идентификаторов перед исходящим POST-запросом, дедупликацию через поле event_id и логику повторных попыток при временных ошибках на стороне внешних сервисов. Передача осуществляется по схеме «сервер-сервер» из инфраструктуры ЕС; браузер пользователя не обращается к рекламной платформе напрямую.

ISO 27001. Сертифицировано. SOC 2 Type II в процессе, целевой срок - второе полугодие 2026 года. BAA доступны на тарифном плане Business для проектов, связанных со здравоохранением.

Для ознакомления с полным соответствием требованиям: /solutions/compliance - резюме для команд по закупкам.

Чего мы не обещаем#

Этот раздел существует потому, что фраза «резидентность данных в ЕС» часто используется вендорами слишком вольно, и мы не должны этого делать.

Elido - это слой ссылок. Клик, маршрутизируемый через европейский edge Elido, остается в инфраструктуре ЕС на уровне Elido. Событие клика логируется в нашем аналитическом хранилище в регионе ЕС. Сигнал о конверсии, пересылаемый на стороне сервера в Meta CAPI, покидает инфраструктуру ЕС - эта передача происходит от вашего имени, под вашу ответственность как контроллера, и вам необходимо задокументировать ее в своем RoPA и обеспечить соответствующим механизмом передачи.

Если вашей организации требуется, чтобы абсолютно никакие персональные данные субъектов из ЕС ни при каких обстоятельствах не покидали ЕЭЗ - включая этап атрибуции на рекламной платформе - решением не является другой сокращатель ссылок. Решение состоит в том, чтобы вообще не отправлять события конверсий на размещенные в США рекламные платформы. Это бизнес-маркетинговое решение, а не технологическое.

Что дает вам Elido: слой ссылок, который по умолчанию обрабатывает данные о кликах субъектов из ЕС в инфраструктуре ЕС, с задокументированными субобработчиками, заранее подписанным DPA, усечением IP-адресов, серверной пересылкой конверсий с хэшированием идентификаторов и количеством субобработчиков, достаточно малым, чтобы провести аудит за один день. Это полностью закрывает обязательство по резидентности на уровне ссылок.

У вашей платформы email-маркетинга, вашей CRM, ваших рекламных платформ и вашего аналитического хранилища есть своя ситуация с резидентностью. Elido не является решением для них; мы являемся решением для уровня редиректов и атрибуции кликов, и мы не собираемся преувеличивать масштаб.

Материал GDPR для сокращателей ссылок подробно рассматривает обязательства обработчика по статьям, если вы хотите узнать обоснование комплаенса, стоящее за любым из вышеперечисленных решений.

Читать кластер по комплаенсу#

Этот пост является ключевым в треке резидентности кластера по комплаенсу. Смежные посты: GDPR для сокращателей ссылок (обязательства обработчика статья за статьей) и готовящийся пост о Schrems II и пикселях отслеживания (практические последствия атрибуции на уровне браузера). Артефакты страницы доверия и контракты: /trust, /legal/dpa, /legal/subprocessors. Резюме для выбора решений: /solutions/compliance.