Персональные данные в мобильном приложении: требования и типовые нарушения

Мобильное приложение собирает персональные данные быстрее, чем сайт: доступ к геолокации, контактам или камере оно может запросить уже на первом экране, до того как пользователь увидел хотя бы строчку из политики конфиденциальности. Персональные данные в мобильном приложении подчиняются тому же 152-ФЗ «О персональных данных», что и данные на сайте, только источников хранения и утечки у приложения больше: сервер разработчика, серверы десятка подключенных SDK, локальное хранилище на самом устройстве.

Разница с обычным сайтом еще и в том, что у приложения два свода требований одновременно - закон о персональных данных и правила магазина приложений. Google Play и App Store отклоняют карточку за неточно заполненный раздел о данных быстрее, чем Роскомнадзор успевает организовать проверку, и оба источника претензий смотрят примерно на одно и то же: что приложение собирает, зачем и куда это уходит. Дальше - какие данные в приложении подпадают под закон, как обращаться с разрешениями устройства и сторонними SDK, что требуют магазины приложений и на чем разработчики чаще всего попадают на нарушение.

Какие данные в приложении подпадают под 152-ФЗ

Формально в приложении действует то же определение, что и в законе: персональные данные - любая информация, которая прямо или косвенно относится к определенному или определяемому человеку. На практике в мобильном приложении под эту категорию обычно попадает не меньше десятка разных полей.

• анкетные данные, введенные при регистрации - имя, телефон, e-mail, дата рождения;
• геолокация, точная и приблизительная, если приложение запрашивает доступ к GPS или сети;
• список контактов из телефонной книги устройства;
• фотографии и видео из галереи или с камеры;
• рекламный идентификатор устройства - IDFA на iOS, GAID на Android;
• IP-адрес, идентификатор сессии, технические данные об устройстве и версии операционной системы;
• в отдельных приложениях - данные о здоровье, финансах, биометрия.

С биометрией отдельная тонкость. Если вход в приложение защищен отпечатком пальца или сканом лица через системный модуль устройства - Face ID, Touch ID, биометрия Android, - само приложение обычно не получает биометрический образец: оно получает от операционной системы только результат сравнения, да или нет. В этом случае приложение не обрабатывает биометрические персональные данные в смысле закона, потому что шаблон лица или пальца не покидает защищенный чип устройства и не проходит через код приложения. Другое дело - если приложение самостоятельно снимает и сохраняет изображение лица или запись голоса, например для верификации личности при оформлении услуги через приложение. Тогда это уже специальная категория данных со своими требованиями к согласию.

Отдельный вопрос - рекламные идентификаторы устройства. Юристы расходятся в том, считать ли IDFA и GAID персональными данными сами по себе: идентификатор не содержит имени и не выдает человека напрямую. Но в связке с данными о сессиях и поведении в приложении идентификатор устройства позволяет узнать конкретного человека, а закон в статье 3 признает персональными данными любую информацию, которая относится к определяемому лицу - не обязательно определенному. Разумная позиция - обращаться с рекламными идентификаторами так же аккуратно, как с остальными персональными данными, а не рассчитывать на то, что формальная анонимность идентификатора снимает вопрос.

Набор данных сильно зависит от отрасли. У интернет-магазина в приложении - адрес доставки, история заказов и способ оплаты. У медицинской клиники, если запись на прием и результаты анализов вынесены в приложение, - данные о здоровье, специальная категория со своими требованиями к согласию и хранению. У школьного приложения для родителей - фамилия и класс ребенка, а если в нем зарегистрирован сам ребенок младше четырнадцати лет, обработку нужно строить через согласие родителя, а не самого пользователя. В кадровом приложении для сотрудников - паспортные данные, ИНН, СНИЛС, иногда фото для пропускной системы. Чем чувствительнее данные, тем меньше права на ошибку в разрешениях и согласиях: клинике или школе разбирательство с Роскомнадзором обходится не только штрафом, но и репутационным ударом, который для медицинского или образовательного проекта заметнее, чем для интернет-магазина.

Разрешения приложения и персональные данные пользователя

Системный запрос разрешения - камера, контакты, геолокация, микрофон, доступ к файлам - решает только один вопрос: может ли приложение технически получить доступ к этим данным на уровне операционной системы. Согласие на обработку персональных данных по 152-ФЗ - вопрос отдельный, и нажатие «Разрешить» в системном диалоге Android или iOS само по себе его не заменяет. Мнения юристов здесь расходятся: часть считает, что для базовых функций системного разрешения достаточно, если цель сбора очевидна из контекста, другая настаивает на отдельном согласии на любую обработку. На практике безопаснее не полагаться на системный диалог и оформить согласие отдельно, хотя бы коротким экраном при первом запуске.

