Журнал "Information Security/ Информационная безопасность" #2, 2026

у разных функциональных владельцев. Результатом выполнения данного этапа становится матрица применимых требо- ваний. После этого требования переводятся в процессную плоскость: для каждого из них назначается ответственный, зада- ется периодичность проверки исполне- ния, определяется ожидаемый результат, способ контроля и подтверждающий цифровой артефакт. На практике в первую очередь целе- сообразно автоматизировать те процес- сы, в которых критичны регулярность исполнения, контроль сроков и наличие подтверждений. К ним обычно относятся учет активов, классификация и катего- рирование, моделирование угроз, управ- ление доступом, регистрация событий безопасности, реагирование на инци- денты, управление уязвимостями, внут- ренний контроль, исполнение корректи- рующих мероприятий, резервное копи- рование. При этом успех автоматизации во многом зависит от текущего уровня зре- лости процессов в организации. Если сам процесс не описан, не закреплен за владельцем и не имеет понятных крите- риев исполнения, автоматизировать, по сути, нечего. Зрелая модель автоматизации Когда основа процесса выстроена, можно переходить к технологической реализации. На этом этапе важно не просто выбрать новый инструмент, а понять, какие системы уже исполь- зуются в компании и как они могут быть встроены в контур соответствия. Это могут быть системы управления досту- пом, конфигурациями, уязвимостями, инцидентами, событиями безопасности, сервис-дески и другие источники, кото- рые не только поддерживают исполнение требований, но и формируют доказа- тельства их реализации. Архитектурно зрелая модель автома- тизации обычно включает несколько взаимосвязанных уровней: l нормативный – библиотека требова- ний, где каждому требованию сопостав- лены процессы, ответственные лица, сроки исполнения, доказательства и контрольные процедуры; l организационный – маршруты согла- сования и workflow для заявок, пере- смотров, проверок, расследований и кор- ректирующих действий; l технический – интеграции с IAM, IdM, SIEM, CMDB, сканерами уязвимостей и другими системами; l отчетный – дашборды, журналы несо- ответствий, карточки систем и другие инструменты управленческой прозрач- ности. Изменение подготовки к проверкам При ручной модели любой запрос (от аудитора, заказчика, регулятора или в рамках расследования инцидента) часто запускает отдельную активность по сбору подтверждающих материалов. Документы приходится искать в почте, на файловых ресурсах, в таблицах и локальных папках. Это занимает время и создает высокий риск того, что часть подтверждений окажется неполной, уста- ревшей или вообще не будет найдена. При автоматизированной модели ком- плект подтверждающих материалов фор- мируется в ходе текущей деятельности: заявки, согласования, результаты про- верок, журналы событий, статусы кор- ректирующих мероприятий и другие артефакты централизованно сохраняют- ся и связываются с конкретными требо- ваниями. Благодаря этому подготовка к проверке перестает быть авральной задачей и становится естественным результатом корректно выстроенного процесса. Что важно учесть помимо автоматизации? Автоматизация не достигает своей цели, если не дает руководству понятной картины происходящего. Важным эле- ментом зрелой модели являются управ- ленческие метрики, позволяющие оце- нить состояние соответствия не на уровне общих формулировок, а через конкрет- ные показатели. К таким показателям могут относиться доля пользователей с несвоевременным пересмотром прав, полнота покрытия источников журнали- рования, количество критических уязви- мостей, не устраненных в установленный срок, время подготовки пакета докумен- тов по запросу регулятора, число про- цессов обработки персональных данных, не связанных с актуальными правовыми основаниями. Подобные метрики помо- гают видеть реальные зоны риска, свое- временно выявлять отклонения и прини- мать решения на основе реальных дан- ных, а не только экспертных суждений. При всех преимуществах автоматиза- ция не является универ- сальным решением и не снимает ответственности с руководителей и вла- дельцев процессов. Соот- ветствие требованиям нельзя приобрести как готовое техниче- ское решение – его можно выстроить только как систему, в которой регламент реализуется через выполнение обяза- тельных этапов, прохождение контроль- ных точек и сбор подтверждающих арте- фактов, а отклонения от предъявляемых требований выявляются в момент воз- никновения, а не накануне проверки. Кроме того, нормативная база в сфере ИБ постоянно меняется, поэтому в кон- туре соответствия необходим отдельный процесс мониторинга регуляторных изменений: оценки применимости новых требований, обновления шаблонов доку- ментов, постановки задач на доработку процессов и пересмотра контрольных процедур. Без этого даже хорошо настроенная система со временем теряет актуальность. Наиболее успешными оказываются те проекты, где автоматизация рассматри- вается не как задача одной функции, а как совместная работа ИБ, ИТ, юриди- ческой службы, HR, внутреннего конт- роля и владельцев бизнес-систем. Толь- ко в этом случае требования перестают существовать отдельно от операционной деятельности и становятся частью реаль- ного управления компанией. Поэтому рынок постепенно смещается от локаль- ной автоматизации отдельных задач к SGRC-моделям, где соответствие тре- бованиям рассматривается как непре- рывный управляемый процесс, связан- ный с рисками, ИТ-активами, бизнес- функциями и жизненным циклом систем. Автоматизация соответствия требо- ваниям – это не внедрение отдельного инструмента, а переход к модели, в кото- рой обеспечивается связь между зако- нодательной нормой, действием, конт- ролем и подтверждением. В результате комплаенс перестает быть набором раз- розненных документов и становится сквозным, наблюдаемым и управляемым процессом. l • 71 УПРАВЛЕНИЕ www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ АМТ-ГРУП см. стр. 78 NM Реклама