GH GambleHub

Реєстр ризиків та методологія оцінки

1) Навіщо і що входить до реєстру

Мета: єдина система опису, оцінки, пріоритезації та моніторингу ризиків, що впливають на гроші (GGR/CF), ліцензії, гравців, дані та репутацію.
Охоплення: продукт/інженерія (SDLC/інциденти), фінанси та платежі (PSP/висновки), KYC/AML/санкції, приватність (GDPR), TPRM/вендори, маркетинг/SDK, дані (DWH/BI), інфраструктура/хмари/DR, операції саппорту і VIP.


2) Таксономія ризиків (приклад)

Інформаційна безпека та приватність: витоку PII/KYC, несанкціонований доступ, неуспіх логування, DSAR-фейли.
Регуляторні/комплаєнс: порушення умов ліцензій, AML/KYC/санкції, рекламні заборони.
Операційні/технологічні: даунтайм PSP/KYC, дефект релізу, деградація latency, інциденти DR.
Шахрайство/зловживання: фрод-депозити, бонусний абуз, платіжні атакуючі патерни.
Фінансові: ліквідність партнерів, chargeback-шоки, концентрація на одному PSP.
Вендорські/ланцюжок поставок: уразливі SDK, субпроцесори з низькими TOMs.
Репутаційні/клієнтські: сплеск скарг, NPS падіння, порушення RG.
Стратегічні/геополітичні: санкції, зміни податків/законів, блокування трафіку.


3) Картка ризику (обов'язкові поля)

ID/Назва ризику

Категорія (з таксономії)

Опис події (що може трапитися) і причини

Активи/процеси/юрисдикції під впливом

Власник ризику (Risk Owner) і куратор (Sponsor)

Наявні контролі (превентивні/детективні/коригуючі)

Ймовірність (P) і Вплив (I) до контролів (inherent)

Залишковий ризик (residual) після контролів

План звернення (treatment): знизити/уникнути/прийняти/передати

Поріг ескалації/рівень загрози (Low/Medium/High/Critical)

KRIs та тригери, метрики та джерела даних

Статус і термін (Next Review), пов'язані САРА/тікети

Зв'язок з реєстром контролів (ID контролів) і політиками

Коментарі аудитора/комітетів (останні рішення)


4) Шкали оцінки (за замовчуванням 5 × 5)

4. 1 Ймовірність (P)

1 - Рідко (<1/5 років)

2 - Низька (1/2-5 років)

3 - Середня (щорічно)

4 - Висока (квартал)

5 - Дуже висока (місяць/частіше)

4. 2 Вплив (I) - вибираємо максимум з гілок

Фінанси: 1:< €10k · 2: €10–100k · 3: €100k–1m · 4: €1–5m · 5: >€5m

Приватність/дані: 1: <1k записів·...· 5: > 1M записів/спецкатегорії

Регулятор/ліцензії: 1: попередження· 3: штраф/перевірка· 5: призупинення ліцензії

Доступність (SLO/SLA): 1: <15 хв·...· 5: > 8 год для критичних зон

Підсумковий бал: 'R = P × I'→ рівні: 1–5 Low, 6–10 Medium, 12–16 High, 20–25 Critical.

(Пороги можна адаптувати під компанію.)


5) Матриця теплокарти і апетит до ризику

Risk Appetite: документ з допусками по доменах (наприклад, витоку PII - нуль толерантності; даунтайм P95 - ≤ X хв/міс; chargeback rate — ≤ Y%).
Heatmap: візуалізація R на 5 × 5; вище апетиту - вимагають плану і термінів CAPA.
Risk Budget: квоти на «прийняті» ризики з обґрунтуванням (економічна доцільність).


6) Методології оцінки

6. 1 Якісна (швидкий старт)

Експертні оцінки за шкалами P/I + обґрунтування, звірка з історією інцидентів і даними KRIs.

6. 2 Кількісна (пріоритетно для Top-10)

FAIR-підхід (спрощено): частота подій × ймовірнісний розподіл збитку (P10/P50/P90); корисно для порівняння варіантів зниження.
Monte Carlo (1000-10k прогонів): варіативність збитку і частоти → Loss Exceedance Curve (ймовірність втрат> X).
TRA (Targeted Risk Analysis): точковий аналіз для вибору частот моніторингу/контролів (актуально для PCI/вендорів).


7) KRIs і джерела

Приклади на домени:
  • Доступність/операції: MTTR, помилки 5xx, P95 latency, інциденти P1/P2,% автоскейла, ємність кластера.
  • Безпека/приватність: % MFA coverage, спроби credential stuffing, незвичайні експорти, DSAR SLA, прапори антимальвару.
  • Платежі: auth rate по PSP, chargeback rate, відмова банку, частка ручних касаутів.
  • KYC/AML: TAT, false positive rate, санкційні хіти, частка ескалацій.
  • Вендори: SLA compliance, дрейф латентності, частота інцидентів, актуальність сертифікатів.

KRIs зв'язуються з ризиками і запускають ескалації при виході за пороги.


8) Життєвий цикл ризику (workflow)

1. Ідентифікація → реєстрація картки.
2. Оцінка (inherent) → маппінг контролів → оцінка residual.
3. Рішення за зверненням (treatment) і план CAPA (дати/власники).
4. Моніторинг KRIs/інцидентів, оновлення картки.
5. Щоквартальний комітет з ризиків: перегляд Top-N, перерозмітка апетиту.
6. Закриття/консолідація або переведення в спостереження (watchlist).


9) Зв'язок з контролями та аудитом

