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

Мультиарендная SaaS-архитектура удобна технически, но создаёт правовую неопределённость в части 152-ФЗ. Большинство CTO узнают об этом при первой проверке РКН или после инцидента. Разбираем, что именно проверять у провайдера, как соотнести уровни защищённости с реальной архитектурой и где граница ответственности между клиентом и SaaS-компанией.

Кто за что отвечает в модели SaaS: оператор, обработчик, поручение?

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

На практике это означает: если провайдер допустил утечку, протокол по ст. 13.11 КоАП составляется в отношении оператора-клиента, а не провайдера. Суд не освобождает оператора от ответственности со ссылкой на чужую инфраструктуру — это подтверждает и сложившаяся практика по принципу ответственности за подрядчика.

В мультиарендной SaaS-архитектуре дополнительный риск — смешение данных разных клиентов на уровне хранения или логирования. Если изоляция арендаторов реализована только на уровне приложения, а не на уровне базы данных или файловой системы, единый инцидент затрагивает всех. Аудит должен проверить именно технические границы изоляции.

Как выбрать уровень защищённости (УЗ) для SaaS-системы?

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

Для SaaS-клиентов типичная ситуация — УЗ-3 или УЗ-2, но граница между ними не очевидна без формализованной модели угроз. УЗ-1 присваивается системам с биометрическими или специальными категориями ПДн при угрозах первого типа; УЗ-4 — минимальный, применим только к общедоступным ПДн при отсутствии угроз первого и второго типов.

Ошибка, которую делают чаще всего: присваивают УЗ-4 «на глаз», не фиксируя модель угроз документально. Если при проверке РКН обнаружится, что фактические угрозы соответствуют первому или второму типу, назначенный УЗ-4 будет квалифицирован как нарушение ст. 19 ФЗ-152 с санкцией по ч. 1 ст. 13.11 КоАП — штраф 150–300 тыс. ₽.

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

Что проверять у SaaS-провайдера по Приказу ФСТЭК №21?

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

При аудите SaaS-провайдера запросите следующие документы и артефакты:

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

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

Ч. 5 ст. 18 ФЗ-152 требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан РФ осуществлялись исключительно в базах данных, находящихся на территории России. Норма действует с 01.09.2015, однако правоприменение ужесточилось после поправок 2024–2025 годов.

С 01.07.2025 вступили в силу изменения, усилившие требования локализации в части запрета первичного сбора данных в иностранной инфраструктуре. Это напрямую затрагивает использование Salesforce, HubSpot, Zendesk и аналогичных платформ, если в них попадают ПДн граждан РФ. Штраф за нарушение локализации — по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽, при повторности по ч. 9 — от 6 до 18 млн ₽.

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

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

Обучение ML-моделей на реальных персональных данных — распространённая практика в продуктовых SaaS-командах. С точки зрения ФЗ-152 обучение на ПДн без согласия субъекта или иного правового основания по ст. 6 является нарушением. Выход — обезличивание данных до начала обучения.

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

Для ML-задач наиболее применимы методы обобщения и введения идентификаторов. Обобщение заменяет точные значения диапазонами (возраст «34» → «30–39»), идентификаторы — случайными токенами без возможности обратного преобразования. Если обратное преобразование технически возможно — данные не являются обезличенными и требуют полного соответствия нормам ФЗ-152.

При аудите SaaS-провайдера, использующего данные клиентов для дообучения моделей, проверьте: есть ли в договоре право провайдера использовать ПДн клиентов для ML; какой метод обезличивания применяется; задокументирован ли процесс в соответствии с требованиями РКН.

Практика: два сценария аудита SaaS со стороны клиента

Сценарий 1. CTO обнаружил отсутствие договора-поручения. IT-компания из Сибирского ФО подключила CRM-систему иностранного SaaS-провайдера в 2022 году. В ходе внутреннего аудита осенью 2025 года CTO установил: договор с провайдером не содержит раздела о поручении обработки ПДн по ст. 6 ФЗ-152, модель угроз отсутствует, данные синхронизируются с серверами в Германии без уведомления РКН. Компания инициировала переговоры с провайдером, заключила дополнительное соглашение с разделом о поручении, уведомила РКН о трансграничной передаче. Проверка РКН, назначенная на начало 2026 года, не выявила нарушений по локализации — предписания не последовало. Ключевой фактор: нарушение устранено до начала проверки, что позволило избежать штрафа по ч. 8 ст. 13.11 КоАП в диапазоне 1–6 млн ₽.

Сценарий 2. Инцидент через провайдера и ответственность оператора. Финтех-компания (Центральный ФО, начало 2026 года) использовала SaaS-платформу для хранения анкет клиентов. После утечки на стороне провайдера данные более 15 000 субъектов оказались в открытом доступе. CTO направил первичное уведомление в РКН в течение 20 часов с момента обнаружения, через 68 часов — отчёт о расследовании. РКН возбудил дело по ч. 13 ст. 13.11 КоАП (штраф для юрлиц 5–10 млн ₽). В ходе производства компания представила договор-поручение, документально подтверждённые меры по УЗ-3 и факт оперативного уведомления. Суд назначил штраф в нижней части диапазона с учётом смягчающих обстоятельств. Провайдер, не имевший статуса оператора, к административной ответственности по ст. 13.11 привлечён не был. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Аудит SaaS-провайдера со стороны клиента — это не разовая проверка документов, а системная оценка: соответствие уровня защищённости реальной модели угроз, корректность договора-поручения, подтверждение локализации и готовность провайдера к 24-часовому уведомлению при инциденте. Ответственность за нарушения в любом из этих пунктов несёт оператор-клиент, а не провайдер.

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