Data Retention and Deletion Schedules

1) Purpose and area

Establish a single Retention Schedule and managed deletion/anonymization schedules for all systems and jurisdictions to:

comply with laws/licenses (GDPR/ePrivacy/AML/local acts);
minimize PII volume;
ensure provability of performance (artifacts/logs);
Reduce incident risk and storage costs

Coverage: account/profile, KYC/AML, payments/PSP, gaming telemetry, RG/SE, CRM/marketing, affiliates, logs/AWP, analytics/DWH, backups/archives, providers/vendors, all target markets.

2) Principles

1. Lawful & Purpose-bound. Deadlines are tied to legal grounds and processing purposes.

2. Data Minimization. Minimum fields/dates; "anonymization instead of perpetual storage."

3. Local-first. Retention is observed within the region (data residency).
4. Policy-as-Data. Graphs are stored as machine-readable records (diagrams), versioned and applied by automation.
5. Fail-Closed. Expired/unknown reason → disallowed/delete trigger.
6. Auditability. Each deletion/anonymization → an artifact in the WORM store.
7. Backups-aware. Backups/archives are subject to the same deadlines (crypto-shredding segments).

3) Roles and RACI

DPO/Head of Compliance (Owner) - policy, register, interpretation of norms, exceptions. (A)

Legal - legal grounds/deadlines for markets, legal holds. (R)

Security/Infra - KMS/encryption, crypto-shred, log access. (R)

Data Platform/Analytics - de-PII/anonymization, DWH/DL rules. (R)

Engineering/SRE - orchestrator of retention, cascades, integration with systems/vendors. (R)

Product/CRM - compliance of features and suppression flows with deadlines. (C)

Vendor Manager - DPA/SLA for removal, confirmation from providers. (R)

Internal Audit - selections, CAPA, independent verification. (C)

4) Data taxonomy and basis

Categories (example):

KUS/Age/Biometrics - documents, selfies/liveliness, verdicts. (Grounds: law/license, public interest; often 5-7 years)
Payments/PCI - tokens, transactions/registries, chargeback. (Reasons: contract/accounting law/PCI)
Game activity - bets/wins, bonuses, discounts. (Grounds: contract/license, operator's interest)
RG/SE - self-exclusion statuses, availability checks/reality checks. (Grounds: law/license, public interest)
CRM/Marketing - contacts, consents, campaign histories. (Grounds: consent/legitimate interest)
Affiliates - click-id, placement, terms-hash (without player PII). (Grounds: contract, legitimate interest)
Logs/AWS - technical events (PII-free by default). (Grounds: legitimate interest/safety)
Analytics/DWH - aggregates/pseudonyms, ML features. (Grounds: legitimate interest/research)

5) Timeline matrix (framework)

Category	Structure	Retention (basic)	After term
CCM/biometrics	passport/selfie/verdict	5-7 years (or by market)	cascade + crypto-shred in archives
Payments	operations, tokens	Accounting/PCI	revoke tokens + identity masking
Gaming events	bets/winnings/bonuses	business need/license (e.g. 5 years)	de-PII → cohorts
RG/SE	statuses/flags	term of license/prevention	save flag without PII, remove bundles
CRM/consents	e-mail/SMS/push, TC-lines	up to otzyva/≤24 months of inactivity	immediate suppression + deletion
Logs/AWS	errors/trails (PII-free)	30-180 days	auto-purge/rotation
Analytics/DWH	aggregates/k-anon. no term (if anonymous)	—

💡 Specific deadlines are set at the jurisdiction level in the profiles (see § 7).

6) Exceptions and blocks

AML/license requirements - priority over the application for removal (DSAR-erase), restriction and minimization are applied.
Legal Hold/disputes/investigations - stop flag for removal; we fix the basis and term.
Third party rights/secrets - editing/depersonalization when issuing/exporting.
Operational registers (for example, accounting) - masking instead of deleting primary keys.

7) Regional profiles (template)


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

8) Policy-as-Data: Graph Model

Store the graphs as entries in the configuration database/registry:


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
}

Versioning is required: any edit → new version + migration plan.

9) Workflows (sketch)

1. Detection: 'retention _ due _ detected' (cron/stream by creation events).
2. Eligibility: checking for exceptions (AML/hold/residency).
3. Orchestration: a package of systems/vendors is formed, strategy (erase/anonymize).
4. Execution: cascading delete jobs, revoke tokens, crypto-shred segment keys in backups.
5. Validation: reconciliation of records, orphan scan, selective verification of DWH/logs.
6. Evidence: report (check amounts, key id, time, volumes) in WORM; link to dashboard.
7. Reporting: KPIs, alerts, CAPAs in case of failures.