Более частая проблема - разрешения, которые приложение запрашивает без связи с реальной функцией. Принцип из статьи 5 152-ФЗ требует, чтобы обработка ограничивалась целями, заявленными при сборе данных: если фитнес-приложение запрашивает доступ к списку контактов, а функция «поделиться с другом» появляется только после регистрации и оплаты подписки, это уже похоже на сбор с запасом, а не под конкретную задачу. Похожая картина - у приложений такси и доставки, которые запрашивают доступ к камере без функции сканирования документов, или у офлайн-редакторов фото, которые просят доступ к микрофону.

Практическое правило - запрашивать разрешение непосредственно перед использованием функции, а не все сразу при первом запуске. Android с версии 6 и iOS изначально поддерживают именно такую модель: пользователь видит запрос доступа к камере в момент, когда нажимает кнопку «Сделать фото», а не при установке приложения. Это не только требование магазинов приложений, но и рабочий способ снять вопрос о цели: разрешение, запрошенное в контексте конкретного действия, само объясняет, зачем оно нужно.

Сторонние SDK и трекеры в приложении

Большая часть данных в приложении уходит не на сервер разработчика, а на серверы сторонних библиотек: аналитика, крэш-репортинг, push-уведомления, атрибуция установок, рекламные сети. Разработчик подключает SDK одной строкой в коде и обычно не проверяет, какие поля данных библиотека собирает и куда их отправляет. С точки зрения 152-ФЗ это не снимает ответственности: компания, которая владеет приложением, остается оператором персональных данных пользователей, даже если фактическую передачу данных выполняет чужой код.

Минимальная проверка для каждого подключенного SDK - четыре вопроса: какие данные библиотека собирает по умолчанию, есть ли у нее настройки для отключения лишнего сбора, где физически расположены ее серверы и передается ли туда что-то, что можно связать с конкретным человеком. Ответы на первые два вопроса обычно есть в документации SDK, на третий и четвертый честно отвечают не все вендоры - тогда приходится смотреть сетевой трафик приложения инструментами вроде прокси-снифферов.

Отдельно стоит сказать про iOS. Начиная с версии 14.5 Apple требует отдельного разрешения на доступ к рекламному идентификатору устройства - системного диалога App Tracking Transparency, который прямо спрашивает пользователя, разрешает ли он отслеживание между приложениями и сайтами. Без этого разрешения IDFA недоступен ни самому приложению, ни подключенным рекламным SDK: они получают только обнуленное значение. Формально это требование Apple, а не 152-ФЗ, но по факту оно решает часть той же задачи: без явного действия пользователя рекламные сети не получают идентификатор, который в связке с остальными данными позволяет узнать конкретного человека.

Аналитические SDK и передача данных за рубеж

Самые распространенные аналитические библиотеки - зарубежные: Firebase Analytics и Crashlytics от Google, сервисы атрибуции установок AppsFlyer и Adjust, платформа push-уведомлений OneSignal. Все они по умолчанию отправляют данные на серверы за пределами России, в США или в Евросоюзе, в зависимости от сервиса. Для владельца приложения это означает трансграничную передачу персональных данных в смысле статьи 12 152-ФЗ, и если страна назначения не входит в перечень «безопасных» по оценке Роскомнадзора, закон требует уведомить регулятора о начале передачи заранее, а не постфактум.

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

Отечественная альтернатива для базовой аналитики - AppMetrica от Яндекса, чьи серверы обработки данных находятся в России. Замена не решает вопрос автоматически: у AppMetrica тоже есть собственный список того, что она собирает, и его тоже стоит сверить с реальными целями. Но она снимает как минимум вопрос трансграничной передачи для этого конкретного канала. Общий принцип простой: чем меньше данных уходит за периметр без явного основания, тем меньше вопросов при проверке.

Рекламные сети и трекеры

С рекламными SDK ситуация обычно хуже, чем с аналитикой: монетизация через рекламные сети часто держится на нескольких партнерах одновременно, и у каждого свой набор собираемых данных - от рекламного идентификатора устройства до истории просмотренных объявлений. Разумный минимум - вести список подключенных рекламных SDK так же, как список используемых на сайте cookie, и раз в квартал сверять его с тем, что реально работает в текущей версии приложения: удаленные из кода библиотеки нередко остаются упомянутыми в политике конфиденциальности, а подключенные заново - нет.

Требования Google Play и App Store к персональным данным

Оба магазина приложений требуют от разработчика самостоятельно задекларировать, какие данные собирает приложение, и дальше сверяют декларацию с содержимым установочного файла - автоматическим сканированием и при ручной модерации. В Google Play это раздел «Безопасность данных» в консоли разработчика: по каждой категории данных - геолокация, персональная информация, финансовая информация и другие - нужно указать, собирается ли она, передается ли третьим лицам и можно ли ее удалить по запросу пользователя. В App Store аналог называется «Конфиденциальность приложения» и делит данные на три группы по степени связи с личностью: данные для отслеживания пользователя, данные, связанные с личностью, и данные, не связанные с личностью.

