Трансграничная передача данных на сайте: как найти её до проверки и что исправлять первым
Маркетинг редко спрашивают, куда уходят данные посетителя — об этом вспоминают, когда приходит запрос от клиента или подрядчика, а в проекте уже год работают счётчики, карты и шрифты с внешних домены. Проблема в том, что на готовом сайте этого не видно: страница загружается, баннер согласия показывает текст, отчёты строятся, и ни один отчёт не сообщит, что часть запросов ушла на серверы за пределами России.
Для индустрии это уже не юридическая абстракция, а рабочая задача: маркетолог отвечает за инструменты, разработчик — за их подключение, руководитель — за бюджет работ. Трансграничная передача данных проходит по отдельному контролируемому сценарию, и до начала такой передачи оператору по-прежнему нужно уведомить Роскомнадзор.
Что реально уходит за рубеж и почему это не видно в отчётах
Список типовых сервисов почти одинаков у проекта любого размера: веб-аналитика, карты, веб-шрифты, видеоплееры, доставка контента, кнопки соцсетей, вход через иностранные аккаунты. Каждый такой запрос — это данные посетителя: адрес, cookie-файлы, идентификаторы устройства, иногда значения полей форм. Факт отправки сам по себе не делает сайт нарушителем, значение имеют основание, согласие и соблюдение требований к самому сценарию передачи.
Коварство в моменте времени. Часть запросов стартует в момент отрисовки страницы, то есть до того, как посетитель увидел баннер и что-то выбрал. Баннер регулирует согласие на cookie-файлы, но не закрывает вопрос передачи за рубеж.
Поэтому разговор «давайте поправим политику» начинается не с документа. Сначала фиксируют факты: включая то, какие данные уходят за рубеж при загрузке страницы. Без этой картины любые правки — работа вслепую, потому что непонятно, что именно менять и в каком порядке.
Осмотр страниц глазами нового посетителя: что считать сигналом
Проверка начинается с чистой сессии. Сайт открывают так, как его видит новый посетитель: на незнакомом устройстве или в режиме инкогнито, без ранее сохранённых cookie-файлов и без входа в аккаунт. Так снимается главное искажение — под своим профилем вы видите не то, что видит первый визит.
Дальше работает инструмент разработчика в браузере. Вкладка сетевых запросов показывает, какие внешние домены получают обращения в первые секунды загрузки, какие cookie-файлы устанавливаются, что происходит до нажатия «Принять» и что — после отказа. Здесь важно смотреть не только на сам факт запроса, но и на то, меняется ли поведение трекеров при отказе.
Сетевой обмен браузера — это технический сигнал для дополнительной проверки, а не доказательство нарушения. Он показывает, куда смотреть, но не подменяет ни юридическую оценку, ни внутреннюю документацию проекта. Если самостоятельный осмотр дал слишком много вопросов без ответов, есть смысл сверить наблюдения с тем, как найти следы таких запросов на страницах.
Пока неизвестно, какие данные и куда уходят, любые исправления документов и кода — это перестановка мебели в тёмной комнате: формально работа идёт, а риск остаётся на месте.
Очерёдность исправлений: от документов к коду
Порядок работ лучше выстраивать по принципу «что проверяющий и посетитель видят первым». Начинать удобно с документов: политика обработки данных, согласия в формах, реквизиты оператора. Отсутствие опубликованной политики — отдельный состав: по ч. 3 ст. 13.11 КоАП для юрлиц это штраф от 30 000 до 60 000 ₽.
Затем интерфейс. Баннер cookie-файлов должен давать не только «Принять», но и равнозначный отказ, а также настройку по категориям — аналитика, реклама, функциональные. Иначе посетитель поставлен в ситуацию выбора без выбора, и к этому возникнут вопросы у любой проверяющей стороны.
Только после этого — код. Лишние зарубежные сервисы заменяют или аккуратно отключают, пересматривают сценарии входа через иностранные аккаунты. Тут важна осторожность: часть сервисов отвечает за работу сайта, и грубое отключение что-то сломает в интерфейсе или в отчётности.
- Зафиксировать факты с чистой сессии: внешние домены, cookie-файлы, старт трекеров до согласия.
- Привести в порядок документы: политику обработки данных, согласия в формах, реквизиты оператора.
- Переделать баннер: равнозначный отказ и настройка категорий вместо единственной кнопки «Принять».
- Разобрать каждый зарубежный сервис: заменить, отключить или оставить с понятным основанием.
- Пересмотреть вход через иностранные аккаунты и связанные с ним сценарии.
- Отдельным блоком — уведомление Роскомнадзора там, где оно обязательно.
Как объяснить объём работ руководителю и подрядчику
Самый частый управленческий вопрос звучит так: «У нас что, всё плохо?» Честный ответ — объём сайта ни о чём не говорит. Зарубежные сервисы спокойно стоят и на небольшом проектном сайте, а отсутствие найденных эпизодов означает лишь, что на осмотренных публичных страницах признаков нет. Это не гарантия соответствия закону: закрытые разделы, серверная часть и внутренние процессы остаются вне осмотра.
Второй вопрос — про санкции. Здесь нужна аккуратность в формулировках. Нарушения по этому блоку описаны в КоАП, и диапазоны у разных составов заметно отличаются: обработка без законных оснований или несовместимо с целями сбора по ч. 1 ст. 13.11 КоАП для юрлиц — это штраф от 150 000 до 300 000 ₽. Конкретный исход зависит от состава и обстоятельств, поэтому корректнее говорить о риске, а не о гарантированном штрафе.
Третий вопрос — в каком формате отчитываться. Руководителю нужен не список технических запросов, а приоритеты: что исправлять в первую очередь и какие последствия у бездействия. Именно так устроен разбор Dobrolex: факты о том, что сайт делает на самом деле, серьёзность каждого эпизода и очерёдность исправлений в одном заключении. Отдельно проговорите границы: заключение не заменяет консультацию юриста и не является обращением в Роскомнадзор.
Если в компании тему поднимают впервые, поможет логика предыдущего материала о том, как проверяют старт аналитики до согласия. Там разобрана та же механика осмотра страниц — с неё удобно начать разговор с командой и подрядчиком, чтобы обсуждать не абстрактные риски, а конкретные запросы.
Трансграничная передача данных — это не одна правка в футере, а последовательность решений, где каждое следующее опирается на предыдущее. Сначала команда получает честную картину обмена, затем закрывает документы и интерфейс, и только потом трогает код, понимая, какой сервис чем рискует. Такой порядок экономит и время разработки, и репутацию перед клиентами, а руководитель видит не панику, а управляемый план работ с понятной очерёдностью.