GH GambleHub

Аудиторські чеклісти і рев'ю

1) Призначення

Створити єдиний каталог чеклістів і правил рев'ю для Операцій і Комплаєнсу, який забезпечує:
  • порівнянність перевірок між командами і періодами;
  • повноту і доказовість результатів;
  • прозоре управління виправленнями (CAPA) і повторними перевірками.

2) Ролі та RACI

Owner: Head of Compliance/Head of Internal Audit - методологія, версії чеклістів. (A)

Process Owners (1-а лінія): self-assessment, артефакти, CAPA. (R)

Compliance/InfoSec/AML/RG (2-а лінія): peer-review, ко-аудити, трактування норм. (R/C)

Internal Audit (3-я лінія): незалежні рев'ю, рейтинги, follow-up. (R)

Management (Exec Sponsor): затвердження висновків і ресурсів на CAPA. (A/C)

3) Типи рев'ю

1. Self-Assessment (SA): щомісяця/квартально власниками процесів за короткими чеклістами.
2. Peer-Review (PR): перехресна перевірка сусідньою командою (без конфлікту інтересів).
3. Management Review (MR): раз на квартал - огляд KPI/KRI, трендів і незакритих CAPA.
4. Internal Audit Review (IA): незалежна перевірка за планом IA.
5. External-Audit Readiness (EAR): підготовка до сертифікацій/інспекцій (ISO/SOC/PCI/регулятор).

4) Загальні правила чеклиста

Кожен чеклист має код, версію, власника, область і обов'язкові розділи:

ID: CL- <code >/Version: v <MAJOR. MINOR >/Owner: <role>
Область: <KYC/AML/RG, GDPR/PII, Payments/PCI, Games/Providers, Reporting, Incidents...>
Frequency: M     Q      Ad-hoc
Material: <criteria for High/Medium/Low>
Sampling: <method and size>
Evidence: <list of files/screenshots/logs>
Question List: [X] Yes [] No [] N/A + Comment + Artifact + Severity
Bottom line: Score/Rating/CAPA
Система оцінок (рекомендована):
  • Fully Met (100–90%) / Largely Met (89–75%) / Partially Met (74–50%) / Not Met (<50%).
  • Severity невідповідностей: S1 критичне/S2 високе/S3 середнє/S4 низьке.
  • Матеріаліті: грошовий ефект (GGR/NGR), охоплення клієнтів/PII, ризик ліцензії/штрафів, вплив на чесність ігор.

5) Каталог чеклістів (скелети з контрольними пунктами)

CL-KYC-01 — KYC/KYB

  • Політика та рівні перевірки затверджені та актуальні.
  • Провайдери KYC мають діючі договори/DPА.
  • SLA за верифікацією дотримуються (метрика D-1).
  • Документи зберігаються відповідно до ретенції; доступ - RBAC.
  • Відмови/ескалації задокументовані; частка FP в нормі.
  • KYB для партнерів: актуальні виписки/бенефіціари.

Докази: вивантаження KYC статусів, реєстр DPA, журнал доступу, sample з 25 кейсів.

CL-AML-02 — AML/CFT

  • Оновлена політика AML і методика скорингу ризиків.
  • Перевірки РЕР/санкції по on-boarding і періодично.
  • SAR/STR направляються в терміни; є підтвердження прийому.
  • Якість розслідувань: повнота, таймінг, закриття.
  • Monitoring rules покривають velocity/structuring/мули.
  • Тест «no tipping-off»: немає повідомлень клієнтів при SAR.

Докази: кейси SAR/STR, логи санкційних перевірок, звіти за часом закриття справ.

CL-RG-03 - Відповідальна гра

  • Реєстр лімітів/самовиключень синхронізований (реєстр/нац. система).
  • Тригери вразливості → контакт в SLA; шаблони комунікацій.
  • Ефективність інтервенцій вимірюється і аналізується.
  • Реклама/бонуси відповідають обмеженням ринку.
  • RG-інциденти і повідомлення регулятору - вчасно.

Докази: логи self-exclusion, комунік. шаблони, метрики outreach.

