Вопрос о том, что сначала выполнять: анализ влияния (аварий) на бизнес или анализ рисков (угроз), периодически возникает среди специалистов по управлению непрерывностью бизнеса. Различные своды знаний и методологии предлагают как очередность «BIA-RA», так и «RA-BIA».
NFPA 1600 «Standard on disaster/emergency management and business continuity programs» (Edition 2013)
«Chapter 5 Planning
......
5.2 Risk Assessment
5.3 Business Impact Analysis»
«Good Practice Guidelines 2013 Global Edition: A guide to Global Good Practice in Business Continuity»
В редакции 2013 года GPG не указывает порядок выполнения этих активностей, но последовательность описания все же намекает на видение авторов: сначала BIA, потом анализ угроз.
Автор книги «Becoming resilient», известный блоггер Dejan Kosutic
«Which comes first – risk assessment or business impact analysis? This is a question I hear a lot – ISO 22301 actually allows both approaches. However, I prefer to do risk assessment first because this way, you will have a better impression of which incidents can happen (which risks you’re exposed to), and therefore be better prepared for doing the business impact analysis (which focuses on consequences of those incidents); further, if you choose the asset-based approach for risk assessment (see section 6.2), you will have an easier time identifying all the resources later on in the business impact analysis. What you definitely shouldn’t do is perform risk assessment and business impact analysis at the same time.»
На мой взгляд, разумно сначала выполнить BIA для того, что определить критичные, с точки зрения очередности восстановления, бизнес-функции, а потом уже выполнить анализ угроз. Прежде всего, в рамках BIA нас не интересует природа инцидента, который нарушил работу процесса, более важно понимать к каким последствиям это приводят.
Зачастую, компания не располагает таким количеством ресурсов, чтобы охватить все бизнес-процессы и связанные с ними ресурсы в рамках business continuity инициативы. Приоритезация бизнес-функций (бизнес-процессов) позволяет изучать угрозы сузив область охвата анализа: начать с тех функций, что «критичней», и не подвергать исследованию все активности бизнеса, что было бы нерационально.
Несмотря на логичность такой последовательности, я все же вижу один недостаток, который в «теории» не должен существовать, но на практике встречается весьма часто.
Выбор правильного способа восстановления бизнес-функции зависит от выдвинутых требований бизнеса ко времени восстановления. В ходе BIA это определяется показателем MTPD (Maximum Tolerable Period of Downtime). Если используется количественный подход к оценке влияния простоя, то, по идее, нужно получить стоимость потерь для того, чтобы определить приемлемость или неприемлемость простоя для какой-то точки времени. В моей практике, бизнес либо не располагает такой информацией, либо весьма смутно представляет чего стоит простой конкретной активности для всей компании, а представители бизнеса настаивают на мгновенном восстановлении. Таким образом, показатель MTPD достаточно подвижен, и, если все же удается донести мысль, что мгновенное восстановление нерационально - например, потому что для этого нужно вложить огромные деньги, то в итоге MTPD будет определятся не риск-аппетитом компании, а сравнением затрат на DR-решение (т.е. на контрмеру) по отношению к стоимости простоя. Но контрмера зависит от риска, влияние которого мы пытаемся уменьшить, соответственно без понимания риска нужно либо выбирать одно решение для всех ситуаций, что явно нелучший вариант, либо параллельно изучать угрозы для бизнес-процесса. В итоге, определение MTPD превращается в «торг» между, например, ИТ (как владельцем ресурса) и бизнесом, где ИТ предлагает защитить бюджет под решение обеспечивающее восстановление ИТ-системы в заданное бизнесом время. А бизнес, понимая все расходы, либо расслабляет это время, если не готов оплатить предложенную смету, либо подтверждает готовность объяснить почему восстановление должно быть выполнено именно в указанное время.
Выбор «правильной» последовательности это решение, которое нужно принять индивидуально в каждом проекте. Важно понимать все последствия от выбранного порядка действий.
