GH GambleHub

Журнал змін політик

1) Призначення та цінність

Навіщо:
  • Прозора історія змін: хто, що, коли і чому.
  • Відповідність вимогам аудиторів/регуляторів (ISO 27001, SOC 2, PCI DSS, GDPR і місцеві норми).
  • Управління ризиками: зв'язка змін з оцінками ризику, інцидентами і CAPA-планами.
  • Єдине джерело істини для співробітників, провайдерів і партнерів.

Результат: знижується операційний і комплаєнс-ризик, прискорюються аудити і розслідування, скорочується час онбордингу.

2) Область охоплення (scope)

Журнал покриває всі документи рівня «policy» і «standard»:
  • Безпека та доступ: ІБ-політика, управління інцидентами, вразливості, ключі/шифрування, секрет-менеджмент, парольна політика, IAM.
  • Дані та приватність: GDPR/DSAR/RTBF, зберігання і видалення, класифікація даних, DLP, логи і аудит.
  • Фінанси/AML/KYC: AML/KYB/KYC, санкційний скринінг, підтвердження джерела коштів.
  • Операції: BCP/DRP, управління змінами, релізна політика, RACI, SRE/SLO.
  • Правові/регуляторні: локальні вимоги ринків, рекламні обмеження, відповідальна гра.

3) Ролі та відповідальність (RACI)

R (Responsible): Власник політики (Policy Owner) і редактор (Policy Editor).
A (Accountable): Документо-власник домену/CISO/Head of Compliance.
C (Consulted): Legal/DPO, Risk, SRE/Operations, Product, Data.
I (Informed): Всі співробітники, зовнішні підрядники (за потребою).

Принципи: dual-control на публікацію; сегрегація обов'язків; обов'язкові консультації Legal/DPO для PII/регуляторних тем.

4) Життєвий цикл зміни

1. Ініціатива: тригер (регуляторна вимога, аудит-файндинг, інцидент, пентест, зміна архітектури).
2. Чернетка: зміна в системі управління документами (Confluence/Git/Policy CMS).
3. Оцінка впливу: на процеси, ризик-реєстр, навчання, договори, інтеграції.
4. Узгодження: Legal/DPO/Compliance/Tech/Operations, фінальне затвердження власником.
5. Публікація: присвоєння версії, дата вступу в силу, розсилка.
6. Онбординг: навчання/квітування, оновлення SOP/Runbook.
7. Моніторинг: контроль дотримання, метрики, ретроспектива.

5) Модель даних журналу (обов'язкові поля)

'policy _ id'- постійний ідентифікатор політики.
'policy _ title'- назва документа.
'change _ id'- унікальний ідентифікатор зміни.
«version» - семантична версія (MAJOR. MINOR. PATCH) або датована.

`change_type` — {MAJORMINORPATCHURGENTREGULATORY}.
`status` — {draftin_reviewapprovedpublishedeffective
'proposer '/' editor '/' approver'- користувачі/групи.
`submitted_at` / `approved_at` / `published_at` / `effective_from`.
«summary» - короткий опис зміни (≤ 300 символів).
'change _ log'- подробиці: що змінено і навіщо.
'rationale'- обґрунтування (регуляторне посилання/інцидент/аудит).
'risk _ ref'- посилання на ризик-реєстр/оцінку впливу.
'legal _ refs'- норми/стандарти (наприклад, GDPR Art. 32, ISO A.8).
'impact _ scope'- на кого впливає (команди/процеси/регіони).
'training _ required'- так/ні + посилання на курс.
'attachments'- diff/pdf, протокол узгодження.
'distribution _ list'- кого повідомити.
'ack _ required'- чи потрібне квітування.
'hold _ flags'- Legal Hold/заморожування (якщо застосовується).
Приклад (YAML):
yaml change_id: POL-SEC-001-2025-11-01-M01 policy_id: POL-SEC-001 policy_title: Access Control Policy version: 2. 0. 0 change_type: MAJOR status: approved submitted_at: 2025-10-18T14:20:00Z approved_at: 2025-10-29T10:05:00Z published_at: 2025-10-30T09:00:00Z effective_from: 2025-11-15 proposer: d. kovalenko editor: secops. editors approver: ciso summary: Review roles and JIT access, enter quarterly-review.
rationale: "SOC Audit 2: CAPA-2025-17; incident # INC-5523"
risk_ref: RSK-AC-2025-004 legal_refs: ["ISO27001 A.5, A.8", "GDPR Art. 32"]
impact_scope: ["Prod Ops", "Payment Ops", "Affiliates"]
training_required: true attachments:
- link: confluence://AC-Policy-v2-diff
- link: git://policy-repo/pol-sec-001@v2. 0. 0 distribution_list: ["all@company", "ops@company", "vendors:payments"]
ack_required: true hold_flags: []

6) Вимоги до версії та типів змін

MAJOR: змінює обов'язкові вимоги/контролі, впливає на аудит/ризики; вимагає навчання і перехідного періоду.
MINOR: уточнення, приклади, не змінюють контроль по суті.
PATCH: правки орфографії/посилань; fast-track.
URGENT: термінова правка через інцидент/уразливість; публікація в прискореному порядку.
REGULATORY: оновлення у зв'язку з новим регуляторним актом/листом регулятора.

Версіонування: фіксуйте теги/релізи; immutable артефакти PDF/HTML з хешем.

7) Workflow узгодження

