Кризове управління та комунікації

1) Мета і область

Створити керований, повторюваний і перевіряється процес реагування на інциденти і кризи, мінімізуючи збиток для гравців, партнерів, регуляторів і бренду. Розділ охоплює технологічні інциденти, комплаєнс-ризики (KYC/AML/відповідальна гра), платіжні проблеми, витоки даних, PR-кризи і форс-мажори (дата-центр/провайдер, DDoS, санкції/блокування, катастрофи).

2) Принципи

Безпека гравців і дані перш за все. Захист засобів, персональних даних та ігрових балансів - пріоритет № 1.
Швидкість> досконалість. Чітка перша комунікація з фактами «що відомо/що ні/що робимо/коли оновлення».
Єдиний голос. Всі зовнішні повідомлення проходять через затверджених спікерів і шаблони.
Перевірюваність. Логи, таймлайни, рішення, гіпотези і артефакти фіксуються для пост-мортема.
Пропорційність. Реакція співвідноситься з рівнем серйозності і юридичними вимогами.
Безперервна готовність. Тренування, сценарії, ретро і поліпшення - як частина BAU.

3) Терміни і рівні серйозності

Інцидент - подія, що порушує нормальну роботу/дотримання вимог.
Криза - інцидент, що загрожує стійкості бізнесу/ліцензії/репутації.

• S1 (критичний): простої Core Gaming/гаманця> 15 хв глобально; витік PII/фінданих; регуляторні розслідування; масова недоступність оплат.
• S2 (високий): деградація> 5% транзакцій, локальні простої регіону, потенційна вразливість без підтвердженого витоку.
• S3 (середній): часткові збої (ігрові провайдери, афіліатні трекінги), негативний медіа-шум, зростання chargeback'ів.
• S4 (низький): поодинокі скарги, локальні регреси.

• S1: перше повідомлення ≤ 15 хвилин, потім кожні 30-60 хвилин; фінальний звіт ≤ 72 години.
• S2: перше ≤ 30 хвилин; апдейти кожні 1-2 години.
• S3–S4: за узгодженим розкладом.

4) Організація та ролі (RACI)

IC (Incident Commander) - командир інциденту, власник таймлайну, скликає «war room», приймає рішення. (Accountable)

Comms Lead (PR/GR/CS): зовнішні та внутрішні комунікації, єдиний наратив, узгодження з юристами. (Responsible)

Tech Lead (SRE/Platform): діагностика кореня, дії з відновлення, фіксація метрик. (Responsible)

Security Lead (AppSec/Blue Team): розслідування інцидентів ІБ, взаємодія з CERT/LEA.
Legal/Compliance: оцінка регуляторних вимог (повідомлення регуляторам/банкам/партнерам, терміни, формулювання).
Payments Lead: PSP/банки, альтернативні маршрути, ручне врегулювання.
CRM/CS Lead: макроси для саппорту, компенсації, сегменти «постраждалі».
Data/Analytics: здорові метрики впливу, когорти, звіт MTTR/фінансовий збиток.
CEO/Exec Sponsor: ескалація S1, публічний стейтмент при необхідності.

5) Життєвий цикл кризи

Детектування → Тріаж → Ескалація → Стабілізація → Комунікації → Відновлення → Пост-мортем і поліпшення

5. 1 Таймлайн реагування (S1 орієнтир)

0-15 хвилин: призначення IC; відкриття «war room»; первинна гіпотеза; тимчасове блокування ризикових дій (наприклад, висновків); holding statement для внутрішньої аудиторії.
15-60 хвилин: перевірка радіусу ураження; перемикання на запасні канали (DR, резервні PSP, CDN Rules); перше зовнішнє повідомлення (статус-сторінка/соцмережі/пошта партнерам).
1-4 години: стабілізація сервісів; FAQ для саппорту; персоналізовані повідомлення порушеним гравцям; фіксація вимог регуляторів.
До 24 годин: детальний апдейт з причинами і планом запобігання; запуск компенсацій/кредитів; бриф для афіліатів/провайдерів.
До 72 годин: фінальний звіт, юридичні повідомлення, ретроспектива, завдання щодо поліпшення.

