От анализа разрывов к плану: владельцы, доказательства, сроки

Проведение анализа разрывов — самая простая часть. Наше пошаговое руководство поможет получить трекер со всеми невыполненными требованиями. Дальше решается, успешно ли пройдёт программа: слишком многие трекеры так и остаются длинными таблицами со строками «не выполнено», за которые никто не отвечает.

Шаг 1: сгруппируйте строки по направлениям работ

Требования пронумерованы по логике стандарта, а не вашей. Сгруппируйте невыполненные строки по тому, что их закроет:

• Управление и политики (область действия, роли, политики, одобрение руководством)
• Идентификация и доступ
• Управление уязвимостями и патчами
• Логирование и мониторинг
• Реагирование на инциденты и отчётность
• Управление поставщиками
• Непрерывность бизнеса и резервное копирование
• Безопасная разработка
• Физическая безопасность

Одно направление часто закрывает десять-двадцать строк. Например, включение требований безопасности в договоры с поставщиками может одновременно выполнить требования ISO 27001, PCI DSS, GDPR и NIS2.

Шаг 2: расставьте порядок по зависимостям и рискам

1. Сначала то, что снимает блокировки: область действия, управление, политики и оценка рисков. Техническая работа без них будет переделываться.
2. Затем высокорисковые разрывы: открытые системы без MFA, непропатченные сервисы, доступные из интернета, непроверенные резервные копии.
3. Затем остальное, с параллельным сбором документации и доказательств, а не в конце.

Шаг 3: оценивайте честно

По каждому направлению: объём работ, исполнители, сроки и стоимость (люди, инструменты, внешняя помощь). Скрытые расходы обычно связаны с последующей эксплуатацией контроля (ежеквартальный обзор — это четыре встречи в год, навсегда), а не с его внедрением.

Шаг 4: назначайте владельцев, которые будут эксплуатировать контроль

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

Шаг 5: определяйте «готово» через доказательства

Задача считается выполненной, когда контроль работает и создаёт доказательства: первый обзор доступа подписан, первая проверка восстановления задокументирована, политика утверждена и доведена до сотрудников. Добавляйте ссылку на доказательство в трекер по мере выполнения: на аудите трекер и есть ваш индекс доказательств.

Разбор на примере

Допустим, компания с сертификатом ISO 27001 должна выполнить требования NIS2. Отчёт о разрывах ISO 27001 → NIS2 сопоставляет каждый пункт NIS2 с чем-то в ISO, но проверка по факту выявляет около дюжины пунктов, выполненных лишь частично. Сгруппированные по способу устранения, они сводятся к четырём направлениям:

• Управление: одобрение руководством мер и обучение руководства (одно заседание, один курс обучения, с фиксацией).
• Отчётность: процедура значительного инцидента со сроками 24 и 72 часа, шаблоны и учения.
• Поставщики: критерии отбора, пункты договоров и обзор двадцати крупнейших поставщиков.
• Техническая глубина: раскрытие уязвимостей, политика криптографии и метрики эффективности.

Четыре владельца, четыре плана, у каждого есть дата и перечень доказательств, вместо дюжины разрозненных строк. Управление и отчётность идут первыми, поскольку надзорные органы спросят о них в первую очередь; техническая глубина следует в течение следующего квартала.

Ключевые выводы

• Группируйте невыполненные требования по тому, что их закроет, а не по номеру требования.
• Сначала управление, область действия и политики: они снимают блокировки для всего остального.
• Назначайте каждому направлению владельца, который будет эксплуатировать контроль.
• Определяйте «готово» как контроль, который работает и создаёт доказательства.

Шаг 6: отчитывайтесь о прогрессе просто

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

Для отправной точки проведите анализ разрывов между стандартом, который у вас есть, и тем, который нужен, и экспортируйте результат. В сравнениях показаны самые распространённые пары в обоих направлениях.

Вопросы

Как расставлять приоритеты для разрывов комплаенса?

По риску и зависимостям: сначала разрывы, которые блокируют другие (управление, область действия, политика), затем высокорисковые технические разрывы, затем документация и доказательства. Нумерация требований — плохой ориентир для порядка.

Кто должен быть владельцем задач по устранению несоответствий комплаенса?

Люди, которые будут эксплуатировать контроль после внедрения, а не команда комплаенса. Комплаенс координирует работу и проверяет доказательства; владельцы контролей выполняют задачи.

Насколько детальным должен быть проектный план по комплаенсу?

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