1. Draft → Review: авто-перевірка шаблону, посилань і метаданих.
2. Multi-review: Legal/DPO/Compliance/Tech/Operations (паралель/послідовно).
3. Approval: власник домену + Accountable.
4. Publish: генерація реліз-замітки, запис в Журнал, розсилка, оновлення "effective_from".
5. Acknowledgement: збір квітування співробітників (LMS/HRIS).
6. Post-publish controls: завдання на оновлення SOP/договорів/скриптів.

Правило двох ключів: публікація можлива тільки при 2 + узгодженнях зі списку затверджених ролей.

8) Юридична фіксація та заморозка (Legal Hold)

Коли: розслідування, судовий запит, регуляторна перевірка.
Що робимо: прапор'hold _ flags = [«legal»]', заморожування видалення/редакцій версії, WORM-архів, журнал дій по Hold.
Зняття Hold: тільки Legal/DPO; всі дії протоколюються.

9) Приватність і локальні регуляції

Мінімізація PII в журналі (зберігайте employee ID замість e-mail, якщо можливо).
Терміни зберігання = «графіки зберігання» (policy records зазвичай 5-7 років).
DSAR/RTBF: журнал виключається з видалення, якщо є законний обов'язок зберігання; фіксуємо правову підставу.

10) Інтеграції

Confluence/Docs/Git: джерело правок і артефактів (diff, PDF).
IAM/SSO: ролі та атрибути співробітників; аудит доступу до журналу.
LMS/HRIS: навчання, тести, квітування.
GRC/IRM: зв'язок з ризиками, контролями, САРА/планами.
SIEM/Логи: аудит операцій над журналом (хто переглядав/експортував).
Ticketing (Jira/YouTrack): ініціюючі завдання і чек-листи випуску.

11) Метрики та SLO

Coverage: % актуальних політик з останнім записом у журналі (мета ≥ 99%).
Time-to-Publish: медіана часу від'submitted _ at'до'published _ at'( мета ≤ 14 днів; urgent ≤ 48 годин).
Ack-rate: частка співробітників, які підтвердили ознайомлення (мета ≥ 98% в 14 днів).
Audit-readiness: частка політик з повним набором артефактів (diff, PDF, підписи) (мета 100%).
Exceptions closed: % закритих винятків/відхилень за терміном.
Access audit: 0 інцидентів несанкціонованого доступу до журналу.

12) Дашборд (мінімальний набір віджетів)

Стрічка останніх публікацій і вступів в силу.
Карта статусів по доменах (Security, Data, AML, Ops).
Теплова карта прострочень узгодження.
Гістограма Time-to-Publish/Time-in-Review.
Ack-rate по департаментах і ролях.
Список відкритих REGULATORY/URGENT змін.

13) Процедури та шаблони

Шаблон запису про зміну (Markdown):

{policy_title} — {version}
Change ID: {change_id}      Type: {change_type}      Effective: {effective_from}
Summary: {summary}
Rationale: {rationale}
Impacts: {impact_scope}
Approvals: {approver} at {approved_at}
Artifacts: {links}
Training: {training_required}
Чек-лист випуску:
  • Заповнені всі обов'язкові поля і посилання на артефакти
  • Проведено оцінку впливу та оновлено ризики
  • Отримані узгодження (dual-control)
  • Сформований immutable-пакет (PDF + hash)
  • Налаштовані розсилки і ack-кампанія
  • Оновлені SOP/Runbooks/контракти (якщо потрібно)

14) Контроль доступу та безпека

RBAC: ролі на читання/створення/затвердження/архівацію.
Just-in-Time: тимчасові повноваження на публікацію/експорт.
Шифрування: TLS in-transit, KMS at-rest; заборона анонімних експортів.
Аудит: логи всіх операцій, алерти на незвичайні дії (масові експорти, часті правки).

15) Впровадження по кроках

MVP (2-4 тижні):

1. Каталог політик і їх власників.

2. Єдиний шаблон запису + обов'язкові поля.

3. Реєстр в Confluence/Notion або проста Policy-CMS; експорт immutable PDF.

4. Базовий workflow узгоджень і ack-кампанія через пошту/LMS.

5. Ролі доступу та журналювання дій.

Фаза 2 (4-8 тижнів):
  • Інтеграція з Git для diff і семантичного версіонування.
  • GRC-зв'язки з ризиками/контролями, звіти для аудиту.
  • Дашборд KPI/SLO, автоматичні нагадування за термінами.
Фаза 3 (8-12 тижнів):
  • API/вебхуки для зовнішніх систем, rule-as-code перевірки відповідності шаблону.
  • Legal Hold + WORM-архів, криптопідписи реліз-пакетів.
  • Мультиюрисдикційність (теги щодо ринків/мов/версій).

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

Зміни поза журналом: заборона публікацій без запису, автоматичні перевірки.
Немає rationale/посилань: робіть поле обов'язковим + шаблони джерел (регулятор, аудит, інцидент).
Немає ack-контролю: інтегруйте LMS/HRIS і відстежуйте KPI.
Змішання чернеток і публікацій: використовуйте окремі простори/гілки.
Доступ «всім»: строгий RBAC, аудит читання експорту.

17) Глосарій (коротко)

Policy - управлінський документ з обов'язковими вимогами.
Standard/Procedure/SOP - деталізація та порядок виконання.
CAPA - коригувальні та попереджувальні дії.
Acknowledgement (ack) - підтвердження ознайомлення співробітником.
Legal Hold - юридична заморозка змін/видалень.

18) Підсумок

Журнал змін політик - це не тільки «історія правок», а керований процес з чіткими ролями, моделлю даних, контролями доступу, юридичною фіксацією і метриками. Його зріла реалізація прискорює аудити, зменшує ризики невідповідності і підвищує операційну дисципліну у всій організації.

Contact

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

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

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

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

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

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