Реалізація журналу обробки персональних даних у мобільному застосунку

Уявіть: ваш мобільний застосунок із мільйоном користувачів у EU. DPA запитує Records of Processing Activities — доказ compliance. Якщо журналу немає, штраф до 4% річного обороту. Саме це сталося з одним із наших клієнтів: після аудиту вони отримали припис за недокументовану передачу даних у рекламну мережу. Ми впровадили журнал за 3 дні, і при повторній перевірці штрафу вдалося уникнути.

GDPR (Article 30) вимагає не просто отримати згоду, а фіксувати кожну операцію: коли, які дані, для яких цілей і на якій підставі. Для B2C застосунків з аудиторією в EU це означає зберігати машиночитаний журнал. Ми пропонуємо повний цикл: аудит поточного стеку, проєктування схеми, реалізацію middleware та клієнтського інтерфейсу.

На практиці 60% застосунків, які ми перевіряли, не логують передачу даних аналітичним сервісам. А це пряме порушення. Наше рішення автоматично перехоплює такі операції та фіксує їх в append-only журналі.

Які операції потрібно журналювати?

Операції обробки, які обов'язково логувати:

• Збір даних при реєстрації: поля, timestamp, правова підстава (consent/contract/legitimate interest)
• Передача третім особам: надсилання email у Mailchimp, аналітика в Firebase, реклама в AdMob — кожна передача із зазначенням отримувача та мети
• Зміна даних: оновлення профілю, email, телефону
• Видалення: за запитом користувача або після закінчення retention period
• Доступ: коли та ким із співробітників переглядалися дані (для корпоративних застосунків)

Чому журнал має бути append-only?

Редагування або видалення записів журналу саме по собі є порушенням GDPR. Тому журнал — append-only. Записи не змінюються та не видаляються. Retention журналу — мінімум 3 роки. Для мобільних застосунків із високою частотою операцій це може бути від 50 000 до 500 000 записів на місяць. Правильна індексація (user_id, operation_type, created_at) забезпечує швидкий пошук при аудиті.

Схема журналу

data_processing_logs: id UUID PK user_id UUID FK NULLABLE -- null для анонімних операцій operation_type VARCHAR -- 'collect', 'transfer', 'update', 'delete', 'access' data_categories TEXT[] -- ['email', 'location', 'purchase_history'] purpose VARCHAR -- 'analytics', 'marketing', 'service_provision' legal_basis VARCHAR -- 'consent', 'contract', 'legitimate_interest' third_party VARCHAR NULLABLE -- 'firebase', 'mailchimp', null actor_type VARCHAR -- 'user', 'system', 'staff' actor_id UUID NULLABLE -- ID співробітника при actor_type='staff' ip_address INET NULLABLE metadata JSONB -- доп. контекст created_at TIMESTAMPTZ DEFAULT NOW() 

Як реалізувати журнал на сервері?

Найзручніше реалізувати через middleware/аспекти, а не вручну в кожному сервісі. Це знижує ризик пропустити операцію. Приклад на Django:

class DataProcessingLogMiddleware: LOGGED_ENDPOINTS = { 'POST /api/auth/register': ('collect', ['email', 'name'], 'contract'), 'PUT /api/user/profile': ('update', ['profile_data'], 'contract'), 'DELETE /api/user': ('delete', ['all_user_data'], 'legal_obligation'), } def process_response(self, request, response): key = f"{request.method} {request.path}" if key in self.LOGGED_ENDPOINTS and response.status_code < 400: op_type, categories, basis = self.LOGGED_ENDPOINTS[key] DataProcessingLog.objects.create( user_id=request.user.id if request.user.is_authenticated else None, operation_type=op_type, data_categories=categories, legal_basis=basis, ip_address=get_client_ip(request) ) return response 

Що бачить користувач у розділі «Мої дані»?

Користувач за GDPR має право побачити, як оброблялися його дані. У застосунку — розділ «Налаштування → Приватність → Історія обробки даних». Показуємо відфільтрований журнал: лише записи з user_id поточного користувача, без технічних деталей, зі зрозумілими описами операцій.

struct DataProcessingEntry: Identifiable, Decodable { let id: UUID let operationDescription: String // "Ваші дані передано аналітичному сервісу" let date: Date let dataCategories: [String] let purpose: String } 

Треті особи вказуємо за офіційними назвами (Google Analytics, Meta Pixel) — користувач має впізнати сервіс.

Інтеграція з consent management

При відкликанні згоди на конкретну мету (наприклад, маркетинг) — створюємо запис у журналі operation_type='consent_revoked' та припиняємо передачу даних відповідним третім особам. Це документує момент відкликання — важливо при аудиті DPA.

Як ми це робимо: етапи впровадження

1. Аудит потоків даних — виявляємо всі точки збору та передачі. Аналізуємо код, конфіги мережевих запитів, інтеграції з SDK (Firebase, AppsFlyer).
2. Проєктування схеми журналу під ваш стек (PostgreSQL, MongoDB, BigQuery). Обираємо оптимальну модель із урахуванням навантаження.
3. Реалізація middleware/аспектів для автоматичного логування ключових операцій. Налаштовуємо тригери на critical endpoints.
4. API для читання історії користувачем — з фільтрацією, пагінацією, правами доступу.
5. Розробка клієнтського UI на SwiftUI / Jetpack Compose / Flutter — показуємо зрозумілу історію.
6. Інтеграція з CMP (consent management platform) та відпрацювання відкликання згоди.
7. Документація API та аудиту, навчання команди.

Терміни та гарантія

Повний проєкт від 5 до 10 днів. Надаємо гарантію на відповідність вимогам GDPR та допомогу при DPA-аудиті. Наш досвід — понад 5 років у розробці мобільних застосунків та compliance-рішень. Отримайте консультацію: надішліть опис вашого застосунку, ми оцінимо обсяг робіт.

Зв'яжіться з нами для аудиту — перевіримо ваш поточний журнал за 1 день. Замовте впровадження журналу обробки даних та захистіть бізнес від штрафів.

Порівняння підходів до логування

Для більшості проєктів ми рекомендуємо middleware-підхід. Він дає баланс між вартістю впровадження та повнотою покриття. При високій частоті змін в API можна перейти на декларативний DPA-фреймворк.