Data Breach Procedures

1) Purpose and scope

Objective: to minimize damage, comply with legal requirements and quickly restore normal operation with confirmed or probable leakage of personal/payment/operational data.
Coverage: PII players and employees, payment artifacts, access logs/tokens, KYC/AML documents, affiliate/partner data, confidential product and infrastructure artifacts.

2) "Leak" definitions and criteria

Data breach - violation of the confidentiality, integrity or availability of personal data (or other protected information) due to a security incident or process error.
Confirmed vs suspect: any indicators (SIEM anomalies, messages from vendors/users, Paste sites) start the procedure before refutation.

3) Severity classification (example)

4) SLA and "incident bridge"

Initiation: with Medium +, a war-room (chat/call) is created, an Incident Commander (IC) is assigned.

SLA: Low - 24 h· Medium - 4 h· High - 1 h· Critical - 15 min

Cadence of updates: every 30-60 minutes (internal), every 2-4 hours (external stakeholders).

5) RACI (enlarged)

6) Response procedure (step by step)

1. Identification and primary validation

A signal from SIEM/EDR/anti-fraud/vendor/user → an entry in the incident register.
Collection of minimal facts: what/when/where/how much, data types and jurisdictions affected.

2. Containment

Disabling vulnerable endpoints/features, geo-segments, time limits, freezing releases.
Key/token rotation, revocation of accesses, blocking of compromised accounts.

3. Eradication

Patch/config fix, cleaning malicious artifacts, rebuilding images, checking sub-processors.

4. Recovery (recovery)

Canary traffic entry, regression monitoring, passing integrity checks.

5. Forensics and impact assessment

Calculation of volume, sensitivity, geographies, risk for subjects; confirmation of affected records.

6. Notifications and Communications

DPO/Legal define the duty and timing of notices; preparation of texts; distribution to addressees.

7. Post-mortem and CAPA

Root Cause Analysis (5 Whys), Corrective/Preventive Action Plan with Owners and Timelines.

7) 72-hour window and legal addressees (landmarks)

Data surveillance (DPA) - notify no later than 72 hours after the detection of a significant leak, if the risk to the rights/freedoms of the subjects is not excluded.
Users - "without undue delay" at high risk (with clear recommendations).
Gambling regulator - when influencing players/sustainability/reporting.
Banks/PSP - at the risk of payments/compromise of tokens/suspicious transactions.
Partners/Vendors - if common flows/data are affected or action is required.

8) Forensics and the "chain of custody of evidence"

Snapshots of volumes/logs, export of artifacts with hashing (SHA-256).
Working only with copies/snapshots; source systems - read-only.
Protocol of action: who/when/what did, commands/tools used.
Storage in WORM/object storage; restricted access, auditing.

9) Communications (internal/external)

Principles: facts → measures → recommendations → the following update.
It is impossible: to publish PII, build untested hypotheses, promise deadlines without control.

• What is found?· Scale/categories· Current measures· Risks· Next steps· Next update in HH: MM.

10) Interaction with vendors/sub-processors

Check their incident registers, access logs, notification SLAs, list of sub-processors.
Request reports (pentest/rate), record confirmation of data deletion/return.
In case of DPA mismatch - escalation and temporary isolation/suspension of integration.

11) Notification templates (fragments)

11. 1 Supervisory Authority (DPA)

Brief description of the event and time of detection, categories/approximate volume of data, groups of subjects, geography, consequences and risks, measures taken/planned, DPO contact, applications (timeline, hash summary).

11. 2 Users

What happened; what data may have been affected; what we did; what you can do (change password, control transactions, phishing tips); how to contact; link to FAQ/support center.

11. 3 Partners/PSP/Regulator

Facts and affected interfaces; Expected partner actions deadlines; contact persons.

12) Incident register (minimum fields)

ID· Discovery/Confirmation Time· Severity· Source· Systems/Data· Scope/Categories· Geographies· Vendors Involved· Actions Taken (in time)· Notifications (to/when)· Responsible Persons (RACI)· References to Artifacts· CAPA/Deadlines· Status.

13) Metrics and targets

MTTD/MTTC/MTTR (detection/containment/recovery).
% of notifications at 72 hours - 100%.
The percentage of incidents with an identified root cause ≥ 90%.
CAPAs are closed ≥ 95%.
Repeated incidents for one reason ≤ 5%.
Percentage of incidents closed in SLA (Medium/High/Critical): 90/95/99%.

14) Checklists

14. 1 Start (first 60 minutes)

• IC assigned and war-room open
• Stabilizing measures (disconnections/limits/key rotation)
• Collecting minimal facts and screenshots/logs
• DPO/Legal notified, preliminary class defined
• Freeze releases and log cleaning protocols

14. 2 Up to 24 hours

• Forensics: scope/categories/geography (draft)
• Notification decision, preparation of texts
• Recovery/Integrity Plan
• WORM Evidence Package, Event Timeline

14. 3 Up to 72 hours

• DPA/Regulator/PSP notifications (if required)
• Comm to users (high risk)
• Updated CAPA Plan, Owners and Timeline

15) Typical scenarios and measures

A) Export support chat database to open storage segment

Measures: close access, inventory downloads, notify affected, strengthen S3/ACL policies, DLP export rules.

B) Compromise of API access tokens

Measures: immediate rotation, recall of refresh tokens, call log verification, webhook re-signing, traffic segmentation.

C) Leakage of KYC scans through vendor

Measures: isolation of integration, confirmation of deletion, re-verification of high-risk clients manually, revision of DPA/deductions.

D) Public Dump Publication

Measures: fixing artifacts (hashes), legal removal of links (takedown), notifications, monitoring further publications.

16) Integration with compliance and privacy

Bundle with GDPR processes: DSAR, RoPA, DPIA/DTIA; update of the Policy and cookies/CIW in case of changes in suppliers/goals.
Include incident in risk matrix and revise thresholds/controls.

17) CAPA and post-mortem (≤ 72 hours after stabilization)

Report structure: facts/timeline· impact· root cause· what worked/not· CAPA list (owner, term, success criterion)· date of effectiveness check (in 30-60 days).

18) Process Maturity Roadmap

Month 1: update playbook, contacts, templates, WORM archive, notification test.
Month 2: tabletop exercises (PII leak/vendor/tokens), SOAR playbooks.
Month 3 +: quarterly retrospectives, vendor audits, bias tests of anti-fraud/detection models, regular revision of thresholds.

TL; DR

In case of a leak: we quickly stabilize (containment), confirm accurately (forensics), notify on time (DPA/users/partners), transparently document (registry, timeline, evidence) and correct the root cause (CAPA). The result is less damage, compliance and restored trust of players and partners.