Бизнес под контролем: Как выстроить безопасность и сохранить устойчивость компании

Система управления безопасностью: роли, полномочия и ответственность

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

У каждого есть начальник. У каждого есть веская причина не принимать чужое решение. А данные продолжают уходить.

Никто не бездействует намеренно. Сотрудники сообщили о подозрении, руководитель передал информацию, ИТ проверило техническую сторону, служба безопасности оценила риск. Но компания не ответила на главный вопрос: кто вправе превратить оценку в действие? Именно здесь становится заметно различие между набором специалистов и системой управления. Специалисты могут быть опытными и добросовестными, но без ясных полномочий их работа похожа на спасательную команду, у которой есть оборудование, но нет права войти в здание.

Когда ответственность ходит по кругу

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

Это не одно и то же. На схеме может быть директор по безопасности, руководитель ИТ и несколько владельцев процессов. Но если ни одному из них не поручено остановить подозрительную операцию, схема не поможет в момент тревоги. Она лишь подскажет, кому отправить ещё одно письмо.

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

Чтобы разорвать её, нужно заранее договориться о четырёх вещах:

1. Кто решает — в том числе кто принимает остаточный риск.

2. Кто действует — кто выполняет контроль или запускает ответные меры.

3. Кто помогает — чьё мнение необходимо для качественного решения.

4. Кто отвечает за результат — кто следит, чтобы вопрос не потерялся между подразделениями.

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

Безопасность — общая функция, а не чужой отдел

Ни одна профильная служба не может в одиночку управлять всеми рисками бизнеса. Служба безопасности не знает всех нюансов клиентского процесса. ИТ не всегда вправе решать, какой перерыв в работе допустим. Юристы не могут принять коммерческий риск вместо владельца продукта. А руководитель подразделения не обязан сам разбираться в настройках технических средств, чтобы понимать последствия решения.

Работающая модель распределяет роли.

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

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

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

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

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

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

Матрица, которая отвечает на практические вопросы

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

• Владелец решения утверждает решение и отвечает, чтобы оно было принято в срок.

• Исполнитель делает работу.

• Консультируемые дают необходимые сведения до решения.

• Информируемые получают информацию после него или по мере развития ситуации.

• Независимый проверяющий оценивает качество процесса отдельно от его исполнителей.

Для каждой конкретной развилки должен быть один ясно названный владелец решения. Если решение зависит от уровня серьёзности, заранее записывают, кому принадлежит право на каждом уровне.

Процесс

Владелец решения и результата

Исполнитель

Кого консультируют

Кого информируют

Независимая проверка

Утверждение правил безопасности

Руководство в пределах корпоративных полномочий

Служба безопасности готовит и поддерживает правила

Владельцы процессов, ИТ, юристы, HR

Руководителей и сотрудников, которых затрагивают правила

Внутренний аудит или контрольная функция

Принятие исключения из правила

Владелец процесса в пределах делегированного риска; выше установленного порога — руководитель соответствующего уровня

Владелец процесса оформляет решение и условия; профильные команды выполняют меры

Безопасность, ИТ, юристы, финансы — по характеру риска

Руководство и затронутые команды

Независимая проверка периодически оценивает исключения

Внедрение меры защиты

Владелец процесса подтверждает требование и приемлемость изменений

ИТ или назначенная операционная команда

Безопасность, пользователи, поставщик решения

Заинтересованные подразделения

Контрольная функция проверяет выбранные меры

Реагирование на подозрительную активность

Назначенный руководитель инцидента — в рамках заранее делегированных полномочий

ИТ и профильные команды локализуют проблему; владелец процесса организует работу бизнеса

Безопасность, юристы, коммуникации — по необходимости

Руководство, затронутые подразделения и другие стороны по установленным правилам

После инцидента проводится независимый разбор

Проверка восстановления и готовности

Владелец процесса отвечает за результат восстановления

ИТ и операционные команды восстанавливают сервис и подтверждают его работоспособность

Безопасность и пользователи процесса

Руководство и зависимые подразделения

Аудит или отдельная контрольная проверка

У матрицы есть важное ограничение: она не заменяет договорённости и связь. Документ, который лежит в папке, недоступной ночью, — не механизм управления. Если в нём указана фамилия человека, ушедшего из компании полгода назад, — это уже исторический документ. Матрица полезна лишь тогда, когда люди знают, где её найти, понимают свои полномочия и могут связаться с нужным человеком.

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

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

Полномочия на остановку и правила эскалации

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

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

Для этого в регламенте указывают:

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

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

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

4. Эскалацию. Если основной контакт недоступен, обращение сразу переходит заместителю или дежурной роли, а не зависает в ожидании одного человека.

5. Условия остановки и возобновления. Кто вправе применить временное ограничение, кто оценивает последствия и кто снимает его.

6. Замещение. Для каждой ключевой роли назначают заместителя с достаточными полномочиями и доступом к необходимой информации.

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

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

Управление должно жить в календаре и бюджете

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

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

Бюджетирование — ещё одна проверка серьёзности намерений. Если компания считает снижение риска важным, ресурсы на меры и обучение должны появляться в планировании, а не возникать только после инцидента. Владелец процесса объясняет, чего стоит непринятый риск; профильная функция — какие меры доступны; руководство сопоставляет затраты с возможными последствиями.

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

Проверка модели на коротком сценарии

Вернёмся к выгрузке из клиентской системы. Теперь у компании есть заранее согласованные правила. Сотрудница сообщает о подозрительной активности через дежурный канал и сразу получает подтверждение. Дежурный специалист безопасности оценивает признаки и по установленному порогу временно приостанавливает выгрузку. ИТ проверяет учетную запись и ограничивает её доступ. Владелец клиентского процесса получает информацию и оценивает, какие операции могут пострадать. Если ограничение затрагивает критичный сервис сверх его полномочий, вопрос немедленно передают назначенному руководителю инцидента.

Подозрение не подтвердилось: выгрузку инициировал сотрудник для согласованной задачи, но использовал необычный способ. Команда фиксирует это, восстанавливает доступ после проверки и корректирует описание нормальных операций, чтобы в следующий раз отличить рабочее действие от опасного. Никто не обвиняет коллегу в лишней осторожности, а ИТ не приходится угадывать, можно ли выключить учетную запись. Скорость появилась не благодаря героизму, а благодаря заранее выданным полномочиям.

Практическая проверка для руководителя

Выберите один процесс, остановка которого заметно повредит компании: платежи, обработку заказов, клиентскую поддержку, производство или работу с чувствительной информацией. За 30–45 минут вместе с владельцем процесса, ИТ и службой безопасности ответьте на вопросы:

• Кто принимает риск, если предложенные меры не внедрены?

• Кто утверждает правила и исключения из них?

• Кто выполняет меры защиты и кто проверяет, что они работают?

• Кто вправе временно остановить опасную операцию?

• Кто разрешает её возобновить?

• Кому и как сообщают о проблеме вне рабочего времени?

• Кто замещает каждого ключевого участника?

• Что произойдёт, если основной контакт не ответит?

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

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