Проверка сайта на 152-ФЗ: как найти скрытые внешние передачи через формы, виджеты и аналитику

Каждый сайт с формой обратной связи — потенциальный нарушитель. Вот как это проверить самостоятельно

Введение: почему визуальная проверка сайта вас не спасёт

Представьте: вы открываете свой корпоративный сайт в браузере. Политика конфиденциальности — есть. Форма с галочкой согласия — есть. Хостинг — российский. Казалось бы, всё в порядке. Но в этот момент браузер пользователя уже отправил его IP-адрес, параметры устройства и поведение на странице в дата-центр в Вирджинии — через счётчик Google Analytics, который поставил разработчик три года назад.

Это не гипотетический сценарий. По оценкам специалистов, проводивших аудиты в разных нишах — от клиник до интернет-магазинов, — около половины нарушений 152-ФЗ скрыты именно на техническом уровне [5]. Владелец сайта о них не знает, потому что они не видны при визуальном осмотре: они живут в коде, в интеграциях, в скриптах сторонних библиотек.

С 30 мая 2025 года вступили в силу новые штрафы по статье 13.11 КоАП РФ [6], а с 1 июля 2025 года начала действовать обновлённая редакция статьи 18 закона 152-ФЗ, ужесточившая требования к локализации первичного сбора данных [1]. Роскомнадзор перешёл к автоматическому мониторингу сайтов с применением ИИ, который работает 24/7 без уведомления владельцев [2].

Эта статья — практическое руководство. Она объясняет, как технически находить скрытые внешние передачи через формы, виджеты и аналитику, какие инструменты для этого использовать и как интерпретировать результаты с точки зрения требований 152-ФЗ.

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

Часть 1. Что закон считает «передачей данных» на сайте

Что такое персональные данные применительно к сайту

Большинство людей думает о персональных данных как о паспортных данных или ФИО. Однако применительно к сайтам к персональным данным относятся также: IP-адреса устройств, через которые совершается выход в интернет; идентификаторы cookies; параметры браузера и устройства; данные о геолокации [7]. Это означает, что любой сайт, на котором установлен хотя бы один счётчик аналитики или маркетинговый пиксель, фактически собирает персональные данные пользователей.

Закон 152-ФЗ относит к персональным данным «любую информацию, относящуюся к прямо или косвенно определённому или определяемому физическому лицу» [8]. Косвенная идентификация через совокупность признаков — IP + браузер + геолокация + поведение — вполне достаточна для признания данных персональными.

Трансграничная передача: что изменилось в 2025 году

До 1 июля 2025 года российские компании могли собирать персональные данные граждан РФ в России, а затем передавать их за рубеж при наличии уведомления в Роскомнадзоре и соблюдении ряда условий. Многие этим пользовались: Google Analytics технически собирал данные за рубежом, но компании подавали уведомление и считали себя в безопасности.

С 1 июля 2025 года ситуация изменилась принципиально. Поправки к части 5 статьи 18 закона 152-ФЗ закрепили принцип «сначала локально»: при сборе персональных данных граждан РФ первичная запись должна происходить в базах данных, физически расположенных на территории России [1]. Только после этого данные могут быть переданы за рубеж — при наличии разрешения РКН и в установленном порядке.

На практике это означает: если при заполнении формы на вашем сайте данные пользователя сначала уходят на сервер Google в США — это нарушение, даже если потом те же данные попадают в российскую CRM. Важен факт первичной записи.

Разъяснения Роскомнадзора от 24.03.2025 № 08-134789 и Минцифры от 12.05.2025 № П25-44929 уточнили: ограничения не распространяются на трансграничную передачу персональных данных, ранее собранных в базы данных на территории России [1]. То есть «запрета на экспорт» как такового нет — есть запрет на то, чтобы первичный сбор происходил за рубежом.

Автоматическая передача: как это происходит без вашего ведома

Ключевая проблема в том, что большинство передач данных происходит автоматически — без какого-либо явного действия оператора сайта. Вот три основных механизма:

