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

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

Рабочий реестр: от обсуждения к управлению

Карта рисков должна помогать вернуться к вопросу: что известно, что решили и кто отвечает. Для этого достаточно простого реестра.

Поле

Что записать

Цель

Какое важное обязательство или результат компании затрагивается

Сценарий

Конкретная цепочка «причина — событие — последствия»

Причины

Условия и факторы, которые могут привести к событию

Последствия

Что пострадает: сроки, деньги, безопасность, закон, репутация, непрерывность

Действующие меры

Что уже снижает вероятность или ущерб и насколько это проверено

Оценка

Вероятность, последствия, уязвимость, скорость развития; уровень уверенности

Владелец

Руководитель, который отслеживает риск и организует решения

Решение

Снизить, передать, принять или избегать риск; конкретные действия

Срок пересмотра

Дата или событие, после которого оценку нужно обновить

Вот как могли бы выглядеть записи «ТерраФуд»:

• Цель: выполнить заказы торговых сетей. Сценарий: остановка единственного одобренного поставщика упаковки приводит к нехватке материала и задержке выпуска. Причины: высокая концентрация закупок, длительное одобрение альтернативы. Последствия: простой и невыполненные поставки. Действующие меры: запас на несколько дней, неформальные контакты с другим производителем. Оценка: вероятность средняя или высокая; последствия высокие; уязвимость высокая; времени на реакцию мало. Владелец: директор по снабжению. Решение: снизить. Пересмотр: через месяц или после испытания альтернативного поставщика.

• Цель: сохранять управляемость отгрузок и прослеживаемость продукции. Сценарий: компрометация учётных данных блокирует доступ к системе заказов. Причины: фишинг и непроверенное восстановление из резервной копии. Последствия: задержки, ошибки в отгрузках, затруднение поиска информации о партиях. Действующие меры: резервное копирование, многофакторная аутентификация для части систем. Оценка: вероятность оценена с невысокой уверенностью; последствия очень высокие; скорость развития высокая. Владелец: ИТ-директор. Решение: снизить. Пересмотр: после теста восстановления и проверки доступа.

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

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

Шаг пятый. Расставьте приоритеты и выберите ответ

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

Для каждого риска компания выбирает один из четырёх основных ответов.

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

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

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

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

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

Когда карта становится планом

На следующем совещании «ТерраФуд» обсуждала уже не сорок три угрозы. На столе лежали три сценария, для каждого были названы владелец и ближайший шаг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс

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

Исполнитель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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