Реализация GDPR-совместимости в мобильном приложении
Штраф по GDPR рассчитывается от глобального годового оборота — до 4% или €20M, что больше. Для мобильного приложения проблема конкретная: приложение собирает данные пользователей из ЕС, и нужно соответствовать требованиям регламента. Это не юридическая консультация — это список технических задач, которые нужно реализовать в коде.
Что считается персональными данными в контексте мобильного приложения
GDPR широко трактует «персональные данные». В мобильном контексте это: email, имя, телефон — очевидно. Но также: IP-адрес, рекламный идентификатор (IDFA/GAID), push-токен, геолокация, fingerprint устройства, поведенческие данные (какие экраны открывал, сколько времени провёл). Если аналитика Firebase или Amplitude собирает user_id в связке с любым из перечисленного — это персональные данные.
Согласие на обработку (Consent)
Согласие должно быть: конкретным (для каждой цели отдельно), информированным (что собирается и зачем), свободным (отказ не лишает функциональности) и отзываемым.
Технически: до первого сбора данных показывать CMP (Consent Management Platform). Популярные: OneTrust, Usercentrics, Didomi, Cookiebot. Все интегрируются в iOS и Android через SDK. Важно: Firebase Analytics, Facebook SDK, AppsFlyer не инициализировать до получения согласия.
Хранить согласие нужно с timestamp и версией Privacy Policy. При обновлении политики — запрашивать согласие повторно.
Права субъектов данных — техническая реализация
Право на доступ (Art. 15). Пользователь может запросить все данные о себе. Реализация: API endpoint, который агрегирует данные из всех баз и сервисов (основная БД, аналитика, CRM, пуш-сервис) и возвращает JSON или PDF. Автоматизация этого процесса экономит время поддержки.
Право на удаление (Art. 17, «право на забвение»). Не просто пометить пользователя как deleted — реально удалить или анонимизировать все персональные данные из всех хранилищ. Это включает: основную БД, аналитические системы (Firebase — deleteUserData, Amplitude — Delete User API), резервные копии (с задержкой по расписанию бэкапов), логи (обезличивание IP, user_id).
Полное удаление из бэкапов — сложная задача. Стандартная практика: бэкапы хранятся максимум 30–90 дней (документируется в Privacy Policy), после этого данные удалённых пользователей исчезают естественным образом.
Право на переносимость (Art. 20). Экспорт данных в машиночитаемом формате (JSON, CSV). Реализуется как функция в настройках приложения.
Право на исправление (Art. 16). Пользователь редактирует профиль — обычно уже есть. Проверить, что изменения синхронизируются во все связанные системы.
Минимизация данных и retention
GDPR требует собирать только то, что действительно нужно. Технический аудит: пройтись по всем местам отправки аналитики, убрать лишние поля. Firebase Analytics по умолчанию собирает многое — отключить через setAnalyticsCollectionEnabled(false) до согласия, ограничить через setUserProperty только нужными атрибутами.
Retention policy: данные хранятся только необходимое время. В Firebase Console — настройка retention периода. В основной БД — cron-job для анонимизации устаревших записей.
Обработка данных несовершеннолетних
Для пользователей до 16 лет (в некоторых странах ЕС — до 13) нужно согласие родителей. Технически: при регистрации запрашивать дату рождения, при обнаружении несовершеннолетнего — отдельный flow с верификацией родительского согласия или блокировка.
Data breach notification
GDPR требует уведомить надзорный орган в течение 72 часов после обнаружения утечки. Технически это означает: система мониторинга с алертами на аномальный доступ к данным, документированный процесс реагирования, логирование всех операций с персональными данными.
Что нужно от приложения конкретно
- CMP SDK интеграция с условной инициализацией SDK аналитики/рекламы
- Экран настроек конфиденциальности с управлением согласиями
- API для экспорта и удаления данных
- Политика конфиденциальности с актуальным описанием всех обрабатываемых данных
- Логирование согласий (кто, когда, какую версию принял)
- Механизм уведомления об изменениях политики
Объём работ варьируется от 3–5 дней (только технические изменения в существующем приложении при наличии CMP) до нескольких недель при необходимости строить инфраструктуру управления данными с нуля. Стоимость рассчитывается после аудита текущего состояния приложения и списка используемых сервисов.