KPI и метрики комплаенса

1) Зачем метрики комплаенса

• делает статус соответствия прозрачным и сравнимым во времени;
• связывает работу комплаенса с бизнес-результатом (снижение потерь/штрафов/задержек релизов);
• позволяет управлять приоритетами и ресурсами по фактам, а не по ощущениям;
• упрощает аудит: есть трассируемые формулы, источники и неизменные артефакты (evidence).

• KPI — показатели исполнения (эффективность процессов).
• KRI — показатели риска (вероятность/влияние событий).
• SLO/SLA — целевые уровни сервиса/обязательства по срокам.
• Leading vs Lagging: предвосхищающие (leading) и запаздывающие (lagging) индикаторы.

2) Карта метрик по доменам (референс-матрица)

3) «Северные звезды» (North Star) комплаенса

1. Audit-ready за N часов (все evidence собраны автоматически).
2. Zero Critical Violations (нулевые критические несоответствия по безопасности/регуляторике).
3. ≥ 90% Coverage автоматизированными контролями (policy-as-code + CCM).

4) Таксономия метрик

4.1 Coverage (охват)

Control Coverage: контролируемые системы / все критичные системы.
Evidence Coverage: артефакты собраны / по чек-листу аудита.
Policy Adoption: процессы, где требования внедрены, / все целевые процессы.

4.2 Effectiveness (эффективность контролей)

Pass Rate тестов контролей: пройдено / всего тестов периода.
FPR/TPR (ложноположит./истинноположит.) для детективных правил.
Incidents Prevented: кейсы, предотвращенные превентивными контролями.

4.3 Efficiency (затраты/скорость)

MTTD/MTTR нарушений: время до детекта/устранения.
Cost per Case (AML/DSAR): часы × ставка + инфраструктурные издержки.
Automation Ratio: авто-решений / все решения.

4.4 Timeliness (сроки)

SLA выполнения (DSAR/STR/обучение): в срок / всего.
Lead Time политик: от триггера до публикации.
Change Lead Time (DevSecOps-гейты): от PR до релиза при комплаенс-проверках.

4.5 Quality (качество данных/процессов)

Evidence Integrity: % артефактов в WORM с хеш-сводкой.
Data Defects: ошибки в рег-отчетности / отчетов.
Training Score: средний балл теста, % с первого раза.

4.6 Risk Impact (влияние на риск)

Risk Reduction Index: ∆ суммарного риск-скора после ремедиации.
Regulatory Exposure: открытые критические гэпы vs требования лицензий/сертификаций.
$ Avoided Losses (оценочно): штрафы/потери, предотвращенные закрытием гэпов.

5) Формулы и примеры расчетов

5.1 DSAR SLA

`DSAR_SLA = (кол-во заявок закрытых ≤ 30 дней) / (кол-во заявок всего)`

Цель: ≥ 98%; красная зона < 95%, желтая 95–97.9.

5.2 Access Hygiene

`AH = устаревшие_права (нет владельца/прошел срок) / все_права`

Порог: ≤ 2% (красная зона > 5%).

5.3 Drift Rate (IaC/Cloud)

`DR = дрейфы(несоответствия IaC↔факт) / мес`

Тренд: устойчивое снижение 3 месяца подряд.

5.4 Time-to-Remediate (по severity)

High: медиана ≤ 30 дней; Critical: ≤ 7 дней. Просрочка → авто-эскалация.

5.5 AML FPR

`FPR = ложноположительные_алерты / все_алерты`

Балансируйте с TPR и потерями на обработку.

5.6 Evidence Coverage (аудит)

`EC = собранные_артефакты / обязательные_по_чек-листу`

Цель: 100% к D-дате аудита; операционная цель — ≥ 95% постоянно.

6) Источники данных и доказательств (evidence)

Витрина Compliance DWH: DSAR, Legal Hold, TTL, аудит-логи, алерты.
IAM/IGA: роли, владельцы, кампании аттестаций.
CI/CD/DevSecOps: SAST/DAST/SCA, секрет-скан, лицензии, гейты.
Cloud/IaC: снапшоты конфигов, дрейф-репорты, KMS/HSM-логи.
SIEM/SOAR/DLP/EDRM: корреляции, плейбуки, блокировки.
GRC: реестр требований, контролей, waivers и аудитов.
WORM/Object Lock: неизменяемый архив артефактов + хеш-сводки.

7) Дашборды (минимальный набор)

