Migration между SaaS-провайдерами

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

Что такое migration с точки зрения 152-ФЗ?

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

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

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

Как выбрать уровень защищённости при смене SaaS-провайдера?

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

При migration UЗ не наследуется автоматически. Новый провайдер может иметь другую аппаратную архитектуру, иную модель угроз и другой сертифицированный состав средств защиты информации. CTO обязан переопределить модель угроз применительно к инфраструктуре нового провайдера и зафиксировать уровень защищённости в обновлённой документации до начала обработки ПДн.

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

Приказ ФСТЭК №21 содержит 109 мер в 15 группах. Базовый набор для УЗ-3 обязателен полностью; адаптация и дополнение — по результатам моделирования угроз. При migration CTO должен получить от нового провайдера подтверждение, какие меры реализованы на уровне инфраструктуры, а какие ложатся на прикладной уровень самого оператора.

Как соблюсти требования локализации при migration из зарубежного облака?

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

При migration из зарубежного SaaS (Salesforce, HubSpot, Workday, SAP SuccessFactors и аналогов) возникает переходный период, в течение которого данные одновременно находятся в двух местах. Юридически это квалифицируется как продолжающееся нарушение локализации до момента полного удаления ПДн из зарубежной системы. Штраф по ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽; повторное нарушение по ч. 9 — от 6 до 18 млн ₽.

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

Обезличивание для ML и логирование при migration: где риски?

При migration SaaS-провайдеры нередко сохраняют технологические логи с ПДн: идентификаторы пользователей, IP-адреса, временны́е метки транзакций. Логи, содержащие любой идентификатор физического лица, являются персональными данными по ст. 3 ФЗ-152. Хранение таких логов у старого провайдера после окончания migration — нарушение ч. 5 ст. 18 и ст. 21 ФЗ-152.

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

На практике при migration CTO сталкивается с двумя сценариями. Первый: провайдер предоставляет дамп данных в формате, где ПДн перемешаны с техническими полями, и обезличивание придётся делать на стороне оператора перед загрузкой в ML-платформу. Второй: новый провайдер сам предлагает услугу обезличивания в рамках ETL-пайплайна — в этом случае необходимо убедиться, что применяемый метод соответствует требованиям Приказа РКН о методах обезличивания.

Для SaaS-систем с функциями КИИ дополнительно применяются требования ФЗ-187. При migration критической информационной инфраструктуры необходимо уведомить ФСТЭК об изменении состава технических средств обработки информации.

Три сценария migration: риски и стратегии

Сценарий 1. Переезд с западного SaaS на российское облако (CTO крупного ритейлера, Центральный ФО, лето 2025). Технический директор запустил migration данных лояльности (4,2 млн субъектов) из зарубежной CRM в российский облачный ЦОД. Переходный период занял 47 дней, в течение которых данные дублировались в двух местах. РКН при плановой проверке зафиксировал нарушение ч. 5 ст. 18 ФЗ-152 и составил протокол по ч. 8 ст. 13.11 КоАП. Стратегия защиты: оператор представил письменное подтверждение о прекращении записи в зарубежную систему с первого дня migration и акт об уничтожении данных от старого провайдера. Суд учёл добросовестность и назначил минимальный штраф в диапазоне нижней трети санкции. ⚠️ Точные реквизиты дела — менеджер уточняет при публикации.

Сценарий 2. Migration внутри России: смена провайдера без переоформления поручения (IT-компания, Северо-Западный ФО, осень 2025). CTO перенёс базу данных клиентов (УЗ-3, 180 000 субъектов) между двумя российскими облачными провайдерами без заключения нового договора-поручения с принимающей стороной. Договор подписали спустя три недели после фактического начала обработки. В ходе аудита по инициативе самой компании выявлено: в этот период новый провайдер обрабатывал ПДн без правового основания — нарушение ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽). Компания самостоятельно уведомила РКН и исправила нарушение до проверки, что позволило ограничиться предписанием без штрафа.

Сценарий 3. Migration ML-данных без обезличивания (SaaS-стартап, Сибирский ФО, начало 2026). Технический директор перенёс исторические данные транзакций (содержали email, телефоны, историю заказов) в облачную ML-платформу нового провайдера без предварительного обезличивания. При проверке РКН квалифицировал это как обработку ПДн без достаточного правового основания для конкретной цели (нарушение ст. 5 и ст. 6 ФЗ-152). Стратегия: DPIA с документированием цели обработки и обезличивание набора данных по методам, предусмотренным Приказом РКН, снизили риск до минимума при дальнейшем взаимодействии с регулятором. ⚠️ Конкретный номер дела — менеджер уточняет при публикации.

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

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

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

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

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

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

С 01.07.2025 — нет, для первичного сбора, накопления и хранения ПДн граждан РФ. Ч. 5 ст. 18 ФЗ-152 запрещает обеспечивать эти операции за пределами РФ. Использование иностранного облака как вспомогательного инструмента без хранения ПДн граждан РФ технически допустимо, но требует чёткого разграничения: какие данные туда попадают, в каком объёме и на какое время. Трансграничная передача в страны без адекватной защиты требует уведомления РКН по ст. 12 ФЗ-152.

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

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

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

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

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

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

Итог

Migration между SaaS-провайдерами — это не техническая задача переноса данных, а юридически значимое событие, которое затрагивает локализацию, поручение обработки, уровень защищённости и обезличивание одновременно. Каждый из этих блоков имеет собственный состав нарушения в ст. 13.11 КоАП с санкциями от 150 тыс. до 18 млн ₽.

DATUM сопровождает IT-команды в подготовке правовой документации для migration: от DPIA и модели угроз до договоров-поручений и уведомлений РКН. Практика охватывает как переезды с зарубежных платформ, так и смену российских провайдеров.