DSAR: user requests for data

1) Purpose and area

Provide a single, predictable and verifiable DSAR process across all channels and jurisdictions, taking into account iGaming, AML/KYC license restrictions, Responsible Play (RG) requirements and local data protection. Coverage: web/mobile, support/CS, CRM/marketing, product/wallet, game providers/PSP, analytics/DWH, logs/AWP, affiliates and external vendors.

2) DSAR types (what the user can request)

Access to personal data and copy of data.
Correcting inaccurate/incomplete data.
Deletion ("right to be forgotten") - subject to exceptions.
Processing restriction (pause for use).
Portability (machine-readable export of basic data).
Objection to marketing/profiling based on it.
Automated Processing Only (AADM) -information and revision as needed.

3) Principles

1. Legality and good faith. No artificial barriers.
2. Proof of identity. Proportional KYC check before check out/delete.
3. Minimization and safety. We issue "exactly as much as necessary," with editing of third parties and secrets.
4. Timing and transparency. Confirmation of acceptance, status and final response on time; reasonable extension is allowed.
5. Provability. Full set of artifacts for audit/regulator.
6. Single point of control. Centralized DSAR portal/queue and integration with all systems.

4) Roles and RACI

DPO/Head of Compliance - process owner, norm interpretation, complex cases. (A)

Privacy Ops/DSAR Team - operational processing, communications, collection/issuance. (R)

Legal - exceptions/restrictions, legal holds, appeals. (C/R)

Security/Infra - secure channels, encryption, access control. (R)

Data Platform/Analytics - data extraction, de-PII, portability. (R)

Product/Engineering - API/connectors to systems, automation. (R)

CS/Trust & Safety - initial acceptance and verification, response templates. (R)

Internal Audit - selections and CAPAs. (C)

5) Reception channels and identification

Channels: portal "Privacy," e-mail privacy @..., CS tickets, mail.

• In account: 2FA + control attributes (part of phone/e-mail, recent operation).
• No account/closed account: proportionally - request a limited set of confirmations (without redundant documents).
• Representative: power of attorney/mandate; we fix the status and volume.

Anti-fraud: flags in case of attribute mismatch/mass requests from one IP/agent.

6) SLA and timing

Receipt: immediately/within 24 hours.
The answer is essentially: within 1 calendar month from the date of receipt (in some jurisdictions it is allowed to extend up to 2 more months with complexity/volume).
Renewal: notify the user in advance with justification.
Refusal/restriction: a reasoned response indicating the grounds and right to complain.

7) Exceptions and limitations (framework)

AML/KYC and iGaming licenses: hold transactions/logs for set periods - deletion does not apply, but restriction/minimization does.
Legal obligations and legal hold: in investigations/court cases.
Rights and freedoms of third parties: editing/depersonalization at the intersection.
Trade secrets/security: do not disclose anti-fraud algorithms/keys/secrets; provide descriptive information.
Obviously unreasonable/excessive requests: a reasonable fee or refusal is possible.

8) Source systems and coverage

Account/Profile: registration data, RG/SE statuses, age, consent.
KUS/Documents: ID, selfie/liveliness (artifacts, where legal).
Payments/PSP: deposits/withdrawals, card tokens (without PAN), chargeback.
Gaming activity: sessions, bets, winnings, bonuses/vager.
CRM/Marketing: channel consents, newsletter/campaign history.
Logs/Security: inputs, devices, important events (without "raw" PII, if this is a log policy).
Affiliates: click sources (without personal data of third parties).
Vendors: records received from/transferred to them (indicating legal grounds).

9) Process (end-to-end)

1. Reception and registration: case creation ('dsar _ case _ id'), request type, deadline.
2. KYC verification: verification of identity, fixation of method/result.
3. Triage: determine coverage, exceptions, whether a legal hold is needed.
4. Data collection: automatic retrievals from systems + requests to vendors.
5. Cleaning/revision: delete redundant, mask third parties/secrets, translate technical data into an understandable form.
6. Preparation of response: data package + explanatory note (goals, deadlines, sources, recipients, rights).
7. Delivery: secure portal/secure archive; encryption and one-time tokens.
8. Closure: recording artefacts, quality control, satisfaction survey.
9. CAPA for incidents and complaints.

10) Formats and tolerability

