«Матрица RACI, это не просто таблица в Excel. В контексте регуляторики 152-ФЗ и ФСТЭК её правильное применение превращает хаос распределения ответственности в прозрачную систему. Речь идёт не о том, чтобы назначить роли, а о том, чтобы каждый контроль стал результатом конкретных, а не коллективных действий.»
Суть матрицы RACI: откуда она взялась и почему это не про ITIL
Аббревиатура RACI расшифровывается как Responsible (ответственный), Accountable (подотчётный), Consulted (консультируемый) и Informed (информируемый). Эта модель пришла из мира управления проектами и бизнес-процессами ещё в 70-80-х годах. Она была создана для решения проблемы размытой ответственности, когда задача не выполняется, потому что «все думали, что это сделает кто-то другой».
В IT-регуляторике, особенно вокруг 152-ФЗ и требований ФСТЭК, этот же феномен проявляется ярко. Например, контроль «Регулярное проведение анализа защищённости» может висеть в воздухе: отдел информационной безопасности считает, что его проводит системный администратор, а тот — что это задача ИБ. В итоге контроль не выполняется, а в случае проверки выясняется, что ответственность нигде не закреплена.
Важно понять разницу: RACI, это не про описания должностей из ITIL, хотя пересечения есть. ITIL фокусируется на процессах и функциях (Service Desk, Incident Management), в то время как RACI, это инструмент для чёткого распределения ролей в рамках конкретных задач или, как в нашем случае, контролей. Это практический инструмент для фиксации договорённостей, а не теоретическая модель.
Почему распределение ролей критично для выполнения требований ФСТЭК
Требования регуляторов, будь то ФСТЭК по 152-ФЗ или Центробанк по стандартам, часто сформулированы как обязательные к исполнению меры защиты. Однако в самих документах редко прописано, кто именно и как должен их реализовывать внутри организации. Это создаёт правовой и организационный вакуум.
Без чёткого RACI:
- Контроли дублируются: два отдела тратят ресурсы на одну и ту же работу.
- Контроли выпадают: задача не выполняется, потому что она не назначена никому.
- Возникает ситуация коллективной безответственности: при сбое виноватых нет, есть только пострадавшие.
- Процесс аудита или проверки превращается в хаотичный поиск виноватых, а не в оценку зрелости процессов.
Матрица RACI заполняет этот пробел. Она формализует негласные договорённости, делая процесс исполнения требований управляемым и доказуемым.
Буква за буквой: расшифровка ролей в контексте ИБ
Ключ к успеху — правильное понимание каждой роли не в общем, а именно применительно к контролю информационной безопасности.
R — Responsible (Исполнитель)
Это лицо или роль, которое непосредственно выполняет работу. В одном контроле может быть несколько R. Например, для контроля «Установка обновлений безопасности» R, это системные администраторы для серверов Windows и Linux, администраторы СУБД для баз данных. Они физически нажимают кнопки, выполняют скрипты, проверяют установку.
A — Accountable (Подотчётный, Утверждающий)
Самая важная и часто путаемая роль. Это лицо, которое несёт конечную ответственность за то, что контроль выполнен правильно и в срок. На одного контроль — только один A. Если R не выполнил работу, именно A несёт за это дисциплинарную или управленческую ответственность. В контексте ИБ это часто руководитель направления, начальник отдела ИБ или ответственный за систему защиты информации (РЗИ). A утверждает результаты работы R.
C — Consulted (Консультант)
Лица, чьё мнение необходимо запросить перед выполнением или при выполнении контроля. Это двусторонняя коммуникация. Например, перед изменением правил межсетевого экрана (контроль «Актуализация правил фильтрации») R обязан проконсультироваться с владельцем бизнес-сервиса (C), чтобы изменение не нарушило рабочие процессы.
I — Informed (Информируемый)
Лица, которых необходимо уведомить о результате выполнения контроля. Коммуникация односторонняя. Например, после отработки инцидента (контроль «Регистрация и анализ инцидентов ИБ») отдел внутреннего аудита (I) получает отчёт для включения в свою программу проверок.
От теории к практике: пошаговая сборка матрицы для пакета контролей
Создание матрицы RACI, это процесс, а не разовое действие.
Шаг 1: Определение списка контролей
Выберите фокус. Не пытайтесь охватить все процессы ИБ сразу. Начните с критичного блока, например, с контролей из требований ФСТЭК к системе защиты информации (СЗИ) или с процессов управления инцидентами. Выпишите их в первый столбец будущей матрицы в виде конкретных, измеримых действий: «Ежеквартальное обновление антивирусных баз», «Проведение вводного инструктажа по ИБ для новых сотрудников», «Анализ журналов событий на критичных серверах».
Шаг 2: Выявление всех вовлечённых ролей
Составьте список всех отделов и должностей, которые могут быть связаны с выбранными контролями. Не ограничивайтесь отделом ИБ. Включите системное администрирование, сетевое администрирование, службу персонала, юридический отдел, внутренний аудит, владельцев бизнес-приложений. Эти роли станут заголовками столбцов матрицы.
Шаг 3: Заполнение ячеек — правила и ловушки
Для каждого контроля на пересечении с каждой ролью проставьте одну из букв: R, A, C, I или оставьте пусто (если роль не вовлечена). Придерживайтесь строгих правил:
- На один контроль — минимум один R и ровно один A.
- R и A могут быть одной и той же персоной для простых задач, но для критичных контролей это разводит ответственность — A должен быть на уровень выше.
- Не превращайте всех в C и I. Избыточные консультации и уведомления парализуют процесс. Задавайте вопрос: «Можно ли выполнить этот контроль, не пообщавшись с этой ролью? Если да — она не C».
Основная ловушка — назначение A на основе должности, а не компетенций. Если A — директор по ИТ, который не разбирается в тонкостях криптографии, он не сможет нести реальную ответственность за контроль «Проверка целостности ключей шифрования». A должен иметь полномочия и знания, чтобы проверить работу R.
Шаг 4: Валидация и согласование
Собранную матрицу нельзя просто спустить сверху. Её необходимо обсудить со всеми назначенными ролями. Проведите рабочую встречу, где представите матрицу и получите обратную связь. Часто на этом этапе выясняется, что роль, назначенная как R, не имеет технической возможности выполнить контроль, или C-роль требует более раннего уведомления. Это нормальная часть процесса — внесите коррективы.
Шаг 5: Публикация и интеграция в процессы
Утверждённая матрица должна перестать быть просто файлом. Интегрируйте её в систему управления процессами ИБ. Назначение A и R можно зафиксировать в системе Service Desk или ITSM как ответственных за соответствующие задачи. Роли C и I могут быть указаны в регламентах процедур. Матрица становится живым документом, на который ссылаются при планировании работ, в ходе аудитов и при расследовании инцидентов.
Распространённые ошибки и как их избежать
Даже при понимании теории на практике возникают типичные провалы.
- Множество A на один контроль. Если ответственность разделена, она исчезает. Жёстко следите за правилом «один A».
- R без полномочий. Назначили системному администратору (R) контроль «Принудительное отключение учётных записей при увольнении», но у него нет доступа к HR-системе для получения оперативных данных. R должен иметь доступ ко всем необходимым ресурсам для выполнения задачи.
- Матрица как мёртвый документ. Самая частая ошибка. Матрицу составили, положили в папку и забыли. Пересматривайте её минимум раз в год или при любых организационных изменениях: слияниях, реорганизациях, внедрении новых систем.
- Путаница между C и I. Консультанта (C) нужно спрашивать до действия, его мнение может повлиять на решение. Информируемого (I) просто ставят перед фактом после. Если путать эти роли, можно либо затягивать процессы ненужными согласованиями, либо, наоборот, принимать решения, не получив критически важной информации.
RACI как инструмент для аудита и демонстрации зрелости
Для проверяющих из ФСТЭК или внутреннего аудита грамотно составленная и действующая матрица RACI — мощный аргумент в пользу зрелости системы управления информационной безопасностью.
Она демонстрирует, что организация:
- Осознаёт свои процессы на уровне распределения ответственности.
- Имеет формализованные процедуры взаимодействия между подразделениями.
- Может чётко показать, кто за что отвечает в каждом конкретном контрольном действии.
При проверке вас могут попросить продемонстрировать, как выполняется тот или иной контроль. Наличие матрицы позволяет не метаться в поисках ответственного, а сразу предъявить схему: исполнитель (R) выполнил работу, результаты утверждены подотчётным (A), с консультантами (C) согласовано, информируемые (I) уведомлены. Это структурирует диалог с проверяющими и снижает операционные риски.
В конечном счёте, матрица RACI, это не о составлении таблиц. Это о внедрении культуры чётких обязательств и прозрачности. В регуляторной среде, где цена ошибки высока, такая культура превращается из рекомендации в необходимость.