Трансграничная передача персональных данных в 2026

«Мы данные за границу не передаём, у нас всё в России»: так отвечает почти каждый владелец сайта, когда заходит речь о трансграничной передаче. И почти всегда это не так. Передача за рубеж происходит не тогда, когда вы сознательно отправляете базу клиентов иностранному партнёру, а каждый раз, когда страница грузит чужой скрипт и вместе с ним отдаёт данные посетителя на сервер иностранной компании. Аналитика, шрифты, чат, форма, рекламный пиксель: каждый из них потенциальный канал такой передачи. Ниже разберём, что закон считает трансграничной передачей на самом деле, почему «сервер за границей» и «передача за границу» это не одно и то же, какая обязанность возникает перед Роскомнадзором и как за полчаса проверить, не передаёте ли вы данные за рубеж сами того не зная.

Что закон считает трансграничной передачей

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

Из этого следует важный нюанс, который часто упрощают до неверного. «Любой иностранный сервис на сайте, это нарушение»: формулировка некорректная. Состав трансграничной передачи возникает, когда вместе с запросом к иностранному сервису уходят именно персональные данные посетителя: его IP в связке с идентификатором, email из формы, телефон, профиль из соцсети, поведение, привязанное к cookie. То есть когда персональные данные оказываются в составе запроса (payload) к иностранному лицу.

Если же речь о чисто технической связи без персональных данных (страница тянет шрифт или библиотеку с иностранного CDN и при этом не передаёт туда ничего, что идентифицирует человека), это не та ситуация, против которой направлена статья о трансграничной передаче. Грань тонкая: тот же шрифтовой сервис передаёт получателю IP-адрес и заголовки браузера, а IP при определённых условиях сам по себе относится к персональным данным. Поэтому каждый сервис нужно оценивать не по принципу «иностранный или нет», а по вопросу: какие данные посетителя физически уходят к этому иностранному получателю.

И ещё одно разграничение, без которого в теме легко запутаться. Трансграничная передача (статья 12) и локализация (часть 5 статьи 18, введённая 242-ФЗ), это две разные обязанности. Локализация про то, где находится первичная база: данные россиян сначала должны записываться на сервер в России. Трансграничная передача про то, что данные уходят за границу иностранному лицу. Они часто пересекаются на одних и тех же сервисах, но требования и ответственность у них свои. Подробно про локализацию читайте в отдельном разборе про требование локализации по 242-ФЗ; здесь сосредоточимся на передаче.

Где трансграничная передача прячется на обычном сайте

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

Аналитика и счётчики. Самый частый канал. Иностранная система веб-аналитики получает идентификатор посетителя, его поведение на сайте, иногда параметры из URL. Это персональные данные, и уходят они на сервер иностранной компании. Аналитику ставят первой и почти никогда не снимают, поэтому именно здесь передача чаще всего идёт годами незамеченной.

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

Формы, чаты и виджеты. Встроенный чат западного сервиса, иностранный конструктор форм, всплывающее окно с зарубежного домена: всё это собирает контакты посетителя и отправляет их на бэкенд получателя. Здесь уходят уже прямые идентификаторы: имя, телефон, email, текст обращения.

Email-рассылки и CRM. Если сервис рассылок или CRM размещён за рубежом, туда структурированно уходит вся клиентская база: контакты, история, сегменты. Это передача в чистом виде, причём массивом, а не по одному визиту.

Платёжные и встроенные скрипты. Иностранный платёжный виджет получает данные плательщика. Встроенные видео, карты, captcha и подобные элементы тоже подгружаются с иностранных серверов и передают как минимум IP и параметры устройства посетителя.

Хостинг и прокси перед сайтом. Если сайт развёрнут на зарубежном облаке или весь трафик проходит через иностранный прокси-сервис, через него идёт в том числе содержимое форм. Технически это передача данных посетителей иностранному лицу, через инфраструктуру которого проходит запрос.

