Разработчики часто считают, что закон о персональных данных касается только банков и медицинских сервисов. На практике под 152-ФЗ подпадает почти любое мобильное приложение: регистрация по телефону или email, геолокация для доставки, push-токен, привязанный к аккаунту, аналитика поведения — всё это персональные данные. Как только приложение начинает их собирать, его владелец становится оператором персональных данных, а не подрядчик, который писал код.
Это не только юридический вопрос. Требования 152-ФЗ и правила App Store, Google Play и RuStore напрямую влияют на архитектуру приложения, выбор хостинга, состав SDK и бюджет проекта — их нужно закладывать в техническое задание ещё до начала разработки, а не «дописывать» перед публикацией в сторе.
Какие данные в приложении считаются персональными
Персональные данные — любая информация, которая прямо или косвенно относится к конкретному человеку. В приложении таких данных обычно больше, чем кажется на первый взгляд: даже технический идентификатор устройства становится персональными данными, если он связан с аккаунтом конкретного пользователя.
| Тип данных | Пример в приложении | На что обратить внимание |
|---|---|---|
| Контактные данные | Телефон, email при регистрации | Часто единственный правовой режим — согласие или договор; нужен способ отзыва |
| Идентифицирующие данные | Имя, дата рождения, фото профиля | Фото профиля пользователя — тоже персональные данные, если по нему можно узнать человека |
| Геолокация | Координаты для доставки, каршеринга, геймификации | История перемещений может косвенно раскрывать место жительства и работы — повышенный риск |
| Идентификаторы устройства | Push-токен, advertising ID, device ID, привязанные к аккаунту | Сами по себе — обезличенные, но в связке с аккаунтом становятся персональными данными |
| Платёжные данные | Последние цифры карты, история заказов, чеки | Полный номер карты и CVC обычно обрабатывает платёжный шлюз, а не приложение — это нужно закрепить договором |
| Специальные категории | Данные о здоровье, вероисповедании в тематических приложениях | Требуют письменного согласия и повышенных мер защиты (ст. 10 152-ФЗ) |
| Биометрические данные | Фото или голос для идентификации (не просто Face ID разблокировки телефона) | Отдельный правовой режим по ст. 11 152-ФЗ и повышенные штрафы за утечку |
Важная оговорка: если приложение просто использует Face ID или Touch ID телефона для входа, само биометрическое изображение обрабатывает операционная система, а не приложение — оператором биометрических данных это автоматически не делает. Другое дело — если приложение само собирает фото или голос для идентификации личности: тогда действует специальный режим.
Кто оператор, а кто обработчик
По 152-ФЗ оператор — тот, кто определяет цели и содержание обработки персональных данных: обычно это владелец приложения и юридическое лицо, на которое оно зарегистрировано, а не студия-подрядчик, которая его написала. Именно владелец приложения подаёт уведомление в Роскомнадзор, публикует политику обработки и отвечает перед пользователями и регулятором.
Подрядчики и сервисы, которые технически обрабатывают данные по поручению владельца, — это обработчики: разработчик, если он администрирует базу данных после сдачи проекта; хостинг-провайдер; сервис SMS- или email-рассылок; сервис пуш-уведомлений. Согласно ч. 3 ст. 6 152-ФЗ, передача данных обработчику возможна только на основании договора, в котором прямо перечислены:
- перечень действий с персональными данными, которые может совершать обработчик;
- цели обработки;
- обязанность обработчика соблюдать конфиденциальность и обеспечивать меры защиты, аналогичные обязанностям оператора;
- ответственность обработчика перед оператором за нарушение договора.
Если в договоре с разработчиком или хостингом нет ни слова про персональные данные, формально поручение обработки не оформлено. При проверке или утечке это работает против владельца приложения: отвечать перед Роскомнадзором и пользователями будет он, даже если утечка произошла на стороне подрядчика.
Базовые обязанности оператора персональных данных
С момента, когда приложение начинает собирать первые персональные данные — например, номер телефона при регистрации, — у его владельца включается стандартный набор обязанностей оператора.
- Уведомить Роскомнадзор. До начала обработки нужно направить в Роскомнадзор уведомление об обработке персональных данных по форме, утверждённой приказом Роскомнадзора от 28.10.2022 № 180 (ст. 22 152-ФЗ). После этого оператор попадает в публичный реестр.
- Определить правовое основание. Каждая операция с персональными данными должна опираться на согласие пользователя либо на исполнение договора с ним (например, договора оферты на использование приложения) — без этого обработка формально незаконна.
- Опубликовать политику обработки персональных данных. Документ должен быть в свободном доступе по ссылке из приложения и описывать, какие данные собираются, для чего, кому передаются и как их можно отозвать (ч. 2 ст. 18.1 152-ФЗ).
- Обеспечить локализацию. Запись, накопление, хранение и извлечение персональных данных граждан РФ должны вестись в базах данных, физически расположенных на территории России (ч. 5 ст. 18 152-ФЗ).
- Назначить ответственного за организацию обработки персональных данных внутри компании и утвердить внутренние документы (ст. 18.1).
- Принять меры защиты данных — организационные и технические, соразмерные рискам: от разграничения доступа до шифрования (ст. 19).
- Уведомлять Роскомнадзор об инцидентах. При утечке — в течение 24 часов первично и 72 часов по итогам внутреннего расследования (ч. 3.1 ст. 21 152-ФЗ).
- Реагировать на обращения пользователей — предоставлять сведения о своих данных, исправлять их и удалять по запросу, обрабатывать отзыв согласия.
Для небольшого стартапового приложения этот список выглядит избыточно бюрократическим, но большинство пунктов закрываются один раз на старте — грамотно составленной политикой, экраном согласия и договором с подрядчиками — и дальше требуют только сопровождения.
Согласие на обработку в приложении
С 1 сентября 2025 года действует правило, введённое Федеральным законом от 24.06.2025 № 156-ФЗ: согласие на обработку персональных данных должно оформляться отдельным документом, а не «зашиваться» внутрь пользовательского соглашения, оферты или политики конфиденциальности.
Важно. Формулировка «регистрируясь, вы соглашаетесь с условиями использования и политикой обработки персональных данных» одним чекбоксом на несколько документов сразу — с 1 сентября 2025 года юридически уязвима. Согласие на обработку персональных данных должно быть самостоятельным экраном или отдельным чекбоксом, который пользователь может принять независимо от других документов.
На практике это означает для интерфейса приложения:
- отдельный экран или отдельный чекбокс именно для согласия на обработку персональных данных — без предзаполненной галочки;
- ссылку на полный текст согласия и политику обработки рядом с чекбоксом;
- журнал согласий на стороне сервера — дата, время, версия текста, с которым согласился пользователь, чтобы можно было подтвердить факт согласия при проверке;
- техническую возможность отозвать согласие и увидеть последствия отзыва (например, часть функций станет недоступна).
Согласие не требуется, если обработка данных нужна исключительно для исполнения договора с самим пользователем — например, чтобы оформить и доставить его заказ. Но как только данные используются шире договора (маркетинговая рассылка, персонализированная реклама, передача партнёрам), нужно отдельное согласие именно на эти цели.
Если приложение публикует данные пользователя для неограниченного круга лиц — например, публичный профиль, отзывы с именем и фото, — по ст. 10.1 152-ФЗ на это нужно ещё одно, отдельное согласие на распространение персональных данных, которое не заменяет обычное согласие на обработку. А согласие на рекламные push-уведомления и email-рассылки оформляется отдельно от согласия на обработку данных, необходимую для работы самого приложения.
Аналитика, SDK и трансграничная передача
Мобильное приложение редко ограничивается собственным кодом: аналитика, крэш-репортинг, реклама и карты подключаются через сторонние SDK, и каждый такой SDK может собирать и передавать данные пользователя своему поставщику — часто на серверы за пределами России. С точки зрения 152-ФЗ это не «чужая» обработка, а обработка, которую владелец приложения допустил на своей площадке.
Что стоит сделать перед подключением любого SDK:
- провести инвентаризацию: какие SDK уже встроены в приложение и какие данные они собирают (это видно в политиках самих SDK и в отчётах Data safety / App Privacy сторов-конкурентов, если продукт похож);
- проверить, куда физически передаются данные — если за рубеж, это трансграничная передача персональных данных;
- для трансграничной передачи направить в Роскомнадзор отдельное уведомление о её начале до фактической передачи (ч. 3 ст. 12 152-ФЗ) — помимо основного уведомления об обработке;
- помнить, что закон разделяет операции: сама передача данных за границу регулируется ст. 12, а запись, хранение и извлечение данных граждан РФ обязаны вестись на территории России независимо от того, передаются ли данные дальше (ч. 5 ст. 18 152-ФЗ).
Практический вывод: перед подключением очередного SDK аналитики или рекламы стоит спросить поставщика, где физически размещены его серверы и как оформлена трансграничная передача — это дешевле, чем разбираться с этим после жалобы пользователя.
Ответственность за нарушения
С 30 мая 2025 года действует новая редакция ст. 13.11 КоАП РФ (изменения внесены Федеральным законом от 30.11.2024 № 420-ФЗ) — штрафы выросли в разы, а составов нарушений стало больше.
| Нарушение | Штраф для организаций |
|---|---|
| Обработка персональных данных без законного основания (ч. 1) | от 150 000 до 300 000 ₽, при повторном нарушении — от 300 000 до 500 000 ₽ |
| Неуведомление Роскомнадзора о намерении обрабатывать персональные данные (ч. 10) | от 100 000 до 300 000 ₽ |
| Неуведомление Роскомнадзора об утечке (ч. 11) | от 1 000 000 до 3 000 000 ₽ |
| Нарушение требования о локализации баз данных в России (ч. 8) | от 1 000 000 до 6 000 000 ₽, при повторном нарушении — от 6 000 000 до 18 000 000 ₽ |
| Первая утечка — в зависимости от числа затронутых субъектов (ч. 12–14) | от 3 до 5 млн ₽ (1–10 тыс. человек), от 5 до 10 млн ₽ (10–100 тыс.), от 10 до 15 млн ₽ (более 100 тыс.) |
| Утечка специальных категорий данных / биометрии | от 10 до 15 млн ₽ / от 15 до 20 млн ₽ |
| Повторная утечка — оборотный штраф | от 1% до 3% совокупной годовой выручки, но не менее 20 млн ₽ (для специальных категорий и биометрии — 25 млн ₽) и не более 500 млн ₽ |
Для должностных лиц и ИП по большинству составов действуют отдельные, более низкие суммы. Практика применения новых норм только формируется, поэтому точные размеры штрафов по конкретной ситуации стоит сверять с актуальной редакцией ст. 13.11 КоАП РФ на момент принятия решения.
Даже для небольшого приложения эти суммы ощутимы: первая же утечка базы из нескольких тысяч пользователей может обойтись дороже, чем вся разработка первой версии.
Требования магазинов приложений
Помимо 152-ФЗ, у каждого стора — свои требования к приватности, и они проверяются при каждой публикации новой версии приложения. Сам процесс публикации описан в статье «Публикация приложения в RuStore, App Store и Google Play».
| Требование | App Store | Google Play | RuStore |
|---|---|---|---|
| Политика конфиденциальности | Обязательна, ссылка в карточке и в самом приложении | Обязательна, ссылка в карточке и данные в форме Data safety | Приложение проходит обязательную проверку при публикации; актуальные требования к политике — в «Гайде по требованиям к приложениям» RuStore |
| Декларация собираемых данных | «Ярлыки приватности» (App Privacy) в карточке приложения | Раздел Data safety с перечнем категорий данных и целей их использования | Запрашиваемые разрешения должны соответствовать функциям приложения; формат декларации сверяйте с документацией RuStore |
| Отслеживание между приложениями | Требует App Tracking Transparency — явный запрос разрешения у пользователя | Регулируется правилами по рекламному ID, отдельного системного диалога нет | Отдельного системного диалога нет; сбор данных SDK регулируется 152-ФЗ и правилами площадки |
| Удаление аккаунта | Обязательно удаление аккаунта внутри приложения (Guideline 5.1.1(v)), без звонков и писем в поддержку | Обязательны оба способа: удаление внутри приложения и через веб-ссылку на страницу удаления | Явно не закреплено так, как у Apple и Google, но по 152-ФЗ пользователь в любом случае вправе потребовать удаления своих данных — функцию стоит делать для всех платформ |
Для App Store и Google Play кнопка «Удалить аккаунт» — отдельный пункт модерации: если её нет, а приложение поддерживает регистрацию, публикацию могут отклонить. Требования RuStore к формату политики конфиденциальности стоит сверять с актуальной документацией платформы перед каждой крупной публикацией — правила магазинов меняются чаще, чем закон.
Что заложить в ТЗ и архитектуру
Требования к персональным данным дешевле закладывать на этапе проектирования, чем переделывать перед публикацией в сторе. Разумный минимум для технического задания на приложение:
- Минимизация данных. Собирать только то, что реально нужно для работы функции — не «на всякий случай про запас».
- Шифрование. Передача данных — только по HTTPS/TLS; чувствительные данные в базе — в зашифрованном виде.
- Безопасное хранение токенов. Токены доступа и сессии — в Keychain на iOS и Keystore на Android, а не в обычных файлах настроек.
- Разграничение доступа в админ-панели. Не у каждого сотрудника поддержки должен быть доступ к полной базе персональных данных.
- Логирование доступа. Кто, когда и к каким записям обращался — пригодится и для безопасности, и для ответа на запрос пользователя.
- Сроки хранения и автоматическое удаление. Заранее определить, сколько хранятся данные после удаления аккаунта, и реализовать это программно, а не вручную.
- Резервные копии в России. Бэкапы базы данных с персональными данными должны храниться там же, где и основная база, — на серверах в РФ.
- Экран согласия и журнал согласий — как отдельный, спроектированный заранее элемент интерфейса, а не доработка перед релизом.
- Функция удаления аккаунта — сразу в дизайне, с учётом требований App Store и Google Play.
Эти пункты влияют и на выбор технологии, и на стоимость разработки: хостинг в России, шифрование и журналирование — это конкретные строки в смете, а не абстрактное «соответствие закону». Полезно свериться и с тем, какие данные вообще нужны приложению, ещё на этапе планирования, чтобы не собирать лишнее.
Частые ошибки
- Согласие спрятано внутри оферты. Один чекбокс «принимаю условия» на пользовательское соглашение, политику и согласие сразу — с 1 сентября 2025 года это прямое нарушение требования об отдельном согласии.
- Политика конфиденциальности «позаимствована» у похожего приложения. В ней остаются чужое название компании, чужие цели обработки и чужие SDK — при проверке это сразу заметно и юридически не защищает никого.
- Серверы за рубежом «для скорости». Удобный зарубежный облачный хостинг для базы данных с персональными данными российских пользователей нарушает требование о локализации, даже если данные больше никуда не передаются.
- Забыли про SDK. Аналитика, реклама и карты подключены без проверки, куда уходят данные и нужно ли по ним отдельное уведомление о трансграничной передаче.
- Нет процедуры удаления данных. Кнопка «удалить аккаунт» есть, но данные физически остаются в базе — при запросе пользователя или проверке это создаёт риск.
- Нет договора поручения обработки с подрядчиком. Разработчик или фрилансер имеет доступ к базе данных после сдачи проекта, а договор ничего не говорит про персональные данные. Что ещё проверить в договоре с разработчиком — в статье «Как выбрать подрядчика для разработки приложения».
Частые вопросы
Нужно ли уведомлять Роскомнадзор, если у приложения мало пользователей?
Да, обязанность подать уведомление об обработке персональных данных не зависит от размера аудитории — она возникает с момента начала обработки. Освобождены от уведомления только отдельные случаи, прямо перечисленные в законе (например, обработка без использования средств автоматизации), и почти ни один из них не относится к мобильному приложению.
Можно ли хранить персональные данные пользователей в зарубежном облаке?
Первичную запись, накопление, хранение и извлечение персональных данных граждан России нужно вести в базах данных на территории РФ. Использовать зарубежное облако как основное хранилище персональных данных российских пользователей нельзя — часть операций с данными при этом попадает под запрет.
Нужна ли политика обработки персональных данных, если в приложении нет регистрации?
Если приложение не собирает никаких данных, которые относятся к конкретному человеку — например, полностью офлайн-калькулятор без аналитики и рекламы, — формальной обязанности может не быть. Но как только подключается почти любая аналитика или push-уведомления, приложение начинает собирать идентификаторы устройства, и политика становится нужна.
Как быть с пользователями младше 14 лет?
Обработка персональных данных несовершеннолетних требует повышенной осторожности: по общему правилу согласие на обработку данных ребёнка младше 14 лет даёт его законный представитель (родитель или опекун), а не сам ребёнок. Если аудитория приложения включает детей, этот сценарий нужно закладывать в интерфейс согласия отдельно и уточнять у юриста применительно к конкретному продукту.
Кто отвечает за утечку данных, если она произошла у подрядчика?
Перед пользователями и Роскомнадзором отвечает оператор — то есть владелец приложения, а не подрядчик-обработчик. Договор с подрядчиком может предусматривать его ответственность перед оператором за нарушение условий обработки, но это не освобождает владельца приложения от обязанности уведомить регулятора и пострадавших пользователей.
Нужно ли отдельное согласие для push-уведомлений?
Технические push-уведомления, которые нужны для работы самого сервиса (например, уведомление о статусе заказа), обычно укладываются в исполнение договора с пользователем. А вот рекламные и маркетинговые push — это уже самостоятельная цель обработки, для которой стоит получать отдельное согласие, не смешивая его с согласием на обработку данных для работы приложения.
Что делать, если пользователь запросил удаление своих данных?
Нужно исполнить запрос в порядке и сроки, установленные 152-ФЗ, — удалить или обезличить данные, если нет законного основания хранить их дальше (например, требований бухгалтерского или налогового учёта), и подтвердить пользователю исполнение запроса. Наличие такой процедуры и её описание в политике обработки — это то, что проверяют и регулятор, и модерация сторов.
Перед публикацией приложения
- Уведомление Роскомнадзору об обработке персональных данных подано
- Политика обработки персональных данных опубликована и доступна по ссылке из приложения
- Согласие на обработку оформлено отдельным экраном, без предзаполненных галочек
- Договоры с разработчиком, хостингом и другими подрядчиками содержат условия о поручении обработки
- База данных с персональными данными российских пользователей размещена на серверах в РФ
- Проведена инвентаризация SDK и проверено, куда уходят данные
- Реализована и работает функция удаления аккаунта и данных
- Заполнены разделы приватности в App Store (App Privacy) и Google Play (Data safety)
Итог
Работа с персональными данными в приложении — не разовая формальность перед запуском, а постоянная часть эксплуатации: уведомление и политика подаются один раз, но согласие, локализация, состав SDK и процедура удаления данных требуют внимания на каждом крупном обновлении. Дешевле заложить это в архитектуру и договоры с подрядчиками ещё на этапе разработки, а не разбирать по частям после жалобы пользователя или запроса Роскомнадзора.
Если продукт ещё в раздумьях между нативной и кроссплатформенной разработкой, стоит помнить, что требования к безопасному хранению данных и работе с Keychain/Keystore закрываются немного по-разному в зависимости от выбранной технологии — это тоже разумно обсудить на старте проекта.
Материал носит информационный характер и не является юридической консультацией. Нормы 152-ФЗ, КоАП РФ и требования магазинов приложений приведены по состоянию на сентябрь 2026 года и могут измениться; конкретные суммы штрафов и порядок действий по отдельным составам стоит дополнительно проверять на момент принятия решения. Для оценки конкретного проекта проконсультируйтесь с юристом, специализирующимся на защите персональных данных.