Проверка Роскомнадзора сайта: формы, файлы cookie, Метрика

Что проверить владельцу сайта перед проверкой РКН: формы заявок, согласия, файлы cookie, Яндекс.Метрику, зарубежные сервисы и уведомление оператора.

Проверка Роскомнадзора для сайта: формы, файлы cookie, Яндекс.Метрика и уведомление РКН

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

Именно маршрут, а не один отдельный документ, становится главным местом риска. Если на сайте висит политика из шаблона, но в реальности заявки уходят в Telegram, систему учета заявок, Метрику и рекламные кабинеты, проверяющий увидит не порядок в обработке персональных данных, а рассинхрон между словами и фактической работой сайта.

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

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

Нужен быстрый разбор сайта перед проверкой или после новости о РКН? Услуга проверки сайта на соответствие требованиям 152-ФЗ и РКН начинается от 45 000 ₽. Это проверка форм, согласий, файлов cookie, аналитики и маршрута заявки, чтобы понять, что нужно исправить на сайте и какие сведения подготовить для уведомления или обновления записи в РКН. Заказать проверку сайта и маршрут данных

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

В малом бизнесе часто звучит фраза: "У нас не банк и не клиника, мы просто принимаем заявки". Но персональные данные начинаются не с паспорта. На сайте они часто начинаются с обычного телефона под кнопкой "Оставить заявку".

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

Интернет-магазин выглядит еще сложнее. Там к контактам добавляются адрес доставки, история заказов, платежный статус, промокоды, корзина и иногда поведение пользователя на сайте. Если рядом работают Метрика, коды рекламных систем и рассылки, данные превращаются в систему, а не в разовую заявку.

B2B-сайт тоже не исключение. Контактное лицо компании может оставить имя, должность, корпоративную почту, телефон, ссылку на сайт, комментарий и ожидания по проекту. Формально это "контакты юрлица", но в составе этих контактов есть сведения о конкретном человеке.

По 152-ФЗ "О персональных данных" персональные данные - это информация, которая относится к прямо или косвенно определяемому человеку. Поэтому телефон, адрес электронной почты, ФИО, IP-адрес в связке с аналитикой, идентификатор файла cookie и текст обращения нужно рассматривать не как мелочь интерфейса, а как часть обработки.

Что РКН может увидеть на сайте без доступа внутрь бизнеса

Проверка сайта начинается не с серверной комнаты. Она начинается с первого экрана.

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

Затем внимание уходит в файлы cookie и подключенные скрипты. На сайте может быть Яндекс.Метрика, коды рекламных систем, чат на сайте, форма обратного звонка, форма внешнего сервиса, сеть доставки файлов, шрифты, карты, мессенджеры. Не каждый скрипт сам по себе означает нарушение, но каждый такой элемент задает вопрос: какие данные он получает, где это описано и совпадает ли это с документами.

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

Форма заявки: согласие должно быть доказуемым

Форма на сайте - это точка входа персональных данных. К ней нельзя относиться как к декоративному блоку, который дизайнер поставил между преимуществами и кнопкой.

Хорошая форма собирает только те поля, которые действительно нужны для первого контакта. Если бизнесу достаточно имени и телефона, не стоит просить дату рождения, полный адрес или лишние документы "на всякий случай". Чем больше данных собирает сайт, тем сложнее объяснить цель обработки и тем больше ответственность за хранение.

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

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

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

Файлы cookie и Яндекс.Метрика: что описать и что не передавать

Файлы cookie сами по себе не всегда автоматически означают нарушение. Но идентификатор файла cookie, IP-адрес, данные браузера, адрес страницы и поведение пользователя могут позволять прямо или косвенно выделить человека. Поэтому аналитика должна быть не "невидимой магией маркетолога", а описанной частью сайта.

У Яндекс.Метрики в справке указано, что сервис получает технические сведения о визитах: адрес страницы, параметры браузера, операционной системы, IP, файлы cookie и другие данные. Это не означает, что Метрику нельзя использовать. Это означает, что ее нужно честно отразить в документе о файлах cookie, согласиях и настройках загрузки скриптов.

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

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

Веб-аналитика должна помогать видеть заявки и конверсии, а не создавать неуправляемую витрину персональных данных.

