Повідомлення про порушення та терміни звітності
1) Призначення та область
Встановити єдиний, перевіряється і повторюваний порядок обов'язкових повідомлень при інцидентах і порушеннях в контурах Операцій і Комплаєнса: безпека даних, платежі/фінансові операції, регуляторні вимоги, відповідальна гра, партнерські інтеграції, репутаційні ризики. Документ задає терміни, адресатів, формати, а також процедури підготовки та контролю.
2) Ключові терміни
Reportable incident (повідомлений інцидент): подія, при якій за законом/ліцензією/договором потрібне повідомлення зовнішнім сторонам.
DPA - орган із захисту даних (GDPR і аналоги).
FIU - фінансова розвідка (AML/CFT; SAR/STR).
PSP/Acquirer/Card Scheme - платіжні провайдери/еквайєри/платіжні системи.
CERT/CSIRT - національні/галузеві центри реагування на інциденти кібербезпеки.
LEA - правоохоронні органи.
Holding statement - перше коротке повідомлення з базовими фактами і часом наступного апдейта.
3) Класи повідомлених подій (категорії)
1. ІБ/конфіденційність: витік PII/фінданих, компрометація облікових записів.
2. Регулятор азартних ігор: збої, що впливають на доступність гри/чесність/баланси; порушення умов ліцензії/реклами/RG.
3. AML/CFT: підозрілі операції/патерни → SAR/STR в FIU.
4. Платежі: масова недоступність PSP, високі відхилення, компрометація платницьких даних.
5. Споживач/гравець: повідомлення порушеним особам (data breach, грошові операції, комп. заходи).
6. Партнери/афіліати/провайдери: вплив на трекінг, звітність, фінансові розрахунки.
7. CERT/LEA: кіберінциденти з суспільною значимістю, фішинг/клонування бренду.
8. Аудит/власники ліцензії: відповідність SLA звітності, підтвердження усунення.
4) Матриця термінів (орієнтири)
5) RACI і ролі
IC (Incident Commander) - власник таймлайну і «war room». (A)
Legal/Compliance Lead - кваліфікація «reportable», вибір адресатів і термінів, фінальний знак. (R/A)
Security Lead - факти ІБ, обсяг компрометації/PII, взаємодія з CERT/LEA. (R)
Payments Lead - PSP/банк/схеми, PCI-питання, повернення/chargebacks. (R)
Comms Lead - текст і канал відправки, статус-сторінка, макроси CS. (R)
Data/Analytics - перелік порушених суб'єктів/транзакцій, оцінка впливу. (R)
CS/CRM Lead - доставка повідомлень гравцям, компенсації. (R)
Exec Sponsor/CEO - публічні заяви S1. (C/I)
6) Наскрізний процес (від виявлення до закриття)
A. Визначення сповіщуваності:- детектування → юридична кваліфікація (Legal) → рішення "reportable? кому? терміни? ».
- збір фактів/артефактів → класифікація серйозності → вибір шаблонів → узгодження (Legal/Comms/IC).
- доставка по каналах (портали регулятора, захищена пошта, API, паперові форми) → фіксація часу відправки і підтвердження отримання.
- за розкладом/віхами → управління версіями текстів → синхронізація зі статус-сторінкою.
- фінальний звіт → CAPA-план → закриття і ретро (≤ 7 днів).
7) Мінімальний склад повідомлення (скелет)
1. Ідентифікатор інциденту, дати/час (UTC і локальне).
2. Короткий опис події і радіусу впливу.
3. Категорії даних/клієнтів/операцій, яких торкнулося.
4. Вжиті заходи (контейнмент/відновлення).
5. Ризик-оцінка та поточний статус.
6. План подальших кроків і ETA наступного апдейту.
7. Контактна особа/канал для зворотного зв'язку.
8. Юридичні реквізити ліцензії/компанії (якщо потрібно).
9. Додатки: таймлайн, технічні артефакти, переліки суб'єктів.
8) Шаблони (швидкі вставки)
8. 1 DPA (витік даних, первинне повідомлення):
Подія/дата виявлення
Категорії даних/обсяг/географії
Заходи щодо мінімізації шкоди (скидання токенів, MFA, моніторинг)
Оцінка ризиків для суб'єктів
План повідомлення суб'єктів і терміни
Контакт DPO/Legal
8. 2 Гравцям (data breach):
Тема: Важлива інформація про безпеку вашого облікового запису
Тіло: що сталося (без тех. деталей і без PII), які заходи прийняті, що зробити гравцеві зараз (змінити пароль, включити MFA), де стежити за апдейтами, як отримати допомогу/компенсації.
8. 3 Регулятор азартних ігор (збій доступності/чесності):
Що: сервіс/ігри/гаманець, часовий інтервал, зони
Вплив: відсотки/кількість ставок/балансів
Заходи: відкат, резерв, safe-mode гаманця
Очікуваний ETA відновлення, контроль чесності/балансів
План остаточної верифікації та звітності
8. 4 FIU (SAR/STR, коротко):
Факти та підстави підозри (без «попередження клієнта»)
Суми/пов'язані акаунти/моделі поведінки
Додатки (транзакції/граф зв'язків)
Контакт відповідального за AML
8. 5 PSP/Acquirer/Card Scheme:
Що сталося (схеми/методи порушені), маркери PCI-ризиків
Бізнес-вплив (auth-rate, відмова/latency)
Вжиті заходи/байпаси, прохання про спільну діагностику
План компенсацій клієнтів/обробка повернень
8. 6 CERT/CSIRT:
Індикатори компрометації (IoC), TTP, вектори
Вжиті заходи і залишилися ризики
Запит координації/розшарювання телеметрії
9) Чек-листи
Перед відправкою первинного повідомлення
- Факти підтверджені; виключені секрети/PII.
- Погоджено з Legal/Compliance; вибрано адресат/канал.
- Вказано наступний апдейт (дата/час/канал).
- Зафіксовані скріншоти/ARTEFACTS і хеш-суми додатків.
- Перевірено локалізацію/мову (якщо потрібно).
Після відправлення
- Отримано підтвердження прийому/номер тікету/реєстровий ID.
- Створено план апдейтів і власники.
- Синхронізовані тексти на статус-сторінці/FAQ/CS-макросах.
Закриття
- Фінальний звіт відправлений і підтверджений.
- CAPA зареєстровані з термінами і метриками ефективності.
Ретро проведено ≤ 7 днів.
10) Реєстр термінів та адресатів (структура даних)
Зберігається в Git/Confluence у вигляді таблиці (версіонується, власник - Legal):11) Артефакти і ретенція
Таймлайн (хвилинна точність), версії всіх повідомлень, підтвердження прийому.
Тих. Артефакти: логи, дампи, експорт метрик, IoC, знімки конфігурацій.
Списки суб'єктів/транзакцій, що використовуються для повідомлення/компенсацій.
Ретенція: зберігання згідно з вимогами ліцензій/законів (зазвичай 1-7 років, уточнюється за юрисдикцією).
12) Метрики відповідності
Timeliness: % повідомлень, відправлених у строк (за категоріями).
Completeness: частка повідомлень, прийнятих з першого разу (без запитів виправлень).
Acknowledgement SLA: середній час отримання підтвердження.
Update Discipline: дотримання інтервалів апдейтів.
CAPA Efficacy: частка закритих CAPA вчасно.
13) Інструменти та автоматизація
Інцидент-бот: команди '/notify <категорія>', автопідстановка термінів/каналів, нагадування про дедлайни.
Шаблонізатор: складання повідомлень з параметрів інциденту; версії/локалізація.
Статус-сторінка: синхрон із зовнішніми апдейтами; контроль TTS (time-to-statement).
SOAR/SIEM: автоматичний збір артефактів для DPA/CERT.
DWH/CRM: сегменти порушених суб'єктів, трекінг доставки і відкриттів.
14) Управління змінами (governance)
Власник розділу: Head of Compliance (резерв - Legal Counsel).
Ревізія реєстру (§ 10): не рідше щоквартально і після кожного S1/S2.
Навчання: table-top по DPA/Regulator/AML - щоквартально; live-drill ІБ - раз на півроку.
Аудит: щорічна незалежна перевірка відповідності термінам і повноті повідомлень.
15) Швидкий старт (впровадження за 30 днів)
1. Сформувати список обов'язкових адресатів за всіма ліцензіями/ринками і занести до реєстру (§ 10).
2. Затвердити шаблони повідомлень (§ 8) і підключити їх до інцидент-боту.
3. Налаштувати SLA-метрики (§ 12) і дашборд «Regulatory Reporting».
4. Провести навчання: data breach → DPA + гравці, платіжна криза → PSP, AML-SAR → FIU.
5. Включити нагадування про дедлайни і автогенерацію holding statements.
6. Запустити ретро за підсумками першого навчання, оновити плейбуки.
- Кризове управління та комунікації
- Інцидентні плейбуки та сценарії
- План безперервності бізнесу (BCP)
- Disaster Recovery Plan (DRP)
- Матриця ескалацій
- Система повідомлень і алертів
- Відповідальна гра і захист гравців