Соответствие мобильного приложения GDPR: аудит и внедрение

Мы проводим аудит и внедряем полное соответствие мобильного приложения требованиям GDPR. Это не одна галочка «добавить кнопку согласия» и не одна неделя работы. Это сквозное изменение архитектуры: от того, что собирается при установке, до того, как обрабатывается запрос на удаление данных через 18 месяцев после регистрации. Большинство приложений проваливают именно технические проверки, а не формальные — Data Protection Authority смотрит на реальное поведение SDK, а не на текст Privacy Policy. Более 5 лет мы помогаем стартапам и enterprise-проектам избегать штрафов до 4% годового оборота.

Почему GDPR-соответствие требует перестройки архитектуры

Типичный стартап присылает приложение с фразой «мы уже GDPR-compliant». После аудита находим:

Firebase Analytics инициализируется до согласия. SDK пишет app_open и first_open события при первом запуске — до того, как пользователь увидел экран согласия. Это нарушение принципа Data Minimisation. Решение — отложенная инициализация через FirebaseApp.initializeApp() только после получения согласия на аналитику.

Advertising ID считывается автоматически. AdvertisingIdClient.getAdvertisingIdInfo() на Android и ASIdentifierManager.shared().advertisingIdentifier на iOS — оба читаются при старте AppsFlyerSDK или Adjust. Без согласия на маркетинг эти идентификаторы трогать нельзя.

Crashlytics отправляет данные без разбора. По умолчанию Firebase Crashlytics включён с момента сборки. Технически crash report содержит device model, OS version, free disk space — это личные данные по GDPR определению. Нужно либо отключать до согласия, либо настраивать с isCrashlyticsCollectionEnabled = false по умолчанию.

Логи содержат персональные данные. Android Logcat и iOS os_log часто содержат email, userId, content of API responses. Если crashlytics или сторонний SDK собирает логи — они уходят на сервера вне EU без явного согласия.

Наша методика отложенной инициализации снижает объём отправляемых данных на 70% по сравнению с обычным запуском.

Как мы строим GDPR-compliant архитектуру

Consent Gate — обязательный первый экран — соответствие мобильного приложения

До любой инициализации аналитических, рекламных или профилирующих SDK — экран согласия. Не pop-up поверх контента, не «принять всё» как единственная опция. IAB TCF v2.2 устанавливает стандарт для mobile: гранулярные категории с возможностью отклонить каждую.

Согласие хранится локально и синхронизируется на сервер. Структура:

struct ConsentRecord: Codable { let userId: String? // nil до регистрации let deviceId: String // IDFV или ANDROID_ID let timestamp: Date let version: String // версия Privacy Policy let purposes: [ConsentPurpose: Bool] // Источник согласия для аудита let collectionMethod: String // "explicit_ui_v2", "imported_from_v1" } enum ConsentPurpose: String, Codable { case necessary case analytics case marketing case personalization case thirdPartySharing } 

SDK-оркестрация на основе согласия

Создаём единую точку инициализации SDK, которая проверяет consent перед каждой инициализацией:

class SDKOrchestrator(private val consentManager: ConsentManager) { fun onConsentUpdated(consent: ConsentRecord) { // Necessary — всегда initializeCrashReporting(minimal = true) // Analytics — только с согласия if (consent.purposes[ANALYTICS] == true) { FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(true) } else { FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(false) } // Marketing — GAID/IDFA только с согласия if (consent.purposes[MARKETING] == true) { initializeAppsFlyer() // requestTrackingAuthorization для iOS 14.5+ } // Third-party sharing — другие рекламные сети if (consent.purposes[THIRD_PARTY_SHARING] == true) { initializeAdjust() } } } 

На iOS 14.5+ маркетинговые SDK требуют ATTrackingManager.requestTrackingAuthorization — это системный диалог, отдельный от нашего consent UI. Порядок важен: сначала наш экран с объяснением, потом системный диалог Apple.

Как реализовать право на доступ (Data Subject Access Request)

Пользователь вправе запросить все данные, которые мы о нём храним. В мобильном приложении это означает:

1. Экран «Мои данные» в настройках профиля
2. Кнопка «Запросить выгрузку» → сервер получает задачу
3. В течение 30 дней (требование GDPR) — ответ на email или in-app уведомление с архивом

Сервер должен агрегировать данные из всех источников: основная БД, аналитические события, push-токены, история сессий, данные третьих сторон (если они хранятся). Согласно GDPR Article 15, пользователь имеет право на копию данных.

Право на удаление (Right to Erasure)

Детально рассматривается в отдельной услуге. В контексте GDPR: удаление должно быть полным, включая резервные копии (с допустимым сроком до следующего цикла backup retention), данные у субпроцессоров, anonymized logs где anonymization обратима.

Технические сложности: данные, необходимые для исполнения договора (история заказов, платежи) могут храниться дольше — до истечения законодательно установленного срока. Нужна классификация данных с разными retention policies.

Обработка данных несовершеннолетних

Если приложение может использоваться детьми до 16 лет (в большинстве стран EU — 16, в некоторых — 13), нужна дополнительная верификация возраста и согласие родителей. Профилирование и поведенческая реклама для несовершеннолетних — под запретом.

Data Processing Agreement с субпроцессорами

Firebase, Amplitude, Braze, Mixpanel, Adjust — все они субпроцессоры. С каждым должен быть подписан DPA. Google/Firebase предоставляют стандартный DPA через Google Cloud Console. Amplitude — отдельно. Большинство команд об этом не думают до первого аудита.

Трансграничная передача данных

Серверы в US принимают данные EU пользователей? Нужно Standard Contractual Clauses (SCC, последние обновления). Самоcертификация EU-US Data Privacy Framework заменила Privacy Shield, но требует регистрации в Министерстве торговли США — актуально для компаний с US-юрисдикцией.

В мобильном приложении это влияет на выбор дата-центра Firebase (можно выбрать EU region для Firestore/Functions), регион Amplitude (api.eu.amplitude.com) и другие SDK с настройкой региона.

Типичные нарушения и решения (таблица)

Что входит в работу

• Аудит всех SDK и конфигураций (проксирование трафика, анализ логов)
• Разработка и интеграция consent-экрана с гранулярными настройками
• Настройка отложенной инициализации всех SDK
• Реализация DSAR и Right to Erasure
• Подготовка и подписание DPA с субпроцессорами
• Документация Record of Processing Activities (ROPA)
• Код-ревью и тестирование
• Поддержка при прохождении проверки DPA

Как внедрить GDPR: пошаговая инструкция

1. Проведите аудит всех SDK и отследите их поведение при первом запуске.
2. Разработайте экран согласия в соответствии с IAB TCF v2.2.
3. Реализуйте consent-менеджер и отложенную инициализацию.
4. Настройте DSAR workflow на сервере.
5. Проверьте retention policies в базе данных.
6. Подпишите DPA со всеми субпроцессорами.
7. Протестируйте сценарии отзыва согласия и удаления данных.

Сроки

Закажите аудит текущего приложения. Получите консультацию по вашему случаю — мы оценим проект и предложим оптимальный план внедрения.