Вопрос об уведомлении в Роскомнадзор часто упрощают до одной фразы: если на сайте есть форма обратной связи, значит уведомление точно нужно. На практике такой подход слишком грубый. Обязанность определяется не самим фактом существования сайта, а тем, как именно через него организована обработка персональных данных, кто является оператором, в каком объеме собираются сведения и как они используются дальше. Поэтому сначала нужно смотреть не на внешний вид ресурса, а на процесс работы с данными.
Многие владельцы сайтов оценивают ситуацию поверхностно. Они видят, что форма собирает имя и телефон, и считают это чем-то слишком простым для отдельного уведомления. Другие, наоборот, подают уведомление автоматически, не разбираясь в основаниях. Обе крайности неудобны. В первом случае бизнес рискует не выполнить свою обязанность. Во втором — тратит время на формальное действие, не проверив остальные элементы обработки данных, которые на практике могут быть важнее самого уведомления.
Чтобы понять, нужно ли подавать уведомление, сначала определяют, является ли владелец сайта оператором персональных данных именно в том сценарии, который реализован на сайте. Если организация или предприниматель через формы, кабинеты, подписку, онлайн-запись, чат или иные инструменты получает и дальше использует сведения о пользователях, вопрос об обязанности возникает не теоретически, а вполне предметно. При этом оценивать нужно не только видимые поля формы. Значение имеют и аналитика, и cookie, и передача заявок в CRM, и любые регулярные действия с полученной информацией.
Отдельная ошибка — считать, что обязанность зависит только от большого объема данных. Даже простой сайт с одной формой может быть частью полноценного процесса обработки. Сведения поступают, сохраняются, передаются сотрудникам, используются для связи с клиентом, попадают в CRM или таблицу, иногда обогащаются дополнительной информацией. То есть сайт становится точкой входа в рабочий бизнес-процесс, а не просто страницей с кнопкой. Поэтому вопрос нужно ставить так: не «много ли данных я собираю», а «есть ли у меня системная обработка данных через сайт и после него».
При определении обязанности обычно проверяют такие обстоятельства:
- какие именно формы и каналы сбора данных есть на сайте;
- кто получает данные после отправки формы и как они используются;
- сохраняются ли сведения в CRM, почте, таблицах, сервисах аналитики и других системах;
- собираются ли данные регулярно и в рамках основной деятельности бизнеса;
- есть ли на сайте личный кабинет, подписка, онлайн-запись, чат или иные постоянные инструменты взаимодействия;
- кто именно выступает оператором: компания, ИП, владелец проекта или иное лицо.
Важный момент — обязанность нельзя определять только по одному документу на сайте. Наличие политики конфиденциальности само по себе не отвечает на вопрос. Не отвечает на него и наличие чекбокса под формой. Это сопутствующие элементы. Главный критерий — фактическая организация обработки данных. Если сайт собирает и передает сведения в рамках устойчивой модели работы, формальная простота интерфейса ничего не меняет.
Часто путаница возникает на сайтах, где часть функций вынесена на внешние сервисы. Например, форма работает через стороннюю платформу, запись идет через отдельный модуль, чат принадлежит внешнему провайдеру, а аналитика собирается через несколько подключений. Владельцу сайта может казаться, что данные «собирает не он», а сервис. Но для оценки обязанности этого недостаточно. Нужно смотреть, кто определяет саму цель взаимодействия с пользователем и кто в итоге использует полученную информацию. Если сайт является частью бизнес-процесса владельца, от этого нельзя уйти простой ссылкой на подрядчика.
Часто бизнес ошибается в таких ситуациях:
- оценивает только форму обратной связи и не учитывает остальные каналы сбора данных;
- считает, что небольшой объем заявок освобождает от обязанности;
- не замечает, что данные регулярно попадают в CRM, мессенджеры и рабочие таблицы;
- полагает, что внешние виджеты и сервисы снимают вопрос с владельца сайта;
- ориентируется на устные советы без анализа своей конкретной модели работы;
- подает уведомление формально, но не приводит в порядок документы и процессы на сайте.
Еще одна проблема — сайт меняется, а оценка обязанности нет. Ресурс мог начинаться с простой страницы контактов, а затем на нем появились квиз, подписка, онлайн-чат, форма расчета стоимости, запись на консультацию, интеграция с рекламными кабинетами и автоматическая передача лидов. Формально это все тот же сайт, но по факту модель обработки данных уже другая. Поэтому проверять обязанность нужно не один раз при запуске, а каждый раз, когда сайт становится функционально сложнее.
Нужно учитывать и внутреннюю сторону вопроса. Даже если бизнес приходит к выводу, что уведомление требуется, этим работа не заканчивается. Подача уведомления не заменяет настройку документов, текстов согласий, интерфейсов форм и порядка работы с заявками. Часто владельцы сайтов воспринимают уведомление как основную юридическую задачу, хотя на практике сайт может вызывать вопросы именно из-за несогласованности процессов, а не из-за одного регистрационного действия.
Правильный подход здесь простой: сначала описать весь путь данных на сайте, затем определить, кто выступает оператором и как именно строится обработка, после этого оценить обязанность по уведомлению и уже потом оформлять сопутствующие документы. Когда эта логика соблюдена, решение получается устойчивым. Когда ее нет, сайт либо живет с неясным риском, либо формально закрывает один вопрос, оставляя без внимания все остальные
При подготовке статьи частично использованы материалы с сайта web2b.law — когда подавать уведомление в Роскомнадзор
Дата публикации: 29 мая 2022 года
