Журнал змін політик
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) або датована.
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, автоматичні нагадування за термінами.
- 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) Підсумок
Журнал змін політик - це не тільки «історія правок», а керований процес з чіткими ролями, моделлю даних, контролями доступу, юридичною фіксацією і метриками. Його зріла реалізація прискорює аудити, зменшує ризики невідповідності і підвищує операційну дисципліну у всій організації.