Графики хранения и удаления данных

1) Цель и область

• соблюсти законы/лицензии (GDPR/ePrivacy/AML/локальные акты);
• минимизировать объем PII;
• обеспечить доказуемость исполнения (артефакты/журналы);
• сократить риски инцидентов и стоимость хранения.

Охват: аккаунт/профиль, KYC/AML, платежи/PSP, игровая телеметрия, RG/SE, CRM/маркетинг, аффилиаты, логи/APM, аналитика/DWH, бэкапы/архивы, провайдеры/вендоры, все целевые рынки.

2) Принципы

1. Lawful & Purpose-bound. Сроки привязаны к законным основаниям и целям обработки.
2. Data Minimization. Минимум полей/сроков; «анонимизация вместо бессрочного хранения».
3. Local-first. Ретенция соблюдается в пределах региона (data residency).
4. Policy-as-Data. Графики хранятся как машиночитаемые записи (схемы), версионируются и применяются автоматикой.
5. Fail-Closed. Истек срок/неизвестно основание → запрет использования/триггер удаления.
6. Auditability. Каждое удаление/анонимизация → артефакт в WORM-хранилище.
7. Backups-aware. Бэкапы/архивы подчиняются тем же срокам (crypto-shredding сегментов).

3) Роли и RACI

DPO/Head of Compliance (Owner) — политика, реестр, трактовка норм, исключения. (A)

Legal — юридические основания/сроки по рынкам, легал-холды. (R)

Security/Infra — KMS/шифрование, crypto-shred, доступ к журналам. (R)

Data Platform/Analytics — де-PII/анонимизация, DWH/DL правила. (R)

Engineering/SRE — оркестратор ретенции, каскады, интеграции с системами/вендорами. (R)

Product/CRM — соответствие фичей и suppression потоков срокам. (C)

Vendor Manager — DPA/SLA по удалению, подтверждения от провайдеров. (R)

Internal Audit — выборки, CAPA, независимая проверка. (C)

4) Таксономия данных и основания

• KYC/Возраст/Биометрия — документы, селфи/живость, вердикты. (Основания: закон/лицензия, общественный интерес; часто 5–7 лет)
• Платежи/PCI — токены, операции/реестры, chargeback. (Основания: договор/закон бухучета/PCI)
• Игровая активность — ставки/выигрыши, бонусы, дисконты. (Основания: договор/лицензия, интерес оператора)
• RG/SE — статусы самоисключения, проверки доступности/реалити-чеки. (Основания: закон/лицензия, общественный интерес)
• CRM/Маркетинг — контакты, согласия, истории кампаний. (Основания: согласие/законный интерес)
• Аффилиаты — click-id, placement, terms-hash (без PII игрока). (Основания: договор, законный интерес)
• Логи/APM — техсобытия (PII-free по умолчанию). (Основания: законный интерес/безопасность)
• Аналитика/DWH — агрегаты/псевдонимы, фичи ML. (Основания: законный интерес/исследования)

5) Матрица сроков (каркас)

6) Исключения и блоки

AML/лицензионные требования — приоритет над заявкой на удаление (DSAR-erase), применяем ограничение и минимизацию.
Legal Hold/споры/расследования — стоп-флаг на удаление; фиксируем основание и срок.
Права третьих лиц/секреты — редактирование/обезличивание при выдаче/экспорте.
Операционные реестры (например, бухгалтерия) — маскирование вместо удаления первичных ключей.

7) Региональные профили (шаблон)

Юрисдикция: ______
KYC/биометрия: срок ___; особые запреты/форматы: ___
Платежи/бухучет: срок ___; маскирование: ___
Игровая активность: срок ___; анонимизация: k≥__
RG/SE: срок ___; политика хранения флага: ___
CRM/согласия: неактивность ≤ __ мес; double opt-in: да/нет
Логи/APM: __ дней; PII-free: да/нет
Бэкапы/архивы: локализация ___; crypto-shred SLA ___
Исключения/легал-холд: условия ___

8) Policy-as-Data: модель графика

retention_rule {
rule_id, version, market, data_class{KYC    PCI    GAME    RG    CRM    LOG    ANON},
lawful_basis{consent    contract    legal_obligation    legit_interest    public_interest},
retention_days, grace_days, action_after{erase    anonymize    mask    revoke_token},
pii{yes/no}, residency_region, backups_policy{crypto_shred:true, kms_key_scope:region},
dsar_applicable{yes/no}, exceptions{aml:true, legal_hold:true},
owner{dpo    legal    security    data}, approved_at_utc, next_review_at_utc
}

Версионирование обязательно: любая правка → новая версия + миграционный план.

9) Рабочие процессы (sketch)

1. Detection: `retention_due_detected` (cron/stream по событиям создания).
2. Eligibility: проверка исключений (AML/hold/residency).
3. Orchestration: формируется пакет систем/вендоров, стратегия (erase/anonymize).
4. Execution: каскадные delete jobs, revoke токенов, crypto-shred ключей сегмента в бэкапах.
5. Validation: сверка записей, orphan-скан, выборочная проверка DWH/логов.
6. Evidence: отчет (чек-суммы, id ключей, время, объемы) в WORM; ссылка в дашборд.
7. Reporting: KPI, алерты, CAPA при сбоях.

10) Бэкапы, архивы и DR