6) Канали і політика комунікацій

Канали: статус-сторінка, e-mail/SMS/push, центр допомоги, соцмережі, in-app банери, партнерська розсилка, тікети регуляторам, сервіс-апдейти PSP, медіазаяви.

• Факти, прозорі дії, терміни наступного апдейту.
• Без звинувачень і технічної «жаргонізованої» невизначеності.
• Jam-шаблони на 5 мовах ключових ринків.
• Завжди вказувати що робити гравцеві зараз (нічого не робити, не переводити кошти, очікувати компенсацій і т.д.).
• Тон: співчуття → відповідальність → дію → запобігання.

7) Плейбуки за типовими сценаріями

7. 1 Витік даних/компрометація облікових записів

Миттєво: ізоляція, форензика, скидання токенів/паролів, MFA-кампанія.
Комунікації: цільові повідомлення порушеним; FAQ по змінам пароля; заява про заходи захисту.
Юридично: повідомлення регуляторам/банкам/PSP в обов'язкові терміни; шаблони для DPIA/репортів.
Превентив: bug bounty, секрет-ротація, WAF/EDR/IDS сигнатури, hardening.

7. 2 Платіжні збої (PSP/банк/AML-прапори)

Миттєво: переключення на резервні PSP/маршрути; м'які ліміти депозитів; призупинення авто-висновків.
Комунікації: статуси в касі, банер «альтернативні методи», партнерський бриф.
Юридично: повідомлення згідно з договорами; дотримання правил повернень і chargeback SLA.
Превентив: мульти-еквайринг, моніторинг відхилень конверсії, «traffic-to-method» балансування.

7. 3 Масова недоступність/деградація платформи

Миттєво: feature-flags → деградація функціоналу (read-only/кеш), виключення «важких» фіч.
Тих. дії: rollback/blue-green, масштабування, rate-limits, DDoS захист.
Комунікації: чіткі інтервали апдейтів; карта порушених регіонів/ігор.
Превентив: SLO/Error Budgets, гейм-провайдер fail-open/close стратегії, chaos-дні.

7. 4 Регуляторні/ліцензійні ризики

Миттєво: freeze на спірні кампанії/механіки, консультація Legal/Compliance.
Комунікації: нейтральні формулювання, відсутність «визнання провини», узгодження з юристами.
Превентив: pre-clearance промо, аудит T & C/bonusing, регіональні спліти фіч.

7. 5 Репутаційний шторм (медіа/соцмережі)

Миттєво: моніторинг згадувань, єдина позиція, підготовлений Q & A.
Комунікації: «ми чуємо/виправляємо» + факти; уникати суперечок у коментарях; підготовлений long-read з фактчеком.
Превентив: медіатренінги спікерів, «dark site» з фактами/хронологією, кризові прес-пакети.

8) Метрики і дашборди

Реакція: MTTA, MTTR, MTTD, TTS (time-to-statement),% апдейтів в SLA.
Вплив: гравці/транзакції порушені, недоотриманий GGR, chargeback rate, частка ручної обробки.
Надійність: SLO за ключовими флоу (депозит, спін, вивід), error budget burn.
Комунікації: охоплення повідомлень, open/click rate,% звернення «повторних», CSAT/DSAT.
Репутація: Sentiment (соцмережі/медіа), частка негативних публікацій, час до нейтралізації тренду.

Статус-сторінка мінімум: аптайм по зонах, інциденти з таймлайном, поточні деградації, ETA і історія.

9) Чек-листи

9. 1 Запуск «war room»

• Призначений IC і стенографіст.
• Підтягнули Tech/Sec/Payments/Legal/Comms/CS Leads.
• Визначено рівень S1-S4, радіус впливу, тріаж гіпотез.
• Рішення по відкату/фічефлагам/резервним маршрутами.
• Підготовлений holding statement і час наступного апдейта.

