Кто оператор: SaaS-провайдер или клиент

С 30.05.2025 действует новая редакция ст. 13.11 КоАП с 18 частями. Штраф за обработку ПДн без надлежащего поручения достигает 300 000 ₽ по ч. 1, а при повторности — 500 000 ₽ по ч. 1.1. Для SaaS-провайдера, работающего с сотнями арендаторов, риск умножается на каждого клиента. В этой статье разбираем, как разграничить роли оператора и лица, осуществляющего обработку по поручению, применительно к мультиарендной архитектуре, уровням защищённости УЗ-1..4 и требованиям ФСТЭК.

Как ФЗ-152 разграничивает оператора и обработчика по поручению?

Ст. 3 ФЗ-152 определяет оператора как лицо, которое самостоятельно или совместно с другими определяет цели обработки персональных данных. Лицо, осуществляющее обработку по поручению оператора, — это тот, кто выполняет технические действия с ПДн, но не определяет ни цели, ни состав данных.

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

Практическая проблема: типовые SaaS-договоры содержат SLA, описание функциональности и условия оплаты, но не содержат поручения на обработку в смысле ст. 6 ч. 3. Это означает, что технически провайдер имеет доступ к ПДн без какого-либо правового основания — именно такую ситуацию РКН квалифицирует как нарушение ч. 1 ст. 13.11 КоАП.

Когда SaaS-провайдер сам становится оператором?

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

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

Сценарий 2: провайдер обрабатывает данные для собственных нужд. Логи запросов, метрики использования, профили активности пользователей для улучшения продукта — всё это обработка в собственных целях провайдера. По ст. 3 ФЗ-152 провайдер здесь оператор, и он обязан уведомить РКН по ст. 22 ФЗ-152 именно в этой роли.

Сценарий 3: обезличивание для ML-моделей. Если провайдер извлекает ПДн арендаторов, применяет методы обезличивания и обучает на результате общую ML-модель — он совершает действия, выходящие за рамки поручения. Приказ РКН о методах обезличивания (5 методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение) регулирует этот процесс отдельно. До тех пор пока обезличивание не завершено в полном соответствии с утверждёнными методами, данные остаются персональными — и провайдер обрабатывает их как оператор без поручения.

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

ПП РФ №1119 устанавливает четыре уровня защищённости информационных систем персональных данных. Уровень зависит от категории ПДн, типа угроз и числа субъектов. Порог смены уровня — 100 000 субъектов.

В мультиарендной SaaS возникает специфическая проблема: каждый арендатор — отдельный оператор с отдельной ИСПДн. Но все они физически размещены в одной инфраструктуре провайдера. Это означает, что уровень защищённости всей инфраструктуры должен соответствовать самому высокому уровню среди всех арендаторов.

Если хотя бы один арендатор обрабатывает специальные категории ПДн (ст. 10 ФЗ-152: здоровье, национальность, религиозные взгляды) — вся платформа обязана соответствовать УЗ-3 или выше. При угрозах первого типа и числе субъектов более 100 000 — УЗ-1. Приказ ФСТЭК №21 определяет 109 мер защиты в 15 группах; базовый набор по каждому уровню провайдер обязан реализовать в собственной инфраструктуре независимо от поручений арендаторов.

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

Облако в РФ: требование локализации и КИИ для SaaS

Ч. 5 ст. 18 ФЗ-152 требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ осуществлялись в базах данных, расположенных на территории РФ. С принятием ФЗ-233 от 08.08.2024 это требование ужесточено: первичный сбор данных также должен происходить в российских базах.

Для SaaS-провайдера, использующего иностранные облачные платформы (AWS, Azure, GCP в зарубежных регионах), это означает прямое нарушение ч. 5 ст. 18. Штраф по ч. 8 ст. 13.11 КоАП за нарушение локализации — от 1 000 000 до 6 000 000 ₽, при повторном нарушении по ч. 9 — от 6 000 000 до 18 000 000 ₽.

Если SaaS-платформа отнесена к критической информационной инфраструктуре по ФЗ-187 о КИИ — требования к инфраструктуре возрастают: обязательная категоризация объектов КИИ, подключение к ГосСОПКА и применение сертифицированных средств защиты информации. Пересечение КИИ и обработки ПДн создаёт двойной регуляторный периметр: ФСТЭК по КИИ и РКН по 152-ФЗ.

Практические сценарии: что происходит при проверке РКН

