Renewal согласия в SaaS

Подписочная SaaS-модель создаёт специфический правовой риск: согласие, полученное при регистрации, не автоматически покрывает обработку на всех последующих периодах — особенно если изменился состав ПДн, цели или обработчики. С 01.09.2025 закон требует отдельного документа согласия. В этом материале — структура renewal-процесса, технические требования по УЗ-1..4, обезличивание для ML и ответственность в мультиарендной архитектуре.

Что такое renewal согласия и когда оно требуется в SaaS?

Renewal согласия — это не автоматическая пролонгация старого документа, а получение нового согласия при наступлении одного из триггеров. По ст. 9 ФЗ-152 в редакции ФЗ-156 от 24.06.2025, согласие должно быть оформлено отдельным документом, содержать полный перечень обрабатываемых данных, цели и срок обработки.

Для SaaS renewal обязателен в четырёх ситуациях. Первая — продление подписки с изменением тарифного плана, если новый план предполагает расширенный сбор ПДн (например, добавление аналитики поведения или биометрической идентификации). Вторая — подключение нового субобработчика, которого не было в первоначальном согласии. Третья — изменение состава ПДн: добавление геолокации, устройства, IP-адреса к уже обрабатываемым данным. Четвёртая — изменение целей обработки, в том числе при запуске ML-моделей на пользовательских данных.

Ключевой вопрос для CTO: когда именно возникает обязанность renewal? Если SaaS-платформа обрабатывает только те данные, что указаны в первоначальном согласии, и состав не меняется — renewal при каждом продлении подписки не нужен. Но стоит появиться новому cookies-трекеру, субобработчику в облаке или ML-пайплайну на пользовательских данных — возникает обязанность обновить согласие до начала такой обработки.

Как устроены уровни защищённости УЗ-1..4 для SaaS-инфраструктуры?

Уровень защищённости информационной системы персональных данных (ИСПДн) определяется по матрице трёх параметров: категория ПДн, тип угроз и число субъектов. ПП РФ №1119 от 01.11.2012 устанавливает четыре уровня — УЗ-4 (минимальный) до УЗ-1 (максимальный).

Для типового B2B SaaS с общими категориями ПДн сотрудников клиентов (ФИО, должность, email, телефон) и числом субъектов до 100 000 при угрозах 3-го типа применяется УЗ-3. При превышении 100 000 субъектов — УЗ-2. Если SaaS обрабатывает специальные категории (состояние здоровья, биометрию) — минимальный уровень повышается до УЗ-2 или УЗ-1 в зависимости от типа угроз.

Практически важное следствие для CTO: уровень защищённости фиксируется в акте классификации ИСПДн. Этот документ — часть обязательного пакета ОРД. Без него при проверке РКН нельзя обосновать применённый набор мер защиты по Приказу ФСТЭК №21. Меры защиты для УЗ-3 включают идентификацию и аутентификацию, управление доступом, защиту машинных носителей, регистрацию событий и антивирусную защиту как базовый набор.

Кто является оператором в мультиарендной SaaS и как распределяется ответственность?

Мультиарендность (multitenancy) создаёт правовую коллизию: SaaS-вендор хранит ПДн нескольких клиентов-операторов в единой инфраструктуре. По ст. 6 ФЗ-152, обработка по поручению оператора допустима на основании договора, в котором чётко определены цели, состав ПДн и меры защиты.

В типичной B2B SaaS-схеме клиент является оператором, а SaaS-вендор — лицом, осуществляющим обработку по поручению (обработчиком). Это означает, что вендор не вправе использовать ПДн клиентов в своих целях — в том числе для обучения ML-моделей — без отдельного основания. Если вендор самостоятельно определяет цели обработки хотя бы части данных (например, поведенческой аналитики для улучшения продукта), он приобретает статус оператора в этой части и несёт полную ответственность.

Договор поручения обработки должен содержать перечень действий с ПДн, обязанность соблюдать конфиденциальность, меры по обеспечению безопасности и условия возврата или уничтожения данных по окончании. Отсутствие такого договора при проверке РКН — самостоятельное нарушение, образующее состав по ч. 1 ст. 13.11 КоАП (штраф 150 000–300 000 ₽).

Обезличивание для ML: как использовать пользовательские данные законно?

ML-пайплайны в SaaS почти всегда работают с пользовательскими данными. Законный путь — обезличивание до начала обучения модели. ФЗ-233 от 08.08.2024 ввёл в ФЗ-152 ст. 13.1, которая регулирует обращение с обезличенными ПДн. Приказ РКН (действует с 2025 года) закрепил пять методов обезличивания.

Для ML-задач наиболее применимы три метода. Введение идентификаторов заменяет прямые идентификаторы (ФИО, email) на псевдонимы — при условии, что таблица соответствия хранится отдельно и недоступна ML-системе. Обобщение заменяет точные значения диапазонами (возраст «35» → «30–40»). Декомпозиция разбивает набор данных на фрагменты, каждый из которых не позволяет идентифицировать субъекта.

