DATUM-сопровождение SaaS-стартапов

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

Кто является оператором в мультиарендной SaaS-архитектуре?

В мультиарендной (multi-tenant) SaaS-модели один и тот же программный слой обслуживает десятки или сотни клиентов-юрлиц, каждый из которых загружает собственные данные своих пользователей. Это создаёт нетривиальную конфигурацию ролей по ФЗ-152.

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

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

Отдельный вопрос — работа с данными сотрудников: разработчики, менеджеры, специалисты поддержки. Здесь SaaS-компания однозначно оператор, а применимые нормы пересекаются с трудовым законодательством (ст. 86–88 ТК РФ). С 01.09.2025 согласие работника на обработку ПДн — отдельный документ по требованиям ФЗ-156 от 24.06.2025.

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

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

Для SaaS-продукта ключевые переменные выглядят следующим образом:

• Категория данных. Если продукт обрабатывает только имя, email, телефон, должность — это общие ПДн. Если к ним добавляются состояние здоровья, национальность, политические взгляды или судимость — это специальные категории по ст. 10 ФЗ-152 с отдельным режимом обработки. Биометрия (изображение лица, голос, отпечатки) — ст. 11 ФЗ-152 и требования ФЗ-572.
• Тип угроз. Угрозы 1-го типа предполагают недокументированные возможности в системном ПО, 2-го — в прикладном, 3-го — актуальны только угрозы не связанные с НДВ. Для большинства коммерческих SaaS-продуктов актуален тип 3 при наличии обоснования.
• Число субъектов. Порог — 100 000. Ниже порога при типе угроз 3 и общих ПДн — УЗ-4 (минимальный набор мер). Выше порога — переход на УЗ-3.

Большинство B2B SaaS-стартапов на общих ПДн с типом угроз 3 и числом субъектов менее 100 тыс. работают на УЗ-4. Это 11 базовых мер: идентификация и аутентификация, управление доступом, защита машинных носителей, регистрация событий безопасности, антивирусная защита и ряд других. При превышении порога 100 тыс. субъектов или переходе на специальные категории ПДн — обязателен УЗ-3 с расширенным составом мер по Приказу ФСТЭК №21.

Облачная инфраструктура не освобождает от обязанности определить УЗ и задокументировать выбор мер. Если SaaS работает на AWS, GCP или Azure — с 01.07.2025 (требования по локализации по ч. 5 ст. 18 ФЗ-152 в ред. ФЗ-233) хранение и первичный сбор ПДн граждан РФ обязаны происходить в базах, физически расположенных в России. Зарубежные дата-центры допустимы только для последующей обработки уже локализованных данных — и только при соблюдении требований о трансграничной передаче по ст. 12 ФЗ-152.

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

Обучение ML-моделей на пользовательских данных — стандартная практика для SaaS-продуктов: рекомендательные системы, предиктивная аналитика, классификаторы, детекторы аномалий. С точки зрения ФЗ-152 этот процесс порождает отдельный риск: необезличенные ПДн, используемые для обучения модели, остаются ПДн со всеми обязанностями оператора.

С 2025 года действует регулирование обезличенных ПДн по ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024). Регулятор установил пять методов обезличивания. Если данные обезличены корректно — они выходят из-под режима ФЗ-152 и могут передаваться, в том числе в системы ML, без согласия субъекта.

• Введение идентификаторов — замена прямых идентификаторов (ФИО, email) на псевдонимы с хранением таблицы соответствия отдельно.
• Изменение состава и семантики — удаление или обобщение атрибутов (точный возраст → возрастная группа).
• Декомпозиция — разделение набора данных так, чтобы ни одна часть не позволяла идентифицировать субъекта.
• Перемешивание — нарушение связи между записями разных атрибутов одного субъекта.
• Обобщение (агрегация) — переход от индивидуальных значений к групповым статистикам.

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

Что входит в базовый комплаенс для SaaS-оператора?

Приведение SaaS-продукта в соответствие с ФЗ-152 — это не разовая задача, а набор процессов. Ниже — минимально необходимый состав для стартапа на стадии роста.

Помимо документационного пакета, СТО обязан обеспечить технические меры, соответствующие определённому УЗ. Для УЗ-4 минимальный набор включает: управление доступом (ролевая модель, принцип наименьших привилегий), регистрацию событий безопасности (логирование), антивирусную защиту и защиту машинных носителей при их использовании. При работе с иностранными облачными провайдерами обязательно оценить применимость Приказа ФСТЭК №21 к конкретной схеме развёртывания.

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

Какие сценарии чаще всего приводят SaaS-стартапы к штрафу?

Три типовых сценария, с которыми DATUM встречается при работе с IT-компаниями.

Сценарий 1. Продукт запущен, уведомление не подано. Ситуация: SaaS работает год-два, обрабатывает ПДн клиентов клиентов (end-users), уведомления в реестре РКН нет. Доказательства: факт обработки устанавливается РКН через публичный сайт, пользовательское соглашение и техническую проверку. Вероятный исход: штраф 100–300 тыс. ₽ по ч. 10 ст. 13.11 КоАП за неуведомление. Стратегия: подать уведомление немедленно (снижает вероятность штрафа или его размер), для повторного нарушения — диапазон уже 300–500 тыс. ₽ по ч. 1.1.

