Local DP в мобильных приложениях

Требования к локальной защите данных в мобильных приложениях изменились трижды за два года: сначала ФЗ-233 ужесточил локализацию с 01.07.2025, затем ФЗ-420 пересобрал санкции ст. 13.11 КоАП с 30.05.2025, наконец ФЗ-421 ввёл уголовную ответственность по ст. 272.1 УК с 11.12.2024. Для CTO это означает: архитектурные решения по хранению данных, выбору SDK и логированию теперь напрямую конвертируются в правовые риски. Эта статья разбирает, как выстроить Local DP в мобильных приложениях под действующие требования ФЗ-152, ПП РФ №1119 и Приказа ФСТЭК №21.

Что такое Local DP и почему он важен для мобильных приложений?

Local DP — подход, при котором персональные данные либо обрабатываются на устройстве пользователя (on-device processing), либо передаются только в инфраструктуру, физически расположенную в России. Для мобильного приложения это прежде всего вопрос архитектуры: где лежит первичная копия данных, какой SDK аналитики подключён, куда уходят push-токены и идентификаторы устройств.

ФЗ-152 не использует термин «Local DP» — он оперирует понятием локализации из ч. 5 ст. 18. Закон требует, чтобы операции записи, систематизации, накопления, хранения, уточнения и извлечения ПДн граждан РФ выполнялись в базах данных, размещённых в России. Трансграничная передача после первичной записи в РФ допустима, но первичная запись за рубежом — нет.

Для мобильного приложения это означает конкретный архитектурный запрет: нельзя, чтобы первым хранилищем данных пользователя оказался сервер AWS в Ирландии, Firebase в США или аналитическая платформа за рубежом. SDK Firebase Analytics, Amplitude, Mixpanel — каждый из них требует отдельной оценки на предмет того, куда уходят данные в момент первой записи.

Как определить уровень защищённости для мобильного приложения?

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

Для типичного мобильного приложения потребительского класса (общие ПДн: имя, email, телефон, история заказов) при угрозах 3-го типа и числе субъектов до 100 000 определяется уровень защищённости УЗ-4. Превышение порога 100 000 субъектов переводит систему на УЗ-3. Приложение с доступом к данным о здоровье (медицинские, фитнес-показатели) или биометрии попадает под специальные категории ст. 10 ФЗ-152 — уровень УЗ-2 или УЗ-1 в зависимости от числа субъектов и типа угроз.

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

Логирование и аналитика в мобильных приложениях: когда данные становятся ПДн?

Идентификатор устройства (IDFA, GAID, Firebase Instance ID), IP-адрес, геолокация и поведенческие паттерны в сессии — каждый из этих элементов в отдельности может не быть персональными данными, но в совокупности с учётной записью пользователя образует ПДн по ст. 3 ФЗ-152. РКН придерживается позиции, что cookies и аналогичные технические идентификаторы, позволяющие идентифицировать физическое лицо, подпадают под режим ПДн.

Это означает, что логи аналитики, передаваемые в Amplitude, Mixpanel или Firebase Analytics вместе с user_id, — это трансграничная передача ПДн. Она допустима только после первичной записи в российскую базу и при выполнении требований ст. 12 ФЗ-152: уведомление РКН о трансграничной передаче, если страна получателя не входит в перечень адекватной защиты.

Для разработчика мобильного приложения практический вывод: любой SDK, отправляющий данные на зарубежный сервер, требует юридической оценки. Если SDK осуществляет первичную запись ПДн — это нарушение локализации. Если он передаёт уже локализованные данные — нужно уведомление о трансграничной передаче. Промежуточный вариант — проксирование через российский сервер с агрегацией до передачи за рубеж.

Обезличивание для ML: как использовать данные пользователей без нарушения ФЗ-152?

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

Выход, который допускает закон, — обезличивание данных до их использования в обучающей выборке. ФЗ-233 от 08.08.2024 ввёл ст. 13.1 ФЗ-152, регулирующую обезличенные ПДн, и поручил РКН определить методы. Подзаконный акт РКН закрепил пять методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация.

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

Мультиарендность в SaaS и мобильных приложениях: кто оператор?

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

Граница размывается, когда платформа сама собирает аналитику использования (product analytics) поверх данных тенантов или использует агрегированные данные для улучшения продукта. В этом случае платформа становится самостоятельным оператором в отношении собственных целей обработки — и должна иметь отдельное правовое основание по ст. 6 ФЗ-152, отдельное уведомление в реестре РКН по ст. 22 и отдельную политику конфиденциальности.

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