У Apple есть еще одно техническое требование, которое часто выпадает из вида: с 2024 года многие популярные сторонние SDK обязаны поставляться с файлом privacy manifest - декларацией, зачем именно библиотека обращается к определенным системным API, например к идентификатору устройства или к буферу обмена. Если используемая версия SDK не обновлена под это требование, Apple может отклонить сборку приложения при загрузке в App Store Connect еще до содержательной проверки карточки. На практике это означает, что при подключении стороннего SDK стоит сразу проверять актуальность его версии, а не только состав собираемых данных.

Расхождение между тем, что заявлено в карточке, и тем, что приложение реально собирает, - частая причина отклонения при модерации и снятия уже опубликованного приложения с публикации. Оба магазина периодически перепроверяют трафик приложений автоматически, и подключение нового SDK без обновления декларации - обычная причина внезапной блокировки обновления. Практический вывод: раздел о данных в консоли магазина стоит обновлять при каждом изменении набора SDK, а не заполнять один раз при первой публикации.

Политика конфиденциальности приложения: что должно быть в карточке

Оба магазина требуют прямую ссылку на политику конфиденциальности приложения в карточке, и ссылка должна вести на реальный, читаемый без входа в личный кабинет текст - не на общий документ компании без упоминания приложения и не на страницу-заглушку. Внутри самого приложения ссылка на политику должна быть доступна до того, как пользователь передаст первые данные - в идеале на экране регистрации или первого запуска, а не спрятана на третьем уровне вложенности настроек.

Что обязательно должно быть в тексте политики конфиденциальности приложения:

• название и реквизиты оператора - компании или ИП, которая владеет приложением;
• перечень собираемых данных, который совпадает с тем, что указано в разделе о данных в магазине приложений;
• цели обработки по каждой категории данных;
• сроки хранения;
• сведения о передаче данных третьим лицам и за рубеж, если она есть;
• права пользователя и порядок их реализации - у кого и как запросить удаление или уточнение данных.

Готовый шаблон с разбором обязательных пунктов есть в статье «Политика обработки персональных данных: образец для сайта 2026» - структура для приложения совпадает почти полностью, разница только в перечне собираемых данных и в разделе про SDK. Политику конфиденциальности приложения часто путают с пользовательским соглашением, хотя это разные документы с разным назначением: что именно не стоит включать в пользовательское соглашение, разобрано в статье про пользовательское соглашение и персональные данные.

Согласие пользователя в мобильном приложении

С 1 сентября 2025 года, после изменений 156-ФЗ от 24.06.2025, согласие на обработку персональных данных должно оформляться отдельным документом, а не строчкой мелким шрифтом внутри пользовательского соглашения или публичной оферты. Для приложения это означает отдельный экран или отдельный чекбокс с текстом согласия и ссылкой на его полный текст, а не общую формулировку вида «Регистрируясь, вы соглашаетесь с условиями использования».

Требования к самому чекбоксу или экрану согласия для приложения такие же, как для формы на сайте: галочка не должна стоять по умолчанию, пользователь должен явно ее поставить, а формулировка - называть, на какую именно обработку он соглашается. Готовый текст для такого согласия - в статье «Согласие на обработку персональных данных: образец 2026».

Отдельно стоит развести согласия по назначению: одно - на обработку данных, необходимую для работы основной функции приложения, второе - на аналитику и рекламу. Первое можно сделать обязательным условием использования приложения, второе - нет: отказ от аналитики не должен блокировать доступ к функциям, ради которых человек приложение поставил. Такое разделение снимает часть вопросов и при проверке, и при написании самой политики - там сразу видно, какая обработка обязательна, а какая опциональна.

Внутри компании за то, чтобы это разделение соблюдалось на практике, а не только на бумаге, должен отвечать конкретный человек - без назначенного ответственного согласие часто существует только в виде текста в App Store, а по факту SDK собирает данные до того, как пользователь успел его увидеть. Кого назначать и как оформить эту роль, разобрано в статье про ответственного за организацию обработки персональных данных.

Приложение и 152-ФЗ: типовые нарушения

На практике набор нарушений у мобильных приложений повторяется от проекта к проекту.

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

Что делать: порядок действий для владельца приложения

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

1. Составить полный список данных, которые собирает приложение и каждый подключенный SDK - по документации библиотек и по сетевому трафику, если документация неполная.
2. Сверить список с реальными функциями приложения и убрать разрешения и поля данных, без которых ни одна функция не работает.
3. Проверить, в какую страну уходят данные каждого стороннего SDK, и сопоставить со списком «безопасных» стран Роскомнадзора.
4. При необходимости подать уведомление РКН о трансграничной передаче персональных данных.
5. Обновить политику конфиденциальности под фактический список данных и целей, разместить ссылку в карточке магазина и внутри приложения на экране регистрации.
6. Оформить согласие отдельным экраном или документом, без предзаполненных галочек, с разделением на обязательную и опциональную обработку.
7. Привести в соответствие раздел о данных в Google Play и в App Store и обновлять его при каждом изменении набора SDK.
8. Назначить внутри компании ответственного за обработку персональных данных, который будет отслеживать эти пункты при последующих обновлениях приложения.

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