1. Compliance Heatmap — системы × нормативы × статус.
2. SLA Center — DSAR/STR/обучение: дедлайны, просрочки, прогноз.
3. Access & SoD — токсичные роли, orphan-аккаунты, прогресс аттестаций.
4. Retention & Deletion — TTL-нарушения, Legal Hold блокировки, тренды.
5. Infra/Cloud Drift — несоответствия IaC, шифрование, сегментация.
6. Findings Pipeline — открытые/просроченные/закрытые по владельцам и severity.
7. Audit Readiness — покрытие evidence и время до готовности «по кнопке».

• Зеленая — цель достигнута/стабильно.
• Желтая — риск отклонения, требуется план.
• Красная — критическое отклонение, немедленная эскалация.

8) OKR-связка (пример квартала)

Objective: Снизить регуляторный и операционный риск без замедления релизов.

KR1: Увеличить Coverage автоматизированных контролей с 72% → 88%.
KR2: Снизить Access Hygiene с 4.5% → ≤ 2%.
KR3: 99% DSAR в срок; медиана ответа ≤ 10 дней.
KR4: Drift Rate облака −40% QoQ.
KR5: Time-to-Audit-Ready ≤ 8 часов (dry-run).

9) RACI за метрики

10) Частота и процедуры измерений

Ежедневно: алерты CCM, дрейф, секреты, критические инциденты.
Еженедельно: SLA DSAR/STR, DevSecOps гейты, Access Hygiene.
Ежемесячно: pass rate контролей, повторные findings, Evidence Coverage.
Ежеквартально: OKR-сводка, Risk Reduction Index, аудит-репетиция (dry-run).

Процедура пересмотра порогов: анализ трендов, затрат и риска; изменение порогов — через Board.

11) Качество метрик: правила

Единая семантика: словарь терминов и SQL-шаблонов.
Версионирование формул: «метрика как код» (репозиторий + ревью).
Проверка воспроизводимости: скрипты реперформа для аудиторов.
Иммутабельность артефактов: WORM + хеш-цепочки.
Приватность: минимизация, маскирование, контроль доступа к витринам KPI.

12) Примеры запросов (SQL/псевдо)

12.1 DSAR SLA (30 дней):

sql
SELECT
COUNTIF(closed_at <= created_at + INTERVAL 30 DAY) / COUNT() AS dsar_sla_rate
FROM dsar_requests
WHERE created_at BETWEEN @from AND @to;

12.2 Access Hygiene:

sql
SELECT
SUM(CASE WHEN owner IS NULL OR expires_at < CURRENT_DATE THEN 1 END)
/ COUNT() AS access_hygiene
FROM iam_entitlements
WHERE system_critical = TRUE;

12.3 Drift (Terraform vs факт):

sql
SELECT COUNT() AS drifts
FROM drift_detections
WHERE detected_at BETWEEN @from AND @to
AND severity IN ('high','critical');

13) Пороговые значения (референс-примеры, адаптируйте)

14) Антипаттерны

Метрики «для отчета» без владельца и плана действий.
Смешение версий формул → несопоставимость трендов.
Охват без эффективности: высокий Coverage, но высокий drift и повторные findings.
Игнор стоимости ложных срабатываний (FPR) в AML/CCM.
Метрики без контекста риска (нет связи с KRI и лицензиями).

15) Чек-листы

Запуск системы KPI

• Словарь метрик и единый репозиторий «метрики как код».
• Назначены владельцы (RACI) и частоты обновления.
• Подключены источники и витрина «Compliance».
• Настроены дашборды и цветовые зоны, SLO/SLA и эскалации.
• WORM-архив и хеш-фиксация отчетов.
• Dry-run для аудита с реперформой.

Перед квартальным отчетом

• Верификация формул, контроль аномалий.
• Обновление околорегуляторных порогов.
• Анализ cost/benefit FPR vs TPR.
• План улучшений по «красным» зонам.

16) Модель зрелости метрик (M0–M4)

M0 Ручной учет: Excel-таблицы, нерегулярные отчеты.
M1 Каталог: единая витрина, базовые SLA и тренды.
M2 Автоматизировано: дашборды в реальном времени, эскалации.
M3 Orchestrated: policy-as-code, CCM, auto-evidence, реперформ.
M4 Continuous Assurance: «audit-ready по кнопке», прогнозные (ML) метрики риска.

17) Связанные статьи wiki

Непрерывный мониторинг соответствия (CCM)

Автоматизация комплаенса и отчетности

Риск-ориентированный аудит

Жизненный цикл политик и процедур

Legal Hold и заморозка данных

DSAR: запросы пользователей на данные

Графики хранения и удаления данных

Итог

Сильные KPI комплаенса — это понятные формулы, надежные источники, владельцы и пороги, автоматизированная витрина и действия по отклонениям. Так комплаенс становится предсказуемым сервисом с измеримым влиянием на риск и скорость бизнеса.