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