Реалізація журналу обробки персональних даних у мобільному додатку
GDPR вимагає не тільки отримати согласие на обробку даних, але й документувати кожну операцію обробки (Article 30 — Records of Processing Activities). Для B2C мобільних додатків з аудиторією в EU це означає: зберігати машиночитаємий журнал того, які дані, коли, для яких цілей та на якій основі обробляються.
Що журналювати
Операції обробки, які потрібно логувати:
- Збір даних при реєстрації: поля, timestamp, правове основання (consent/contract/legitimate interest)
- Передача третім лицям: відправка email у Mailchimp, аналітика у Firebase, реклама у AdMob — кожна передача з указанием отримувача та цілі
- Зміна даних: оновлення профілю, email, телефону
- Видалення: по запиту користувача або за істечення retention period
- Доступ: коли та кім з сотрудниць переглядалися дані (корпоративні додатки)
Схема журналу
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()
Журнал — append-only. Записи не редагуються та не видаляються (видалення записів журналу саме по собі нарушення). Retention журналу — мінімум 3 років.
Автоматичне журналювання на сервері
Зручніше всього реалізувати через middleware/аспекти, а не вручну в кожному сервісі:
# Django middleware приклад
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–3 дні: схема журналу, middleware для автоматичного логування ключових операцій, API для читання історії, клієнтський UI.