Incident playbooks and scripts

1) Purpose of the section

Form a single, versioned set of playbooks to respond quickly and consistently to incidents within the Operations and Compliance loop, from detection to recovery, communications, legal notices and improvements.

2) Playbook standard (script card)

ID: PB- <code >/Version: v <MAJOR. MINOR >/Owner: <role/name>
Title: <short and unambiguous>
Scope: <technology/payments/information security/compliance/PR>
Severity: S1    S2    S3    S4 (activation criteria)
Detection: <metrics/alerts/log signatures/sources>
Start triggers: <conditions and thresholds>
RACI: IC / Tech Lead / Sec Lead / Comms / Legal / Payments / CS / Data
Response steps:
0-15 min: <start actions, war room, holding statement>
15-60 min: <stabilization/bypasses/reserves/first external message>
1-4 hours: <in-depth diagnostics/fixes/targeted notifications>
Up to 24 hours: <final update/compensation/reports/retro slot>
Communications: <templates for status, players, partners, regulators, media>
Artifacts: <timeline, logs, dumps, screenshots, tickets, reports>
Legal: <to/when to notify, formats, languages>
Exit criteria: <conditions for closing the incident>
MTTD/MTTA/MTTR targets: <numerical benchmarks>
Prevention: <CAPA and backlog links to epics>
Last workout: <date/results/remarks>

3) Severity and Triage Matrix (Summary)

S1 (critical): global Core/wallet downtime, PII/financial data leak, massive inaccessibility of payments, regulatory investigations.
Updates: ≤15 min first; every 30-60 minutes thereafter.
S2 (high): regional downtime, payment conversion drop> 10%, confirmed vulnerability without leakage.
S3 (average): degradation of individual providers/feature, growth of CS calls> 30% to the database.
S4 (low): local defects, single complaints.

Triage (quick check): fact? scale? security of means/data? legal deadlines? backup routes? the channel of the first message and the time of the next update?

4) Roles and communications

IC (Incident Commander): Timeline/solution owner.
Tech Lead (SRE/Platform): diagnostics/fixes/workarounds.
Security Lead (AppSec/Blue Team): forensics/containment/information security notifications, if necessary.
Payments Lead: PSP/banks, multi-routes, manual processing.
Legal/Compliance: Regulatory Notices, Language, Deadlines.
Comms Lead: status page, e-mail/SMS/push, affiliates, media.
CS/CRM Lead: macros, compensations, target segments.
Data/Analytics: impact assessment, reports, MTT control.

Single voice: any external messages - via Comms + Legal.

5) Universal checklists

5. 1 Playbook start (0-15 min)

• IC assigned, war room open, stenographer assigned.
• Severity (S1-S4), radius of influence identified.
• Protective measures are taken (phicheflags, limits, stop conclusions at risks).
• The holding statement and ETA of the next update have been prepared.
• Created tickets for fixing artifacts (logs/dumps/screenshots).

5. 2 Before the first external message

• Facts confirmed, secrets excluded/PII.
• Legal review of wording.
• Clear instructions to users on what to do now.
• The time of the next update is specified explicitly.

5. 3 Closing the incident

• Root eliminated/compensatory measures implemented.
• Compensations accrued, disputed transactions processed.
• Final report/status updated; retro assigned ≤7 days.
• CAPA items are created with owners and dates.

6) Typical playbooks (catalog)

PB-SEC-01: Data Breach/Account Compromise (S1)

Detection: input anomalies, EDR/WAF triggers, account hacking complaints, forum leak.
0-15 min: isolation of affected systems; rotation of secrets; disabling compromised tokens; inclusion of MFA campaign.
15-60 min: targeted notifications to those affected; first public communication; fixing artifacts for forensics.
1-4 hours: PII access audit; Provider/Cloud requests preparation of regulatory notices.
Up to 24 hours: detailed report, key change, password update, monitoring extension.
Communications: status page, e-mail to affected, partners, if necessary - media Q & A.
Legal: Regulatory/Bank/PSP notifications within the prescribed timeframe.
Exit criteria: risk localized; all tokens replaced; players sent instructions; missing/limited damage confirmed.
Prevention: bug bounty, hardening, DLP, secret management.

PB-PAY-02: Payment crisis (PSP/bank unavailable) (S1/S2)

Detection: auth-rate drop, increase in failures, output queue.

0-15 min: switch to standby PSP/routes; soft suspension of auto-outputs; banner at the box office "alternative methods."

15-60 min: first external message (cash desk/status); manual priority of VIP/vulnerable groups; communication with PSP.
1-4 hours: recalculation of limits; compensation for inconvenience; report to partners.
Up to 24 hours: final report; SLA returns updating traffic balancing rules.
Prevention: multi-acquiring, health-checks by methods, auto-rebalance.

PB-NET-03: DDoS/mass network degradation (S1)