Первый механизм — JavaScript-скрипты третьих сторон. Когда браузер пользователя загружает страницу вашего сайта, он также загружает и исполняет все внешние JavaScript-скрипты, подключённые к странице. Каждый такой скрипт — Google Analytics, Facebook Pixel, Hotjar, LiveChat — работает в браузере пользователя и может отправлять данные на свои серверы напрямую, минуя ваш сервер. Вы как оператор сайта физически не участвуете в этой передаче — она происходит между браузером пользователя и зарубежным сервером [3].

Второй механизм — встроенные формы и виджеты. Если на вашем сайте используется форма, созданная во внешнем сервисе (Google Forms, Typeform, JotForm), или виджет обратного звонка, чат-бот или форма подписки от зарубежного email-провайдера (Mailchimp, SendGrid) — данные пользователя при заполнении уходят сразу на серверы этого сервиса, нередко за рубеж [3].

Третий механизм — пиксели и трекеры. Пиксели социальных сетей (Facebook Pixel, до блокировки), рекламные трекеры, системы записи поведения пользователей (Hotjar, FullStory) отправляют данные о каждом посещении страницы, каждом клике и каждом заполнении формы на внешние серверы [9].

Часть 2. Карта типичных нарушителей: что именно передаёт данные

Аналитика

Google Analytics (включая GA4) — наиболее распространённый пример нарушения. При загрузке страницы, оснащённой счётчиком Google Analytics, браузер пользователя отправляет на серверы Google в США: IP-адрес, параметры устройства, версию браузера, геолокацию, поведение на странице [10]. Роскомнадзор ещё в 2022 году признал Google Analytics инструментом трансграничной передачи данных [11], а с января 2025 года начал направлять компаниям уведомления с требованием удалить его с сайтов [11].

Google Tag Manager (GTM) создаёт дополнительную сложность: само по себе его присутствие на сайте не означает нарушения, однако через GTM может быть подключён Google Analytics или другие запрещённые счётчики, причём это не всегда видно из исходного кода страницы — конфигурация тегов загружается динамически [12].

Hotjar, Yandex.Metrika в зависимости от настроек, FullStory, Mixpanel, Amplitude — все эти сервисы требуют проверки: где расположены их серверы и подпадают ли они под требования локализации.

Яндекс.Метрика хранит данные на российских серверах и, по общему мнению специалистов, соответствует требованиям локализации [13]. Однако её присутствие на сайте должно быть задекларировано в политике конфиденциальности — именно за отсутствие этого упоминания одна из компаний получила предписание от РКН [5].

Виджеты и встроенные элементы

Виджеты мессенджеров — кнопка WhatsApp, всплывающий виджет Telegram — при нажатии или даже при простом отображении на странице могут передавать параметры пользователя на серверы соответствующих платформ [3]. С 1 июля 2025 года такие виджеты при наличии передачи данных попадают под действие требований о локализации.

Google reCAPTCHA при каждой проверке пользователя («я не робот») отправляет в Google данные о поведении пользователя, cookies, IP-адрес и ряд параметров браузера [14]. Альтернативы с российскими серверами — решение от CloudPayments и ряд других [14].

Онлайн-консультанты и чат-боты: JivoSite, Tidio, Intercom, Zendesk Chat — сервисы, у которых серверная инфраструктура расположена за рубежом, передают данные пользователей (включая историю переписки) на зарубежные серверы [3].

Карты и геолокация: встроенные карты Google Maps при каждой загрузке фрагмента с картой передают данные пользователя в Google. Яндекс.Карты при аналогичном использовании хранят данные в России.

Формы и email-маркетинг

Формы на Google Forms: данные, введённые пользователем, сразу сохраняются в Google Sheets или Google Drive — фактически первичный сбор происходит на серверах Google [10].

Формы в конструкторах сайтов: если ваш сайт создан на Tilda, Wix, Webflow или аналогичных конструкторах с зарубежной инфраструктурой, следует проверять, куда уходят данные из встроенных форм — на серверы конструктора или на ваш собственный сервер [5].

Email-рассылки через Mailchimp, SendGrid, GetResponse: если данные подписчика при заполнении формы сразу попадают в эти сервисы — это прямая передача на зарубежные серверы [3].