9. 2 Перед зовнішнім повідомленням

• Факти підтверджені, немає PII/секретів.
• Юридична перевірка формулювань.
• Зрозумілі інструкції гравцям/партнерам.
• Вказано канал/час наступного апдейту.

9. 3 Закриття інциденту

• Усунуто першопричину/тимчасовий захист.
• Компенсації нараховані, спірні транзакції оброблені.
• Фінальний звіт опубліковано, статус-сторінка оновлена.
• Скликані ретро, CAPA-план в backlog з власниками і датами.

10) Шаблони повідомлень

• Подія: [тип/сервіс]
• Вплив: [хто/де/коли]
• Ми робимо: [дії]
• Наступний апдейт: [час]

• Тема: Перебої в роботі [сервісу] - ми вже виправляємо
• Тіло: що сталося (1-2 рядки), що робити зараз, безпека засобів/даних, ETA наступного апдейта, посилання на статус.

• Короткий бриф (що/вплив на трекінг/тимчасові заходи/очікуваний ефект) + контакт для питань.

• Формальне повідомлення з фактами, тимчасовими заходами, оцінкою клієнтського впливу, планом запобігання, термінами фінального звіту.

11) Інструменти та артефакти

Runbooks/Playbooks в репозиторії з версіонуванням (за сценаріями).
War Room: постійний канал (чат/відео) з ботом-секретарем (лог часу і рішень).
Інцидент-бот: команди '/declare', '/severity', '/update', '/close', автозаповнення таймлайну.
Шаблон пост-мортема: проблема → вплив → корінь → що спрацювало/ні → CAPA → власники/терміни.
Компенсації: калькулятор постраждалих сегментів (за часом/каналом/грою/платежем), пресети бонусів.
Журнали аудиту та ретенції: для відповідності регуляторним вимогам.

12) Готовність і тренування

Quarterly симуляції S1-S2 (table-top + live-drills), включаючи «нічні» сценарії.
Медіатренінги для спікерів, «мостові» брифи для CEO.
Верифікація контактів (24 × 7), чергування і «backup on call».
Стрес-тести: DDoS-ігри, відключення провайдера PSP, деградація БД, падіння CDN.
Навчальні «PR-шторми»: з фейковими заголовками і шкалою Sentiment.

13) Юридичний та комплаєнс-контур

Мапінг обов'язкових повідомлень по юрисдикціях (терміни, формат, мова).
Політика щодо зберігання логів/артефактів та доступу до них.
Guidance з «відповідальної гри» в кризу: як не погіршити вразливість гравців.
Умовні «червоні лінії» для комунікацій (що не можна розкривати до узгодження).
Порядок взаємодії з правоохоронними органами/CERT.

14) Пост-мортем і поліпшення

Проведення ретро ≤ 7 днів, поза пошуком винних, з конкретними CAPA.
Оновлення плейбуків/шаблонів, включення нових індикаторів (ранні ознаки).
Відстеження виконання CAPA і перевірки ефективності через 30/60 днів.

15) Швидкий старт (резюме впровадження за 30 днів)

1. Затвердити ролі IC/Comms/Tech/Sec/Legal/Payments/CS і графік on-call.
2. Звести матрицю S1-S4 і SLA апдейтів, опублікувати на внутрішньому порталі.
3. Завести статус-сторінку і шаблони повідомлень (5 мов/ринків).
4. Зібрати «war room» (чат/відео) з бота-логгером і макросами.
5. Створити 5 плейбуків: витік, платіжна криза, деградація платформи, регуляторний ризик, PR-шторм.
6. Підняти моніторинг метрик «гравець-досвід»: депозит/вивід/спін/логін.
7. Провести table-top навчання (2 години) + оновити документи за підсумками.

• План безперервності бізнесу (BCP)
• Disaster Recovery Plan (DRP)
• Матриця ескалацій
• Система повідомлень і алертів
• Журнали аудиту операцій
• Відповідальна гра і захист гравців