Access/copy: machine-readable files (CSV/JSON/Parquet) + readable PDF-vault.
Portability: profile/transaction core in a structured, widely used format; diagrams are attached.
Correction: we make changes and confirm to the user.
Deletion: cascading jabs, crypto deletion of archives, confirmation of system/date ranges.

11) Secure delivery

Portal with MFA/one-time links; link lifetime ≤ 7 days.
Archives with a password, transferring a password via a separate channel.
Download/view logs; limiting the number of copies.

12) Data model (minimum)

dsar_case {
case_id, subject_id_hash, market, type{access    rectify    erase    restrict    port    object    aadm},
received_at_utc, acknowledged_at_utc, due_at_utc, extended_to_utc, status,
id_verification{method, result, evidence_id, verified_at_utc},
scope{systems[], date_range, include_vendors{true    false}},
legal_basis_notes, exemptions[], legal_hold{yes/no, reason},
data_packages[{system, format, size_mb, records_count, redactions[]}],
delivery{channel, url, password_hint, expires_at_utc, downloaded_at_utc},
communications[], owner, approvers{dpo, legal}, closed_at_utc, outcome,
audit_artifacts[]
}

13) KPI/KRI and dashboard

DSAR SLA (median, 95th percentile) by request type.
Extension Rate and reasons for renewals.
Verification Failure Rate.
Redaction Error Rate.
Portability Success Rate (format validity, readability complaints).
Complaint/Appeal Rate and regulatory findings.
End-to-End Time-to-Deliver and auto-extraction coverage.

14) Checklists

A) Acceptance/Verification

• Request registered, type/market defined.
• Receipt sent, deadline set.
• KYC check performed/requested in proportion to risk.
• Representative status checked (if applicable).

B) Collection/preparation

• All relevant systems/vendors are covered.
• AML/legal hold exceptions applied.
• Third party/secret redactions complete.
• Formats are readable, diagrams are attached.

C) Delivery/Closure

• The packet is loaded into a secure channel, the password is transmitted separately.
• An explanatory letter with rights and contacts has been sent.
• Download logs and confirmation to the user.
• Artifacts stored in WORM, KPIs updated.

15) Communication templates (fragments)

Receipt

Identity Confirmation Request (KYC-light)

Extension Notice

Waiver/restriction with basis

Completion (Package Issue)

key> Your Data is Ready. Reference: {URL}. Valid until {date}. The password will be sent as a separate message. The letter contains explanations: sources, processing purposes, retention periods, rights and DPO contacts.

16) Automation and integration

DSAR orchestrator: single queue, SLA timers, webhooks for systems.
Auto-extraction: connectors to profile, wallet, CRM, DWH, logs (PII-free).
Editing template: third-party/secret masks, EXIF deletion.
Portability: circuit generator (JSON Schema) and validator before issue.
Secure delivery: one-time links, download control, auto-closing cases.

17) Frequent mistakes and prevention

Issuance of "cheese" with data from third parties. → Strict edition and double review.
→ SLA timers, early renewals, prioritization.
Redundant KYC check. → Proportionality and minimization.
Inconsistency of formats. → Common schemes/validators.

Unaccounted Sources (Vendors/Affiliates) → Systems Register and Regular Reviews

Leak on delivery. → Only secure portal, encryption, separate password channel.

18) 30-day implementation plan

Week 1

1. Approve DSAR, RACI, SLA policy and letter templates.
2. Compile system/vendor register and data map.
3. Start the DSAR portal (MVP) and the to-do queue.

Week 2

4) Implement KYC light and artifact logs (WORM).
5) Connect auto-extraction (profile/wallet/CRM/DWH).
6) Customize editing and standard export formats.

Week 3

7) Pilot 10-20 requests (synthetic + real); measure SLA/quality.
8) Enable secure delivery (one-time links, password separately).
9) CS/Privacy Ops training (scripts, escalations).

Week 4

10) Full release; dashboard KPI/KRI, overdue alerts.
11) Quarterly Audit/Sampling Plan and CAPA.
12) Plan v1. 1: connector to logs (PII-free), auto-portability, multilingual templates.

19) Related Sections

GDPR: User Consent Management/Cookies and CMP Policy

Localization of data by jurisdictions

Privacy by Design: design principles

Age verification and age filters

AML/KYC treatments and retention

Compliance Dashboard and Monitoring/Regulatory Reports

Internal and external audit/Audit checklists