Персональные данные в мобильном приложении: требования 152-ФЗ для разработчиков и владельцев

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

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

Почему персональные данные в мобильном приложении становятся предметом юридического риска

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

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

Отдельный риск создает смешение ролей. Заказчик приложения нередко считает, что за соблюдение закона отвечает разработчик, поскольку он создает интерфейс и серверную часть. На практике оператором персональных данных обычно выступает именно владелец сервиса, который определяет цели обработки и состав данных. Разработчик же может быть лицом, осуществляющим обработку по поручению оператора, если это прямо оформлено договором в соответствии с частью 3 статьи 6 Закона № 152-ФЗ. Если такого оформления нет, распределение ответственности становится спорным и неудобным для всех участников проекта.

Какие нормы применяются, когда обрабатываются персональные данные в мобильном приложении

Базовый акт в этой сфере, конечно, Закон № 152-ФЗ. Для мобильных сервисов наибольшее значение имеют статьи 5 и 6, определяющие принципы и условия обработки, статья 9 о согласии субъекта персональных данных, статья 18.1 о мерах, направленных на обеспечение выполнения обязанностей оператора, статья 19 о безопасности персональных данных и статья 22 об уведомлении уполномоченного органа. Если приложение ориентировано на потребителей, дополнительно имеет значение Закон РФ от 07.02.1992 № 2300-1 «О защите прав потребителей», поскольку информация о порядке использования сервиса и обработке пользовательских данных не должна быть вводящей в заблуждение.

Если в приложении используются элементы авторизации, электронного взаимодействия, хранения цифровых документов или идентификации клиента, нередко затрагиваются и положения Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». Для медицинских, образовательных, финансовых и иных специализированных сервисов действуют дополнительные отраслевые требования. Например, медицинское приложение может затрагивать не просто общие сведения о пользователе, а данные о состоянии здоровья, которые по статье 10 Закона № 152-ФЗ относятся к специальным категориям персональных данных и требуют повышенного внимания к основанию обработки.

На уровне ответственности основным актом выступает КоАП РФ. Вопросы, связанные с нарушением законодательства о персональных данных, регулируются статьей 13.11 КоАП РФ. Конкретный состав зависит от характера нарушения: отсутствие правового основания, избыточный сбор сведений, непредоставление обязательной информации субъекту, несоблюдение требований к опубликованию политики обработки, нарушение обязанностей по обеспечению безопасности. Поэтому персональные данные в мобильном приложении нельзя оценивать по принципу «документ есть или документа нет». Один и тот же сервис может одновременно допускать несколько разных нарушений.

Согласие в приложении и правовые основания обработки

Одна из самых частых ошибок связана с тем, что согласие в приложении подменяет собой весь правовой анализ. Между тем статья 6 Закона № 152-ФЗ допускает обработку персональных данных не только на основании согласия, но и в иных случаях, прямо предусмотренных законом, например для исполнения договора, стороной которого является субъект данных. Это важно для мобильных сервисов электронной торговли, доставки, записи на услуги, банковского обслуживания или телемедицины. Если пользователь оформляет заказ, часть сведений действительно может обрабатываться как необходимая для исполнения договора. Но это не дает права бесконтрольно расширять объем собираемой информации.

Согласие в приложении требуется там, где выбранное действие не может быть обосновано иным законным основанием. Типичный пример, маркетинговые рассылки, рекламный профиль пользователя, передача сведений партнерам, использование геолокации вне минимально необходимой функции сервиса, доступ к контактам, фотографиям или микрофону при отсутствии прямой связи с услугой. Для таких случаев необходимо не просто формально получить согласие, а обеспечить его конкретность, информированность, сознательность и однозначность. Это следует из статьи 9 Закона № 152-ФЗ.

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

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

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

Доступ приложения к данным: принцип минимизации и пределы допустимого сбора