Корпоративная почта на Gmail: если заявки с сайта приходят на Gmail-адрес менеджера, они хранятся на серверах Google — это потенциальная трансграничная передача персональных данных [15].

CDN и библиотеки

Многие сайты подключают JavaScript-библиотеки (jQuery, Bootstrap, Font Awesome) не со своего сервера, а с CDN (Content Delivery Network) — в частности, с cdnjs.cloudflare.com, cdn.jsdelivr.net или googleapis.com. Само по себе использование CDN для библиотек не передаёт персональные данные пользователя, однако это создаёт зависимость от зарубежной инфраструктуры, которую необходимо учитывать при оценке рисков.

Часть 3. Как технически обнаружить скрытые передачи: пошаговая инструкция

Инструмент 1: DevTools браузера — вкладка Network

Это самый доступный инструмент, не требующий установки дополнительного программного обеспечения. Он встроен во все современные браузеры (Chrome, Firefox, Edge).

Порядок действий:

Откройте браузер Chrome и перейдите на страницу вашего сайта, которую хотите проверить. Нажмите F12 или правой кнопкой мыши выберите «Просмотр кода» → вкладка «Network» («Сеть»). Перезагрузите страницу нажатием Ctrl+R (или Cmd+R на Mac) — при этом панель должна быть открыта, чтобы зафиксировать все запросы с момента загрузки.

В панели Network вы увидите все HTTP-запросы, которые браузер выполнял при загрузке страницы. Теперь ищите подозрительные запросы. Нажмите на строку поиска (иконка лупы) и введите по очереди: google-analytics.com, googletagmanager.com, google.com, facebook.net, facebook.com, hotjar.com, mailchimp.com, amazonaws.com, cloudflare.com. Если на запрос по какому-либо домену есть ответ — данные туда передаются.

Особое внимание уделите колонке «Initiator» («Инициатор»): она показывает, какой скрипт инициировал запрос. Это позволяет понять, какой именно сторонний сервис стоит за передачей.

Проверьте не только главную страницу, но и страницы с формами: страницу контактов, страницу заказа, страницу подписки. При заполнении формы перейдите на вкладку Network и посмотрите, куда уходит POST-запрос при отправке.

Инструмент 2: просмотр исходного кода

Комбинация Ctrl+U (Cmd+U на Mac) открывает исходный HTML-код страницы. Используйте поиск по странице (Ctrl+F) и ищите следующие ключевые строки: google-analytics, gtag, googletagmanager, fbq (Facebook Pixel), hotjar, jivosite, intercom, freshchat, mailchimp, sendgrid, recaptcha, googleapis.com, cdn.jsdelivr.net, cloudflare.

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

Обратите внимание: Google Tag Manager (gtag или googletagmanager.com) является «контейнером», который может содержать десятки других тегов, недоступных из исходного кода страницы. Его наличие требует дополнительной проверки через вкладку Network.

Инструмент 3: браузерные расширения

Privacy Badger (Electronic Frontier Foundation) — бесплатное расширение для Chrome и Firefox, которое автоматически обнаруживает и блокирует трекеры сторонних сервисов. Визуально показывает список всех трекеров на странице.

uBlock Origin с включённым журналом запросов — расширение для блокировки рекламы и трекеров. В режиме «расширенный пользователь» показывает все исходящие запросы к сторонним доменам.

Blacklight от The Markup — онлайн-инструмент (themarkup.org/blacklight), который анализирует сайт по URL и выдаёт детальный отчёт о трекерах, пикселях и утечках cookies. Не требует установки — достаточно ввести адрес сайта.

Инструмент 4: анализ cookies

В DevTools перейдите в раздел Application (Приложение) → Cookies. Здесь отображаются все cookie, установленные на текущей странице. Обратите внимание на cookies от сторонних доменов (например, _ga от google-analytics.com, _fbp от facebook.com, _hjid от hotjar.com). Каждый такой cookie означает, что соответствующий сервис получил данные пользователя.

Важный нюанс: технические cookies (session, csrf-token, auth-cookie) персональными данными не являются, однако аналитические и рекламные cookies — в совокупности с другими данными — могут использоваться для идентификации пользователя [16].