Зарубежные сервисы и трансграничная передача

Если на сайте есть Google Analytics, зарубежная система учета заявок, иностранный чат на сайте, внешняя форма, сеть доставки файлов, сервис рассылок или облачная таблица, появляется отдельный вопрос: уходит ли что-то иностранному получателю.

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

В 152-ФЗ есть отдельная логика по трансграничной передаче персональных данных. Если она есть, ее нужно анализировать отдельно и отражать в документах. Важно не смешивать два разных действия: уведомление об обработке персональных данных по статье 22 и уведомление о намерении осуществлять трансграничную передачу. Иногда правильнее заменить сервис российским аналогом. Иногда достаточно изменить настройки и убрать лишнюю передачу. Иногда требуется отдельная процедура. Без карты потоков данных это превращается в гадание.

Уведомление в Роскомнадзор: почему важно совпадение с реальностью

Один из самых частых вопросов: нужно ли подавать уведомление в Роскомнадзор, если сайт просто собирает заявки?

Общее правило из статьи 22 152-ФЗ такое: оператор до начала обработки персональных данных уведомляет Роскомнадзор, если не попадает под исключения. Исключения существуют, но после изменений последних лет рассчитывать на аргумент "мы маленькие, значит нам не надо" становится все рискованнее.

Уведомление важно не только подать. Оно должно совпадать с тем, что реально делает бизнес. В нем отражаются цели обработки, категории данных и субъектов, способы обработки, сроки, меры защиты, сведения о трансграничной передаче, местонахождение баз данных и дата начала обработки. Если сайт изменился, появились система учета заявок, рассылки, новые формы, подрядчики или аналитика, старая запись может перестать соответствовать фактической обработке. По статье 22 152-ФЗ изменения в сведениях нужно сообщать не позднее 15-го числа месяца, следующего за месяцем, в котором такие изменения возникли.

Отдельная ситуация - когда при попытке подать первичное уведомление появляется сообщение "Запись об операторе с таким ИНН уже существует". Это обычно означает, что оператор уже есть в реестре, и нужно не создавать новую первичную запись, а искать себя в реестре операторов РКН и подавать сведения через форму внесения изменений. В таком случае пригодится регистрационный номер записи из реестра.

Проверить наличие записи можно по ИНН на портале персональных данных Роскомнадзора. Если запись есть, задача меняется: не "подать с нуля", а понять, какие сведения уже опубликованы и что нужно актуализировать.

Карта данных: сайт, политика, файлы cookie, система учета заявок и уведомление

Самая сильная проверка - это не поиск одной ошибки, а сверка всего маршрута.

Допустим, на сайте форма собирает имя, телефон, город, нишу и комментарий. Пользователь отправляет заявку, она уходит в почту, копируется в Telegram, затем менеджер заносит ее в систему учета заявок. Параллельно Метрика фиксирует визит, источник рекламы и достижение цели. Если политика говорит только "мы используем адрес электронной почты для ответа", а уведомление РКН не знает ни про сайт, ни про систему учета заявок, ни про аналитику, проблема не в одной фразе. Проблема в том, что документы не описывают реальность.

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

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

Последний слой - публичные документы. В политике, согласии, документе о файлах cookie и реквизитах должны совпадать оператор, контакты, права субъекта данных и дата актуальной редакции. Если эти документы живут отдельно от реальной формы, проверка быстро превращается в поиск расхождений.

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

Штрафы: почему бизнес начал реагировать быстрее

Размеры штрафов зависят от состава нарушения, статуса нарушителя, повторности и обстоятельств. Поэтому корректнее говорить не "вам точно грозит конкретная сумма", а "цена ошибки выросла, и видимые нарушения стало опаснее игнорировать". Например, за невыполнение или несвоевременное выполнение обязанности уведомить Роскомнадзор по ч. 10 ст. 13.11 КоАП РФ для юридических лиц предусмотрен штраф 100 000-300 000 ₽.

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

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

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

Чек-лист проверки сайта за один вечер

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

