RACI: как построить матрицу ответственности при утечке данных

RACI — это простой способ распределить ответственность между людьми.

Аббревиатура состоит из четырёх ролей:

R (Responsible) — тот, кто делает работу
A (Accountable) — тот, кто отвечает за итоговое решение и результат
C (Consulted) — те, кого нужно подключить за советом или дополнительной информацией
I (Informed) — те, кого нужно держать в курсе происходящего

Такой подход помогает убрать путаницу: каждый знает, что именно он делает, кто принимает решение и кому передавать информацию дальше.

При утечке данных это особенно важно. Скорость реакции напрямую снижает ущерб и помогает выполнить обязательства перед пользователями и регуляторами.

Как RACI применима к инцидент-менеджменту

RACI помогает выстроить управление инцидентом в логичный и прозрачный процесс. В основе матрицы лежит несколько принципов.

1. Один ответственный за результат (A) на каждую задачу

В кризисе нельзя оставлять «коллективную ответственность». Если два руководителя отвечают за одно решение, возникает задержка. Каждый считает, что второй тоже может принять решение.

Например, при утечке никто не понимает, кто должен утвердить уведомление клиентам. Текст письма готов, но его согласование занимает часы. Если роль A назначена заранее, письмо уходит вовремя, и компания снижает риск недовольства пользователей.

2. Разграничение: те, кто делает работу (R), и те, кто согласовывает решения (A)

Например, техническая команда может начать изоляцию серверов сразу, если это её зона ответственности. Ей не нужно ждать одобрения, если решение уже прописано в RACI. Руководитель, который назначен A, подтверждает только итоговый шаг: что делать дальше, какие сервисы восстанавливать и в каком порядке. Это помогает не перегружать руководителей мелкими задачами и ускоряет реакцию.

3. Роли консультантов (C) и информируемых (I)

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

Благодаря таким принципам RACI упрощает процесс реагирования: каждый понимает свою роль, решения принимаются без задержек.

RACI для сценария утечки данных — пошагово

— Соберите список сценариев и задач

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

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

Например: «изолировать сервер», «подготовить технический отчёт», «согласовать текст уведомления клиентам», «уведомить регулятор в срок». Чем конкретнее список, тем проще назначать роли и проверять исполнение.

— Определите минимальный набор ролей

Выделите реальные роли в вашей компании: владелец бизнеса, CISO или ответственный за безопасность, IT-инженер, юрист, PR/коммуникации, служба поддержки, ответственный за работу с подрядчиками.

Если в компании роли не совпадают с должностями, используйте функции: «тот, кто утверждает коммуникацию», «тот, кто изолирует систему», «тот, кто собирает логи». Не создавайте лишних ролей — это только усложнит работу.

В малом бизнесе многие роли могут выполнять одни и те же люди, но важно прописать, кто в каждом случае принимает ключевое решение.

— Назначьте R/A/C/I для каждой задачи

Заполните матрицу: для каждой задачи укажите:

R (кто выполняет)
A (кто отвечает за результат)
C (кого нужно спросить/подключить)
I (кого оповестить)

Стремитесь к правилу «один A» — это ключ.

— Протестируйте матрицу на учебном сценарии

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

Проверяйте: все ли знают свои контакты, достаточно ли полномочий у R для действий, не мешают ли друг другу назначенные роли.

— Утвердите и опубликуйте матрицу

После теста внесите правки, утвердите матрицу на уровне руководства. Раздайте доступ всем вовлечённым: храните файл в централизованном месте, укажите резервные контакты и порядок эскалации.

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

FAQ — ответы на частые вопросы

Можно ли назначать одного человека на несколько ролей?

Можно, но с оговорками. В малом бизнесе один и тот же человек часто выполняет несколько функций: владелец может быть и A по коммуникации, и I по техническим задачам. Это нормально, если решения простые и вероятность серьёзного инцидента низкая.

Нельзя совмещать роли, когда они конфликтуют по логике принятия решения. Например, один человек не должен одновременно быть R (выполняет работу) и A (утверждает результат) для одной и той же критичной задачи, где объективность важна — уведомление регулятора, юридические решения, внешняя пресс-коммуникация.

Каких ошибок избегать при создании RACI?

Назначение нескольких A на одну задачу — приводит к затягиванию решений.
Слишком много R — когда в задаче участвует целая группа без ясных обязанностей.
Не учет подрядчиков и аутсорсеров в матрице.
Отсутствие резервных контактов и каналов связи.
Фиксация только на бумаге, без тестов и обновлений.

Как фиксировать ответственность и проводить ревизию ролей?

Фиксация должна быть простой и надёжной. Включите в матрицу контактные данные: рабочий телефон, резервный номер, e-mail, время, когда человек доступен. Храните матрицу в централизованном репозитории с версионированием (корпоративный диск, внутренний портал). В документе укажите порядок эскалации: кто следующий, если основной контакт не отвечает через оговоренное время.

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

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

Следите за: