Retention policies

1) Why storage policies

Retention policies determine how long and why you store each type of data, where it is placed, who is responding, and how the data is deleted or anonymized. Without them, it is impossible to maintain privacy, minimization and reproducibility of reporting, especially in iGaming with sensitive PII/finance, regulation and investigations.

• Compliance with laws/licenses and agreements with providers/PSP.
• Minimize risks of leaks and fines.
• Predictable storage costs and platform performance.
• Support for DSAR, Legal Hold, audit, and versioning processes.

2) Basic principles

1. Purpose limitation-The term is tied to a specific processing target.
2. Minimization: do not store "just in case"; at the end of the goal - delete/anonymize.
3. Transparency and provability: each record must have an owner, class, term and basis.
4. Separation of environments: prod/stage/sandboxes with different dates and sets of fields.
5. Policy-as-Code: policy as configuration in repository + CI checks.
6. Defense in Depth: storage + backups + audit logs + Legal Hold are consistent.

3) Classification and legal grounds

Classes: Public/Internal/Confidential/Restricted (PII/finance) with tags: 'pii', 'financial', 'tokenized', 'backup', 'legal _ hold', 'wip', 'dsar _ subject'.

• Legal duty/licensing (e.g. reporting and AML).
• Contract execution (transactions/disbursements).
• Legitimate interest (security, anti-fraud) - with an assessment of the balance.
• Consent (marketing/personalization) - with separate deadlines and feedback.

4) Shelf life matrix (reference for iGaming)

key> Customize Your Jurisdictions and Licenses. Below are approximate categories and typical storage windows.

5) Legal Hold and Freeze

Legal Hold is temporarily canceling deletions/TTLs for sets related to the investigation/dispute.
The source of truth is the Legal Hold registry: owner, date, reason, data range, withdrawal date.
Removal - according to the approved process; all delayed deletions run as delayed jabs.

6) DSAR and "right to remove"

Store subject tokens (not PII) for graph search.
Maintain the distinction between deletion, aliasing, and anonymization.
Do not delete records that are required to be stored by law - mark the processing limit; explain the subject.
In backups - deletion on future rotations + marks "subject erased" in the active layer.

7) Backups, archives and WORM

3-2-1: three copies, two types of media/clouds, one offline/air-gapped.
Encryption with provider-independent KMS/HSM keys.
WORM for audit/regulatory reporting.
Backup rotation policy: the storage period of backups should not exceed the period of active data, if there are no mandatory exceptions.
Scheduled restore test.

8) Cross-border and geo-localization

Geo-scoping: Data and encryption keys are region/license bound.
Replication respects local retention periods and transmission limits.
Provider/PSP/KYC contracts are required to reflect storage locations and timing.

9) Storage architecture and automation

• Raw/Bronze (minimum term, no PII if possible).
• Silver (cleared facts with TTL and masking).
• Gold (long-term units/displays).
• Feature Store/Model Registry (versioning and time-travel without PII).

• Lifecycle policies/TTL in objects/tables/topics.
• Policy as code: YAML/JSON with 'purpose', 'retention _ period', 'post _ expiry _ action', 'legal _ hold _ override'.
• CI Linter: blocks PR if new set without'retention _ policy '.
• Scheduler: Daily "what expires tomorrow/in the week" check.
• Deletion jobs: soft delete → dependency check → hard delete/crypto erase.

10) Deletion, anonymization, pseudonymization

Hard delete - physical deletion (consider cascades and lineage).
Soft delete - label 'deleted _ at', hiding, plan for subsequent hard delete.
Crypto-erase - delete keys for data unavailability.
Anonymization is an irreversible transformation; it is permitted to store the units.

Pseudonymization - replacement with tokens; mandatory/pepper key policy and prohibition of reversibility outside the "clean zone."

11) Metrics and SLO