1. Есть ли на каждой форме ссылка на политику обработки персональных данных. 2. Можно ли отправить заявку без согласия. 3. Не отмечен ли чекбокс заранее. 4. Соответствует ли текст согласия конкретной форме. 5. Есть ли отдельный документ о файлах cookie или понятный раздел о них. 6. Стоит ли Яндекс.Метрика, Google Analytics, код рекламной системы VK, рекламные счетчики, чат или форма обратного звонка. 7. Не передаются ли в аналитику телефон, адрес электронной почты, имя или текст заявки. 8. Куда уходит заявка после отправки. 9. Кто имеет доступ к заявкам. 10. Есть ли компания или ИП в реестре операторов персональных данных. 11. Совпадает ли уведомление РКН с тем, что реально делает сайт. 12. Указаны ли реквизиты оператора и контакты для обращений.

Если на половину вопросов ответ "не знаю", это уже повод для проверки. Не потому что все срочно плохо, а потому что у бизнеса нет карты собственного цифрового маршрута данных.

Что делать, если нашли проблему

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

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

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

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

В CentrLP мы называем эту услугу проверкой сайта по персональным данным. По сути это практический разбор сайта на соответствие требованиям 152-ФЗ, правилам Роскомнадзора и фактическому маршруту заявки: от формы на странице до системы учета, аналитики, подрядчиков и документов.

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

После диагностики собирается карта данных. В ней видно, какие данные собираются, зачем, где хранятся, кому доступны и что должно быть отражено в политике, документе о файлах cookie, форме согласия и уведомлении РКН. Если нужно обновление сведений в реестре, мы готовим техническую и фактическую основу: цели, категории данных, субъекты, сервисы, базы, обработчики и проблемные места, которые должен проверить профильный юрист.

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

Базовый ориентир стоимости - от 45 000 ₽ за проверку и карту исправлений. Внедрение правок в сайт, формы, аналитику, страницы услуг и технический маршрут заявки оценивается отдельно, если объем выходит за рамки первичной проверки.

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

Нужен быстрый разбор сайта перед проверкой или после тревожной новости о РКН? Заказать проверку сайта по персональным данным от 45 000 ₽

Частые ошибки на сайтах

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

"Метрика - это не персональные данные". Все зависит от состава данных, настроек, целей и возможности идентифицировать пользователя прямо или косвенно. Метрику можно использовать аккуратно, но ее нельзя игнорировать в документах и настройках.

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

"Мы не храним данные, они просто приходят в Telegram". Если заявка с телефоном приходит в Telegram, почту или систему учета заявок, это все равно обработка. Вопрос не только в хранении на сайте, а во всем маршруте данных.

"Мы маленькая компания, РКН нас не проверит". Сайт виден всем. Формы, документы, файлы cookie, скрипты и реестр проверяются быстрее, чем внутренние процессы.

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

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

Частые вопросы

Нужно ли подавать уведомление в РКН, если на сайте только форма заявки?

Часто - да, если компания или ИП обрабатывает персональные данные и не попадает под исключения. Но важно не просто подать уведомление, а сделать так, чтобы сведения соответствовали реальности: целям, категориям данных, субъектам, способам обработки, срокам и сервисам.

Что делать, если РКН пишет, что запись с таким ИНН уже существует?

Нужно проверить организацию в реестре операторов по ИНН и найти регистрационный номер. Если запись действительно есть, обычно используется не первичная форма уведомления, а форма внесения изменений в сведения в реестре.

Достаточно ли одного чекбокса под формой?

Нет. Чекбокс - только интерфейсное подтверждение действия пользователя. Нужны актуальные документы, понятный текст согласия, техническая невозможность отправки без согласия и соответствие фактической обработке.

Нужно ли описывать Яндекс.Метрику?

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

Что делать с Google Analytics?

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

Можно ли взять готовую политику и просто заменить название компании?

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

Что делать, если уже пришло требование от Роскомнадзора?

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

Короткий вывод

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

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

Источники и полезные ссылки

Федеральный закон № 152-ФЗ "О персональных данных" Статья 22 152-ФЗ: уведомление об обработке персональных данных Статья 13.11 КоАП РФ: ответственность за нарушения в области персональных данных Реестр операторов персональных данных Роскомнадзора Портал персональных данных Роскомнадзора Согласие на обработку персональных данных, разрешенных для распространения Как работает Яндекс.Метрика Политика Яндекса о файлах cookie