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

Российский рынок SaaS-решений столкнулся с кардинально изменившейся регуляторикой: ФЗ-420 от 30.11.2024 расширил ст. 13.11 КоАП до 18 частей, ФЗ-421 ввёл уголовную ответственность по ст. 272.1 УК, а с 01.07.2025 ужесточились требования локализации по ч. 5 ст. 18 ФЗ-152. В этой статье разобраны четыре типовых спора между SaaS-провайдером и клиентом — с анализом применимых норм, судебной практики и тактики защиты.

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

Ключевой вопрос любого спора — разграничение ролей. По ст. 3 ФЗ-152 оператор самостоятельно определяет цели и содержание обработки. Лицо, обрабатывающее ПДн по поручению оператора, оператором не является. SaaS-провайдер, предоставляющий инфраструктуру без самостоятельного определения целей, формально является обработчиком по поручению (п. 3 ст. 6 ФЗ-152). На практике граница размывается.

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

Судебная практика ВС РФ исходит из принципа: оператор отвечает за утечку через подрядчика как за свою собственную. Поэтому клиент-оператор, чьи данные «утекли» через дефект в SaaS-платформе, несёт ответственность перед субъектами ПДн, а уже в порядке регресса взыскивает убытки с провайдера. Этот принцип задаёт логику всех четырёх кейсов ниже.

Каким должен быть договор поручения обработки и что бывает без него?

Сценарий первый: SaaS-провайдер без договора поручения. Крупная российская HR-платформа (Центральный ФО, 2025 год) предоставляла клиентам-работодателям доступ к модулю обработки резюме. Договор с клиентами содержал лицензионное соглашение, но отдельного соглашения об обработке ПДн не было. После инцидента с утечкой базы соискателей РКН возбудил дело в отношении клиента-оператора по ч. 12 ст. 13.11 КоАП (утечка от 1 000 до 10 000 субъектов, штраф 3–5 млн ₽). Клиент предъявил иск к провайдеру о взыскании расходов на защиту и суммы штрафа.

Арбитражный суд округа отказал в иске к провайдеру, поскольку тот действовал как хостинг-провайдер, не имея доступа к содержимому баз данных. Отсутствие договора поручения обработки лишило клиента возможности ссылаться на п. 3 ст. 6 ФЗ-152 — не было зафиксировано ни поручение, ни перечень действий, ни обязанность провайдера обеспечить конфиденциальность.

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

Сценарий второй: несоответствие УЗ. Медицинская лаборатория (Северо-Западный ФО, осень 2025) использовала облачную МИС от SaaS-провайдера для хранения результатов анализов. Данные о здоровье относятся к специальным категориям ПДн по ст. 10 ФЗ-152. В сочетании с числом субъектов свыше 100 000 это требует УЗ-3 по ПП РФ №1119. Провайдер декларировал только УЗ-4.

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

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

Что происходит при локализации данных и иностранном облаке?

Сценарий третий: облако за рубежом. С 01.07.2025 требования ч. 5 ст. 18 ФЗ-152 о локализации стали жёстче: первичная запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны осуществляться в базах данных на территории России. SaaS-провайдер, использующий AWS eu-west или Azure Western Europe как основной регион хранения без репликации в российский регион, нарушает это требование.

IT-компания (Приволжский ФО, начало 2026) получила протокол по ч. 8 ст. 13.11 КоАП за хранение клиентских ПДн в облаке иностранного гипероблака. Штраф для юрлица по данной части составляет 1–6 млн ₽. Клиенты платформы, чьи ПДн оказались за рубежом, предъявили претензии о нарушении договора поручения обработки. Суд установил солидарную ответственность провайдера (технический исполнитель) с оговоркой, что финансовое бремя административного штрафа несёт лицо, привлечённое к ответственности, то есть сам оператор-клиент.

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

Как обезличивание для ML защищает от споров по ФЗ-152?

Сценарий четвёртый: ML-модели на клиентских данных. Ряд SaaS-провайдеров использует агрегированные данные клиентов для обучения моделей машинного обучения — прогнозирования оттока, скоринга, рекомендаций. С точки зрения ФЗ-152 это самостоятельная цель обработки, несовместимая с исходной (исполнение договора с субъектом). Нарушение принципа несовместимости целей — состав по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽ для юрлица), а при повторности — ч. 1.1 (300–500 тыс. ₽).

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

В разбираемом споре (Уральский ФО, лето 2025) клиент обнаружил в политике конфиденциальности SaaS-провайдера формулировку об «улучшении сервиса». Суд квалифицировал это как обработку в новой цели без согласия субъектов. Провайдер не смог доказать применение обезличивания по утверждённой методике. Решение: обязанность уничтожить производные датасеты и компенсация расходов клиента на переработку собственной политики конфиденциальности.

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

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

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

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

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

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

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

3. Что такое обезличивание для ML и как его документировать?

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

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

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

5. Какие СЗИ обязательны для SaaS при УЗ-3?

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

Итог

Четыре разобранных сценария показывают одну закономерность: основная часть споров SaaS-провайдера с клиентом возникает из-за трёх пробелов — отсутствия договора поручения обработки, неверно определённого УЗ и несогласованных целей использования данных. Новые штрафы ст. 13.11 КоАП с 30.05.2025 делают цену этих пробелов исчислимой: от 1 до 500 млн ₽ в зависимости от масштаба инцидента и повторности.

DATUM сопровождает SaaS-провайдеров и их клиентов в разграничении ролей по ФЗ-152, оценке уровней защищённости по ПП РФ №1119 и Приказу ФСТЭК №21, подготовке договоров поручения обработки и реагировании на инциденты в режиме 24/72 часа.

12 марта 2029 года