10) Backups, archives and DR

Localization: backups in the same region/block.
Encryption: per-region KMS/HSM; keys are segmented by market/tenant.
Crypto-shredding: on reaching the deadline - destruction of the segment key, report with 'kms _ key _ id'.
Immutable storages: mark "waiting for crypto-shred" in the scheduler.

11) Analytics/DWH and anonymization

De-PII Pipeline: before export to DWH - tokenization/truncation/k-anon, bining dates/geo, suppression of rare values, diff. privacy on reports.
Global Reports - Aggregates Only; banning "raw" PIIs outside the region.
Fate of historians: after the term - breaking ties with primary identifiers.

12) Integration with DSAR/CMP/Localization

DSAR-erase: uses the same orchestration/artifact mechanisms; in case of conflicts with AML, → the restriction instead of deleting.
CMP/Consent: withdrawal of consent → immediate stop-processing and inclusion of a marketing data retention timer.
Residency: graphs are applied in the regional perimeter, PII exports are subordinate to cross-border mechanisms.

13) Deletion Artifacts Model


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 and dashboard

Retention Compliance Rate - the proportion of records that have reached the deadline and processed in the SLA.
Time-to-Erase - median/95th percentile from trigger to completion.
Backup Crypto-Shred SLA - the proportion of segments with destroyed keys on time.
Orphaned Data Rate - orphaned records/nonsynchronous replicas.
Vendor Erasure Ack - confirmation from vendors on time.
DSAR Linkage - the proportion of deletions associated with DSAR cases.
Auditability Score -% of tasks with full package of artifacts.
Exceptions Mix - The proportion of records held by AML/hold.

15) Checklists

A) Design and policy

Category and Market Registry approved by DPO/Legal.
Legal basis and action_after are defined for each record.
Schedule versioning and next revision date.
System/Vendor/Key Map and Localization Perimeters.

B) Technique and operations

The Presentation Orchestrator is connected to all systems.
Cascaded deletions/masking/anonymization tested.
Crypto-shred for backups: keys are segmented, reports are generated.
Orphan scans and scheduled validation samples.
The WORM artifact store is available to the audit.

C) Vendors

DPA/SLA: deletion period, format of confirmations, penalties.
Quarterly confirmations, test deletions.
Blacklist of providers with violations.

16) Templates (quick inserts)

A) Schedule record (YAML example)

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) Vendor clause (deletion/confirmation)

💡 The Supplier shall, within N days from the date of the request, delete/anonymize the data in accordance with the attached retention schedule and provide confirmation (volume, method, time, key/lot identifiers).

C) Anonymization Decision (DWH)

key> Individual Events Expired. We save only aggregates with k≥20, binning dates (week), geo - up to "region," suppression of rare categories <0.5%.

17) Frequent mistakes and prevention

Removed from the production database, but not from backups. → Crypto-shred, key accounting by market.
PII fall into AWS/logs. → PII-free by default, masking on the agent, short retention.
DWH with PII tails. → Mandatory de-PII pipeline before export.
No artifacts. → Mandatory generation of'erasure _ artifact'and WORM storage.
Vendor did not confirm deletion. → Hold payments/sanctions, escalation and offboarding.

18) 30-day implementation plan

Week 1

1. Approve the taxonomy/grounds and primary registry of retentions by categories.
2. Prepare regional profiles (EU/UK/...): deadlines, exceptions, backups.
3. Specify model 'retention _ rule' and 'erasure _ artifact'.

Week 2

4) Deploy the presentation orchestrator (cron/stream), connect key systems.
5) Set up crypto-shred (KMS by market), log of key operations.
6) Include de-PII pipeline for DWH/reports.

Week 3

7) Pilot: 2 categories (CRM/logs) + 1 game event part → anonymization.
8) Vendor tests: requests for deletion and confirmation.
9) KPI/KRI dashboard and alerts (Time-to-Erase, Orphan Rate).

Week 4

10) Full release; quarterly reviews of schedules and regional profiles.
11) CAPA for found residues/violations.
12) Plan v1. 1: automatic orphan scans and vendor reports.

19) Interrelated sections

Delete and anonymize data

DSAR: user requests for data

Localization of data by jurisdictions

GDPR: Consent Management/Cookies and CMP Policy

Privacy by Design

At Rest/In Transit, KMS/BYOK/HYOK encryption

Compliance Dashboard and Monitoring/Internal and External Audit