GDPR vs 152-ФЗ для SaaS

С 01.07.2025 требования к локализации персональных данных граждан РФ ужесточились. Одновременно действующий в ЕС GDPR предъявляет собственный набор требований к субъектам данных, находящимся на территории Евросоюза. Для SaaS-компании с мультирегиональной базой клиентов это означает необходимость проектировать архитектуру хранения, логирование и механизмы согласий под два параллельных режима. Ниже — технический и правовой разбор ключевых пересечений и расхождений, практика выбора уровня защищённости и требования к обезличиванию для ML-моделей.

Чем GDPR и 152-ФЗ принципиально различаются для SaaS-архитектуры?

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

GDPR, напротив, оперирует не географией инфраструктуры, а принципом применимости к субъектам данных: регламент распространяется на любую обработку данных жителей ЕС вне зависимости от местонахождения оператора (ст. 3 GDPR). Для SaaS это означает, что даже полностью российская инфраструктура попадает под GDPR, если продукт направлен на пользователей из ЕС или мониторирует их поведение.

Второе принципиальное расхождение — правовое основание обработки. 152-ФЗ допускает широкий перечень оснований по ст. 6: договор, закон, согласие, законный интерес в ограниченных случаях. GDPR явно называет «законный интерес» (legitimate interest) как самостоятельное основание по ст. 6(1)(f) с обязательным балансировочным тестом. Это создаёт асимметрию: одно и то же действие с данными может быть законным по GDPR и требовать отдельного согласия по 152-ФЗ.

Третье расхождение — права субъектов данных. GDPR закрепляет право на переносимость данных (ст. 20), право на забвение (ст. 17) и право не подвергаться автоматизированному принятию решений (ст. 22). В 152-ФЗ аналогом права на забвение служат ст. 21 (устранение нарушений при обращении субъекта) и ст. 14 (право на доступ к информации об обработке), однако право на переносимость в структурированном машиночитаемом формате в российском законодательстве прямо не закреплено.

Какой уровень защищённости выбрать для SaaS — УЗ-1, УЗ-2, УЗ-3 или УЗ-4?

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

Для типового B2B SaaS (CRM, HR-платформа, финансовый сервис) стандартная логика такова:

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

Ключевая ошибка CTO в SaaS-контексте — занижение типа угроз без формального обоснования. Тип угроз определяется не самостоятельно, а на основе модели угроз, разрабатываемой с учётом методических документов ФСТЭК. При использовании публичного облака российского провайдера угрозы 2-го типа становятся актуальными по умолчанию для большинства архитектур — что автоматически поднимает УЗ на ступень выше.

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

Для SaaS-мультиаренды (multi-tenant) возникает дополнительный вопрос: один уровень для всей системы или раздельная классификация по тенантам. Формально 152-ФЗ и ПП №1119 не запрещают мультиарендную архитектуру, но оператор обязан обеспечить изоляцию данных разных клиентов и независимость применяемых мер защиты. На практике это означает, что УЗ системы определяется по наиболее чувствительному тенанту.

Как устроено поручение обработки в SaaS и кто остаётся оператором?

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

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

В терминах GDPR аналогичная конструкция — controller (клиент) и processor (провайдер). Обязательный документ — Data Processing Agreement (DPA) по ст. 28 GDPR с указанием предмета и срока обработки, характера и цели, типа ПДн, категорий субъектов и обязанностей процессора. Отличие от 152-ФЗ: GDPR прямо обязывает процессора не привлекать субпроцессоров без явного согласия контроллера, тогда как в российском законодательстве субпоручение регулируется менее строго.

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

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

С 2025 года применяются пять методов обезличивания, установленных подзаконным актом РКН:

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

Практически важный момент: псевдонимизация (введение идентификаторов с сохранением таблицы соответствия у оператора) по российским нормам не является обезличиванием — обезличенные данные должны быть необратимо или функционально несвязаны с субъектом без внешней информации. По GDPR псевдонимизация прямо упомянута как рекомендуемая мера защиты (Recital 29), но псевдонимизированные данные остаются персональными данными, если оператор сохраняет ключ соответствия.

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

Как учитывать 152-ФЗ при использовании иностранных облаков и инструментов аналитики?

Salesforce, AWS, Azure, Google Cloud — популярные инфраструктурные решения для SaaS. Их использование в связке с данными граждан РФ создаёт три типа правовых рисков.

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