Ситуация А. SaaS-провайдер обрабатывает ПДн сотрудников арендатора через HR-модуль. Договор содержит только описание функциональности. РКН при плановой проверке арендатора запрашивает поручение на обработку — его нет. Результат: протокол по ч. 1 ст. 13.11 в отношении арендатора (обработка через ненадлежащее лицо) и по ч. 1 ст. 13.11 в отношении провайдера (обработка без правового основания). Штраф на каждого — 150 000–300 000 ₽. Стратегия: оформить поручение задним числом не получится — РКН проверяет дату подписания. Выход — немедленное заключение соглашения об обработке по поручению и уведомление РКН об изменении сведений по ст. 22 ФЗ-152.

Ситуация Б. Провайдер ML-платформы использует деперсонализированные транзакционные данные арендаторов для обучения общей модели рекомендаций. Деперсонализация выполнена псевдонимизацией (замена ID на хэш). РКН признаёт хэш-ID обратимым идентификатором — данные остаются персональными. Провайдер квалифицируется как самостоятельный оператор, обрабатывающий ПДн без уведомления (ч. 10 ст. 13.11, штраф 100 000–300 000 ₽) и без правового основания (ч. 1 ст. 13.11). Стратегия: применить методы обезличивания по приказу РКН — введение суррогатных идентификаторов с уничтожением таблицы соответствия, обобщение числовых признаков до диапазонов. После верификации обезличивания — провайдер вправе работать с данными самостоятельно.

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

Как это применяется на практике

Кейс 1. IT-компания (Сибирский ФО, осень 2025) — провайдер CRM-платформы для малого бизнеса. При аудите выяснилось: 47 из 60 договоров с арендаторами не содержали поручения на обработку ПДн. После обращения в DATUM юристы разработали стандартное приложение о поручении, провели массовое переподписание за 18 рабочих дней. Параллельно выявлено несоответствие УЗ инфраструктуры: провайдер применял УЗ-3, тогда как среди арендаторов — медицинская лаборатория со специальными категориями ПДн. Проведена переклассификация до УЗ-2, дополнены меры по Приказу ФСТЭК №21. Плановая проверка РКН состоялась через 2 месяца и завершилась без протоколов.

Кейс 2. В деле об ML-обогащении (Центральный ФО, начало 2026) технический директор платформы электронной коммерции обнаружил при внутреннем аудите, что модель персонализации обучается на ПДн арендаторов, обезличенных только псевдонимизацией. Юристы DATUM совместно с командой разработки перевели пайплайн обучения на метод обобщения числовых признаков и декомпозиции. Данные прошли верификацию обезличивания. Провайдер переоформил статус с «обработчика по поручению» на «оператора обезличенных данных» — уведомление РКН скорректировано в течение 10 рабочих дней по ст. 22 ФЗ-152.

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

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

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

1. Какой УЗ выбрать для SaaS-платформы с разнородными арендаторами?

Выбирайте уровень защищённости исходя из наиболее чувствительной категории ПДн среди всех арендаторов на платформе. Если хотя бы один арендатор обрабатывает специальные категории ПДн по ст. 10 ФЗ-152 (здоровье, биометрия, национальность), вся инфраструктура должна соответствовать УЗ-2 или УЗ-1 в зависимости от типа угроз и числа субъектов по ПП РФ №1119. Применение УЗ-3 в таких случаях — прямое нарушение ст. 19 ФЗ-152 и основание для предписания ФСТЭК.

2. Можно ли использовать иностранные облака для хранения ПДн российских пользователей?

Нет, если речь идёт о первичном сборе, хранении или систематизации ПДн граждан РФ. Ч. 5 ст. 18 ФЗ-152 требует размещения баз данных в России. Нарушение — штраф по ч. 8 ст. 13.11 КоАП от 1 000 000 до 6 000 000 ₽. Допустимо использовать зарубежные облака только для хранения копий ПДн после первичной обработки в российских базах, при условии соблюдения требований трансграничной передачи по ст. 12 ФЗ-152 и уведомления РКН.

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

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

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

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

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

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

Итог

В SaaS-модели оператором ПДн почти всегда является клиент-арендатор, а провайдер — обработчик по поручению по ст. 6 ч. 3 ФЗ-152. Исключения: провайдер обрабатывает данные для собственных целей, агрегирует ПДн между арендаторами или обучает ML-модели на необезличенных данных. В каждом из этих случаев провайдер приобретает статус самостоятельного оператора со всеми вытекающими обязательствами — уведомлением РКН, соответствием УЗ по ПП РФ №1119 и реализацией мер по Приказу ФСТЭК №21.

Практика DATUM включает сопровождение SaaS-провайдеров при разграничении ролей, разработке поручений на обработку, классификации ИСПДн в мультиарендных архитектурах и прохождении проверок РКН и ФСТЭК.