Retention Coverage% sets with approved policy.
On-time Deletion - percentage of deletions completed on time.
Zero-PII in Logs: masking logs.
Legal Hold Accuracy: registry coincidence with actual freezes.
Backup Restore-Rate: successful test restores.
SLA DSAR Average query execution time (by type).
Cost vs Retention: Aggregation/TTL savings.

12) RACI (example)

Policies and Standards: CDO/DPO (A), Governance Council (R/A), Legal (C), Security (C).
Directory and labels: Data Stewards (R), Domain Owners (A), Platform (C).
Automation/TTL: Platform/SRE (R), Sec (C).
Legal Hold/DSAR: DPO/Legal (A/R), Domains (C).
Audit and backups: SecOps/SRE (R), Internal Audit (C).

13) Templates (ready to use)

13. 1 Retention policy (thumbnail)

Scope: enumeration of domains and exceptions.
Grounds: legal duty/contract/consent/legitimate interest.
Dates: table'dataset → period → action '.
Legal Hold: Inclusion/withdrawal process.
DSAR search/delete/limit order.
Backups/WORM: deadlines, keys, recovery test.
Control: metrics, review annually, policy owner.

13. 2 Retention dial card

Dataset: `payments. transactions`

Class: Restricted (Finance)

Basis: legal duty/accounting

Term: N years from the date of operation

Action after the deadline: anonymization of aggregates, hard delete parts

Legal Hold override: да

Responsible: Owner/Steward, DPO

Tags/contracts: 'pii', 'tokenized', 'retention: N', contract reference

13. 3 YAML policy (policy-as-code, fragment)

yaml dataset: payments. transactions purpose: accounting_and_aml class: restricted retention_period: P{N}Y    # ISO 8601 duration post_expiry_action: anonymize_then_delete legal_hold_override: true geo_scope: EU backups:
retention_period: P{N}Y worm: true audit:
enabled: true destination: worm://audit/payments

13. 4 Starting checklist

• Each dataset has a card and a YAML policy
• Enabled TTL/lifecycle rules in vaults
• Dates/reasons/owners are displayed in the catalog
• Set up expiration alerts and On-time Deletion report
• Legal Hold registry synchronized with storage flags
• Table-top DSAR script/delete in backups

14) Implementation Roadmap

0-30 days (MVP)

1. Set inventory and classification; assign owners.
2. Add the 'retention' field to the contract/directory; create top set cards.
3. Enable TTL/lifecycle for logs and raw layer; PII prohibition in logs.
4. Legal Hold Registry and Processes; Coverage/On-time Deletion base reports.

30-90 days

1. Roll out policy-as-code (YAML) and CI linter; PR unit without 'retention'.
2. Implement anonymization/pseudonymization of the post-term; automate deletion jobs.
3. Bring backups in line with the deadlines; Enable WORM for auditing.
4. Associate DSAR with Retench and Tokenization; SLA reports.

3-6 months

1. Geo-localization of sets and keys; cross-border policies.
2. Advanced storage cost and TTL effect analytics.
3. Quarterly Term Reviews with Legal/Domains; external audit.
4. Scaling to partners/providers (contractual requirements for retraining).

15) Anti-patterns

"We keep everything forever" - without reason and a plan for removal.
Inconsistency: the asset is deleted, and in backups - forever.
The absence of Legal Hold: erasing evidence.

Uniform terms for all domains "for simplicity."

DSAR without real removal in derived showcases/features.
Sandboxes with copies of prod-PII and endless term.

16) Related Sections

Data Management, Access Control, Data Tokenization, Security and Encryption, Data Origin and Path, Auditing and Versioning, Legal Hold and DSAR, Confidential ML.

Total

Storage policies turn a "chaotic warehouse" into a managed archive: each field knows its own term, foundation and destiny. For iGaming, this is the foundation of compliance, economy and trust in data: you store enough, but not too much, you know how to quickly delete and prove, and at the same time do not break reports, ML and operational processes.