CL-PCI-04 - Платежі/PCI

  • Сегментація PCI та інвентар PAN/CHD в актуальному стані.
  • Токенізація/шифрування в транзиті/at-rest; ключі ротуються.
  • Auth-rate/decline/latency по PSP в порогах; fallback-маршрути.
  • Chargeback process і доказова база для диспутів.
  • Уразливості з ASV сканів усунені в термін.
  • Журнали доступу до платіжної зони - повні і незмінні.

Докази: network-діаграми, звіти ASV, кейси chargebacks, ключова політика KMS.

CL-GAMES-05 - Провайдери ігор/чесність

  • Контракти і тех. специфікації актуальні; версії RNG/білдів - в реєстрі.
  • RTP-drift моніторинг і пороги реакції; freeze процедурно закріплений.
  • Синхронізація балансів round/session/гаманець.
  • Інциденти провайдера: таймлайн, фіксація, компенсації гравцям.
  • Звіти регулятору по чесності/RTP - здані і підтверджені.

Докази: вивантаження RTP, логи API провайдера, приклади freeze-тікетів.

CL-REP-06 - Регуляторна звітність

  • Календар дедлайнів: статуси «готовий/відправлений/прийнятий».
  • Схеми даних версіоновані; файли підписані/з хешами.
  • Reconciliation: гаманець ↔ PSP ↔ GL без розбіжностей> X%.
  • Підтвердження прийому (ID/квитанції) збережені і пов'язані з артефактами.
  • Локалізація/мова дотримані.

Докази: дашборд дедлайнів, квитанції, SQL-звірки.

CL-INC-07 - Інциденти/повідомлення

  • TTS (перше повідомлення) в SLA за S1/S2.
  • Повідомлення DPA/регуляторам/PSP/CERT - в терміни, з підтвердженнями.
  • Повнота артефактів: таймлайн, логи, повідомлення, списки порушених.
  • Ретро ≤ 7 днів, CAPA зареєстровані і рухаються.
  • Компенсації гравцям нараховані згідно з політикою.

Докази: журнал інцидентів, статус-сторінка, пакети артефактів.

CL-GDPR-08 — GDPR/PII

  • Реєстр обробок (RoPA) актуальний; правові підстави коректні.
  • DSAR закриваються ≤ 30 днів; прострочення пояснені.
  • DPIA виконані для високоризикових процесів.
  • Псевдонімізація/маскування при вивантаженнях і звітах.
  • Договори з обробниками і SCC в силі.

Докази: RoPA, журнал DSAR, DPIA, приклади масок у звітах.

CL-ITGC-09 - Загальні ІТ-контролі

  • Управління змінами: PR-процес, тести, approvals, separation of duties.
  • Доступи: RBAC/ABAC, періодична ревізія, off-boarding ≤ 24 год.
  • Резервне копіювання/відновлення, періодичні тести DR.
  • Логи аудиту незмінні, ретенція дотримується.
  • Спостережуваність: SLO/помилкові бюджети, алерти на критичні метрики.

Докази: вибірки PR, логи IAM, звіти DR-тестів, політики ретенції.

6) Методика вибірок і доказів

Розмір: орієнтуйтеся на обсяг операцій і ризик (наприклад, min 25, pps/стратифікація для великих масивів).
Методи: випадкова, систематична, спрямована (аномалії/крайові випадки), за періодами піків.
Достатність: не менше 2-3 незалежних джерел на ключовий висновок (логи, скріншоти, вивантаження, тікети).
Простежуваність: кожному пункту чеклиста - доказ з ID і посиланням в реєстрі.

7) Рубрикатор рейтингів рев'ю

Effective - контроль спроектований і працює стабільно, невідповідностей S1/S2 немає.
Generally Effective (з поліпшеннями) - є S3/S4, але ризики під контролем.
Partially Effective - системні S2; високий залишковий ризик.
Ineffective - S1/множина S2; потрібен негайний план відновлення.

8) CAPA и follow-up

Для кожного finding: корінь → дія → власник → термін → метрика успіху.
SLA закриття: S1 - ≤ 30 днів; S2 - ≤ 60 днів; S3 - ≤ 90 днів; S4 - за домовленістю.
Верифікація: аудитор прикладає докази впровадження (скріни/логи/політики), змінює статус на Verified.
Ескалація: прострочення S1/S2 - в щотижневий MR, на Аудит-комітет щокварталу.

