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

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

Apple требует разместить ссылку на политику конфиденциальности в App Store Connect и сделать ее доступной внутри приложения. Отдельно разработчик заполняет сведения о конфиденциальности для карточки приложения. В них учитываются не только собственный сервер и база, но и сторонние сервисы, встроенные в приложение.

Google Play также требует ссылку в карточке и доступ к документу внутри приложения. Все опубликованные приложения заполняют раздел «Безопасность данных». В правилах Google Play о пользовательских данных прямо указано, что политика должна описывать доступ, сбор, использование и передачу данных, в том числе через сторонний код.

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

Для российского продукта есть еще один уровень. Статья 18.1 Федерального закона № 152-ФЗ обязывает оператора опубликовать документ о политике обработки персональных данных и обеспечить к нему доступ. Требования закона не заменяются правилами Apple или Google, а правила магазинов не заменяются российским документом.

Сначала составьте карту данных

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

Для каждой строки укажите источник, цель, предполагаемое основание обработки, получателей, место хранения, роли с доступом, срок и способ удаления. Формулировка «для улучшения качества сервиса» ничего не объясняет ни пользователю, ни разработчику.

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

Что написать в самой политике

В начале должно быть понятно, кто выступает оператором. Укажите полное наименование, адрес и рабочий способ связи. Эти сведения не должны противоречить названию разработчика в магазине приложений и реквизитам компании.

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

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

Также нужны сведения о получателях и подрядчиках, трансграничной передаче, если она есть, сроках хранения или правилах их определения, защите, правах пользователя, порядке обращения, отзыва согласия и удаления данных, дате вступления документа в силу и изменениях.

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

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

Политика, согласие и разрешение телефона — разные вещи

Политика информирует пользователя обо всей обработке. Формы App Store и Google Play дают краткое структурированное описание до установки. Разрешение iOS или Android технически открывает доступ к камере, микрофону, фотографиям или геолокации. Согласие относится к определенной цели обработки, когда именно согласие служит подходящим основанием.

Разрешение на камеру для загрузки фотографии не означает согласие на распознавание лица или рекламу. Отказ от необязательной аналитики не должен ломать запись на услугу, если она может работать без аналитики.

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

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

Проверьте сторонние SDK и сервисы

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

Apple возлагает на разработчика ответственность за сторонний код и требует декларации конфиденциальности для ряда распространенных SDK. Google Play также требует отражать их поведение в разделе «Безопасность данных». Ссылка на политику поставщика не освобождает владельца приложения от проверки.

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

Чек-лист безопасности Android-приложения поможет проверить разрешения, журналы, секреты и зависимости. Общие меры защиты собраны в чек-листе безопасности мобильного приложения.

Учтите 152-ФЗ до выбора инфраструктуры

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

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

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

Удаление аккаунта должно работать во всех системах

Если в iOS-приложении можно создать аккаунт, Apple требует дать возможность начать его удаление внутри приложения. Google Play требует внутренний сценарий и отдельную страницу в интернете, с которой пользователь может отправить запрос на удаление аккаунта и связанных данных.

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

Сценарий обычно включает повторное подтверждение личности, понятное описание последствий, остановку будущих списаний, подтверждение запроса и состояние для сотрудника поддержки. Запрос должен дойти до внешних сервисов, если они хранят связанные данные.

Требования Google Play к удалению аккаунтов удобно превратить в критерии приемки. Добавьте их в чек-лист публикации приложения, а не оставляйте на день модерации.

Как меняется документ для разных приложений

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

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

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

Конкретные примеры делают документ короче и понятнее, потому что он рассказывает о реальном сервисе, а не перечисляет все юридические термины, которые когда-либо встречались в чужих политиках.

Проверка перед отправкой в магазины

1. Зафиксируйте состав версии. Запишите функции, разрешения, адреса серверов, версии SDK, админ-панель и подрядчиков именно для готовой сборки.
2. Дорисуйте все потоки. Не забудьте действия до входа, уведомления, журналы, поддержку, выгрузки и резервные копии.
3. Подготовьте документ под рынки запуска. Проверьте российские и зарубежные требования, а чувствительные сценарии передайте юристу.
4. Заполните формы из той же карты. Сравните каждую строку сведений Apple и Google с политикой.
5. Проверьте права пользователя. Откажите в разрешении, отзовите необязательное согласие, запросите сведения и удалите тестовый аккаунт.
6. Назначьте владельца документа. Сохраните версию, дату, согласование и список изменений, после которых требуется повторная проверка.

Карта и результаты тестов должны остаться у владельца продукта. В руководстве по передаче документации перечислено, что нужно получить от разработчика при завершении проекта.

Как не потерять актуальность после запуска

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

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

Храните предыдущие версии и даты действия. О существенных изменениях сообщайте понятным способом. Исправление опечатки не требует навязывать пользователю новое согласие.

Как Appfyl учитывает приватность при оценке

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

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

Укажите роли, разрешения, интеграции и удаление в интерактивном брифе Appfyl. О разработке мобильного продукта можно узнать на сайте Appfyl.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

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