Риск 2 — трансграничная передача без уведомления. Даже если локализация соблюдена, передача данных в иностранную систему (например, в CRM Salesforce или аналитику GA4) квалифицируется как трансграничная передача по ст. 12 152-ФЗ. Для стран, не включённых в перечень стран с адекватным уровнем защиты ПДн (США в него не входят), требуется предварительное уведомление РКН.

Риск 3 — отсутствие поручения с иностранным провайдером. Использование иностранного облака или SaaS-инструмента без надлежащего договора поручения создаёт ситуацию, в которой иностранный провайдер фактически обрабатывает ПДн граждан РФ без правового основания.

Практическое решение для SaaS: разделение потоков данных по гражданству субъектов. Данные российских пользователей — первичная запись в российском облаке (Яндекс.Облако, VK Cloud, Selectel, МТС Линк и аналоги) с последующей репликацией в глобальный кластер для аналитики. При этом в глобальный кластер передаются уже обезличенные или агрегированные данные. Это позволяет сохранить единую аналитическую инфраструктуру, не нарушая требования локализации.

Что касается КИИ (критической информационной инфраструктуры по 187-ФЗ): SaaS-платформы, предоставляющие услуги субъектам КИИ (банкам, операторам связи, энергетике, здравоохранению), могут сами получить статус объекта КИИ — с дополнительными требованиями по мониторингу инцидентов через ГосСОПКА. Это пересекается с требованиями 152-ФЗ, но не заменяет их.

Практика применения: три типовых сценария для CTO

Сценарий 1. B2B SaaS с российскими корпоративными клиентами, инфраструктура в AWS.

Ситуация: CRM-система для отдела продаж обрабатывает контакты менеджеров и клиентов. Первичная запись — в AWS eu-west. Число субъектов превышает 100 000. Поручения обработки с тенантами не оформлены.

Доказательства нарушения при проверке РКН: логи записи данных в иностранный датацентр, отсутствие договора поручения, отсутствие уведомления о трансграничной передаче.

Вероятный исход: протокол по ч. 8 ст. 13.11 (локализация, 1–6 млн ₽) и по ч. 10 ст. 13.11 (отсутствие уведомления о трансграничной передаче, 100–300 тыс. ₽). При повторной проверке — ч. 9 (6–18 млн ₽).

Стратегия: миграция первичной записи в российский датацентр, оформление договоров поручения с клиентами, уведомление РКН о трансграничной передаче для аналитических данных, оформление обезличивания перед передачей в AWS.

Сценарий 2. EdTech SaaS с аудиторией в России и ЕС, единая платформа.

Ситуация: платформа онлайн-образования собирает данные студентов из РФ и ЕС в единой базе PostgreSQL в Hetzner (Германия). ML-модель рекомендаций обучается на полном датасете, включая ПДн.

Доказательства нарушения: отсутствие разделения баз по юрисдикции, обучение ML на необезличенных данных граждан РФ, отсутствие DPA с Hetzner как процессором.

Вероятный исход: нарушение ч. 5 ст. 18 152-ФЗ + нарушение Art. 28 GDPR (отсутствие DPA). РКН вправе вынести предписание о блокировке обработки до устранения нарушений.

Стратегия: разделение баз данных (российский кластер + европейский кластер), обезличивание датасетов перед обучением ML одним из пяти методов, заключение DPA с Hetzner, уведомление РКН.

Сценарий 3. SaaS-провайдер без уведомления в реестре РКН, клиенты — юрлица.

Ситуация: B2B-платформа автоматизации HR-процессов обрабатывает личные дела сотрудников клиентов. Позиция CTO: «мы обрабатываем только данные юрлиц». РКН не уведомлён.

Доказательства нарушения: данные о ФИО, должностях, зарплатах, паспортных данных — персональные данные физических лиц. Поручение от клиентов не оформлено — провайдер самостоятельный оператор.

Вероятный исход: штраф по ч. 10 ст. 13.11 (отсутствие уведомления, 100–300 тыс. ₽), дополнительно — по ч. 3 (отсутствие политики обработки, 30–60 тыс. ₽).

Стратегия: немедленное уведомление РКН через pd.rkn.gov.ru, публикация политики обработки ПДн, оформление договоров поручения с клиентами.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

Команда DATUM сопровождает SaaS-компании в определении уровней защищённости, оформлении договоров поручения с клиентами, подготовке уведомлений о трансграничной передаче и документировании процедур обезличивания для ML-пайплайнов.