Практический риск: псевдонимизация без контроля доступа к таблице соответствия не является обезличиванием по смыслу ФЗ-152. Если ML-система имеет доступ к обеим частям — данные по-прежнему персональные. CTO обязан зафиксировать метод обезличивания в ОРД и провести оценку воздействия (DPIA), если ML обрабатывает специальные категории или данные в масштабе.

Логирование, облако и КИИ: технические требования для SaaS в РФ

Логи приложения нередко содержат ПДн: IP-адреса, идентификаторы сессий, email в URL-параметрах. По позиции регулятора, IP-адрес в связке с другими данными является ПДн. Это означает, что системы логирования входят в периметр ИСПДн и должны соответствовать применимому УЗ.

Требования к хранению логов для целей реагирования на инциденты установлены Приказом ФСТЭК №21 в части мер группы РСБ (регистрация событий безопасности). Для УЗ-3 обязательны: фиксация событий входа/выхода, изменений прав доступа, ошибок аутентификации; хранение логов не менее установленного периода; защита от модификации.

Облачная инфраструктура. С 01.07.2025 требования к локализации по ч. 5 ст. 18 ФЗ-152 ужесточены. Первичная запись, систематизация, накопление и хранение ПДн граждан РФ должны осуществляться только в базах, физически расположенных в России. Использование AWS, GCP, Azure с регионом вне РФ для хранения ПДн российских пользователей нарушает ч. 5 ст. 18. Штраф по ч. 8 ст. 13.11 КоАП — от 1 000 000 до 6 000 000 ₽, при повторном нарушении — от 6 000 000 до 18 000 000 ₽.

КИИ (критическая информационная инфраструктура). Если SaaS обслуживает объекты КИИ или сам является значимым объектом КИИ по ФЗ-187, требования к защите информации определяются параллельно с 152-ФЗ и приоритетом обладают нормы ФЗ-187 в части инцидентов. CTO обязан провести категорирование — это отдельная процедура, не совпадающая с классификацией ИСПДн.

Как renewal применяется на практике: сценарии для CTO

Сценарий 1. Запуск новой фичи с расширенным сбором данных. SaaS-платформа для HR добавляет модуль аналитики вовлечённости: теперь система фиксирует время работы, паузы, частоту переключений. Это новая категория данных, не указанная в первоначальном согласии. Ситуация: фича запущена, согласие не обновлено. Доказательства нарушения: лог сбора поведенческих данных, отсутствие обновлённой формы согласия в документах. Вероятный исход: протокол по ч. 2 ст. 13.11 КоАП, штраф до 700 000 ₽ за обработку без надлежащего согласия. Стратегия: триггер на renewal должен срабатывать в CI/CD-пайплайне при изменении состава собираемых ПДн — юридическая проверка до релиза.

Сценарий 2. Смена облачного провайдера с переездом за рубеж. CTO принимает решение мигрировать базу данных на европейский регион AWS для снижения задержек. Ситуация: ПДн граждан РФ хранятся за пределами РФ. Доказательства нарушения: конфигурация облачного аккаунта, DNS-записи, договор с AWS. Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП от 1 000 000 до 6 000 000 ₽, предписание РКН о локализации. Стратегия: до миграции — правовой анализ состава данных; если есть ПДн граждан РФ — только российские регионы (Яндекс Облако, SberCloud, MCS) или гибридная схема с локальным мастером.

Сценарий 3. ML-модель обучена на исторических данных без обезличивания. Data Science-команда использовала production-дамп для обучения рекомендательной модели. Ситуация: ПДн обрабатываются для цели (обучение ML), не указанной в согласии, без обезличивания. Доказательства нарушения: датасет с реальными идентификаторами, логи доступа DS-команды. Вероятный исход: нарушение ст. 5 ФЗ-152 (принцип соответствия целям) и ст. 9 (отсутствие согласия на данную цель) — состав по ч. 1 ст. 13.11, штраф 150 000–300 000 ₽, и риск по ст. 272.1 УК при квалификации как незаконного использования. Стратегия: ввести обязательное обезличивание перед передачей данных DS-команде; зафиксировать метод в ОРД; при необходимости — отдельное согласие на обработку в целях улучшения сервиса.

Примеры из практики

Кейс 1. SaaS-компания (Центральный ФО, осень 2025) запустила ML-фичу персонализации без обновления согласий и без договора поручения с облачным провайдером. При плановой проверке РКН выявлено три нарушения: отсутствие договора поручения, несоответствие состава ПДн тексту согласия, отсутствие акта классификации ИСПДн. Выдано предписание об устранении в течение 30 дней и возбуждено два административных дела. Юристы DATUM сформировали пакет ОРД, заключили договоры с субобработчиками и подготовили возражения на протоколы. По ч. 3 ст. 13.11 назначен штраф в нижней трети диапазона с учётом добровольного устранения нарушений.

