Сертификация SaaS на 152-ФЗ

Понятия «сертификация по 152-ФЗ» в законе нет — есть требование привести информационную систему в соответствие с уровнем защищённости (УЗ) и выполнить меры по Приказу ФСТЭК №21. Для SaaS это означает: определить УЗ для каждого арендатора, выстроить поручение обработки, локализовать данные граждан РФ и подтвердить готовность организационно-распорядительной документацией. В 2025 году РКН зафиксировал 118 случаев компрометации баз; правоприменение по новым нормам ст. 13.11 только накапливается, и первые дела уже рассмотрены арбитражными судами.

Что такое «соответствие 152-ФЗ» для SaaS-продукта?

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

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

На практике это значит: в договоре с каждым B2B-клиентом должен быть раздел о поручении обработки с указанием целей, перечня ПДн, мер защиты и запрета передачи третьим лицам. Без этого раздела вендор рискует быть квалифицирован как самостоятельный оператор — с полным объёмом ответственности по ст. 13.11 КоАП.

Как определить уровень защищённости UZ для SaaS-арендаторов?

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

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

Типичный B2B-SaaS в секторе HR, CRM или ERP обрабатывает общие категории ПДн (ФИО, должность, контакты) — это УЗ-3 или УЗ-4. Если клиент — медицинская организация или страховщик с данными о состоянии здоровья пациентов, платформа автоматически переходит в зону УЗ-2 по ст. 10 ФЗ-152 (специальные категории). Этот факт нужно явно оговорить в политике обработки вендора и в договоре-поручении.

Какие технические меры ФСТЭК обязательны для SaaS?

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

Для SaaS с УЗ-3 ключевые группы мер — следующие.

• ИАФ (идентификация и аутентификация): многофакторная аутентификация для привилегированных учётных записей, разграничение сессий арендаторов.
• УПД (управление правами доступа): ролевая модель, принцип наименьших привилегий, контроль административного доступа к данным арендаторов.
• РСБ (регистрация событий безопасности): логирование всех операций с ПДн — важно для SaaS, где журнал доступа является доказательством в случае инцидента.
• ЗИС (защита информационной системы): сегментация сети, защита API-шлюзов, шифрование трафика между компонентами.
• АВЗ (антивирусная защита) и СОВ (обнаружение вторжений): для облачных систем реализуются через контейнерную безопасность и SIEM.

Отдельный вопрос — применение сертифицированных средств защиты информации (СЗИ). Приказ ФСТЭК №21 допускает использование несертифицированных СЗИ при наличии иных компенсирующих мер и соответствующего обоснования в модели угроз. Требование обязательной сертификации СЗИ установлено для УЗ-1 и объектов КИИ по 187-ФЗ — для большинства коммерческих SaaS оно не является абсолютным.

Как работает локализация и облако в РФ для SaaS?

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

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

Практический выход — гибридная архитектура: первичные базы с ПДн граждан РФ размещаются у российского облачного провайдера (Яндекс Облако, VK Cloud, SberCloud), аналитика и обработка агрегированных данных — у любого провайдера при условии обезличивания. Трансграничная передача обезличенных данных уведомления РКН не требует — при соблюдении методов из Приказа РКН о методах обезличивания (5 методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация).

Обезличивание для ML: как обучать модели на ПДн без нарушений?

Обучение ML-моделей на персональных данных клиентов — одна из самых юридически неопределённых зон для SaaS. Исходные ПДн нельзя использовать для обучения без согласия субъекта (ст. 9 ФЗ-152) или иного правового основания. Но если данные обезличены по установленным методам — они перестают быть персональными и могут использоваться свободно.

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

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

Типовые ситуации: как это работает на практике

Ситуация 1. SaaS-платформа для HR без договора-поручения. IT-компания из Сибирского ФО предоставляла HR-SaaS корпоративным клиентам. Обработка ПДн сотрудников клиентов велась без раздела о поручении в договоре — вендор значился как самостоятельный оператор. При плановой проверке РКН (весна 2026) инспектор квалифицировал обработку как нарушение ч. 1 ст. 13.11 КоАП. CTO и генеральный директор получили предписание и протокол. Штраф составил несколько сотен тысяч рублей. После добавления раздела о поручении и актуализации реестра операторов нарушение было устранено; при обжаловании постановления суд снизил штраф до минимума, применив ст. 4.1 КоАП.

Ситуация 2. ML-обучение на исходных ПДн клиентов без обезличивания (Северо-Западный ФО, осень 2025). Финтех-SaaS использовал транзакционные данные клиентов-арендаторов для дообучения антифрод-модели. Данные не были обезличены — хранились в исходном виде с идентификаторами физических лиц. После жалобы одного из арендаторов РКН провёл внеплановую проверку. Квалификация — ч. 1 ст. 13.11 КоАП (обработка ПДн в целях, несовместимых с заявленными). Штраф в диапазоне 150–300 тыс. ₽. Технический директор инициировал разработку пайплайна обезличивания (агрегация + декомпозиция) и внёс изменения в политику обработки. Повторная проверка нарушений не выявила.

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

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

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

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

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

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

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

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

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

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

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

Итог

Соответствие SaaS-платформы требованиям 152-ФЗ — это архитектурное, юридическое и документационное решение одновременно. Правильный УЗ, договор-поручение с каждым арендатором, локализация первичных баз в РФ и обезличенный ML-пайплайн закрывают большинство оснований для претензий РКН и исключают оборотные штрафы по ч. 15 ст. 13.11 КоАП при повторном инциденте.

Юристы DATUM сопровождают SaaS-вендоров в полном цикле соответствия: от определения УЗ и разработки модели угроз до формирования комплекта ОРД и защиты в случае проверки или инцидента. Практика по 152-ФЗ в части IT-инфраструктуры ведётся с 2014 года.

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

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

16 февраля 2030 года