152-ФЗ и персональные данные в мобильном приложении
Разбор для владельца продукта: какие решения по данным нужно принять до разработки, а не после того как приложение уже отправляют в магазины.
Если мобильное приложение собирает имя, телефон, email, адрес, дату рождения, фото, геолокацию, медицинские сведения, историю заказов или другие данные, которые могут относиться к человеку, проект нужно планировать с учетом 152-ФЗ. Важно заранее описать, какие данные собираются, зачем они нужны, где хранятся, кто имеет доступ, как пользователь дает согласие, как данные удаляются и какие тексты проверяет юрист.
Подготовьте запрос на оценку приложения через практичные вопросы
Отметьте нужные функции: аккаунты, корзину, платежи, админку, интеграции, хранение данных и запуск.
Главные выводы
- Не все данные одинаково рискованные, но почти любое приложение с личным кабинетом собирает персональные данные.
- Требования 152-ФЗ влияют на серверную часть, аналитику, админ-панель, поддержку, резервные копии и доступы команды.
- Пользователь должен понимать, какие данные он передает и зачем.
- Нельзя просто скопировать чужую политику конфиденциальности: она должна соответствовать фактическому поведению приложения.
- Юристу нужно дать не общую идею приложения, а карту данных: поля, цели, хранение, интеграции, доступы и удаление.
Какие данные стоит выписать до разработки
| Тип данных | Примеры в приложении | Что решить заранее |
|---|---|---|
| Контакты | телефон, email, имя, мессенджер | зачем нужны, как подтверждаются, кто видит |
| Профиль | дата рождения, город, фото, интересы | обязательные поля или можно пропустить |
| Заказы и записи | адрес, история покупок, посещения, комментарии | срок хранения, доступ поддержки, возвраты |
| Геолокация | текущая точка, адрес доставки, маршрут | нужна постоянно или только в момент действия |
| Платежи | статус платежа, чек, возврат, тариф | что хранится у приложения, а что у платежного провайдера |
| Чувствительные сценарии | здоровье, дети, финансы, документы | отдельная проверка юриста, безопасность и ограничения доступа |
Что именно говорит закон о хранении
В 152-ФЗ есть важная для российских проектов норма: при сборе персональных данных, в том числе через интернет, запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан РФ должны происходить с использованием баз данных на территории России, если не применяется исключение. Для владельца приложения это означает, что вопрос "где находится сервер" нельзя оставлять на последний спринт.
На практике нужно обсудить с юристом и технической командой:
- какие данные считаются персональными в вашем сценарии;
- где находится основная база;
- где находятся резервные копии;
- какие внешние сервисы получают данные;
- что уходит в аналитику, рассылки, поддержку и платежи;
- как пользователь может удалить аккаунт или запросить данные;
- кто внутри компании имеет доступ к админ-панели.
Если приложение связано с медициной, образованием детей, финансами или корпоративными данными сотрудников, планируйте юридическую проверку как часть разработки, а не как формальность перед релизом.
Согласие, политика и тексты в приложении
Пользователь должен видеть понятные документы до передачи данных. Минимальный набор обычно включает политику конфиденциальности, согласие на обработку персональных данных, условия использования и контакты оператора. Для некоторых сценариев могут понадобиться отдельные согласия: рассылки, рекламные уведомления, обработка специальных категорий данных или передача третьим лицам.
Не делайте документы отдельно от продукта. Если приложение просит геолокацию, политика должна объяснять, зачем она нужна. Если есть push-уведомления, нужно разделять технические уведомления о заказе и маркетинговые сообщения. Если есть админ-панель, важно описать, кто видит данные и зачем.
Apple просит указывать сведения о приватности приложения в App Store, а Google Play требует заполнить раздел безопасности данных. Поэтому несоответствие между фактическим сбором данных, политикой и карточкой магазина может стать не только юридическим риском, но и проблемой публикации. Для проверки используйте официальные материалы Apple про App Privacy Details и Google Play про Data safety.
Есть идея приложения и нужен трезвый следующий шаг?
Разобрать идею приложенияАналитика и внешние сервисы
Многие команды думают, что персональные данные — это только поля анкеты. Но данные могут уходить в аналитику, журналы ошибок, чат поддержки, сервис рассылок, платежного провайдера, CRM, систему записи или облачное хранилище.
Перед запуском сделайте простую карту:
- какие события аналитики отправляются;
- есть ли в событиях телефон, email, имя, адрес или номер заказа;
- какие ошибки пишутся в журналы;
- какие данные видит поддержка;
- какие данные получает платежный провайдер;
- какие данные выгружаются в CRM;
- где хранятся вложения, фото, документы или записи.
Хорошая практика — не отправлять лишние личные данные в аналитику и журналы. Для продуктовой аналитики часто достаточно обезличенного идентификатора, события и статуса, а не полного телефона или адреса.
Как Appfyl подходит к проектам с данными
В Appfyl мы начинаем с карты данных. Сначала определяем роли: пользователь, администратор, менеджер, провайдер, врач, преподаватель, курьер или сотрудник. Затем описываем, какие данные каждая роль создает, видит и меняет.
После этого проектируется серверная часть: авторизация, права доступа, админ-панель, журналы, резервные копии, удаление аккаунта и события аналитики. Это помогает не превращать безопасность в позднюю переделку.
Для MVP-проектов Appfyl обычно планирует бюджет в диапазоне 1-1,5 млн рублей. Если в продукте есть чувствительные данные, платежи, несколько ролей, сложная админ-панель или юридически значимые действия, оценка часто ближе к средним и крупным диапазонам: 1,5-3,5 млн рублей и выше. Сам 152-ФЗ не делает проект дорогим автоматически, но дисциплина вокруг данных добавляет работу, которую нельзя игнорировать.
Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.
Что подготовить для оценки
Перед разговором со студией или юристом выпишите:
- Какие данные пользователь вводит сам.
- Какие данные приложение собирает автоматически.
- Какие данные видит администратор.
- Какие внешние сервисы нужны: платежи, CRM, рассылки, аналитика, карты, поддержка.
- Где пользователь может удалить аккаунт.
- Какие данные должны храниться после удаления из-за бухгалтерии, возвратов или споров.
- Какие сценарии являются чувствительными: здоровье, дети, финансы, документы, геолокация.
Если вы пока не уверены в функциях, начните с интерактивного брифа Appfyl: он помогает разложить приложение по ролям, функциям и интеграциям.
Используйте эти выводы, чтобы собрать реалистичную первую версию.
Оценить MVPПревратите исследование в план запуска
Appfyl поможет превратить идею в понятный план приложения, список функций первой версии и план первых работ.
Обсудить план приложенияПолезные ссылки
Частые вопросы
Скорее всего, да, если приложение собирает имя, телефон, email, историю записей или комментарии клиента. Точный состав обязанностей должен проверить юрист, но проектировать данные нужно заранее.
Для российских персональных данных нужно отдельно проверять требования к локализации, фактическое место хранения, резервные копии и внешние передачи. Не принимайте решение только по удобству разработки.
Нужно и то и другое. Документ должен описывать реальность, а приложение должно технически ограничивать доступ, не писать лишнее в журналы и давать пользователю понятный путь по данным.
Во многих случаях оператор персональных данных обязан подавать уведомление, но есть исключения и детали. Это вопрос для юриста, которому нужно дать карту данных и описание процессов.
Собирайте только нужные данные, уберите лишние поля, ограничьте доступы в админ-панели, не отправляйте личные данные в аналитику и заранее проверьте юридические тексты.