0-15 min: enable anti-DDoS profiles; rate-limits/capping; CDN/WAF guard rules temporarily turn off heavy endpoints.
15-60 min: geo-filters/blacklists; communication with the provider; first message to users with ETA.
1-4 hours: scaling fronts; canary checks; analysis of attack telemetry.
Prevention: regular DDoS exercises; adaptive profiles; spare ASN/CDN.

PB-GAME-04: Failure of the game provider (S2/S3)

Detection: an increase in provider API errors, a surge in CS calls for specific titles.
Steps: Temporarily hide affected games; Show prompt/replacements Balance sheet synchronization notifying provider and players.
Prevention: fail-open/close strategies, directory caching, health-marking games.

PB-REG-05: Regulatory Incident (S1/S2)

Cases: Violation of bonus conditions, KYC/KYB failures, violation of advertising.
Steps: freeze controversial mechanics; Legal/Compliance consultation; neutral wording; template reporting.

Prevention: pre-clearance promo, regular T&C audits

PB-FRD-06: Fraudulent Ring/Abuse (S2)

Detection: a surge in multiaccounting, bonus abuse, arbitration anomalies.
Steps: time limits for deposits/withdrawals; target KYC; blocking of device/payment/IP bundles; risk report.
Communications: individual notifications; avoid disclosing anti-fraud logic publicly.
Prevention: behavioral models, graph analytics, velocity filters.

PB-DATA-07: Data Integrity/Balance Desynchronization (S1/S2)

Steps: moving the wallet to "safe-mode"; prohibition of dangerous operations; Recovery from logs/snapshots reconciliation of units; personal notifications.
Prevention: biphasic commits/idempotence, event-sourcing, invariants.

PB-AFF-08: Drop in affiliate tracking (S3)

Steps: fixing pixels/postbacks; compensation reports; notifications to partners; temporal attribution coefficients.
Prevention: monitoring of conversions, reserve collbacks.

PB-PR-09: Reputation Storm (S2/S3)

Steps: single position; factual; Q&A; avoid controversy in comments; prepare a long read with facts.
Prevention: media training of speakers, "dark site" with facts.

PB-PHI-10: Phishing/fake sites (S2)

Steps: evidence gathering; notifying registrars/hosters; warning to players; Updating an anti-phishing page DMARC/Brand Indicators.
Prevention: domain similarity monitoring, partnership with anti-phishing providers.

7) Message templates (quick inserts)

• key> Reason: [Component/Provider]. Impact: [percentage/geography/period]. Measures taken: [reserve/rollback/validation]. Compensations: [type/criteria]. Next steps: [prevention/timing].

Partners/affiliates: a short brief "what/how affects tracking/temporary measures/ETA."

Regulator/banks/PSP: formal notification: facts, measures, customer impact, prevention plan, deadline for final report.

8) Metrics and goals

Detection: MTTD, alert-to-noise.
Reaction: MTTA, TTS (time-to-statement),% of updates to SLA.
Recovery: MTTR, RTO/RPO on affected services.
Impact: affected players/transactions, lost GGR, chargeback rate.
Communications: open/click-rate, coverage, retry rate, CSAT/DSAT.
Compliance: timeliness of mandatory notifications, completeness of artifacts.

9) Artifacts and evidence base

• time-line of decisions and actions (minute accuracy);
• logs/dumps/screenshots/export graphs;
• Configuration/build versions
• Message copies and recipient lists
• Lists of affected accounts/transactions
• legal notices (drafts/submissions/responses).

10) Tools and integrations

Incident bot: '/declare ', '/severity S1.. S4', '/update <text> ', '/close'.
Status page: public feeds; integration with uptime sensors.
Compensation: segment calculator (by time, geo, game, payment method).
Security stack: EDR/WAF/SIEM/IDS; playbooks in SOAR.
Observability: logs/metrics/trails, error budgets, SLO dashboards.

11) Management of the playbook directory (governance)

Versioning: Git repository, PR process, semantic versions.
Responsibility: each playbook has an owner and a reserve.
Audits: at least quarterly, after each S1/S2 - unscheduled.
Training: table-top once a quarter, live-drill for critical scenarios once every six months.
Compatibility: links to BCP/DRP, Escalation Matrix, Responsible Play, Notification Policy.

12) Quick start to implementation (in 30 days)

1. Form a list of top 10 risk scenarios and appoint owners.
2. For each - issue a card according to the standard (section 2) and enter it in the repository.
3. Connect playbooks to the incident bot (shortcodes and message templates).
4. Conduct 2 table-top exercises (payments + information security) and 1 live-drill (degradation of the game provider).
5. Start the metrics dashboard (MTTD/MTTA/MTTR, TTS,% of updates to SLA).
6. Create a CAPA backlog, agree on the timing and RACI.
7. Roll back the "dry" distribution of templates (to players/partners/regulators) through the sandbox.

• Crisis management and communications
• Business Continuity Plan (BCP)
• Disaster Recovery Plan (DRP)
• Escalation Matrix
• Notification and alert system
• Responsible play and player protection