Объединяет все эти случаи одно: владелец сайта не воспринимает их как «передачу за границу», потому что не делал ничего специального. А с точки зрения закона передача состоялась в тот момент, когда персональные данные посетителя ушли иностранному получателю.

Уведомление Роскомнадзора: его подают заранее

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

Закон устроен так. Уведомление о намерении осуществлять трансграничную передачу подаётся отдельно от обычного уведомления об обработке персональных данных. То есть даже если вы уже уведомили РКН о том, что обрабатываете данные, для передачи за рубеж нужно второе, самостоятельное уведомление. В нём указывают правовое основание и цель передачи, категории и перечень передаваемых данных, категории субъектов и список иностранных государств, куда данные планируется передавать.

Более того, перед подачей уведомления оператор обязан сам получить от иностранного получателя сведения о том, какие меры защиты данных тот применяет. Это требование появилось с поправками, вступившими в силу 1 марта 2023 года: бремя оценки защиты на стороне получателя закон возложил на самого оператора, который передаёт данные.

Дальше логика зависит от страны получателя. Если данные уходят в государство, обеспечивающее адекватную защиту прав субъектов (страны Конвенции Совета Европы или включённые в перечень Роскомнадзора), передачу можно начать после направления уведомления. Если же страна адекватной защиты не обеспечивает, Роскомнадзор рассматривает уведомление и вправе запретить или ограничить такую передачу, и до его решения начинать передачу в эту страну нельзя.

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

Почему это всплывает именно сейчас

Раньше тема трансграничной передачи жила в основном на бумаге: требование было, но контроль за ним точечный. За последние пару лет ситуация изменилась по двум причинам, и обе делают «фоновое» нарушение заметным.

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

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

Сложение этих двух факторов и создаёт типичную ситуацию 2026 года: владелец искренне уверен, что данные за рубеж не передаёт, а фактическая картина его стека говорит обратное и легко проверяется со стороны.

Как проверить, не передаёте ли вы данные за рубеж

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

1. Соберите полный список того, что грузит ваш сайт. Не по памяти, а по факту: откройте инструменты разработчика в браузере (вкладка «Сеть»), перезагрузите страницу и посмотрите, к каким доменам идут запросы. Многие сервисы подключены подрядчиками или остались от прошлых задач, и владелец о них не помнит.
2. Отделите иностранных получателей от российских. По каждому домену определите, кому он принадлежит. Российский сервис, который сам хранит данные в РФ, вопроса трансграничной передачи не создаёт.
3. По каждому иностранному сервису ответьте: уходят ли с ним персональные данные. Аналитика и пиксели передают идентификаторы и поведение, значит да. Формы и чаты передают прямые контакты, да. Шрифт или библиотека без идентификации посетителя, это пограничный случай, оценивайте, что именно отдаётся (как минимум IP и заголовки). Если персональные данные не уходят, состава трансграничной передачи нет.
4. Сверьте с уведомлениями. Если хотя бы один иностранный сервис получает персональные данные посетителей, проверьте, подано ли по нему отдельное уведомление в Роскомнадзор о трансграничной передаче, и подано ли оно до начала передачи.
5. Решите по каждому проблемному сервису. Варианты: заменить на российский аналог, убрать совсем, либо, если передача обоснована и легальна, оформить её по правилам: получить от получателя сведения о защите и подать уведомление.

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

Главная сложность ручной проверки в том, что список подключённых сервисов почти всегда длиннее, чем кажется, и часть из них определить на глаз трудно: непонятно, чей это домен, какие данные и куда он отдаёт. Здесь и помогает автоматическая проверка. Сервис sitelaw проходит по страницам сайта, фиксирует запросы к внешним сервисам, выделяет иностранных получателей и показывает, какие из них создают риск по трансграничной передаче и локализации. Запустить такую проверку и разобраться с требованиями можно на странице проверки по 242-ФЗ: за один проход вы получаете список того, что реально подключено к вашему сайту, вместо догадок.

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

Коротко

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