Sub-processors в SaaS: цепочка поручений

С 30.05.2025 ст. 13.11 КоАП насчитывает 18 частей, и часть из них напрямую затрагивает архитектурные решения SaaS-команд: локализация данных (ч. 8), неуведомление об утечке (ч. 11), утечка от 1 000 субъектов (ч. 12–14). CTO, который не зафиксировал договором каждый sub-processor в стеке, создаёт прямой путь к протоколу РКН. Ниже — системный разбор: правовая конструкция поручения, архитектурные паттерны, требования ФСТЭК по уровням защищённости и конкретные сценарии для мультиарендных платформ.

Как работает конструкция поручения обработки в 152-ФЗ?

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

Ключевой практический момент: закон не запрещает цепочку «оператор → обработчик → sub-processor». Но он не создаёт для неё отдельного регулирования. Это означает, что в российском праве sub-processor — это тоже обработчик по поручению, и между каждыми двумя звеньями цепочки должен быть самостоятельный договор, соответствующий п. 3 ст. 6 ФЗ-152. Разрыв в любом звене — ответственность у оператора верхнего уровня.

Для SaaS это создаёт трёхуровневую модель: клиент (оператор ПДн своих пользователей) → SaaS-вендор (обработчик по поручению клиента) → инфраструктурный провайдер, аналитический сервис, ML-платформа (sub-processors). Если клиент — компания с 50 000 пользователей, то весь трафик данных через стек SaaS-платформы покрыт только тогда, когда каждый уровень закрыт договором.

Чем мультиарендность усложняет цепочку sub-processors?

Мультиарендная SaaS (multi-tenant) обрабатывает ПДн нескольких операторов-клиентов в одной инфраструктуре. Это рождает четыре специфических правовых проблемы.

Первая — смешение данных разных операторов на уровне sub-processor. Если облачный провайдер не обеспечивает логическую изоляцию, один оператор фактически предоставляет доступ к данным своих субъектов другому оператору. Это нарушение ст. 5 ФЗ-152 (принцип совместимости целей) и потенциально ч. 1 ст. 13.11 КоАП.

Вторая — разные уровни защищённости у разных клиентов. Клиент с медицинскими данными требует УЗ-3 по ПП РФ №1119, клиент с общедоступными данными — УЗ-4. На одной инфраструктуре SaaS-платформа обязана либо физически разделить контуры, либо обеспечить режим УЗ-3 для всех арендаторов — что существенно дороже.

Третья — уведомление в реестр РКН. SaaS-вендор как обработчик в реестр не вносится: вносится оператор-клиент. Но если SaaS-платформа одновременно является оператором (собирает логи пользовательских действий, данные телеметрии, cookies авторизации), она обязана самостоятельно подать уведомление по ст. 22 ФЗ-152 и корректно разграничить два потока обработки.

Четвёртая — утечка у sub-processor. По сложившейся позиции судебной практики, оператор несёт ответственность за утечку, произошедшую у обработчика или sub-processor, если договором не была обеспечена надлежащая защита. 24-часовой дедлайн по ч. 3.1 ст. 21 ФЗ-152 начинает течь с момента, когда оператор узнал или должен был узнать об инциденте — независимо от того, на каком уровне стека он произошёл.

Какой уровень защищённости выбрать для SaaS по ПП РФ №1119?

Уровень защищённости информационной системы персональных данных (ИСПДн) определяется тремя параметрами: категория данных, тип угроз и количество субъектов. Для SaaS-платформы с мультиарендностью базовая логика следующая.

Если хотя бы один клиент передаёт специальные категории ПДн (здоровье, политические взгляды, биометрия) — система обязана соответствовать УЗ-3 как минимум, а при актуальных угрозах второго типа — УЗ-2. Порог 100 000 субъектов влияет на повышение УЗ при общих ПДн: до 100 000 субъектов с общими ПДн и угрозами третьего типа — УЗ-4, выше 100 000 — УЗ-3.

Для мультиарендной SaaS практически значимы два сценария. Первый: платформа обрабатывает только общие ПДн (ФИО, email, телефон, история заказов) и клиентов до 100 000 субъектов у каждого арендатора — достаточен УЗ-4. Второй: хотя бы один арендатор работает с медицинскими или HR-данными (специальная категория по ст. 10 ФЗ-152) — весь контур должен обеспечивать УЗ-3 или производиться физическое разделение.

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

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

ML-пайплайны — один из самых проблемных sub-processors в SaaS-архитектуре. Если модель обучается на реальных пользовательских данных без обезличивания, это обработка ПДн со всеми вытекающими требованиями: правовое основание, уровень защищённости, включение провайдера ML-инфраструктуры в цепочку поручений.