Кейс 2. Аналогичная ситуация воспроизводит логику дела case_S2_pkr_analitika: SaaS-платформа для инвестиционного анализа (Северо-Западный ФО, начало 2026) пострадала от хакерской атаки; утекли данные около 70 000 пользователей — ФИО, должности, служебные email. Оператор не уведомил РКН в течение 24 часов (ч. 3.1 ст. 21 ФЗ-152), что добавило состав по ч. 11 ст. 13.11 КоАП (штраф 1 000 000–3 000 000 ₽) к составу по ч. 14 (штраф 10 000 000–15 000 000 ₽). Применение смягчающих обстоятельств позволило снизить итоговую сумму, однако оба состава остались в силе. Для CTO урок прямой: процедура реагирования на инциденты должна быть автоматизирована и протестирована до первого инцидента. Задержка в уведомлении удваивает количество составов.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка ИСПДн, ОРД и renewal-процедур
• DPIA (оценка воздействия) — для ML-пайплайнов и новых фич с ПДн
• Комплект ОРД под ключ — акт классификации, договоры поручения, политика

Частые вопросы

1. Какой УЗ выбрать для SaaS?

УЗ определяется по матрице ПП РФ №1119: категория ПДн, тип угроз и число субъектов. Для типового B2B SaaS с общими ПДн (ФИО, email, должность) и числом субъектов до 100 000 при угрозах 3-го типа применяется УЗ-3. При превышении 100 000 субъектов или обработке специальных категорий — УЗ-2. Тип угрозы определяется по результатам оценки в модели угроз: большинство стандартных коммерческих SaaS применяют тип 3, если используется серийное системное ПО без кастомных модификаций. Фиксируется в акте классификации ИСПДн — обязательном документе ОРД.

2. Можно ли использовать иностранные облака?

Для хранения ПДн граждан РФ — нет. С 01.07.2025 по ч. 5 ст. 18 ФЗ-152 первичная запись, систематизация, накопление, хранение и уточнение ПДн граждан РФ должны происходить в базах на территории России. AWS, GCP, Azure с регионом вне РФ для этой цели не подходят. Допустима схема: мастер-база в РФ (Яндекс Облако, SberCloud, MCS), репликация за рубеж — но первичная обработка только в РФ. Штраф за нарушение локализации — от 1 000 000 до 6 000 000 ₽ по ч. 8 ст. 13.11 КоАП.

3. Что такое обезличивание для ML?

Обезличивание — это преобразование ПДн, при котором невозможно без несоразмерных усилий определить принадлежность данных конкретному субъекту. Для ML применяются методы, закреплённые Приказом РКН (2025): введение идентификаторов (псевдонимизация с изолированной таблицей соответствия), обобщение (замена точных значений диапазонами), декомпозиция (разбивка на несвязанные фрагменты). Псевдонимизация без разделения доступа к ключам не является обезличиванием по ФЗ-152 — данные остаются персональными. Метод фиксируется в ОРД; обязательна оценка риска деобезличивания.

4. Кто является оператором в мультиарендной SaaS?

Клиент SaaS-платформы, который самостоятельно определяет цели и состав ПДн своих пользователей, является оператором. SaaS-вендор в этой схеме — обработчик по поручению (ст. 6 ФЗ-152). Однако если вендор использует данные всех арендаторов для собственных целей (агрегированная аналитика, обучение ML, бенчмаркинг), он приобретает статус оператора в этой части. Основание — договор поручения обработки с чётким разграничением целей и запретом использования данных вне этих целей. Его отсутствие образует состав по ч. 1 ст. 13.11 КоАП.

5. Какие СЗИ обязательны для SaaS по Приказу ФСТЭК №21?

Приказ ФСТЭК №21 определяет 15 групп мер защиты; базовый набор зависит от УЗ. Для УЗ-3 обязательны: идентификация и аутентификация пользователей (ИАФ), управление правами доступа (УПД), защита машинных носителей (ЗНИ), регистрация событий безопасности (РСБ), антивирусная защита (АВЗ). Часть мер можно закрыть встроенными средствами ОС и СУБД при их документированном применении. Для УЗ-2 дополнительно требуется система обнаружения вторжений (СОВ) и контроль целостности (ОЦЛ). Конкретный состав СЗИ определяется по модели угроз и акту классификации.

Итог

Renewal согласия в SaaS — это не разовая задача, а постоянный процесс, встроенный в жизненный цикл продукта. Каждое изменение состава ПДн, появление нового субобработчика или ML-фичи требует правовой оценки до релиза. С 01.09.2025 отдельный документ согласия стал обязательным, и архаичные формы в оферте создают прямой риск штрафа.

Технические требования — УЗ-1..4 по ПП РФ №1119, меры ФСТЭК №21, локализация с 01.07.2025, обезличивание для ML — формируют единую систему, которую нужно документировать в ОРД. DATUM сопровождает SaaS-компании на всех этапах: от классификации ИСПДн и DPIA до защиты от штрафов по ст. 13.11 КоАП.