Сценарий 2. Облако в Германии, пользователи — граждане РФ. Ситуация: CTO выбрал AWS Frankfurt как основной регион из соображений latency. После 01.07.2025 первичный сбор и хранение ПДн граждан РФ в зарубежной инфраструктуре нарушает ч. 5 ст. 18 ФЗ-152. Доказательства: IP хостинга устанавливается автоматически при проверке РКН. Вероятный исход: штраф 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП (нарушение локализации), при повторном — 6–18 млн ₽. Стратегия: перенести первичную базу в облако с российскими дата-центрами (Яндекс.Облако, SberCloud, VK Cloud); зарубежная реплика допустима при надлежащем уведомлении о трансграничной передаче.

Сценарий 3. Утечка данных через уязвимость зависимости. Ситуация: CI/CD-пайплайн использует уязвимую версию open-source библиотеки; злоумышленник получил доступ к БД с email и телефонами 15 000 пользователей. Инцидент обнаружен командой безопасности. Доказательства: факт утечки фиксируется в логах и подтверждается появлением данных в даркнете. Вероятный исход: штраф 3–5 млн ₽ по ч. 12 ст. 13.11 (утечка 1–10 тыс. субъектов) или 5–10 млн ₽ по ч. 13 (10–100 тыс.). Стратегия: уведомить РКН в течение 24 часов, подать отчёт за 72 часа, зафиксировать меры по устранению уязвимости — это влияет на размер штрафа и применимость ст. 4.1 КоАП.

Как применяется КИИ 187-ФЗ к SaaS-продуктам?

ФЗ-187 о безопасности критической информационной инфраструктуры (КИИ) распространяется на субъекты КИИ — организации в сферах здравоохранения, науки, транспорта, связи, энергетики, финансов и ряде других. Сам по себе SaaS-стартап не является субъектом КИИ, если не работает в этих сферах и не признан таковым регулятором.

Однако если SaaS-продукт используется организацией — субъектом КИИ, и стартап является интегрированным в её информационную инфраструктуру подрядчиком, возникают договорные обязательства перед клиентом по выполнению требований безопасности КИИ. Это не прямая ответственность по ФЗ-187, но риск потери контракта и репутационный риск при инциденте на стороне клиента.

Для SaaS-продуктов в сферах медицины, образования или финтеха — сочетание 152-ФЗ и 187-ФЗ становится реальным комплаенс-требованием при росте бизнеса, и его лучше учитывать на этапе архитектурных решений, а не после получения протокола.

Кейс 1. IT-компания (Сибирский ФО, начало 2026), разработчик B2B SaaS для HR-автоматизации. При расширении клиентской базы выше 80 тыс. субъектов CTO инициировал аудит — выявлено отсутствие документации по УЗ, договоров поручения обработки с клиентами и уведомления в реестре РКН. DATUM подготовил полный пакет ОРД, подал уведомление и разработал типовой договор поручения. Компания прошла плановую проверку РКН без штрафов.

Кейс 2. SaaS-стартап в области аналитики данных (Центральный ФО, осень 2025), использовавший пользовательские данные для обучения рекомендательной модели. При обращении выяснилось: датасет содержал необезличенные email и идентификаторы пользователей. DATUM оценил схему обработки, разработал методологию обезличивания с применением метода введения идентификаторов и декомпозиции, подготовил DPIA. Компания устранила нарушение до обращения РКН.

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

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

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

1. Какой УЗ выбрать для SaaS с общими ПДн и числом субъектов менее 100 тысяч?

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

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

С 01.07.2025, после вступления в силу требований по локализации (ч. 5 ст. 18 ФЗ-152 в редакции ФЗ-233), первичный сбор, систематизация, накопление и хранение ПДн граждан РФ должны осуществляться в базах данных, физически расположенных в России. AWS Frankfurt, Google Cloud Europe, Azure West Europe — не соответствуют этому требованию в качестве основного хранилища. Последующая передача уже локализованных данных в зарубежную инфраструктуру возможна при выполнении требований ст. 12 ФЗ-152 о трансграничной передаче и уведомлении РКН. Нарушение локализации — штраф 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП, повторное — 6–18 млн ₽.

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

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

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

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

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

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

Итог

SaaS-стартап как оператор или обработчик ПДн несёт полный объём обязанностей по ФЗ-152: уведомление РКН, определение и документирование уровня защищённости по ПП РФ №1119, применение мер по Приказу ФСТЭК №21, соблюдение локализации, регламентация ML-пайплайнов через обезличивание по ст. 13.1. С 30.05.2025 цена несоблюдения — оборотный штраф до 500 млн ₽ при повторной утечке.

DATUM сопровождает IT-компании и SaaS-стартапы в выстраивании комплаенса по 152-ФЗ: от определения ролей в мультиарендной архитектуре до аудита ML-пайплайнов, разработки ОРД и сопровождения проверок РКН. Практика «Ветров и партнёры» работает с операторами ПДн с 2014 года.