Видалення та анонімізація даних

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

Забезпечити законне, безпечне і доказове видалення/анонімізацію даних гравців, транзакцій і операційних журналів у всіх системах (продукт/гаманець, KYC/AML, RG, маркетинг/CRM, аналітика/DWH, логи/АРМ), включаючи вендорів/провайдерів і бекапи, з урахуванням локалізації по юрисдикціях.

2) Принципи

1. Політика передусім практики. Ретенція, цілі та місця зберігання визначені до збору.
2. Мінімізація і розділення. Окремі сховища для PII, токенізація в подіях.
3. Видалення = подія з доказом. Будь-яке видалення підтверджується артефактом.
4. Fail-Closed. Невідомий статус/регіон → заборону операцій з PII.
5. Backups-aware. Бекапи підкоряються тим же правилам, що бойові дані.
6. «Анонімізація замість безстрокового зберігання». Якщо закон не вимагає PII - переводимо в агрегати.

3) Ролі та RACI

DPO/Compliance (Owner) - політика ретенції/видалення, виключення, аудит. (A)

Security/Infra - шифрування, ключі, крипто-стирання, бекапи/DR. (R)

Data Platform/Analytics - де-PII пайплайни, агрегати, DWH/DL. (R)

Product/Engineering/SRE - API видалення, каскади, тести, спостережуваність. (R)

Legal - локальні терміни та обмеження (AML/ліцензійні). (C)

Privacy Ops/DSAR Team - призначені для користувача видалення/виправлення. (R)

Vendor Manager - зобов'язання вендорів, підтвердження виконання. (R)

Internal Audit - вибірки, CAPA. (C)

4) Таксономія даних і стандарт ретенції

5) Технічні методи

5. 1 Видалення

Каскадне логічне/фізичне: soft-delete → job на фізичне видалення.
Крипто-стирання (crypto-shredding): знищення ключа шифрування сегмента/тенанта; застосовується до бекапів/архівів.
Revocation токенів: відкликання платіжних/трекерних токенів у провайдерів.
Nullify/Mask: для полів, що вимагають формального збереження запису (наприклад, бухгалтерія).

5. 2 Псевдонімізація

Заміна первинних ідентифікаторів токенами; таблиця відповідностей зберігається окремо з окремим KMS.

5. 3 Анонімізація

Агрегування/кохортування, k- anonimnost/ℓ -diversity, бінінг, обрізка рідкісних значень, диференціальна приватність у звітах.

5. 4 Маскування логів

Агент редагує PII на зборі (e. g., e-mail → hash/partial), заборона «сирих» ідентифікаторів в APM.

6) Життєвий цикл видалення

1. Тригер: термін ретенції, DSAR-erase, закриття аккаунта, відкликання згоди, завершення договору/мети.
2. Оцінка: чи є юридичні блоки? (AML/легал-холд/ліцензія).
3. Оркестрація: формується erasure-пакет за системами/вендорами.
4. Виконання: каскади, токени revoke, крипто-wipe для архівів.
5. Валідація: звірка записів, контроль залишків (orphaned data).
6. Артефакт: звіт з хешами партій/ключів, часом і обсягом.
7. Репортинг: дашборд KPI, журнал для аудиту/регулятора.

7) Особливі зони уваги

7. 1 Бекапи/архіви/DR

Бекапи в тому ж регіоні, шифрування і каталогізація ключів.
Реалістично: фізичне видалення з immutable-backup складно → застосовуємо crypto-shredding сегмента при досягненні терміну.

7. 2 Логи і телеметрія

Політика PII-free by default; якщо PII неминучі - локальні логи, короткі терміни, маскування на агенті.

7. 3 DWH/аналітика

Тільки де-PII дані; при необхідності історики - анонімізувати і розірвати зв'язок з вихідною PII.

7. 4 Вендори та провайдери

DPA/додаткової угоди: терміни, механізми видалення, підтвердження виконання (Certificate of Destruction/Erase Evidence).

7. 5 Локалізація по юрисдикціях

Видалення здійснюється в регіональному периметрі, експорт PII за його межі заборонений; глобальні звіти - тільки агрегати.

8) API/івенти та модель даних

