Реестр операторов ПДн: как обновить уведомление и не потерять в DLP-политиках

На прошлой неделе к нам обратился клиент с розничной сетью - несколько десятков магазинов по регионам, программа лояльности, call-центр, HR-система. Запрос конкретный: «Нам пришло письмо от РКН с требованием актуализировать уведомление оператора персональных данных. Что менять и что это вообще значит для нашей DLP?»

Ситуация типовая и одновременно неочевидная. Разбираем, как мы это делали.

Откуда взялось требование

РКН в 2025 году активно чистит реестр операторов ПДн: часть записей там с 2013-2014 годов, когда операторы уведомляли про одни категории данных, а по факту давно обрабатывают другие. Регулятор это видит - особенно после крупных утечек, когда выясняется, что оператор «работает только с именем и телефоном», а в слитой базе ещё ИНН, адреса доставки, история покупок и данные карт лояльности.

Формально оператор обязан уведомлять об изменениях состава обрабатываемых ПДн. На практике большинство этого не делали - не из злого умысла, просто бизнес рос, данных собиралось больше, а юридическая служба за этим не следила. Теперь РКН начал присылать запросы, и игнорировать их не стоит: за неуведомление предусмотрен отдельный состав по КоАП.

Что пришлось раскапывать у клиента

Мы начали с инвентаризации - не документальной, а фактической. Попросили доступ к реестру систем и прошли по каждой:

• Программа лояльности. Собирает: имя, телефон, email, дата рождения, история покупок, геолокация магазина при сканировании карты. Уведомление 2019 года: «имя, телефон, email». Дата рождения и геолокация - не указаны.
• HR-система. Здесь всё серьёзнее: паспортные данные, СНИЛС, ИНН, медицинские справки при приёме на работу, сведения о судимости для отдельных должностей. Это специальные категории ПДн по статье 10 152-ФЗ. В уведомлении - пробел.
• Call-центр. Записи звонков хранятся 180 дней. Голос - это биометрические ПДн по статье 11. Не указаны.
• Интернет-магазин. Адреса доставки, история заказов, данные карты (через платёжный шлюз, но шлюз - подрядчик, и это тоже надо отразить в уведомлении как передачу третьим лицам).

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

Что меняется в самом уведомлении

Форма уведомления оператора (утверждена приказом Роскомнадзора) содержит несколько ключевых блоков, которые пришлось переработать:

• Категории субъектов. Добавили сотрудников (отдельно от клиентов), кандидатов при найме, клиентов интернет-магазина отдельно от офлайн-покупателей.
• Перечень категорий ПДн. Явно указали специальные (медицинские данные для HR), биометрические (голос в call-центре), добавили геолокационные данные - они не специальные, но отдельная категория в контексте рекомендаций РКН.
• Цели обработки. Их оказалось больше, чем в исходном уведомлении: маркетинговые коммуникации и аналитика покупательского поведения - отдельные цели с разными правовыми основаниями.
• Передача третьим лицам. Платёжный шлюз, транспортные подрядчики для доставки, облачный провайдер HR-системы - всё это теперь должно быть отражено.

Связка с DLP-политиками

Вот где стало интересно. Клиент использует DLP-систему, настроенную несколько лет назад. Политики контролировали утечки «персональных данных» как единой категории - по маскам телефонов, email, ФИО. Никакой разницы между обычными и специальными категориями в политиках не было.

После того как мы зафиксировали реальный состав данных, появилась задача привести DLP в соответствие:

• Специальные категории - медданные из HR-системы - требуют более жёстких политик: запрет выгрузки на внешние носители без явного согласования, алерт при любой пересылке за периметр, отдельный журнал событий по этому типу данных.
• Биометрия - записи звонков - хранятся в отдельном хранилище call-центра. DLP туда не заглядывала вообще. Настроили мониторинг копирования из этого хранилища.
• Геолокация и история покупок - обезличиваются перед передачей в аналитический контур, но DLP этого не проверяла. Добавили контроль на уровне шины данных.

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

Где сейчас

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

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

Работа в процессе. Но то, что начиналось как «пришло письмо от РКН», превратилось в нормальный аудит реального состояния защиты ПДн - с инвентаризацией, обновлёнными документами и настроенной под актуальный состав данных DLP. Что, в общем-то, и нужно было сделать раньше.