Уведомление оператора персональных данных в Роскомнадзор

Уведомление в Роскомнадзор подается по статусу оператора персональных данных.

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

Подготовка перед подачей - чтобы уведомление не расходилось с фактом
Перед заполнением имеет смысл пройти путь пользователя и собрать базовые ответы: какие категории данных собираются (например, имя, телефон, email, сведения из заказа), какие технические данные фиксируются, какие события улетают в аналитику, где хранятся заявки, кто имеет доступ. Отдельно проверьте, какие подрядчики участвуют: CRM, почтовые сервисы, коллтрекинг, чаты, сервисы рассылок, платежные решения. Именно на этом этапе чаще всего обнаруживается, что документы на сайте и фактические интеграции описаны по-разному.

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

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

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

Точки риска - подрядчики и внешние сервисы
У владельца сайта редко все находится "в одном месте". Заявки уходят в CRM, звонки записываются в телефонии, чаты хранят переписку, рассылки запускаются через отдельный сервис, аналитика передает идентификаторы. В уведомлении важно, чтобы общая картина была целостной. Если подрядчик реально получает данные и участвует в обработке, он должен быть учтен в логике процесса и в документах на сайте. Иначе на запросы будет трудно отвечать: вы будете доказывать одно, а фактически работает другое.

Один список, что подготовить до заполнения уведомления

Перечень форм - какие есть формы и какие поля в каждой форме.
Цели - для каждой формы и каждого процесса, что именно вы делаете с данными.
Системы хранения - почта, CRM, админка, телефония, сервисы чатов и рассылок.
Подрядчики - кто получает данные, на каком основании, кто администрирует доступы.
Доступы - роли сотрудников, принцип минимальных прав, порядок выдачи/отзыва.
Сроки хранения - хотя бы по основным категориям: заявки, заказы, переписка, записи звонков.
Документы на сайте - политика, согласия, cookie-логика, контакты для обращений по данным.

Когда и почему уведомление нужно обновлять
Сведения обычно требуют актуализации при изменении фактической обработки. Типовые причины: добавили личный кабинет, подключили новый чат или коллтрекинг, поменяли CRM, запустили рассылки, начали принимать оплату на сайте, изменили состав данных в формах, сменили организацию или реквизиты, перераспределили роли между участниками (например, кто принимает оплату и кто оказывает услугу). Важно не ждать "проверки", а обновлять информацию, когда меняется процесс.

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

При подготовке статьи частично использованы материалы с сайта web2b.law - уведомление оператора персональных данных в Роскомнадзор

Дата публикации: 29 мая 2022 года