Как найти передачу данных за рубеж на действующем сайте

Владельцы сайтов часто уверены, что данные посетителей остаются внутри страны: хостинг российский, контракты подписаны, баннер на месте. Но на практике ip-адреса, cookie и параметры поведения могут уходить в иностранные сервисы ещё до того, как человек кликнул «принять». Проблема в том, что трансграничная передача возникает не из-за намерения владельца сайта, а из-за технической логики подключённых инструментов — аналитики, карт, виджетов авторизации и шрифтов.

Для маркетолога это означает одно: нужно проверять не только документы, но и реальное поведение сайта в момент первой загрузки страницы. Именно там видно, какие запросы уходят к внешним доменам и какие из них ведут за пределы России.

Инструменты разработчика показывают сетевые запросы в момент загрузки страницы

Когда передача данных становится трансграничной

Трансграничная передача — это не абстрактная категория из закона, а конкретное событие: данные посетителя покидают территорию России и попадают в сервис, который расположен или хранит информацию за рубежом. Для этого не нужна форма регистрации или личный кабинет. Достаточно, чтобы браузер посетителя отправил запрос к иностранному домену, передав при этом ip-адрес, cookie или параметры страницы.

Разница между передачей внутри страны и передачей за рубеж — в правовом режиме. Трансграничная передача требует основания и уведомления Роскомнадзора заранее. Критерии стран уточнялись отдельной нормой в 265-ФЗ от июля 2026 года, но обязанность уведомлять до начала передачи сохранилась. Это означает, что владелец сайта не может просто включить иностранный сервис и разобраться с документами позже.

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

Какие инструменты чаще всего уводят данные за рубеж

Самые частые источники трансграничной передачи — это не формы сбора контактов, а фоновые подключения, которые запускаются автоматически при загрузке страницы. Аналитические системы, карты, шрифты с внешних CDN, кнопки авторизации через социальные сети, виджеты чата и поддержки — каждый из них может отправлять данные посетителя в момент первого запроса.

Особенность в том, что такие инструменты кажутся безобидными. Маркетолог добавил карту, чтобы показать адрес офиса, дизайнер подключил красивый шрифт, разработчик встроил кнопку входа через аккаунт — и никто не задумался, куда уходят запросы. Но с точки зрения закона каждый такий запрос может создавать риск, если данные покидают Россию до получения согласия.

Ещё один распространённый случай — аналитика, которая стартует раньше, чем посетитель успел кликнуть по баннеру. Технически это означает, что данные ушли до согласия, и вопрос о передаче за границу возникает автоматически, если сервис иностранный.

Проверка сетевых запросов помогает увидеть, какие домены получают данные посетителя

Как проверить сайт на передачу данных самостоятельно

Начните с чистой сессии: откройте сайт в приватном окне браузера, без входа в аккаунт и без сохранённых cookie. Так вы увидите поведение сайта глазами нового посетителя — именно в этом режиме заметно, что запускается до любого согласия.

Откройте инструменты разработчика (обычно клавиша F12) и обратитесь к вкладке «Сеть» или Network. Обновите страницу и посмотрите на список запросов: каждая строка — это обращение браузера к какому-то домену. Часть из них принадлежит вашему сайту, часть — внешним сервисам. Запишите домены, которые выглядят иностранными или незнакомыми.

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

Что проверить в документах

После технической части обратитесь к документам. Откройте политику обработки персональных данных, согласия в формах и оферты. Проверьте, указан ли оператор с полными реквизитами, упомянута ли передача данных третьим лицам, понятен ли объём собираемых данных и цели их использования.

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

В какой последовательности исправлять найденные проблемы

Очерёдность исправлений строится по серьёзности риска, а не по удобству задачи. Первым делом закрывайте то, что уводит данные за рубеж до получения согласия: это самые чувствительные эпизоды и одновременно самые прямые нарушения режима передачи.

Затем настройте cookie-баннер так, чтобы у посетителя был настоящий выбор: кнопка отказа, настройка категорий cookie и запуск трекеров только после явного согласия. Если на баннере есть только «принять всё», предпочтение пользователя не соблюдается, и баннер выполняет декоративную роль.

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

1. Откройте сайт в приватном окне и проверьте, какие запросы уходят до клика по баннеру — вкладка Network в инструментах разработчика покажет список доменов.
2. Запишите внешние домены и выясните, где они расположены — это основа для дальнейшей проверки.
3. Оцените cookie-баннер: есть ли кнопка отказа и настройка категорий, или только «принять».
4. Прочитайте политику обработки и проверьте, названы ли оператор, цели обработки и передача третьим лицам.
5. Составьте список всех сторонних сервисов: аналитика, карты, шрифты, чаты, кнопки входа — каждый может получать данные.
6. Отделите зарубежные сервисы от российских и оцените, есть ли у вас основание для передачи данных за рубеж и уведомлён ли Роскомнадзор.

Исправление рисков требует координации между маркетологом, разработчиком и юристом

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

Трансграничная передача данных — это не формальность и не абстрактный риск. Это конкретное техническое событие, которое можно и нужно проверять регулярно. Маркетолог, который знает, как открыть инструменты разработчика и прочитать список сетевых запросов, получает контроль над тем, что происходит с данными посетителей. Проверка Dobrolex показывает риски на публичных страницах и помогает оценить, что стоит исправить в первую очередь.