Инструмент 5: проверка при заполнении форм

Этот шаг критически важен, потому что многие передачи данных происходят именно в момент отправки формы, а не при загрузке страницы.

Откройте страницу с формой. Откройте DevTools → вкладка Network. В строке фильтра выберите тип XHR или Fetch — это покажет только AJAX-запросы. Заполните форму тестовыми данными (например, «test@test.ru», «9999999999») и нажмите «Отправить». В панели Network появятся новые запросы — это запросы, которые были инициированы отправкой формы. Проверьте, на какие домены они уходят.

Если данные уходят на mailchimp.com, us-east-1.amazonaws.com, api.salesforce.com или аналогичные зарубежные адреса — это прямая передача персональных данных на зарубежные серверы.

Инструмент 6: сканеры уязвимостей и комплексные инструменты

Для более глубокого анализа используются специализированные инструменты. Burp Suite Community Edition — профессиональный инструмент для анализа HTTP-трафика: перехватывает все запросы между браузером и серверами, позволяет детально анализировать, что именно передаётся и куда [17]. Бесплатная версия подходит для ручного аудита. OWASP ZAP (Zed Attack Proxy) — бесплатный открытый аналог с похожими возможностями.

Для тех, кто не готов работать с этими инструментами вручную, существуют онлайн-сервисы типа 152DOC, которые автоматически сканируют сайт на предмет нарушений и формируют рекомендации [18].

Часть 4. Что делать с результатами проверки: интерпретация и приоритизация

Что проверяет РКН автоматически

Роскомнадзор при автоматическом мониторинге фиксирует: наличие и доступность политики обработки персональных данных; наличие и видимость cookie-баннера; факт подключения сторонних скриптов (аналитика, пиксели); данные о хостинге через WHOIS и IP-геолокацию [16]. Важно понимать: автоматический мониторинг фиксирует факт подключения стороннего сервиса, но не оценивает корректность правового основания — это делается уже при полноценной ручной проверке [16].

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

Матрица рисков: что опасно, что допустимо, что требует оформления

Высокий риск (требует немедленного устранения или замены):

• Google Analytics без уведомления в РКН, любой первичный сбор данных на зарубежные серверы [10]
• Формы, данные из которых напрямую уходят в Mailchimp, Hubspot, Salesforce с зарубежными серверами
• Чат-боты и виджеты с первичной обработкой за рубежом
• reCAPTCHA без альтернативного решения

Средний риск (требует уведомления РКН и документального оформления):

• Зарубежные CRM, если первичный сбор происходит в России, а затем данные передаются за рубеж [1]
• Сервисы с серверами в «безопасных» странах (ЕАЭС, БРИКС) [19]
• Видеоконференции и мессенджеры при передаче чувствительных пользовательских данных

Допустимо при соблюдении условий:

• Яндекс.Метрика (серверы в РФ, необходимо упоминание в политике) [13]
• VK Pixel (серверы в РФ) [20]
• Российские CRM и SaaS-сервисы с серверами в РФ
• CDN для JavaScript-библиотек без передачи персональных данных

Приоритет исправлений

На практике рекомендуется следующий порядок действий:

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

Второй этап — оценка и классификация. Для каждого обнаруженного сервиса определить: передаются ли персональные данные, где расположены серверы, есть ли уведомление в РКН, упомянут ли сервис в политике конфиденциальности.

Третий этап — устранение нарушений. Заменить сервисы с высоким риском на российские аналоги. Для сервисов среднего риска подать уведомление в РКН о трансграничной передаче. Обновить политику конфиденциальности с указанием всех используемых сервисов.

Часть 5. Российские альтернативы: чем заменить

Аналитика

Яндекс.Метрика — полноценная замена Google Analytics с хранением данных на российских серверах. Имеет тепловые карты, вебвизор, воронки конверсий, поддерживает интеграцию с Яндекс.Директом [13]. Бесплатна.

Roistat, CoMagic, Calltouch — российские системы сквозной аналитики, которые хранят данные в РФ [13].