С технической точки зрения приложение может запросить почти любую информацию, если пользователь нажмет кнопку согласия в интерфейсе операционной системы. Но доступ приложения к данным сам по себе не делает их сбор законным. Закон оценивает не возможность устройства, а необходимость обработки для заранее определенной и законной цели. Статья 5 Закона № 152-ФЗ требует, чтобы содержание и объем обрабатываемых данных соответствовали заявленным целям обработки, а сами данные не были избыточными.

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

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

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

Политика конфиденциальности приложения и документы, которые должны работать в связке

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

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

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

Документ	Для чего нужен	Что обычно вызывает риск
Политика в отношении обработки персональных данных	Раскрывает пользователю модель обработки и права субъекта	Несоответствие фактическим процессам приложения
Согласие пользователя	Фиксирует волеизъявление на конкретные действия, если иного основания нет	Слишком общий текст без разделения целей
Договор с разработчиком или подрядчиком	Определяет, действует ли подрядчик по поручению оператора и какие меры обязан соблюдать	Отсутствие условий о конфиденциальности, безопасности и пределах обработки
Внутренние локальные акты оператора	Подтверждают выполнение статьи 18.1 и статьи 19 Закона № 152-ФЗ	Документы есть только формально и не применяются в реальной работе

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

Передача данных через API, подрядчики и трансграничные вопросы

Во многих проектах ключевой риск скрыт не на экране регистрации, а в архитектуре обмена данными между системами. Передача данных через API происходит постоянно: мобильное приложение взаимодействует с backend, CRM, сервисом аналитики, платежной системой, платформой уведомлений, службой техподдержки, системой распознавания документов, сервисом карт и геолокации. Для бизнеса это обычная интеграция. Для юриста это цепочка возможных операций по передаче персональных данных, каждая из которых должна иметь правовое основание и быть описана в документах.

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

Передача данных через API особенно чувствительна там, где используются иностранные облачные платформы, сторонние библиотеки аналитики и инструменты push-маркетинга. В таких случаях необходимо отдельно оценивать, происходит ли трансграничная передача персональных данных и соблюдаются ли требования статьи 12 Закона № 152-ФЗ. Для оператора имеет значение не только страна регистрации поставщика, но и то, где физически размещаются серверы, кто имеет доступ к сведениям и как именно организован обмен информацией.

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

Какие ошибки чаще всего ухудшают позицию владельца приложения

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

Нередко встречается и другая проблема: оператор считает, что если пользователь поставил галочку, значит любые действия с данными допустимы. Это неверно. Даже при наличии согласия сохраняются требования статьи 5 Закона № 152-ФЗ о соразмерности объема данных заявленным целям, точности, достаточности и недопустимости избыточности. Согласие не устраняет обязанности обеспечивать безопасность обработки, ограничивать круг допущенных лиц и актуализировать документы при изменении функционала сервиса.

В практической работе чаще всего повторяются несколько ошибок:

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

Есть и менее заметные, но не менее важные нарушения. Например, отсутствие процедуры ответа на запросы субъекта персональных данных, невозможность корректно удалить учетную запись и связанные сведения, отсутствие сроков хранения разных категорий данных, неполный учет тестовых и резервных копий, где также могут находиться пользовательские сведения. Персональные данные в мобильном приложении должны оцениваться как непрерывный процесс, а не как разовая настройка при релизе.

Как выстроить правовую модель до спора и проверки

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

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

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

На практике наиболее устойчивую позицию получает тот владелец сервиса, который может показать логику обработки от цели до документа и от документа до технической реализации. Если политика конфиденциальности приложения соответствует реальному пользовательскому пути, если передача данных через API оформлена договорами и отражена в модели обработки, если согласие в приложении получено по тем целям, где оно действительно требуется, и если доступ приложения к данным ограничен необходимым объемом, спорная ситуация становится значительно управляемее.

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

Если вам нужна надежная команда юристов с большим практическим опытом, обращайтесь в ООО ЮК Шмелева и партнеры. Заявку можно оставить на сайте нашей юридической компании или позвонить по телефону 8 (800) 201 56 52. Отзывы о нашей работе можно посмотреть на Яндекс.Картах.