0. Начало
Управление непрерывностью бизнеса (BCM — business continuity management) — большая тема, достойная отдельной книги.
В этой статье я приведу базовый подход к BCM, который может пригодиться небольшим и средним компаниям, например работающим в ИТ области.
Классическая структура документации BCM:
Чтобы ориентироваться в терминах, см. BCM — термины, примеры disruptions.
1. Политика управления непрерывностью бизнеса
Для совсем небольших компаний политику можно совместить с процедурой. Но для компаний побольше, а также компаний, имеющих постоянный контакт с зарубежными партнерами — лучше иметь краткую и лаконичную политику.
В Политике BCM нужно прописать:
- роли, ответственности, область действия;
- правила — что должен сделать каждый из офисов компании, либо каждое из подразделений (если речь идет о компании с одним офисом);
вот примерный список обязательных действий: определить что защищать, до какого уровня, определить общую стратегию по защите, разработать собственно сами процедуры по защите;
- желательно упомянуть про необходимость соответствовать локальному законодательству, об интеграции с BCP планами поставщиков и вендоров;
2. Процедура управления непрерывностью бизнеса
В процедуре расписываем детали, как же мы будем все внедрять.
Я предлагаю упрощенный процесс BCM:
2.1 Business Impact Analysis — BIA
Первым шагом BIA является определение критичных бизнес-процессов и активов.
Это анализ, и результат анализа — информация для определения, что же на самом деле стоит защищать от прерываний. См. пример результата BIA:
BCP активности — чрезвычайно доргостоящи, и поэтому важно точно определить границы нашей защиты, и приоритет защищаемых активов. Когда начинаешь просчитывать MTD, RTO (см. BCM — термины, примеры disruptions), отвечать на вопросы про количество затронутых пользователей, то мозги прочищаются, и вырисовывается четкая картинка — что же реально важно для бизнеса.
Некоторые рекомендации по проведению грамотного BIA:
- Необходимо организовать совещание с участием ключевых руководителей со стороны бизнеса и поддерживающих подразделений (сотрудники HR и IT отделов, менеджер ИБ, юрист и т.п.)
- Организатор совещания (лучше всего, если это будет кто-то из ключевых руководителей) готовит предварительную версию документа BIA, заполнив список критических бизнес-процессов и активов офиса на свое усмотрение;
- Во время совещания, участники уточняют данный список, проводят детальный анализ для каждого из пунктов.
- По результатам, принимается решение о необходимости разработки защитных/превентивных мер. В случае положительного решения, данный бизнес-процесс/актив в дальнейшем обрабатывается в Плане обеспечения непрерывности бизнеса офиса Компании.
Как правило, требуется несколько подобных совещаний для завершения BIA.
2.2 Risk Analysis — RA
Анализ рисков (RA) относится к области технической защиты информации, в отличие от BIA. BIA анализирует прерывания с точки зрения бизнеса и позволяет выработать стратегию по управлению непрерывностью бизнеса.
А процесс RA в свою очередь, основывается на результатах BIA и осуществляет технический анализ, что позволяет определить технические особенности внедрения.
Что делаем в рамках RA:
- оценивается стоимость активов;
- идентифицируются угрозы и уязвимости активов;
- разрабатываются защитные/превентивные меры для выбранных активов (которые в дальнейшем могут быть включены в Планы по обеспечению непрерывности бизнеса).
Если в компании уже имеется внедренный процесс управления рисками, то нужно полностью задействовать его. Если нет, то — внедрить:) Вообще, сейчас даже ИСО 9001 требует внедренного процесса управления рисками.
В процессе RA необходимо ориентироваться на предпочтительный уровень риска (risk appetite, см. BCM — термины, примеры disruptions).
2.3 Стратегия управления непрерывностью бизнеса
Имея результаты проведенных BIA и RA, руководство принимает решение по каким ситуациям (бизнес-процессам/активам и соответствующим рискам) следует разрабатывать Планы по обеспечению непрерывности.
В общем случае существуют две стратегии:
- использование различных защитных/превентивных мер;
- дублирование ИС (в том числе использование альтернативных площадок).
Помните понятия RTO и MTD?
Так вот, если RTO = 8 ч., то сотрудники ИТ отдела скорее всего успеют переустановить системное ПО и восстановить данные из резервных копий. Если RTO = 1ч., то здесь наверняка потребуются дублирующие системы и компоненты (что гораздо дороже, чем восстановление данных из резервных копий).
Бывает, что руководство выставляет RTO в пару часов, но узнав стоимость мер по поддержанию такой цифры, быстро сдувается до 8-24 часов:)
Итак, определив стратегию, приступаем к написанию самих планов BCP.
2.4 Разработка и внедрение планов BCP
После предыдущих шагов, обычно в голове складывается список необходимых действий. Лучше создать стандартную структуру (шаблон) плана BCP, и разложить в ней всю накопившуюся информацию.
В планах BCP должны быть рассмотрены:
- первоначальные шаги по реагированию на любые кризисные события (когда еще неизвестно, какую конкретно процедуру плана BCP нужно будет запускать); обычно это сбор ключевых сотрудников (команды BCP), информирование руководства и др.
- критерии активации и деактивации плана;
- детальные процедуры по восстановлению для каждого из кризисных событий; можно разместить их в виде приложений к плану;
- критерии успешности процедуры восстановления;
- процедура тестирования плана BCP;
- полезные контакты, практики, ссылки и т.д.
Пример содержимого документа:
Не забудьте про требования локального законодательства — оно всегда имеет приоритет перед любыми политиками компании. Если у компании тесные связи с вендорами/подрядчиками, то лучше бы добиться существования планов BCP и у них, и синхронизировать общие действия.
Разработанный план должен быть утвержден (буквально подписан) руководством компании. Хранить документ лушче не только в эл. виде, но и в бумажном, размещенным в надежных местах (сейф в кабинете директора, в бухгалтерии). В случае необходимости, каждый вовлеченный член команды BCP должен иметь беспрепятственный доступ к документу.
После разработки, план BCP должен быть внедрен (!) А то ведь некоторые забывают:)
Как внедрять? Я рекомендую на проектной основе. См. об этом в посте Внедрение процессов и практик.
2.5 Тестирование и мониторинг планов BCP
Планы по обеспечению непрерывности бизнеса можно считать надежными, только в случае их регулярного тестирования и актуализации.
При тестировании планов, выявляются несостыковки в инструкциях, проводится обучение персонала, повышается уровень взаимодействия и компетентности задействованных сотрудников.
Возможные подходы по тестированию планов BCP:
- Опрос (checklist test) — проводится методом анкетирования подразделений, задействованных сотрудников компании;
- Проход по плану (structured walk-through) — пошаговое ролевое чтение планов BCP членами команды BCP, вирутальное выполнение процедур планов BCP;
- Моделирование (simulation test) — виртуальное моделирование прерывания выбранных бизнес-процессов или сбоя активов;
- Тестирование на реальном объекте (interruption test) — реальная остановка бизнес-процесса/актива и выполнение комплекса работ по ее восстановлению согласно планам BCP.
Чем серьезнее бизнес, тем более серьезным должно быть тестирование. В идеале — проводятся реальные прерывания бизнес-процессов, с прогоном по всем шагам плана BCP. Я нечастно видел такое, но эффект классный — план становится реальным.
Ну а чаще всего, разыгрываются ролевые игры, когда за общим столом каждый из членов команды BCP «проигрывает» свои действия.
По результатам тестирования должен быть создан отчет, на основании которого принимаются решения об обновлении плана, применении доп. защитных мер и т.п. Кроме того, данный отчет требуется стандартом.
Еще хотел написать О создании культуры компании, о встраивании практик BCM в культуру компании. Но это же фантастика для славян, не будем:)
3. Заключение
Как бы ни банально звучало, эффективность планирования непрерывности бизнеса напрямую зависит от степени заинтересованности руководства.
А что по поводу сложности внедрения — тут все просто: глаза боятся, руки делают:)
4. Полезные ссылки:
Покажи свою работу — новая книга Остина Клеона.