• `retention_due_detected`, `erasure_job_started`, `erasure_job_completed`, `crypto_shred_done`, `vendor_erasure_ack_received`, `erase_validation_failed`, `dsar_erase_linked`, `audit_artifact_saved`.

erasure_job {
id, subject_id_hash    scope{cohort    partition}, trigger{retention    dsar    contract_end    consent_withdrawn},
market, region, systems[], vendors[],
started_at_utc, completed_at_utc, status{ok    partial    failed},
method{cascade    crypto_shred    nullify    token_revoke},
counts{records, tables, bytes}, checksum{before, after},
keys_destroyed[{kms_key_id, destroyed_at_utc, evidence_id}],
validation{orphan_scan:passed    failed, sample_checks[]},
linked_cases{dsar_case_id?}, owner, approvers{dpo, security}, audit_artifacts[]
}

9) Контроль і спостережуваність

Erasure Coverage - частка систем, покритих автоматичним видаленням.
Time-to-Erase - медіана часу від тригера до завершення.
Orphaned Data Rate - виявлені «осиротілі» записи.
Backup Crypto-Shred SLA - вчасно знищені ключі.
Vendor Ack Rate - частка підтверджень віддалень від вендорів вчасно.
DSAR Erase SLA - дотримання термінів по призначених для користувача видалень.
Auditability Score - наявність артефактів за вибірками.

10) Чек-листи

A) Політика та дизайн

• Реєстр ретенції за категоріями/ринками затверджений Legal/DPO.
• Карта систем/вендорів із зазначенням PII/регіонів/ключів.
• Визначено методи: каскад/крипто-wipe/де-PII для аналітики.
• DPA/контракти оновлені (SLA видалення, підтвердження).

B) Техніка та операції

• API видалення і оркестратор завдань включені.
• PII-free логи/агенти маскують чутливі поля.
• Бекапи зашифровані, ключі сегментовані по ринках.
• Автотести: DSAR-erase, cron ретенції, orphan-скан.
• Панель моніторингу KPI/алерти.

C) Аудит і поліпшення

• Квартальні вибірки систем/вендорів з артефактами видалення.
• Тест DR/відновлення з урахуванням віддалених сегментів.
• CAPA за знайденими залишками/порушеннями.

11) Шаблони (швидкі вставки)

A) Клауза з вендором (видалення/ретенція)

B) Рішення щодо анонімізації (внутрішня форма)

C) Відповідь користувачеві (DSAR-erase завершено)

12) Часті помилки і профілактика

Видалення з бойової БД, але не з бекапів. → Crypto-shredding і реєстр ключів.
PII в логах/АРМ. → Маскування на агенті, коротка ретенція.
Орфанні записи (крос-сервіси). → Orphan-скани і контрактні каскади.
DWH з PII-хвостами → Де-PII пайплайни перед експортом, заборона сирих ідентифікаторів.
Немає артефактів. → Обов'язкова генерація звітів і WORM-сховище.
Вендор не видалив. → SLA і санкції/hold платежів до підтвердження.

13) 30-денний план впровадження

Тиждень 1

1. Затвердити реєстр ретенції та матрицю методів (каскад/крипто/де-PII).
2. Скласти карту систем/вендорів/ключів, відзначити регіональні периметри.
3. Специфікувати модель артефактів і дашборд KPI.

Тиждень 2

4) Реалізувати оркестратор видалень, API і події; підключити DSAR-лінки.
5) Включити маскування логів і правила «PII-free by default».
6) Налаштувати crypto-shred для бекапів, сегментацію KMS по ринках.

Тиждень 3

7) Де-PII конвеєр для DWH (кохорти/k-анонімність/бінінг).
8) Пілотні видалення: 20 кейсів DSAR + 2 партії з ретенції; закрити CAPA.
9) Оновити DPA з ключовими вендорами (SLA/підтвердження).

Тиждень 4

10) Повний реліз; запустити дашборд і алерти (Time-to-Erase, Vendor Ack).
11) DR-тест з сегментом віддалених ключів.
12) План v1. 1: Дифф. приватність у звітах, авто-orphan-скани за розкладом.

14) Взаємопов'язані розділи

GDPR: управління згодою користувачів

Політика cookies та CMP-системи

Privacy by Design: принципи проектування

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

DSAR: запити користувачів на дані

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

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