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

1) Назначение и ценность

• Прозрачная история изменений: кто, что, когда и почему.
• Соответствие требованиям аудиторов/регуляторов (ISO 27001, SOC 2, PCI DSS, GDPR и местные нормы).
• Управление рисками: связка изменений с оценками риска, инцидентами и CAPA-планами.
• Единый источник истины для сотрудников, провайдеров и партнеров.

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

2) Область охвата (scope)

• Безопасность и доступ: ИБ-политика, управление инцидентами, уязвимости, ключи/шифрование, секрет-менеджмент, парольная политика, 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: связь с рисками, контролями, CAPA/планами.
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) Процедуры и шаблоны

{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) Внедрение по шагам

1. Каталог политик и их владельцев.

2. Единый шаблон записи + обязательные поля.

3. Реестр в Confluence/Notion или простая Policy-CMS; экспорт immutable PDF.

4. Базовый workflow согласований и ack-кампания через почту/LMS.

5. Роли доступа и журналирование действий.

• Интеграция с 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) Итог

Журнал изменений политик — это не только «история правок», а управляемый процесс с четкими ролями, моделью данных, контролями доступа, юридической фиксацией и метриками. Его зрелая реализация ускоряет аудиты, уменьшает риски несоответствия и повышает операционную дисциплину во всей организации.