Типовые сценарии для CTO мобильного приложения

Сценарий 1. Firebase Analytics как основная аналитическая платформа. Ситуация: мобильное приложение с аудиторией 500 000 пользователей РФ использует Firebase Analytics (Google, серверы за рубежом) для сбора событий. Первичная запись событий происходит в Firebase до записи в российскую БД. Доказательства нарушения: данные о географии серверов Firebase публично доступны, архитектура приложения зафиксирована в документации. Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽ за нарушение локализации. Стратегия: либо проксирование через российский сервер с перехватом и локальной записью до отправки в Firebase, либо замена на отечественный аналог (AppMetrica с российскими серверами).

Сценарий 2. ML-модель на сырых пользовательских данных. Ситуация: команда передала в дата-сайентистам выгрузку из БД с именами, email и историей действий для обучения рекомендательной модели. Согласие пользователей охватывает цели «улучшение сервиса» в общих формулировках. Доказательства нарушения: согласие не включает явного указания на обучение ML-модели как отдельной цели. Вероятный исход: штраф по ч. 1 ст. 13.11 КоАП от 150 000 до 300 000 ₽ за обработку с нарушением принципа ограничения целей (ст. 5 ФЗ-152). Стратегия: переработать согласие с явным указанием ML-цели либо провести обезличивание по методам ст. 13.1 ФЗ-152 до передачи в обучение.

Сценарий 3. SaaS-платформа без договора поручения. Ситуация: мобильное приложение хранит данные пользователей на облачной платформе российского хостинга, но договор не содержит раздела о поручении обработки ПДн. Утечка данных произошла на стороне хостинга. Доказательства нарушения: отсутствие договора поручения, зафиксировано проверкой РКН. Вероятный исход: штраф по ч. 1 ст. 13.11 КоАП + предписание об устранении. Стратегия: включить в договор с хостингом раздел о поручении обработки по ст. 6 ч. 3 ФЗ-152, перечень допустимых действий и требование к мерам защиты.

Как это применяется на практике

Кейс 1. IT-компания Северо-Западного федерального округа (осень 2025) разработала мобильное приложение для ритейл-сети с аудиторией около 200 000 пользователей РФ. Аналитика подключалась через зарубежный SDK с первичной записью за рубежом. РКН при плановой проверке зафиксировал нарушение ч. 5 ст. 18 ФЗ-152. Был составлен протокол по ч. 8 ст. 13.11 КоАП; штраф по делу составил несколько миллионов рублей. После вынесения постановления компания переработала архитектуру — внедрила проксирующий российский сервис с локальной первичной записью. Повторного нарушения зафиксировано не было.

Кейс 2. FinTech-компания Центрального федерального округа (начало 2026) использовала данные 80 000 клиентов для обучения ML-модели скоринга без обезличивания. Обращение одного из субъектов в РКН инициировало проверку. Договор с дата-сайентистами (ИП, сторонний подрядчик) не содержал условий о поручении обработки. Компании были предъявлены претензии по ч. 1 и ч. 2 ст. 13.11 КоАП; общий размер санкций составил несколько сотен тысяч рублей. В арбитраже удалось применить ч. 1 ст. 4.1.2 КоАП (расчёт как для ИП) и снизить итоговый штраф. Стратегия защиты основывалась на немедленном устранении нарушения до вынесения постановления и первичности.

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

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

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

1. Какой УЗ выбрать для SaaS-приложения с 150 000 пользователей?

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

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

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

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

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

4. Кто является оператором ПДн в мультиарендной SaaS-платформе?

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

5. Какие средства защиты информации (СЗИ) обязательны для мобильного приложения?

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

Итог

Local DP в мобильных приложениях — это не отдельная опция, а архитектурное требование с прямыми санкциями: от 1 до 6 млн ₽ за нарушение локализации, от 3 до 15 млн ₽ за утечку данных, уголовная ответственность по ст. 272.1 УК при незаконной передаче. Три ключевых точки контроля — SDK-аналитика (куда уходит первичная запись), ML-пайплайны (есть ли обезличивание) и договоры с подрядчиками (есть ли поручение обработки).

DATUM сопровождает IT-команды и CTO в построении архитектуры обработки ПДн, соответствующей ФЗ-152: аудит SDK и потоков данных, разработка модели угроз и акта УЗ, подготовка договоров поручения и DPIA для ML-систем.