Matomo (self-hosted) — открытое программное обеспечение для веб-аналитики, которое можно развернуть на собственном сервере в России. Функционально сопоставимо с Google Analytics [14].

Формы и обратная связь

Для сбора заявок рекомендуется использовать формы, написанные непосредственно на сайте, с отправкой данных на российский backend. Альтернативно — использование форм в российских конструкторах с российской инфраструктурой.

Email-рассылки

Unisender, SendPulse, DashaMail — российские сервисы email-маркетинга с серверами в РФ.

Корпоративная почта

Замена Gmail на Яндекс.Почту для бизнеса или Mail.ru для бизнеса решает проблему хранения переписки и заявок с персональными данными на зарубежных серверах.

CAPTCHA

Капча от CloudPayments и ряд других российских решений могут заменить Google reCAPTCHA [14].

Часть 6. Ошибки и риски при самостоятельной проверке

Типичные ошибки при аудите

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

Игнорирование Google Tag Manager. GTM — это «чёрный ящик»: из исходного кода страницы видно только его присутствие, но не то, какие теги в нём настроены. Необходимо отдельно проверять конфигурацию GTM — либо через доступ к аккаунту GTM, либо через анализ сетевых запросов при загрузке страницы.

Игнорирование мобильной версии и AMP. Мобильная версия сайта или AMP-страницы могут иметь отдельный набор скриптов, отличный от десктопной версии. Проверку нужно проводить на обеих версиях.

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

Неучтённые интеграции с CRM. Если ваш сайт интегрирован с CRM через API, данные из форм могут уходить в CRM напрямую. Нужно проверять, где расположены серверы CRM и через какой механизм передаются данные.

Юридические ловушки

Неполная политика конфиденциальности — одна из самых распространённых причин претензий РКН. Достаточно не упомянуть Яндекс.Метрику или VK Pixel, которые реально используются, и предписание гарантировано [5].

Несоответствие между политикой и уведомлением в РКН. РКН сверяет перечень сервисов, указанных в политике конфиденциальности, с тем, что указано в уведомлении оператора. Расхождение — основание для замечания.

Согласие, встроенное в другой документ. С 1 сентября 2025 года согласие на обработку персональных данных должно быть оформлено как самостоятельный документ — встраивать его в пользовательское соглашение или политику конфиденциальности запрещено [21].

«Молчаливое согласие» через предустановленные галочки. Предустановленная галочка в форме не является действительным согласием. Пользователь должен поставить её самостоятельно.

Часть 7. Кейсы и реальные примеры нарушений

Кейс 1: Компания из Твери

Компания получила уведомление о нарушении 152-ФЗ. Причина оказалась двойной: отсутствие галочки согласия на обработку персональных данных в форме обратной связи, а в политике конфиденциальности не упоминалась Яндекс.Метрика, которая реально использовалась на сайте. РКН дал 10 рабочих дней на исправление. При дополнительном аудите обнаружилось ещё несколько несоответствий [5].

Кейс 2: Масштабная проблема с GTM

Ряд компаний, удаливших Google Analytics, оставили на сайте Google Tag Manager. Технически GTM сам по себе может не нарушать требования, если в нём настроены только безопасные теги. Однако на практике через GTM нередко продолжал работать Google Analytics — что РКН фиксировал при проверке [12].

Кейс 3: Скрытая интеграция подрядчика

Несколько компаний столкнулись с тем, что сайт был сделан подрядчиком, который по умолчанию подключал удобные ему зарубежные сервисы — чат, форму обратной связи, аналитику. Владелец бизнеса об этом не знал. Ответственность за нарушение при этом несёт оператор персональных данных — то есть сам бизнес, а не подрядчик [3].

Часть 8. Тренды и что будет дальше

Автоматизация надзора

Роскомнадзор перешёл к ИИ-мониторингу сайтов, который работает без предупреждения и без участия инспектора [2]. Это означает, что случайные нарушения будут находиться с той же вероятностью, что и системные. Жалобы от конкурентов — ещё один механизм инициирования проверки: РКН обязан реагировать даже на анонимные обращения [19].

Оборотные штрафы за повторные утечки