9) Робочі артефакти (шаблони)

9. 1 Чеклист (лист перевірки)

'Пункт''Так/Ні/N/A''Коментар'`Severity`Артефакт (ID).

9. 2 Finding Card

Код Заголовок Факт Критерій Ризик/вплив Причина (root cause) Рекомендація S-рівень.

9. 3 CAPA Sheet

Finding → Кроки → Власник → Термін → Метрика/поріг → Докази → Статус → Дата верифікації.

9. 4 PBC-лист (Provided By Client)

Запит → Формат → Джерело → Відповідальний → Дедлайн → Отримано (дата) → Коментарі.

10) Дашборд рев'ю

Coverage: % процесів, охоплених рев'ю за період.
Findings by Severity: розподіл S1-S4.
CAPA Progress: виконано/в роботі/прострочено; медіана часу закриття.
Repeat Findings: частка повторів за 12 міс.
Timeliness: дотримання графіка SA/PR/MR/IA.
Effectiveness Trend: динаміка рейтингів по областях.

11) Календар і частоти

Monthly: SA по KYC/Payments/GDPR DSAR, інциденти/повідомлення.
Quarterly: PR по AML/RG/Providers/Reporting, MR для всіх напрямків.
Semi-Annual/Annual: IA по зонах високого ризику; EAR перед сертифікаціями/інспекціями.

12) Чек-карти «Швидкий старт» (по 7 пунктів)

KYC (7-point): Політика Провайдери/DPА SLA Черги> SLA RBAC Відмови/ескалації Звіт про FP.
AML (7-point): Списки РЕР/санкції SAR терміни Якість розслідувань Velocity/structuring No tipping-off Тренінги Caseboard KPI.
RG (7-point): Реєстр/синхронізація Контакти в SLA Ефективність Обмеження реклами Скарги Інциденти Звіти регулятору.
PCI (7-point): Сегментація Ключі/ротація ASV/вулни Журнали доступу Токенізація Chargebacks Fallback PSP.
Games (7-point): RTP-drift Freeze процедура Баланс-синхрони Інциденти провайдера Версії RNG/білдів Звіти чесності SLA API.
Reporting (7-point): Календар Схеми/версії Підпис/хеш Reconciliation Мова/локаль Квитанції DQ-метрики.
Incidents (7-point): TTS Повідомлення в терміни Повнота артефактів Компенсації Ретро CAPA Дашборд.

13) Часті помилки і як їх уникнути

Чеклісти без доказів → всі пункти зажадають артефакт ID.
Оцінка без матеріаліті → фіксуйте пороги в картці чеклиста.
Дублювання SA/PR/IA → узгоджений календар і єдиний реєстр запитів (PBC).
«Документоцентризм» без тестів операційності → завжди брати вибірку операцій.
CAPA без метрик → задавайте вимірювані результати (наприклад, DSAR ≤ 30 днів ≥ 98%).

14) План впровадження (30 днів)

Тиждень 1

1. Затвердити методологію та шкали рейтингів.
2. Створити 8 базових чеклістів (CL-KYC/AML/RG/PCI/GAMES/REP/INC/GDPR).
3. Завести реєстр артефактів і шаблони PBC/Finding/CAPA.

Тиждень 2

4. Провести пілот SA в 2 процесах і PR в 1 процесі.
5. Налаштувати дашборд рев'ю і журнал CAPA.
6. Видати тренінг за «доказами і вибірками».

Тиждень 3

7. EAR-сесія з найближчої сертифікації/інспекції.
8. Узгодити графік MR/IA на квартал.
9. Зафіксувати пороги матеріаліті та розміри вибірок.

Тиждень 4

10. Випустити v1. 0 каталогу чеклістів і карти календаря.
11. Провести ретро пілота, оновити версії чеклістів (v1. 1).
12. Включити рев'ю в KPI власників процесів.

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

Внутрішній аудит і зовнішній аудит

Регуляторні звіти та формати даних

Повідомлення про порушення та терміни звітності

Дашборд комплаєнсу та моніторинг

Інцидентні плейбуки та сценарії

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

Contact

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

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

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

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

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

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