С 2025 года в действие вошли методы обезличивания, установленные подзаконным актом РКН: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. После корректного обезличивания данные выходят из-под действия ФЗ-152 — и sub-processor, работающий только с обезличенными данными, не создаёт обязательств по поручению.

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

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

Можно ли использовать иностранные облака как sub-processors?

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

Для SaaS-платформы это означает: если облачный провайдер (sub-processor) физически хранит данные за пределами РФ — это нарушение локализации. Штраф по ч. 8 ст. 13.11 КоАП — от 1 000 000 до 6 000 000 ₽, при повторности (ч. 9) — от 6 000 000 до 18 000 000 ₽.

Практически используемые решения: российские облачные провайдеры (Yandex Cloud, SberCloud, МТС Cloud, «Облако.ру»), размещение в аттестованных ЦОД на территории РФ. Если иностранный провайдер физически разворачивает зону в РФ — локализационное требование считается выполненным при условии, что данные не реплицируются за рубеж.

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

Практические сценарии: как цепочка ломается

Сценарий 1. Аналитический sub-processor без договора. Ситуация: SaaS-платформа (Приволжский ФО, середина 2025) подключила сервис продуктовой аналитики, передающий в него события с ФИО и email пользователей. Договор поручения отсутствовал — только «Terms of Service» провайдера. При проверке РКН установлено отсутствие договора по п. 3 ст. 6 ФЗ-152 и факт трансграничной передачи без уведомления. Исход: протокол по ч. 1 ст. 13.11 и ч. 8 ст. 13.11 — штрафы в совокупности в сотни тысяч рублей. Стратегия: до подключения любого внешнего сервиса, получающего ПДн, — договор поручения с перечнем действий, данных и требованием защиты.

Сценарий 2. ML-инфраструктура на иностранном облаке. Ситуация: технический директор компании (Центральный ФО, осень 2025) обучал рекомендательную модель на поведенческих данных пользователей, переданных в облачный ML-сервис за рубежом. Данные не были обезличены. Локализационное требование нарушено. Трансграничное уведомление не подавалось. Доказательства нарушения: логи исходящего трафика с ПДн, записи в базе иностранного провайдера. Вероятный исход: ч. 8 ст. 13.11 (1–6 млн ₽) + ч. 1 ст. 13.11 (до 300 000 ₽). Стратегия: обезличивание данных до передачи в ML-инфраструктуру либо перенос обучения в аттестованный облачный контур в РФ.

Сценарий 3. Утечка у sub-processor — дедлайн у оператора. Ситуация: провайдер мониторинга инфраструктуры (sub-processor SaaS-платформы) уведомил CTO об инциденте через 30 часов после его обнаружения. К этому моменту 24-часовой дедлайн на первичное уведомление РКН уже истёк. Исход: штраф по ч. 11 ст. 13.11 (1–3 млн ₽). Стратегия: в договор с каждым sub-processor включать требование немедленного (не позднее 6 часов) уведомления SaaS-платформы о любом инциденте с ПДн — с запасом для соблюдения 24-часового срока перед РКН.

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

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

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

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

Уровень защищённости определяется по ПП РФ №1119 исходя из категории ПДн, типа угроз и числа субъектов. Для мультиарендной SaaS с общими ПДн и клиентами до 100 000 субъектов при угрозах третьего типа достаточен УЗ-4. Если хотя бы один арендатор передаёт специальные категории (здоровье, биометрия, HR-данные работников) — весь контур должен соответствовать УЗ-3. Практически: определите «верхнюю планку» среди всех арендаторов и применяйте её ко всей инфраструктуре либо физически разделяйте контуры.

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

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

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

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

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

В мультиарендной SaaS роли разделены: клиент (арендатор) является оператором ПДн своих пользователей — он определяет цели и состав обработки. SaaS-вендор — обработчик по поручению клиента. Однако если SaaS-платформа самостоятельно собирает данные пользователей (логи, телеметрия, cookies авторизации) для своих целей (улучшение продукта, аналитика), она становится самостоятельным оператором в отношении этих данных и обязана подать уведомление в РКН по ст. 22 ФЗ-152.

5. Какие СЗИ обязательны?

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

Итог

Цепочка sub-processors в SaaS — это не архитектурная деталь, а правовая конструкция, каждое звено которой должно быть закрыто договором поручения по п. 3 ст. 6 ФЗ-152. Мультиарендность, ML-инфраструктура и иностранные облака создают три самостоятельных зоны риска: нарушение локализации (ч. 8 ст. 13.11, до 6 млн ₽), утечка через sub-processor (ч. 12–14, до 15 млн ₽) и пропущенный дедлайн уведомления РКН (ч. 11, до 3 млн ₽).

DATUM сопровождает SaaS-команды в части 152-ФЗ: аудит цепочки поручений, определение уровней защищённости, DPIA для сложных архитектур, комплект ОРД включая договоры с sub-processors.

14 апреля 2029 года