Delete and anonymize data

1) Purpose and area

Ensure legal, secure and provable deletion/anonymization of player data, transactions and operational logs in all systems (product/wallet, KYC/AML, RG, marketing/CRM, analytics/DWH, logs/AWP), including vendors/providers and backups, taking into account localization by jurisdiction.

2) Principles

1. Politics before practice. Retention, targets and storage locations are identified prior to collection.
2. Minimization and separation. Separate vaults for PII, tokenization in events.
3. Deletion = event with evidence. Any deletion is confirmed by an artifact.
4. Fail-Closed. Unknown status/region → PII operations are not allowed.
5. Backups-aware. Backups follow the same rules as combat data.
6. "Anonymization instead of perpetual storage." If the law does not require PII, we transfer it to aggregates.

3) Roles and RACI

DPO/Compliance (Owner) - retention/deletion policy, exceptions, audit. (A)

Security/Infra - encryption, keys, crypto erasure, backups/DR. (R)

Data Platform/Analytics - de-PII pipelines, aggregates, DWH/DL. (R)

Product/Engineering/SRE - removal API, cascades, tests, observability. (R)

Legal - local terms and restrictions (AML/licensed). (C)

Privacy Ops/DSAR Team - custom deletions/fixes. (R)

Vendor Manager - obligations of vendors, confirmation of performance. (R)

Internal Audit - samples, CAPA. (C)

4) Data taxonomy and retention standard

5) Technical methods

5. 1 Removal

Cascaded logical/physical: soft-delete → job for physical deletion.
Crypto-shredding: destruction of the segment/tenant encryption key; applies to backups/archives.
Revocation of tokens: recall of payment/tracker tokens from providers.
Nullify/Mask for fields that require a formal record save (for example, accounting).

5. 2 Pseudonymization

Replacing primary identifiers with tokens; the mapping table is stored separately with a separate KMS.

5. 3 Anonymization

Aggregation/cohortation, k- anonimnost/ℓ -diversity, binning, rare value clipping, differential privacy in reports.

5. 4 Log masking

The agent edits the PII at the assembly (e. g., e-mail → hash/partial), prohibition of "raw" identifiers in APM.

6) Deletion lifecycle

1. Trigger: retention period, DSAR-erase, account closure, withdrawal of consent, completion of contract/goal.
2. Score: Are there legal blocks? (AML/legal-hold/license).
3. Orchestration: an erasure package is formed by systems/vendors.
4. Execution: cascades, revoke tokens, crypto-wipe for archives.
5. Validation: reconciliation of records, control of residuals (orphaned data).
6. Artifact: Report with batch/key hashes, time and volume.
7. Reporting: KPI dashboard, audit/regulator log.

7) Special areas of attention

7. 1 Backups/Archives/DR

Backups in the same region, encryption and key cataloging.
Realistic: physical removal from immutable-backup is difficult → we use crypto-shredding segment when the deadline is reached.

7. 2 Logs and telemetry

PII-free by default policy; if PII is inevitable - local logs, short deadlines, masking on the agent.

7. 3 DWH/Analytics

De-PII data only; if necessary, historians - anonymize and break the connection with the original PII.

7. 4 Vendors and providers

DPA/additional agreements: deadlines, deletion mechanisms, Certificate of Destruction/Erase Evidence.

7. 5 Localization by jurisdiction

Removal is carried out in the regional perimeter, export of PII outside it is prohibited; Global Reports - Aggregates Only

8) API/Events and Data Model

• `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) Control and observability

Erasure Coverage - the proportion of systems covered by automatic deletion.
Time-to-Erase - median time from trigger to completion.
Orphaned Data Rate - detected "orphaned" records.
Backup Crypto-Shred SLA - keys destroyed on time.
Vendor Ack Rate - the share of confirmations of deletions from vendors on time.
DSAR Erase SLA - Meet deadlines for user-defined deletions.
Auditability Score - presence of artifacts by samples.

10) Checklists

A) Politics and design

• Category/Market Qualification Register approved by Legal/DPO.
• System/Vendor Map showing PII/Regions/Keys.
• Defined methods: cascade/crypto-wipe/de-PII for analytics.
• DPAs/contracts updated (deletion SLAs, confirmations).

B) Technique and operations

• The delete API and job orchestrator are enabled.
• PII-free logs/agents mask sensitive fields.
• Backups are encrypted, keys are segmented by market.
• Autotests: DSAR-erase, cron retentions, orphan scan.
• KPI/Alert dashboard.

C) Audit and Improvements

• Quarterly system/vendor samples with deletion artifacts.
• DR/Recovery test with remote segments.
• CAPA by balances/violations found.

11) Templates (quick inserts)

A) Clause with vendor (deletion/retention)

B) Anonymization solution (internal form)

C) Answer to user (DSAR-erase complete)

12) Frequent mistakes and prevention

Removal from the combat database, but not from backups. → Crypto-shredding and key registry.
PII in logs/AWP. → Masking on the agent, short retention.
Orphan records (cross-services). → Orphan scans and contract cascades.
DWH with PII-tails. → De-PII pipelines before export, prohibition of raw identifiers.
No artifacts. → Mandatory report generation and WORM storage.
Vendor has not deleted. → SLA and sanction/hold payments before confirmation.

13) 30-day implementation plan

Week 1

1. Approve the retentions register and methods matrix (cascade/crypto/de-PII).
2. Make a map of systems/vendors/keys, mark regional perimeters.
3. Specify the model of artifacts and KPI dashboard.

Week 2

4) Implement a deletions orchestrator, API and events; connect DSAR links.
5) Enable log masking and "PII-free by default" rules.
6) Configure crypto-shred for backups, KMS segmentation by market.

Week 3

7) De-PII pipeline for DWH (cohorts/k-anonymity/binning).
8) Pilot deletions: 20 DSAR cases + 2 retention parties; Close the CAPA.
9) Update DPA with key vendors (SLAs/confirmations).

Week 4

10) Full release; start dashboard and alerts (Time-to-Erase, Vendor Ack).
11) DR test with remote key segment.
12) Plan v1. 1: diff. privacy in reports, scheduled auto-orphan scans.

14) Interrelated sections

GDPR: user consent management

Cookies and CMP System Policy

Privacy by Design: design principles

Localization of data by jurisdictions

DSAR: user requests for data

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

Compliance Dashboard and Monitoring/Internal and External Audit