Локализация: бэкапы в том же регионе/блоке.
Шифрование: per-region KMS/HSM; ключи сегментированы по рынкам/тенантам.
Crypto-shredding: по достижении срока — уничтожение ключа сегмента, отчет с `kms_key_id`.
Иммутабельные хранилища: пометка «ожидает crypto-shred» в планировщике.

11) Аналитика/DWH и анонимизация

De-PII Pipeline: перед экспортом в DWH — токенизация/усечение/k-анон, бининг дат/гео, подавление редких значений, дифф. приватность на отчетах.
Глобальные отчеты: только агрегаты; запрет «сырых» PII за пределы региона.
Судьба историков: после срока — разрыв связей с первичными идентификаторами.

12) Интеграции с DSAR/CMP/Локализацией

DSAR-erase: использует те же механизмы оркестрации/артефактов; при конфликтах с AML → ограничение вместо удаления.
CMP/Consent: отзыв согласия → немедленный stop-processing и включение таймера ретенции маркетинговых данных.
Резидентность: графики применяются в региональном периметре, экспорт PII подчинен трансграничным механизмам.

13) Модель артефактов удаления

erasure_artifact {
job_id, rule_version, market, region, scope{subject    partition    cohort},
systems[], vendors[], method{cascade    crypto_shred    anonymize    mask    revoke_token},
started_at_utc, completed_at_utc, status{ok    partial    failed},
counts{records, tables, bytes}, checksum{before, after},
kms_keys_destroyed[{id, destroyed_at_utc}], orphan_scan{passed    failed},
dsar_case_id?, approvers{dpo, security}, evidence_uri(WORM)
}

14) KPI/KRI и дашборд

Retention Compliance Rate — доля записей, достигших срока и обработанных в SLA.
Time-to-Erase — медиана/95-й перцентиль от триггера до завершения.
Backup Crypto-Shred SLA — доля сегментов с уничтоженными ключами вовремя.
Orphaned Data Rate — «осиротевшие» записи/несинхронные реплики.
Vendor Erasure Ack — подтверждения от вендоров в срок.
DSAR Linkage — доля удалений, связанных с кейсами DSAR.
Auditability Score — % задач с полным пакетом артефактов.
Exceptions Mix — доля записей, удержанных AML/hold.

15) Чек-листы

A) Дизайн и политика

• Реестр ретенции по категориям и рынкам утвержден DPO/Legal.
• Определены lawful basis и action_after для каждой записи.
• Версионирование графиков и дата следующего пересмотра.
• Карта систем/вендоров/ключей и локализационные периметры.

B) Техника и операции

• Оркестратор ретенции подключен ко всем системам.
• Каскадные удаления/маскирование/анонимизация протестированы.
• Crypto-shred для бэкапов: ключи сегментированы, отчеты формируются.
• Orphan-сканы и валидационные выборки по расписанию.
• WORM-хранилище артефактов доступно аудиту.

C) Вендоры

• DPA/SLA: срок удаления, формат подтверждений, штрафы.
• Ежеквартальные подтверждения, тестовые удаления.
• Черный список провайдеров с нарушениями.

16) Шаблоны (быстрые вставки)

A) Запись графика (YAML-пример)

yaml
- rule_id: CRM-MKT-EMAIL version: 1.3 market: EU data_class: CRM lawful_basis: consent retention_days: 730  # ≤24 мес неактивности grace_days: 30 action_after: erase pii: true residency_region: EU backups_policy: { crypto_shred: true, kms_key_scope: region }
dsar_applicable: true exceptions: { aml: false, legal_hold: true }
owner: dpo

B) Клауза по вендору (удаление/подтверждение)

C) Решение об анонимизации (DWH)

17) Частые ошибки и профилактика

Удалили из прод-БД, но не из бэкапов. → Crypto-shred, учет ключей по рынкам.
PII попадают в APM/логи. → PII-free по умолчанию, маскирование на агенте, короткая ретенция.
DWH с «хвостами» PII. → Обязательный de-PII pipeline перед экспортом.
Нет артефактов. → Обязательная генерация `erasure_artifact` и WORM-хранение.
Вендор не подтвердил удаление. → Hold платежей/санкции, эскалация и offboarding.

18) 30-дневный план внедрения

Неделя 1

1. Утвердить таксономию/основания и первичный реестр ретенции по категориям.
2. Подготовить региональные профили (EU/UK/…): сроки, исключения, бэкапы.
3. Специфицировать модель `retention_rule` и `erasure_artifact`.

Неделя 2

4) Развернуть оркестратор ретенции (cron/stream), подключить ключевые системы.
5) Настроить crypto-shred (KMS по рынкам), журнал ключевых операций.
6) Включить de-PII pipeline для DWH/отчетов.

Неделя 3

7) Пилот: 2 категории (CRM/логи) + 1 партиция игрового события → анонимизация.
8) Вендор-тесты: запросы на удаление и подтверждения.
9) Дашборд KPI/KRI и алерты (Time-to-Erase, Orphan Rate).

Неделя 4

10) Полный релиз; квартальные ревью графиков и региональных профилей.
11) CAPA по найденным остаткам/нарушениям.
12) План v1.1: автоматические orphan-сканы и отчеты по вендорам.

19) Взаимосвязанные разделы

Удаление и анонимизация данных

DSAR: запросы пользователей на данные

Локализация данных по юрисдикциям

GDPR: управление согласием / Политика cookies и CMP

Privacy by Design

Шифрование At Rest / In Transit, KMS/BYOK/HYOK

Дашборд комплаенса и мониторинг / Внутренний и внешний аудит