Кожен ризик повинен посилатися на конкретні контролі (див. розділ «Внутрішні контролі та їх аудит»):
  • Превентивні: RBAC/ABAC, SoD, ліміти, шифрування, WebAuthn, сегментація.
  • Детективні: SIEM/алерти, звірки, WORM-логи, UEBA.
  • Коригувальні: відкати, блокування виплат, відкликання ключів, термінові патчі.
  • В аудиті DE/OE перевіряється, що контролі знижують ризик до апетиту і працюють стабільно.

10) Приклади карток (YAML, фрагменти)

10. 1 Витік PII через вендорський SDK (Tier-1)

yaml id: R-PRIV-001 title: "Утечка PII через SDK маркетинга"
category: privacy/vendor assets: [pii_profiles, sdk_mobile]
owner: privacy_lead inherent:
likelihood: 3 impact: 5  # >1M записей / регуляторные штрафы controls:
preventive: [cmp_enforced, data_minimization, sdk_allowlist, tokenization]
detective: [worm_logs, export_signing, siem_anomaly_exports]
corrective: [sdk_kill_switch, key_rotation, incident_comm_plan]
residual:
likelihood: 2 impact: 4 treatment: reduce kri:
- name: "Anomalous export volume"
threshold: ">P99 baseline"
- name: "SDK version drift"
threshold: "N-1 only"
status: active next_review: 2026-01-15

10. 2 Деградація PSP: провал авторизації платежів

yaml id: R-PAY-007 title: "Падение конверсии авторизации у PSP#1"
category: payments/availability owner: head_of_payments inherent: {likelihood: 4, impact: 4}
controls:
preventive: [multi_psp_routing, rate_limits, timeout_policies]
detective: [auth_rate_dashboard, p95_latency_alerts]
corrective: [failover_to_psp2, traffic_shaping, incident_swar_rm]
residual: {likelihood: 2, impact: 3}
kri:
- name: "Auth rate PSP1"
threshold: "< baseline-3σ for 15m"
escalation: "Incident P1 if <X% for 30m"

11) Агрегування та портфельне управління

Top-N (Risk Register View): сортування по residual R і «вище апетиту».
Теми (Risk Themes): кластери (вендори, приватність, PSP) → власники тем.
Карти взаємозалежностей: riski↔kontroli↔vendory↔protsessy.
Сценарії та стрес-тести: що якщо «PSP # 1 і KYC # 1 недоступні 2 години?» - оцінка сукупного збитку і план дій.
LEC (Loss Exceedance Curve): річний профіль втрат для ради/борду.


12) Пороги ескалації та сигнали

Operational: SLO/SLA порушення → Incident P1/P2.
Compliance/Privacy: перевищення ретеншн, неуспіх DSAR, експорт без'purpose'→ негайна ескалація DPO/Legal.
Vendor: повторні SLA-зриви → CAPA у постачальника, перегляд договору.
Financial: вихід chargeback> порогу → ручні перевірки, коригування лімітів/бонусів.


13) RACI (укрупнено)

АктивністьBoard/CEORisk CommitteeRisk OwnerSecurity/PrivacyDomain OwnersData/BIInternal Audit
Апетит до ризикуARCCCII
Таксономія/шкалиIA/RCRCCI
Ведення реєструICA/RRRRI
Оцінка/оновленняICA/RRRRI
ЕкскалаціїIA/RRRRII
Аудит/перевіркиICCCCCA/R

14) Метрики (KPI/KRI) системи ризик-менеджменту

Coverage: 100% критичних процесів мають зареєстровані ризики і власників.
Review On-time: ≥ 95% карток переглянуті вчасно.
Above Appetite: ↓ QoQ частка ризиків вище апетиту.
CAPA Closure (High/Critical): ≥ 95% вчасно.
Detection Lag: медіана часу від відхилення KRI до ескалації (прагне до ↓).
Incident Recurrence: повторні інциденти з однієї причини - 0.


15) Чек-листи

15. 1 Створення картки

  • Категорія та опис події/причин
  • Активи/процеси/юрисдикції відзначені
  • Оцінені P/I (inherent) і residual з обґрунтуванням
  • Маппінг контролів (ID), KRIs і джерела даних
  • План САРА/терміни/власники
  • Поріг ескалації та рівня загроз

15. 2 Щоквартальний комітет

  • Топ-10 за residual і вище апетиту
  • Нові/емерджент-ризики, зміни законів/вендорів
  • Статус CAPA і прострочення
  • Рішення: прийняти/знизити/передати/уникнути; оновити апетит/пороги

16) Дорожня карта впровадження (4-6 тижнів)

Тижні 1-2: затвердити таксономію, шкали, апетит; вибрати інструмент (таблиця/BI/IRM). Створити 10-15 стартових карток за критичними процесами.
Тижні 3-4: зв'язати ризики з контролями і KRIs; побудувати теплокарту/дашборди; запустити комітет з ризиків.
Тижні 5-6: впровадити кількісну оцінку для Top-5 (FAIR/Monte Carlo light), автоматизувати збір KRIs, формалізувати ескалації та звітність борду.


17) Пов'язані розділи wiki

Внутрішні контролі та їх аудит, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Least Privilege, TPRM і SLA, Інциденти і витоки, DR/BCP, Політика логів і WORM - для повного циклу «ризик → контроль → метрика → докази».


TL; DR

Робочий реєстр ризиків = чітка таксономія + стандартизовані шкали + апетит/пороги → картки з власниками, контролями і KRIs → теплокарта і комітети → пріоритетна кількісна оцінка для Top-ризиків і CAPA в строк. Це робить ризики керованими, порівнянними і доказовими для борда і регуляторів.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.