Трансграничная передача ПДн в ритейле: разбор 152-ФЗ после поправок № 265-ФЗ
По данным Право.ru, вступление в силу поправок к ст. 12 Федерального закона № 152-ФЗ от 26.07.2026 № 265-ФЗ и обсуждение нового перечня «адекватных» государств сместили фокус с практических аспектов на юридические тонкости. Для российского ритейла, чьи ИТ-инфраструктуры глубоко интегрированы с зарубежными сервисами (от CDP-платформ до облачных MDM), эти изменения означают не просто смену формата отчетности, а фундаментальную перестройку архитектуры потоков данных. Вопросы, оставшиеся за рамками дискуссии — изменение правовой природы перечня, переход от уведомительного к разрешительному режиму и судьба старых уведомлений — напрямую влияют на непрерывность бизнес-процессов и легитимность работы мобильных устройств сотрудников.
Что произошло
Законодательные изменения, инициированные 265-ФЗ, и проект нового перечня стран, обеспечивающих адекватную защиту ПДн, трансформируют саму механику взаимодействия бизнеса с регулятором.
Во-первых, изменилась правовая природа перечня. Если ранее он служил своего рода «белым списком», работа с которым по умолчанию считалась безопасной при наличии договора, то теперь его статус требует переоценки. Юридическая конструкция смещается в сторону того, что само включение страны в перечень является лишь необходимым, но не достаточным условием. Ритейлеру теперь недостаточно просто сослаться на 152-ФЗ; необходимо доказывать, что принимающая сторона (например, зарубежный вендор MDM или облачного хранилища) обеспечивает уровень защиты, эквивалентный российскому, на уровне конкретных технических и организационных мер.
Во-вторых, происходит концептуальный сдвиг потока данных из уведомительного режима в разрешительный. Ранее стандартной практикой была отправка уведомления в Роскомнадзор о намерении осуществлять трансграничную передачу, после чего, если не приходил запрет, деятельность считалась легальной. Новый подход подразумевает, что для ряда стран и категорий данных передача не начнется до момента получения de facto или de jure разрешения. Это означает, что любая интеграция с новым зарубежным SaaS-сервисом (например, для аналитики поведения покупателей в торговом зале) превращается в проект с неопределенным сроком запуска, зависящим от скорости работы регулятора.
В-третьих, статус ранее поданных уведомлений остается «серой зоной». Неофициальные заверения Роскомнадзора о том, что старые уведомления пересматриваться не будут, не имеют силы нормативного акта. Для ИТ-директора это означает риск: инфраструктура, легализованная год назад, завтра может оказаться вне правового поля, если ведомство изменит свою интерпретацию или если зарубежный провайдер изменит условия обработки данных (например, перенесет серверы в другую юрисдикцию).
Почему это важно
Для ритейл-ИТ-руководителя эти изменения бьют по трем критическим направлениям: мобильность, аналитика и управление парком устройств.
1. MDM/EMM и мобильная инфраструктура. Большинство корпоративных систем управления устройствами (включая Komendant MDM и аналоги) используют облачные компоненты или синхронизируются с глобальными Identity-провайдерами (IdP) через протоколы вроде SCIM. Если ваш MDM-агент на Android-терминале сбора данных (ТСД) в магазине отправляет телеметрию на серверы в юрисдикции, которая выпала из «адекватного» списка или требует разрешения, вы нарушаете закон каждую секунду.
* Смежный кейс: Переход на отечественные ОС, такие как Аврора, частично снимает проблему на уровне ОС, но не решает ее, если само MDM-решение остается гибридным (on-premise ядро + зарубежное облако для Push-уведомлений APNS/FCM).
2. Customer Data Platforms (CDP) и программы лояльности. Ритейл живет на данных. Сбор геолокации, истории покупок и данных карт лояльности с последующей передачей в зарубежные облака (например, для использования моделей машинного обучения) теперь находится под прямым ударом. Если страна хранения данных переходит в категорию «требующих разрешения», ваша CDP не сможет получать данные в реальном времени. Это парализует персональные акции в кассовой зоне.
3. Риски 152-ФЗ и реестра Минцифры. Для компаний, претендующих на льготы ИТ-компаний или работающих с государственными заказчиками, любая трансграничная передача должна быть безупречно задокументирована. Отсутствие актуального разрешения при проверке может стать основанием для исключения из реестра Минцифры или крупных штрафов, которые в 2026 году исчисляются процентами от выручки. Использование зарубежных сервисов аналитики (например, для тепловых карт в гипермаркетах) без должного оформления теперь невозможно.
Что делать
Пассивное ожидание разъяснений Роскомнадзора — непозволительная роскошь. Требуется проактивный технический и юридический аудит.
1. Провести инвентаризацию потоков с привязкой к юрисдикциям.
Необходимо составить карту данных, где для каждого пакета (например, токен устройства, геокоординаты курьера, данные чека) указан конечный IP-адрес или FQDN и страна его регистрации. Особое внимание уделить «скрытым» передачам: куда уходят логи с касс, куда бэкапятся базы данных из облака, куда стучатся MDM-агенты на полках.
2. Актуализировать локальные политики MDM.
На уровне /docs/policies необходимо внедрить строгие ограничения. Для парка Android-устройств (ТСД, смартфоны курьеров) через MDM следует:
* Запретить использование личных аккаунтов Google на корпоративных устройствах (Applications Policy -> Disallow user control of application settings для com.google.android.gms).
* Заблокировать установку приложений из неизвестных источников, которые могут создавать неконтролируемые туннели данных.
* Настроить Network Policy для принудительной маршрутизации всего трафика устройств через корпоративный VPN-шлюз с российской гео-привязкой, где это технически возможно.
3. Пересмотреть архитектуру уведомлений и перейти к точечным разрешениям.
Старые «генеральные» уведомления на все подряд больше не работают. Необходимо подготовить пакет документов для Роскомнадзора, разделив потоки:
* Поток 1 (Уведомительный): Передача в страны из финального «адекватного» перечня (когда он будет утвержден) с жестко прописанными мерами защиты в договоре поручения.
* Поток 2 (Разрешительный): Для всех остальных случаев (включая США, часть стран Азии) подготовить обоснование необходимости. Здесь нужно детально описать, какие именно данные (например, только device_id без привязки к ФИО) и для каких целей (например, получение обновлений безопасности ОС) передаются.
4. Техническая локализация и маскирование.
Внедрить практики обработки данных до их отправки за рубеж. Если зарубежному сервису аналитики для работы нужен паттерн покупок, передавайте ему обезличенные данные (хэши корзин без ID пользователя). На уровне баз данных используйте динамическое маскирование. Для критичных сервисов (видеонаблюдение с распознаванием лиц, MDM) приоритетно рассматривайте on-premise развертывание или использование решений, чьи серверы физически находятся в РФ (ссылки на импортонезависимые стеки можно найти в /docs/aurora).
5. Настроить мониторинг конфигураций через SCIM и SSO.
Чтобы избежать ситуации, когда администратор по ошибке подключает новый зарубежный плагин к CRM, нарушая режим трансграничной передачи, необходимо централизовать управление доступами. Использование /docs/scim для синхронизации пользователей гарантирует, что любая интеграция с внешним IdP будет проходить через контролируемый канал, а не создаваться точечно в каждом приложении.
Источник: https://pravo.ru/opinion/266312
---
Источник: https://pravo.ru/opinion/266312/