С 30 мая 2025 года за повторную утечку персональных данных введены оборотные штрафы: от 1% до 3% от годовой выручки, но не менее 20 млн рублей [22]. При этом максимальный штраф за массовую утечку может достигать 500 млн рублей [22]. Это принципиально меняет экономику вопроса: для крупных компаний несоблюдение требований может стоить сотни миллионов.

Расширение требований к согласию

Поправки к статье 9 закона 152-ФЗ, вступившие в силу с 1 сентября 2025 года, запретили совмещать согласие на обработку персональных данных с другими документами [21]. Каждый оператор должен иметь отдельный документ согласия — как физически отдельный элемент интерфейса, а не галочку в оферте.

Государственная система обезличивания

По поручению Правительства РФ в России создаётся государственная система обезличивания персональных данных — «озеро данных», начавшее работу с сентября 2025 года [23]. Компании, работающие с большим объёмом данных, должны разобраться с интеграцией в эту систему. Подробности данных о фактическом запуске и требованиях к моменту написания статьи в полной мере не представлены в открытых источниках.

Часть 9. Практический чек-лист для аудита сайта

Технические проверки:

• Открыть DevTools → Network и проверить все внешние запросы при загрузке каждой ключевой страницы
• Отдельно проверить запросы при отправке каждой формы
• Проверить исходный код на наличие скриптов сторонних сервисов
• Установить и запустить Privacy Badger или uBlock Origin, посмотреть список заблокированных трекеров
• Использовать Blacklight (themarkup.org/blacklight) для быстрого сканирования
• Проверить конфигурацию GTM (если он используется)
• Проверить cookies в разделе Application → Cookies в DevTools
• Проверить мобильную версию сайта отдельно

Юридические проверки:

• Убедиться, что политика конфиденциальности содержит перечень всех реально используемых сервисов аналитики и маркетинга
• Убедиться, что согласие на обработку ПДн оформлено как самостоятельный элемент, пользователь ставит галочку самостоятельно
• Убедиться, что подано уведомление в Роскомнадзор об обработке персональных данных
• Если используются зарубежные сервисы — проверить наличие уведомления о трансграничной передаче
• Убедиться, что политика соответствует тому, что указано в уведомлении в РКН
• Согласие на обработку ПДн — отдельный документ (с 01.09.2025)
• Cookie-баннер предлагает реальный выбор, «принять всё» не является единственным вариантом

Организационные проверки:

• Провести инвентаризацию всех интеграций — что подключено, кем и когда
• Запросить у подрядчиков полный перечень используемых ими сервисов при разработке вашего сайта
• Назначить ответственного за соблюдение требований в части персональных данных
• Установить регулярность аудита — не реже раза в квартал

Заключение: от разовой проверки к постоянному контролю

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

Принцип «проверить один раз и забыть» в реальности не работает. Именно поэтому профессиональное сообщество всё активнее говорит о необходимости непрерывного мониторинга потоков персональных данных, а не разовых аудитов.

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

Один из подходов к решению этой задачи — платформа Пятый фактор. Это on-prem система для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: базах данных, хранилищах, почте, AD/LDAP, CRM, 1С, API. Ключевая особенность, которая делает её безопасной для внедрения, — работа только с метаданными, структурой и агрегатами без передачи и хранения сырых значений персональных данных. Таким образом, сам инструмент контроля не становится дополнительным источником риска.

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

Штрафы растут, требования ужесточаются, а ИТ-ландшафт компаний постоянно меняется. В этих условиях контроль персональных данных должен быть процессом, а не событием.

Источники

[1] Comply.ru — Локализация и трансграничная передача персональных данных. Что изменилось с 1 июля 2025 года — https://comply.ru/tpost/c43ezsout1-lokalizatsiya-i-transgranichnaya-peredac

[2] Klerk.ru — Роскомнадзор и проверка сайтов: как мониторят, на что смотрят и как не нарушить закон — https://www.klerk.ru/blogs/data-sec/677999/

[3] Roskom24.ru — Что запрещено на сайте с 1 июля 2025 — https://roskom24.ru/chto_zapreshcheno_na_sayte_s_1_iyulya_2025/

