Персональные данные переведут на новую модель защиты: почему маркетингу это аукнется первым

Если вы маркетолог, то у вас почти наверняка есть база подписчиков, которым вы направляете свои рассылки, CRM с сегментами или даже чат-бот и рекомендательная модель, которая подбирает оффер на основе анализа поведения пользователя.

Все это — персональные данные, и правила их защиты впервые за тринадцать лет переписывают целиком. Проект приказа ФСТЭК, который должен заменить приказ №21 от 18 февраля 2013 года, убирает привычную таблицу мер и заставляет оператора самому собирать защиту под свою архитектуру, а потом доказывать, что она работает.

Звучит как тема для ИБ-отдела, а не для маркетолога. На самом деле это касается всех, кто работает с базами клиентов. Маркетинг обычно собирает персональные данные интенсивнее многих других отделов, а значит, и разгребать новые требования придется ему — вместе с ИТ и безопасниками.

Тринадцать лет спустя регулятор переписывает правила

Приказ № 21 вышел в 2013 году. Тогда не было ни массовых облаков, ни контейнерных сред, ни IoT, ни нейросетей, которые ежедневно пережевывают пользовательские данные. За эти годы изменился и ландшафт, и характер угроз, а перечень требуемых мер оставался прежним. Новый документ объявляет приказ № 21 утратившим силу и должен вступить в действие с 1 сентября 2026 года. Но пока в опубликованной версии проекта нет номера приказа — значит, работать нужно по старым требованиям, пока документ не подписан и не зарегистрирован в Минюсте.

Суть изменений в том, что жесткая таблица «мера — уровень» уходит. Уровни защищенности УЗ-1 — УЗ-4 сохраняются, но конкретный состав мер оператор теперь подбирает сам или с помощью приглашенного консультанта, опираясь на архитектуру системы и актуальные угрозы. Логика унифицируется с подходом к безопасности государственных информационных систем. Теперь схожие системы больше не будут защищаться по разным правилам.

Меры защиты выбираете вы — и вы же отвечаете за свой выбор

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

Появляется и новый ритуал — оценка эффективности мер через «уровень зрелости». По проекту ее проводят до начала обработки персональных данных, затем не реже одного раза в три года и внепланово после каждого инцидента. Провести оценку можно самостоятельно, если в штате есть специалисты нужной квалификации, либо привлечь лицензированных подрядчиков со стороны. Компании, в которых нужных специалистов нет, вынуждены будут пойти к консультантам или искать инструменты автоматизации, других путей проект не оставляет.

Для отдела маркетинга это значит, что вопрос «а на каком основании мы храним эти 200 тысяч контактов и как и чем их защищаем» перестал быть риторическим. Ответ придется оформлять документами.

За подрядчика теперь тоже отвечаете вы

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

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

Усилена и связка с ГосСОПКА: в состав мер входит непрерывное взаимодействие с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак. Раньше это касалось только компаний с госучастием, теперь – всех. Сама обязанность уведомлять об инцидентах с персональными данными не является новацией — и раньше требовалось направить уведомление в течение 24 часов с момента обнаружения атаки.

Впервые в качестве отдельной поверхности атаки назван ИИ 

В перечне мер впервые отмечены области, которых в старом приказе не было: искусственный интеллект, интернет вещей, облака и контейнеризация, защита от DDoS, устройства сотрудников (ноутбуки, смартфоны, рабочие станции, электронная почта), а также беспроводные сети и API.

Отдельный блок, посвященный ИИ — своевременный и правильный сигнал. Модели все чаще обучаются и работают на персональных данных, а обучающие выборки становятся самостоятельной поверхностью атаки. Для маркетолога это тоже уже не абстракция: если нейросеть сегментирует клиентов, то и обучающие данные, и сами запросы к модели — это тоже персональные данные, которые можно «отравить» на этапе обучения или выкачать через неудачно построенные запросы.

Правда, должен заметить, что эта тема пока проработана слабо. Состав мер по ИИ в проекте имеет рамочный характер, конкретных методик, порогов и критериев названо немного. Думаю, что детали неизбежно потребуется раскрывать отдельными методическими рекомендациями и согласовать с другими актами — рекомендациями Банка России по ИИ для финансового сектора и законом об ИИ.

Пока это выглядит как заявка на будущее регулирование, а не готовый чек-лист. Оператору, который прогоняет персональные данные через нейросети, придется самому построить модель угроз для своей системы.

В политике обработки данных придется раскрыть больше, чем раньше

Есть в проекте неочевидный момент, который уже вызвал повышенное внимание специалистов. Состав мер по обеспечению безопасности персональных данных проект предлагает закреплять в политике обработки персональных данных, а закон обязывает публиковать ее в открытом доступе. Это фактически означает, что часть своего защитного контура теперь придется показывать всем желающим, так что операторам стоит заранее продумать, что уходит в публикуемую политику, а что должно остаться во внутренних документах.

Что нужно сделать с базами данных клиентов до первой проверки

Сразу скажу, работы на первых порах станет больше, чем раньше. Зато можно надеяться, что уйдет бессмысленный формализм и появится свобода строить защиту под реальную архитектуру. Вот мой план действий для тех, кто отвечает за данные в отделе маркетинга.

1. Провести ревизию: какие системы и подрядчики трогают персональные данные, где они физически живут, какие технологии задействованы.
2. Актуализировать модель угроз с учетом фактически используемых инструментов — облаков, API, ИИ-сервисов.
3. Пересмотреть договоры с обработчиками и порядок их проверки.
4. Решить, кто и как будет оценивать уровень зрелости: свои специалисты, внешний консультант или современные инструменты автоматизации оценки комплаенса.
5. Определить границы того, что вы хотите рассказать о своей киберзащите в публичной политике обработки данных перед тем, как выложить её на сайт.

Главную ценность проекта нового приказа я вижу не в количестве мер, а в смещении фокуса с вопроса «поставили ли вы средство защиты» на вопрос «доказали ли вы, что оно защищает». Если на практике оценка зрелости превратится в проставление очередных галочек, то красивый и современный адаптивный подход выродится в тот же бумажный комплаенс, который мы уже время от времени наблюдали, только немного посложнее прежнего.