Під час аудиту GDPR-відповідності клієнтського порталу ми виявили відсутність незмінного журналу згод. Регулятор запитав докази — без Consent Log компанія ризикувала штрафом до 20 млн євро або 4% річного обороту. Типовий запит: надати історію змін згод для кожного користувача за останні 3 роки. Без журналу ви не зможете цього зробити — доведеться або визнавати відсутність даних, або підробляти записи. Судова практика підтверджує, що компанії без Consent Log програють справи. Ми розробили рішення, яке не лише фіксує кожну дію користувача, а й надає API для керування та експорту даних. Наш досвід — понад 30 проєктів, де журнал згод став основою юридичної безпеки. Згідно з GDPR (https://en.wikipedia.org/wiki/General_Data_Protection_Regulation), згода має бути отримана законно та доказово. Consent Log — єдиний спосіб забезпечити прозорий аудит. Регулятори щорічно виписують штрафи на мільярди євро за подібні порушення.
Що має містити Consent Log?
GDPR вимагає фіксацію контексту кожної події:
- Часова мітка згоди (timestamp)
- Хто дав згоду (користувач або анонімний ID)
- На що саме дано згоду (конкретні категорії: аналітика, маркетинг тощо)
- Версія документа, з яким ознайомився користувач
- Метод отримання згоди (banner, checkbox, API)
- IP-адреса та user-agent для прив'язки до юрисдикції
| Характеристика | Без журналу | З Consent Log |
|---|---|---|
| Можливість довести отримання згоди | Ні | Так, з точністю до секунди |
| Швидкість відповіді на DSAR | 5–7 днів ручного збору | 5 хвилин через API |
| Вартість обробки одного DSAR-запиту | до 2000 євро | незначні |
| Ризик штрафу за відсутність доказів | Високий (до 20 млн євро) | Мінімізований |
Схема бази даних
CREATE TABLE consent_events (
id BIGSERIAL PRIMARY KEY,
-- Ідентифікація
user_id BIGINT REFERENCES users(id) ON DELETE SET NULL,
anonymous_id UUID, -- для неавторизованих
session_id VARCHAR(100),
-- Дані згоди
event_type VARCHAR(20) NOT NULL, -- 'granted', 'denied', 'withdrawn', 'updated'
categories JSONB NOT NULL, -- {"analytics": true, "marketing": false, ...}
document_version VARCHAR(20), -- версія Privacy Policy
method VARCHAR(30), -- 'banner', 'settings_page', 'api', 'import'
-- Контекст
ip_address INET,
user_agent TEXT,
country_code CHAR(2),
language_code CHAR(5),
-- Аудит
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
-- Заборона оновлення рядків (immutable audit log)
updated_at TIMESTAMPTZ,
CONSTRAINT no_updates CHECK (updated_at IS NULL)
);
-- Індекси для швидкого пошуку
CREATE INDEX idx_consent_user ON consent_events(user_id) WHERE user_id IS NOT NULL;
CREATE INDEX idx_consent_anon ON consent_events(anonymous_id) WHERE anonymous_id IS NOT NULL;
CREATE INDEX idx_consent_date ON consent_events(created_at);
CREATE INDEX idx_consent_type ON consent_events(event_type);
Як реалізувати незмінний Consent Log?
Ми використовуємо комбінацію SQL-обмежень та архітектури, що виключає оновлення записів. Додатково можна додати хеш попереднього рядка для ланцюжка — це блокчейн-підхід без блокчейну. Результат: впевненість, що журнал не був скомпрометований. Для прискорення пошуку — індекси за user_id та anonymous_id. Весь код покривається тестами незмінності.
Подія: користувач дав згоду на аналітику та маркетинг через банер. До таблиці потрапляє: timestamp, user_id (або anonymous_id), категорії {"analytics": true, "marketing": true}, версія «v2.1», метод «banner», IP з Німеччини, user-agent Chrome на Windows. Усі рядки лише вставляються, ніколи не оновлюються.
Запис згод
import uuid
from datetime import datetime
import hashlib
class ConsentLogger:
def __init__(self, db, geoip):
self.db = db
self.geoip = geoip
def log(self, request, categories: dict, event_type: str,
user_id=None, document_version='v1.0'):
# Визначити анонімний ідентифікатор
anonymous_id = self._get_or_create_anonymous_id(request)
country = self.geoip.country(request.remote_addr)
self.db.execute("""
INSERT INTO consent_events
(user_id, anonymous_id, session_id, event_type, categories,
document_version, method, ip_address, user_agent, country_code, created_at)
VALUES (%s, %s, %s, %s, %s::jsonb, %s, %s, %s, %s, %s, %s)
""", (
user_id,
anonymous_id,
request.session.get('id'),
event_type,
json.dumps(categories),
document_version,
'banner',
request.remote_addr,
request.user_agent.string[:500],
country,
datetime.utcnow()
))
def _get_or_create_anonymous_id(self, request):
cookie_id = request.cookies.get('consent_id')
if cookie_id:
return cookie_id
return str(uuid.uuid4())
def get_user_consent_history(self, user_id: int):
return self.db.query("""
SELECT event_type, categories, document_version, created_at, ip_address
FROM consent_events
WHERE user_id = %s
ORDER BY created_at DESC
""", (user_id,))
def get_current_consent(self, user_id: int) -> dict:
"""Актуальна згода користувача"""
latest = self.db.query_one("""
SELECT categories FROM consent_events
WHERE user_id = %s AND event_type IN ('granted', 'updated')
ORDER BY created_at DESC
LIMIT 1
""", (user_id,))
return latest['categories'] if latest else {}
API для керування згодами
@app.route('/api/my/consent', methods=['GET'])
@login_required
def get_my_consent():
"""Поточна згода користувача"""
current = consent_logger.get_current_consent(current_user.id)
history = consent_logger.get_user_consent_history(current_user.id)
return jsonify({
'current': current,
'history': [{
'event': r['event_type'],
'categories': r['categories'],
'version': r['document_version'],
'date': r['created_at'].isoformat(),
} for r in history[:10]]
})
@app.route('/api/my/consent', methods=['DELETE'])
@login_required
def withdraw_consent():
"""Відкликання згоди на маркетингову обробку"""
consent_logger.log(
request,
categories={'analytics': False, 'marketing': False, 'preferences': False},
event_type='withdrawn',
user_id=current_user.id
)
# Видалити дані з маркетингових систем
revoke_from_mailchimp(current_user.email)
revoke_from_facebook_custom_audience(current_user.email)
return jsonify({'status': 'withdrawn'})
Експорт для регулятора
def export_consent_for_user(user_id: int) -> dict:
"""Звіт для відповіді на запит регулятора або DSAR"""
records = db.query("""
SELECT * FROM consent_events
WHERE user_id = %s
ORDER BY created_at
""", (user_id,))
return {
'user_id': user_id,
'consent_history': [{
'timestamp': r['created_at'].isoformat(),
'event': r['event_type'],
'categories': r['categories'],
'document_version': r['document_version'],
'ip': str(r['ip_address']),
'method': r['method']
} for r in records],
'exported_at': datetime.utcnow().isoformat(),
'format_version': '1.0'
}
API-експорт скорочує час відповіді на DSAR з 5 днів до 5 хвилин — у 1440 разів швидше за ручний збір.
Процес впровадження та терміни
- Аналітика — вивчаємо поточну систему згод, виявляємо прогалини.
- Проєктування — схема БД, API, експортні формати.
- Реалізація — пишемо код, міграції, налаштовуємо індекси.
- Тестування — юніт-тести, інтеграційне тестування незмінності, навантаження до 1000 запитів/с.
- Деплой — розгортання на production, консультація команди.
Реалізація під ключ — від 2 до 3 робочих днів. При інтеграції зі складними legacy-системами термін може збільшитися до 5 днів. Ми виконали понад 30 проєктів з журналом згод за 6 років роботи — накопичений досвід дозволяє уникнути типових помилок.
Що входить в роботу
- Код модуля Consent Logger на Python/Django або Node.js
- SQL-міграції для створення таблиці
consent_eventsта індексів - REST API для керування згодами (поточна, відкликання, історія)
- Експорт даних для DSAR у JSON-форматі, готовий до відправки регулятору
- Інструкція з підключення до фронтенду (банер згод, сторінка налаштувань)
- Навантажувальне тестування: до 1000 запитів на секунду
- Консультація з юридичної сторони (які категорії фіксувати, як довго зберігати — зазвичай 3 роки)
| Етап | Що робимо | Результат |
|---|---|---|
| Аналітика | Аудит поточного потоку згод, пошук вразливостей | Звіт з рекомендаціями |
| Проєктування | Схема consent_events, індекси, архітектура API |
Документація схеми |
| Реалізація | Написання ConsentLogger, REST-ендпоінтів |
Робочий код |
| Тестування | Перевірка незмінності, навантажувальне тестування | 100% проходження тестів |
| Деплой | Розгортання, моніторинг | Запуск на production |
Типові помилки при впровадженні Consent Log
- Зберігання лише поточної згоди, без історії змін — це не відповідає GDPR.
- Використання UPDATE замість INSERT — журнал стає перезаписуваним.
- Відсутність anonymous_id для неавторизованих користувачів — неможливо прив'язати події.
- Пропуск контекстних даних (IP, user-agent, мова) — регулятор може вимагати.
- Не налаштований експорт для DSAR — доводиться писати на коліні під запит.
Ми гарантуємо, що ваша реалізація Consent Log відповідатиме духу та букві GDPR. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Замовте впровадження — отримайте готове рішення за кілька днів.