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