Зарубежный сервис на сайте: кто в команде отвечает за риск штрафа

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

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

Маркетологи и разработчик обсуждают внешние сервисы на сайте компании

Почему передача за рубеж ничья

Типичная картина выглядит так. Маркетинг считает, что за код отвечает разработка. Разработка ставит то, что прислали в задаче, и не оценивает юридическую сторону. Юрист видит только политику обработки и текст согласия, но не знает, какие скрипты реально загружаются на странице. Подрядчик уходит, а его счётчики и виджеты остаются на годы.

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

Отдельная ловушка — путать передачу с хранением. Подключённый зарубежный счётчик ещё не означает, что база клиентов лежит за границей. А размещение базы граждан РФ вне России — самостоятельный риск по ч. 8 ст. 13.11 КоАП, где для юрлиц предусмотрено от 1 до 6 млн ₽. Это разные вопросы, и решать их должны разные люди.

Как встроить проверку в подключение сервисов

Самый дешёвый момент для решения — до того, как сервис появился на сайте. Уведомление о трансграничной передаче подаётся до её начала, поэтому вопрос «куда уйдут данные» должен звучать на этапе постановки задачи, а не после релиза. Хорошо работает простое правило: никакой внешний скрипт не попадает в менеджер тегов без короткой карточки.

1. Инициатор описывает, зачем нужен сервис и можно ли обойтись без него.
2. Разработчик фиксирует, к каким доменам обращается скрипт и в какой момент загрузки.
3. Ответственный за персональные данные сверяет сервис с политикой, согласием и поданными уведомлениями.
4. Запуск настраивается после согласия посетителя, если оно требуется.
5. Сервис вносится в общий реестр с указанием владельца и даты подключения.

Для уже работающего сайта нужен первичный перечень. Как его собрать по сетевым запросам браузера в чистой сессии, мы описали в материале про поиск иностранных сервисов на сайте. А мы уже разбирали, как найти передачу на действующем сайте без доступа к коду. Здесь важнее другое: у каждой строки перечня должен появиться человек, который отвечает за решение.

Разработчик проверяет, какие внешние скрипты загружаются на странице

Как говорить о риске с руководителем и подрядчиком

Руководителю не нужен список доменов. Ему нужен ответ на три вопроса: что сайт делает сейчас, какой из этого вытекает риск и сколько стоит его закрыть. Удобно опираться на понятную санкцию: если у обработки нет законного основания, по ч. 1 ст. 13.11 КоАП для юрлиц предусмотрено от 150 до 300 тыс. ₽. Формулировать стоит языком риска: «к этому могут возникнуть вопросы», а не «нас оштрафуют».

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

Отказываться от зарубежного сервиса не обязательно. Обязательно, чтобы кто-то в компании осознанно принял это решение и мог его объяснить.

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

Маркетолог объясняет руководителю риски внешних сервисов на сайте

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