Графіки зберігання та видалення даних

1) Мета і область

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

Охоплення: акаунт/профіль, KYC/AML, платежі/PSP, ігрова телеметрія, RG/SE, CRM/маркетинг, афіліати, логи/АРМ, аналітика/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) Таксономія даних і підстави

• КУС/Вік/Біометрія - документи, селфі/жвавість, вердикти. (Підстави: закон/ліцензія, суспільний інтерес; часто 5-7 років)
• Платежі/PCI - токени, операції/реєстри, chargeback. (Підстави: договір/закон бухобліку/PCI)
• Ігрова активність - ставки/виграші, бонуси, дисконти. (Підстави: договір/ліцензія, інтерес оператора)
• RG/SE - статуси самовиключення, перевірки доступності/реаліті-чеки. (Підстави: закон/ліцензія, суспільний інтерес)
• CRM/Маркетинг - контакти, згоди, історії кампаній. (Підстави: згода/законний інтерес)
• Афіліати - click-id, placement, terms-hash (без PII гравця). (Підстави: договір, законний інтерес)
• Логи/АРМ - техподія (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 потрапляють в АРМ/логи. → 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

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