[4] Comply.ru — Штраф за несоблюдение требования о локализации (ч. 8 и 9 ст. 13.11 КоАП) — https://comply.ru/tpost/c43ezsout1-lokalizatsiya-i-transgranichnaya-peredac

[5] VC.ru — Как РКН проверяет сайты на соответствие ФЗ 152: полный гайд — https://vc.ru/marketing/2264701-avtomaticheskaya-proverka-saytov-roskomnadzora

[6] КонсультантПлюс — Персональные данные: новые штрафы с 30 мая 2025 года — https://www.consultant.ru/legalnews/28492/

[7] HostInside.ru — Проверка сайта на 152-ФЗ — полное руководство 2025 — https://hostinside.ru/blog/152fz/

[8] КонсультантПлюс — Федеральный закон «О персональных данных» от 27.07.2006 N 152-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_61801/

[9] Riverstart.ru — Разбор поправок в 152-ФЗ: новые требования к персональным данным с 30 мая 2025 — https://riverstart.ru/blog/novyie-trebovaniya-kpersonalnyim-dannyim-v2025-pravila-rabotyi-dlya-biznesa-s152-fz

[10] VC.ru — Запрет на передачу персональных данных за пределы РФ: запрещён ли Google Analytics и что с ним делать — https://vc.ru/marketing/2153541-zapret-na-google-analytics-v-rossii

[11] VC.ru — С 1 июля 2025 Google аналитику запрещено использовать на российских сайтах. Правда или миф? — https://vc.ru/marketing/2036972-zapret-google-analitiki-v-rossii-s-1-iyulya-2025-goda

[12] DHPrime.ru — У вас на сайте Google Analytics? Ждите Роскомнадзор насчет трансграничной передачи данных — https://dhprime.ru/blog/articles/u-vas-na-sayte-google-analytics-zhdite-roskomnadzor-naschet-transgranichnoy-peredachi-dannykh/

[13] VC.ru — Запрет на передачу персональных данных: альтернативы Google Analytics — https://vc.ru/marketing/2153541-zapret-na-google-analytics-v-rossii

[14] Klerk.ru — С 1 июля 2025 Google аналитика, формы, капча, WhatsApp и Telegram на сайте — под запретом — https://www.klerk.ru/blogs/roskom24/652336/

[15] HostInside.ru — Зарубежные почтовые сервисы как источник трансграничной передачи ПДн — https://hostinside.ru/blog/152fz/

[16] Ads-soft.ru — Аудит сайта по 152-ФЗ: как подготовиться к проверке Роскомнадзора и снизить риски — https://ads-soft.ru/articles/audit-sayta-po-152-fz-kak-podgotovitsya-k-proverke-roskomnadzora-i-snizit-riski/

[17] Practicum.yandex.ru — Burp Suite для тестирования безопасности веб-приложений — https://practicum.yandex.ru/blog/burp-suite-ustanovka-i-nastrojka/

[18] E-office24.ru — Трансграничная передача персональных данных: новые требования — https://e-office24.ru/news/transgranichnaya-peredacha-personalnykh-dannykh/

[19] Klerk.ru — Требования Роскомнадзора к сайтам 2025: чек-лист для бизнеса — https://www.klerk.ru/blogs/roskom24/650389/

[20] Utlab.ru — 152-ФЗ о персональных данных: требования 2025 года — https://www.utlab.ru/blog/152-fz-chto-dolzhen-znat-vladelets-lyubogo-sayta/

[21] Klerk.ru — Обработка персональных данных: новые требования с 01.07.2025 и 01.09.2025 — https://www.klerk.ru/blogs/fedresurs/658225/

[22] Arbitr-praktika.ru — Штрафы за персональные данные с 30 мая 2025 года — https://www.arbitr-praktika.ru/article/2742-shtrafy-za-personalnye-dannye

[23] Riverstart.ru — Государственная система обезличивания персональных данных — https://riverstart.ru/blog/novyie-trebovaniya-kpersonalnyim-dannyim-v2025-pravila-rabotyi-dlya-biznesa-s152-fz