Как собрать единую матрицу требований за три дня: план для IT-безопасности

"За три дня построить матрицу нельзя, но можно собрать всё в одном месте и навести порядок, после чего начинается настоящая работа".

Каждый разработчик в российском IT, связанный с регуляторикой, сталкивался с хаосом требований. Требования ФСТЭК из разных приказов, 152-ФЗ, отраслевые стандарты и внутренние политики компании — всё это существует в разрозненных документах, таблицах и головах сотрудников. Попытка провести аудит или внедрить новый процесс превращается в долгий поиск: где у нас прописана настройка журналирования? Какой именно приказ ФСТЭК регулирует криптографическую защиту каналов связи? На согласование одного пункта уходит неделя.

Единая матрица требований, это не идеальная таблица на все случаи жизни. Это живой инструмент, который показывает, какие требования к какой системе или процессу применяются, кто за них отвечает и в каком они состоянии. Главная её цель — убрать неопределённость и перестать тратить время на поиск.

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

Почему стандартные подходы не работают

Попытки построить матрицу «правильно» с самого начала обычно проваливаются. Собирается рабочая группа, начинаются бесконечные дискуссии о структуре, формате полей, методиках сопоставления. Проект растягивается на месяцы, а на выходе получается громоздкий документ, который никто не хочет актуализировать.

Частая ошибка — начинать с детального анализа каждого требования. Вы пытаетесь разобраться в нюансах 187-го приказа ФСТЭК, пока не поняли, к каким бизнес-процессам вашей компании он вообще относится. Это как собирать мебель, не имея инструкции и понимая, для какой комнаты она предназначена.

Другой тупик — попытка учесть абсолютно все источники требований сразу. Вы добавляете в матрицу не только 152-ФЗ и приказы ФСТЭК, но и рекомендации ЦБ, ГОСТы, внутренние стандарты группы компаний. Объём работы становится необъятным, энтузиазм угасает.

Третий день следует потратить на то, что даст немедленный результат.

День первый: инвентаризация и первичная структура

Цель первого дня — собрать все «кирпичики» в одну кучу и наметить каркас. Не нужно ничего анализировать глубоко.

1. Собрать источники. Не ищите «все требования». Соберите документы, которые уже используются в работе:

   • Ключевые приказы ФСТЭК (например, № 21, 17, 239).
   • Текст 152-ФЗ с актуальными изменениями.
   • Внутренние политики информационной безопасности.
   • Регламенты и инструкции по администрированию.
   • Отчёты прошлых аудитов или проверок. Создайте общую папку и сбросьте туда все PDF, Word-файлы и ссылки. Это ваша сырая база.

2. Определить области (домены). Разделите свою ИТ-инфраструктуру и процессы на крупные логические блоки. Не усложняйте. Например:

   • Периметр (межсетевые экраны, VPN).
   • Криптография (средства шифрования, ЭП).
   • Управление доступом (учётные записи, Active Directory).
   • Защита от вредоносного кода.
   • Резервное копирование и восстановление.
   • Инцидент-менеджмент. Эти области станут столбцами или отдельными листами в вашей матрице.

3. Выбрать инструмент и создать шаблон. Не изобретайте сложные системы. Возьмите Excel или Google-таблицы. Создайте простейшую структуру:

   • Столбец «Требование» (текст требования).
   • Столбел «Источник» (ссылка на документ и пункт).
   • Столбец «Область применения» (к какому домену относится).
   • Столбец «Ответственный».
   • Столбец «Статус» (Пусто/В работе/Выполнено/Не применимо). Этого достаточно для старта. Не добавляйте больше пяти столбцов.

День второй: наполнение и первичное сопоставление

Сегодня нужно быстро заполнить матрицу, не погружаясь в детали.

1. Распределите требования по областям. Берите документы из папки и бегло просматривайте. Каждый пункт, который хоть как-то касается ваших доменов, выносите в отдельную строку матрицы. Не пытайтесь перефразировать или объединять — копируйте текст «как есть» и указывайте источник. Цель — выгрузить всё из документов в структурированное поле. Пусть строк будет 200 или 300 — не страшно.

2. Проставьте предварительных ответственных. Для каждой строки задайте вопрос: кто в компании в принципе может отвечать за эту тему? Не ищете точного человека, а определяете роль или отдел: «Администраторы ИБ», «Сетевая команда», «Команда разработки». Это создаст первичные точки ответственности.

3. Пометьте очевидные статусы. Некоторые требования будут явно невыполненными или, наоборот, давно реализованными. Смело ставьте «Не применимо», если требование явно не касается вашей инфраструктуры, или «Выполнено», если уверены на 100%. Остальное оставляйте пустым.

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

День третий: фокус на главное и первые действия

Последний день нужен для того, чтобы матрица начала работать, а не стала очередным архивом.

1. Выявите белые пятна. Отсортируйте таблицу по столбцу «Ответственный». Всё, что осталось без владельца, — ваши главные риски. Соберите руководителей отделов и распределите эти пункты. Не обязательно искать идеального кандидата — важно, чтобы каждая строчка была на контроле у кого-то.

2. Определите quick wins. Отсортируйте по статусу «Пусто». Найдите среди них требования, которые можно закрыть быстро и с минимальными затратами: обновить политику, настроить уже имеющееся средство, провести инструктаж. Сформируйте из них список на ближайшую неделю. Это даст быстрое ощущение прогресса.

3. Назначьте хранителя. Матрица будет умирать без человека, который её обновляет. Назначьте ответственного (часто это специалист по ИБ или архитектор), кто будет вносить изменения при появлении новых требований, смене ответственных или изменении статусов. Установите простой регламент: раз в месяц проверять актуальность.

4. Интегрируйте в процессы. Чтобы матрица не стала отдельным файлом, привяжите её к существующим процедурам. Например, при запуске нового проекта — проверять, какие требования из матрицы к нему применимы. При смене ответственного — передавать ему его строки в матрице. При внутреннем аудите — использовать матрицу как чек-лист.

Чего не стоит делать в эти три дня

• Не углубляйтесь в детализацию. Не тратьте время на написание методик выполнения, создание сложных атрибутов или интеграцию с системами ticketing.
• Не стремитесь к автоматизации. Попытки сразу подключить скрипты для парсинга документов или создания дашбордов съедят все время. Сначала нужна ручная, но полная картина.
• Не пытайтесь добиться идеальной чистоты. Допустимы дубли, не совсем точные формулировки. Главное — собрать всё. Чистку можно провести позже, на основе работающей матрицы.
• Не делайте её закрытой. Матрица должна быть доступна всем ключевым специалистам. Скрытый файл на локальном диске — гарантия её скорой смерти.

Результат трёхдневного спринта — не идеальная система, а рабочий инструмент, который переводит разговоры о «много требований» в конкретные строки с владельцами и статусами. Он покажет реальный масштаб, выявит зоны неопределённости и даст план первых шагов. Всё остальное — детализация, автоматизация, интеграция, это уже следующий этап, который имеет смысл начинать, когда основа уже создана и приносит пользу.