АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Аудит обеспечения непрерывности бизнеса и восстановления после сбоев

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Ауди́т обеспе́чения непреры́вности би́знеса и восстановле́ния по́сле сбо́ев (англ. business continuity and disaster recovery auditing, BCDR auditing) — процесс независимой оценки планов и процедур, направленных на поддержание обеспечения непрерывности бизнеса (ОНБ; англ. business continuity, BC) и восстановления после сбоев (ВПС; англ. disaster recovery, DR).

Согласно международному стандарту ISO 22301, ОНБ представляет собой способность организации продолжать предоставление продуктов или услуг на приемлемом, заранее определённом уровне после сбоя[1], в то время как ВПС является его составной частью, сфокусированной на восстановлении технологической инфраструктуры[2]. Аудит обеспечивает третью сторону валидации для заинтересованных лиц в том, что документация всесторонняя и достоверная, не содержит существенных искажений[3].

Общие сведения

Термины «обеспечение непрерывности бизнеса» (ОНБ) и «восстановление после сбоев» (ВПС) часто употребляются вместе, однако описывают разные, хотя и взаимодополняющие, аспекты устойчивости организации.

Обеспечение непрерывности бизнеса (англ. Business Continuity, BC) — это, согласно стандарту ISO 22301, способность организации продолжать предоставление продуктов или услуг на приемлемом, заранее определённом уровне после инцидента, ведущего к сбою. ОНБ представляет собой комплексный и проактивный процесс управления, который охватывает все аспекты функционирования организации (персонал, процессы, коммуникации, технологии) с целью предотвращения полной остановки деятельности и минимизации потерь. В России этому стандарту соответствует ГОСТ Р ИСО 22301-2021.

Восстановление после сбоев (англ. Disaster Recovery, DR), в свою очередь, является составной частью ОНБ и представляет собой набор политик и процедур, сфокусированных на восстановлении технологической инфраструктуры и данных после катастрофического события[3][4]. В отличие от широкого охвата ОНБ, ВПС концентрируется преимущественно на ИТ-составляющей бизнеса[5].

Таким образом, если ОНБ отвечает на вопрос «Как сохранить работу бизнеса в целом во время кризиса?», то ВПС отвечает на более узкий вопрос: «Как восстановить нашу ИТ-инфраструктуру после катастрофы?».

Структура системы менеджмента по ISO 22301

Система менеджмента непрерывности бизнеса (СМНБ) по стандарту ISO 22301:2019 представляет собой структурированный подход, который позволяет организации защищаться от сбоев, снижать вероятность их возникновения, готовиться к ним, реагировать и восстанавливать свою деятельность[6]. Структура стандарта основана на «структуре высокого уровня» (англ. High-Level Structure, HLS), что делает его совместимым с другими стандартами на системы менеджмента, такими как ISO 9001 (качество) и ISO/IEC 27001 (информационная безопасность).

В основе стандарта лежит методология «Plan-Do-Check-Act» (PDCA, или цикл Деминга), которая обеспечивает постоянное улучшение системы[7]. Стандарт состоит из десяти разделов, из которых требования, обязательные для внедрения, содержатся в разделах с 4 по 10[7].

Раздел 1. Область применения
Определяет назначение стандарта.
Раздел 2. Нормативные ссылки
Указывает на связанные документы.
Раздел 3. Термины и определения
Содержит терминологию, используемую в стандарте.
Раздел 4. Среда (контекст) организации
Требует от организации понять внутренние и внешние условия, в которых она работает, определить потребности заинтересованных сторон (клиентов, акционеров, регуляторов) и документировать область применения СМНБ[7].
Раздел 5. Лидерство
Устанавливает, что высшее руководство должно демонстрировать приверженность СМНБ через разработку «Политики непрерывности бизнеса» и распределение ролей, обязанностей и полномочий[8][9].
Раздел 6. Планирование
Организация должна определить риски и возможности, связанные с СМНБ, и установить измеримые цели в области непрерывности бизнеса[7][10].
Раздел 7. Поддержка (обеспечение)
Посвящён ресурсам, необходимым для функционирования СМНБ: компетентному персоналу, процессам внутренних и внешних коммуникаций, а также управлению документированной информацией[7].
Раздел 8. Функционирование (операционная деятельность)
Ключевой раздел, описывающий специфические для непрерывности бизнеса процессы. Он включает в себя анализ воздействия на бизнес (англ. Business Impact Analysis, BIA) и оценку рисков для определения приоритетов и сроков восстановления (англ. Recovery Time Objective, RTO), разработку стратегии и планов непрерывности бизнеса, а также проведение учений и тестирования[10][11][12][13].
Раздел 9. Оценка результатов деятельности
Эффективность СМНБ отслеживается через мониторинг, измерение показателей, проведение внутренних аудитов и анализ со стороны руководства[7][14].
Раздел 10. Улучшение
На основе результатов оценки организация предпринимает действия для постоянного совершенствования СМНБ, включая устранение несоответствий и реализацию корректирующих действий[7][13].

Показатели

Главная задача ONB и ВПС — защитить организацию в случае, если её деятельность и/или ИТ-сервисы становятся частично или полностью недоступными. Для количественной оценки требований к восстановлению и определения приоритетов используются два ключевых показателя[15]:

undefined
  • Целевое время восстановления (англ. Recovery Time Objective, RTO) — максимальный промежуток времени, в течение которого система или сервис должны быть восстановлены после сбоя[16].
  • Целевая точка восстановления (англ. Recovery Point Objective, RPO) — определяет максимальный допустимый объём потери данных, измеряемый во времени (например, данные за последние 15 минут или 4 часа)[16].

Значения RTO и RPO устанавливаются для каждого критически важного процесса индивидуально на основе анализа воздействия на бизнес (англ. Business Impact Analysis, BIA). В ходе BIA организация определяет, какие бизнес-процессы являются наиболее важными, и оценивает потенциальные финансовые, репутационные и операционные потери от их простоя[17]. Результаты анализа позволяют приоритизировать восстановление систем и данных[18]. Таким образом, для наиболее критичных сервисов показатели RTO и RPO будут стремиться к нулю, тогда как для менее важных систем они могут составлять несколько часов[19].

Показатели ВПС

Минимизация простоев и потери данных в процессе восстановления после сбоев обычно определяется двумя ключевыми показателями:

  • Время восстановления до работоспособности (англ. recovery time objective, RTO) — время до полного восстановления работы системы;
  • Точка восстановления (англ. recovery point objective, RPO) — максимальный допустимый объём потери данных (от времени резервной копии до инцидента).

Роль аудитора

В 2024—2025 годах роль внутреннего аудитора в оценке обеспечения непрерывности бизнеса (англ. Business Continuity Management, BCM) и восстановления после сбоев (англ. Disaster Recovery, DR) смещается от формальной проверки наличия планов к стратегической оценке реальной устойчивости организации. Этот процесс обусловлен вступлением в силу новых Международных стандартов внутреннего аудита с января 2025 года, а также ростом таких угроз, как кибератаки, геополитические риски и сбои в цепочках поставок[20][21]. Внутренний аудитор перестаёт быть контролёром и становится стратегическим партнёром, помогающим повышать общую готовность компании к кризисам.

Ключевые направления аудиторской проверки включают:

  • Риск-ориентированная оценка. Вместо проверки на соответствие (англ. compliance) аудитор оценивает, насколько планы BCM и DR адекватны текущему ландшафту рисков[22]. Согласно отчёту Института внутренних аудиторов (IIA) «Risk in Focus 2025», непрерывность бизнеса является одним из главных рисков[23]. Аудитор должен анализировать адекватность планов в контексте актуальных угроз (кибератаки, санкции, разрывы логистических цепочек) и проверять интеграцию BCM со стратегическим планированием организации[21][24].
  • Оценка динамического тестирования. Аудитор проверяет не просто факт проведения учений, а их качество и реалистичность. Оценивается вовлечённость ключевого персонала и руководства, а также то, как результаты тестов используются для реального улучшения планов[25]. Также проверяется способность компании быстро адаптировать и обновлять планы в ответ на новые угрозы[24].
  • Аудит ИТ-инфраструктуры и кибербезопасности. Поскольку большинство сбоев связано с ИТ, аудит включает углублённую оценку планов восстановления ИТ-инфраструктуры, реальную возможность быстрого восстановления систем и данных, а не только наличие резервных копий[26][27]. Проверяются риски, связанные с зависимостью от третьих сторон (например, облачных провайдеров), и интеграция планов реагирования на инциденты кибербезопасности в общую систему BCM[25][28].
  • Человеческий фактор и коммуникации. Аудит охватывает оценку программ обучения и осведомлённости персонала о своих действиях в кризисной ситуации, а также проверку наличия и адекватности планов антикризисных коммуникаций для взаимодействия с сотрудниками, клиентами и регуляторами[25].
  • Соответствие новым стандартам внутреннего аудита. Новые Глобальные стандарты внутреннего аудита (англ. Global Internal Audit Standards), вступающие в силу с 2025 года, требуют от аудиторов разрабатывать стратегию своей деятельности, согласованную с целями организации, и быть более вовлечёнными в оценку корпоративной культуры и готовности к кризисам[29]. Это также подразумевает использование технологий и анализа данных для непрерывного мониторинга рисков[30].

Документация

План восстановления после сбоев (ВПС; англ. disaster recovery plan, DRP) — это документированный процесс или набор процедур для реализации процессов восстановления после сбоев в ИТ-сфере организации и защиты инфраструктуры в случае возникновения бедствия[31]. Разработка современного DRP представляет собой циклический процесс, регламентируемый такими стандартами, как NIST SP 800-34 и ГОСТ Р ИСО/МЭК 27031-2012, и направленный на минимизацию последствий сбоев[32]. Согласно определению, это «всестороннее описание согласованных действий до, во время и после катастрофы»[33]. Бедствия могут быть как природными, так и техногенными (включая кибератаки и человеческие ошибки)[34], причём последние — как преднамеренными, например, террористический акт, так и случайными, например, ошибка оператора или программная ошибка.

Виды планов

Выбор конкретной стратегии восстановления зависит от установленных в ходе анализа влияния на бизнес (BIA) целевых показателей RTO и RPO[35]. Современные технические стратегии включают:

Резервное копирование и восстановление (англ. Backup and Restore)
Базовая стратегия, предполагающая создание резервных копий данных и систем на удалённых площадках или в облаке для их последующего восстановления.
Резервные ЦОД
Организация собственной резервной площадки. В зависимости от степени готовности к переключению выделяют:
  • «Горячий» резерв (англ. hot site) — полностью дублирующая основную площадку инфраструктура, готовая к мгновенному переключению.
  • «Тёплый» резерв (англ. warm site) — площадка с базовым оборудованием и связью, требующая времени на запуск полных копий систем.
  • «Холодный» резерв (англ. cold site) — подготовленное помещение с подведёнными коммуникациями, куда оборудование завозится только после сбоя.
Виртуализация
Использование виртуальных машин, которые не привязаны к физическому оборудованию и могут быть быстро запущены на резервных серверах, в том числе в облаке[35].
Облачное восстановление как услуга (англ. Disaster Recovery as a Service, DRaaS)
Современный подход, при котором компания арендует инфраструктуру у облачного провайдера для аварийного восстановления[36]. Он предполагает репликацию виртуальных машин и данных в облако провайдера, что позволяет быстро запустить ИТ-системы на резервной площадке в случае сбоя. Этот подход значительно снижает капитальные затраты на содержание собственного резервного ЦОДа и повышает гибкость[37].

Лучшие практики

Современные лучшие практики разработки DRP сместились от простого восстановления после сбоев оборудования к обеспечению комплексной киберустойчивости, особенно в контексте защиты от программ-вымогателей[38]. Ключевые практики включают:

  • Интеграция с бизнес-процессами. План должен быть не просто техническим документом, а неотъемлемой частью всех процессов бизнес-анализа и общей стратегии непрерывности бизнеса (BCP), обеспечивая восстановление критически важных для компании функций, а не только отдельных серверов[39];
  • Фокус на киберустойчивости. DRP должен включать конкретные меры по противодействию кибератакам. Это подразумевает защиту резервных копий от шифрования и удаления, их изоляцию от основной сети и регулярную проверку на целостность и отсутствие вредоносного ПО[40];
  • Продвинутая стратегия резервного копирования. Классическое правило «3-2-1» (три копии на двух разных носителях, одна из которых удалённая) эволюционировало в правило «3-2-1-1-0». Дополнительная «1» означает, что одна из копий должна быть неизменяемой (англ. immutable) или находиться в физической изоляции (англ. air-gapped), что защищает её от атак. «0» означает, что процедуры восстановления должны регулярно тестироваться и проходить без ошибок[41];
  • Автоматизация и оркестровка. Использование современных инструментов для автоматизации и оркестровки процессов восстановления позволяет значительно сократить целевое время восстановления (RTO) и минимизировать риск человеческой ошибки при активации плана[40];
  • Регулярное тестирование и актуализация. План должен неоднократно тестироваться на практике, а не оставаться формальной документацией. Современные стандарты требуют проведения регулярных, в том числе автоматизированных, тестов процедур восстановления[42]. План необходимо актуализировать при каждом крупном изменении в инфраструктуре или бизнес-процессах, например, при поглощении, запуске нового продукта или обновлении систем;
  • Тщательное документирование и учёт. Организации обязаны вести учёт всех записей, связанных с DRP. Это включает хранение копий плана (как на основной площадке, так и вне её), ведение актуального списка поставщиков оборудования и программного обеспечения, а также фиксацию результатов тестирования. Наличие этой документации является обязательным элементом для прохождения аудита[43].

Взаимосвязь с планом обеспечения непрерывности бизнеса

Международный стандарт ISO 22301 рассматривает обеспечение непрерывности бизнеса (ОНБ) как комплексную систему менеджмента. В рамках этой системы различные планы не являются отдельными элементами, а представляют собой взаимосвязанные компоненты, которые обеспечивают устойчивость организации[44]. Стандарт определяет требования к их разработке, реализации и управлению[45]. Ключевые планы, составляющие эту систему, включают:

План обеспечения непрерывности бизнеса (англ. Business Continuity Plan, BCP)
Центральный документ, который, согласно ISO 22301, содержит документированные процедуры для реагирования, восстановления и возобновления деятельности организации до заранее определённого уровня после сбоя[45]. Он разрабатывается на основе анализа влияния на бизнес (BIA) и оценки рисков и охватывает все аспекты бизнеса: персонал, процессы, коммуникации и технологии[46]. Термины План возобновления деятельности (англ. Business Resumption Plan, BRP) и План обеспечения непрерывности операций (англ. Continuity of Operations Plan, COOP) часто используются как синонимы, хотя последний более распространён в государственных учреждениях[47].
План управления инцидентами (англ. Incident Management Plan, IMP)
Является ключевой частью операционных требований ISO 22301 (раздел 8). Он устанавливает структуру и процедуры для немедленного реагирования на инцидент с целью его сдерживания, минимизации ущерба, защиты персонала и координации действий команд[48][49].
План действий в чрезвычайной ситуации (англ. Emergency Action Plan, EAP)
Фокусируется на немедленных действиях для обеспечения безопасности людей в первые минуты кризиса. Он включает процедуры эвакуации, оповещения персонала и связи с экстренными службами. В контексте ISO 22301 является частью процедур реагирования на инциденты[50].
План восстановления после сбоев (англ. Disaster Recovery Plan, DRP)
Рассматривается как подмножество BCP, сфокусированное на восстановлении технологической инфраструктуры и ИТ-систем[51]. В то время как BCP охватывает весь бизнес, DRP концентрируется на технических шагах по восстановлению серверов, данных и сетей после катастрофического события[50].

Таким образом, все эти планы являются составными частями единой системы управления непрерывностью бизнеса. Стандарт ISO 22301 обеспечивает, чтобы они были не просто отдельными документами, а частью живого, тестируемого и постоянно улучшаемого процесса[44].

Тестирование

В 2024—2025 годах учения по обеспечению непрерывности бизнеса (англ. Business Continuity, BC) и восстановлению после сбоев (англ. Disaster Recovery, DR) развиваются в сторону проверки комплексной устойчивости. Организации отходят от формальных проверок, переходя к гибким и интегрированным стратегиям, способным противостоять современным угрозам, таким как кибератаки и сбои в сложных цепочках поставок[52]. Ключевыми тенденциями становятся интеграция ОНБ и ВПС в единую дисциплину операционной устойчивости, фокус на сценариях кибератак, адаптация к гибридным форматам работы и использование искусственного интеллекта как для создания реалистичных сценариев, так и для автоматизации восстановления[52][53].

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

Настольные учения (англ. Tabletop Exercises)

Наиболее доступный формат, представляющий собой штабные дискуссии. Ключевые сотрудники собираются для обсуждения гипотетического сценария сбоя (например, отказ основного ЦОДа, кибератака), проговаривая свои действия в соответствии с планами, но не выполняя их на практике[54]. Цель — проверить знание планов, выявить пробелы в документации и оценить координацию между командами. В ходе учений модератор может вводить новые усложняющие факторы («инъекции») для проверки гибкости реагирования[53].

Функциональные учения (англ. Functional Exercises)

Формат предполагает практическую отработку отдельных элементов плана без полного прерывания основной деятельности. Например, команда ИТ-специалистов может провести реальное восстановление сервера из резервной копии на тестовой площадке или проверить каналы экстренной связи[55]. Цель — проверить работоспособность технических решений, оценить реальное время выполнения процедур (RTO/RPO) и практические навыки персонала[56]. Тестирование проводится в контролируемой, изолированной среде.

Полномасштабные симуляции (англ. Full-Scale Simulations)

Наиболее сложный и ресурсоёмкий формат, имитирующий реальную катастрофу. Симуляция может включать эвакуацию персонала, активацию резервного офиса или ЦОДа и полное переключение критичных операций на резервные мощности[57]. Цель — комплексная проверка всей системы управления непрерывностью бизнеса в условиях, приближённых к реальным. Часто такие учения проводятся без предварительного предупреждения для оценки реальной готовности команд.

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

В рамках перечисленных форматов могут применяться специфические подходы:

  • Тестирование на проникновение (англ. Penetration Testing) — контролируемая попытка взлома ИТ-систем для выявления уязвимостей и проверки устойчивости к кибератакам. Существуют различные методологии, такие как OSSTMM, OWASP, ISSAF[57][58].
  • Хаос-инженерия (англ. Chaos Engineering) — практика, при которой в работающей системе целенаправленно создаются сбои (например, отключается сервер) для проверки её способности выдерживать непредвиденные отказы в автоматическом режиме[55].
  • Проверка по чек-листу (англ. Checklist Test) — простейший метод, при котором ответственные лица по заранее составленному списку проверяют наличие и доступность всех необходимых ресурсов: документации, контактов, оборудования.

Регулярное проведение учений (рекомендуется не реже одного-двух раз в год) является лучшей практикой и позволяет превратить план из формального документа в работающий инструмент, обеспечивающий реальную устойчивость бизнеса[52].

Преимущества

Аудит обеспечения непрерывности бизнеса (ОНБ) и восстановления после сбоев (ВПС) предоставляет независимую оценку готовности организации к кризисам и является стратегическим инструментом управления[59], особенно в условиях 2022—2025 годов, характеризующихся ростом киберугроз и геополитической нестабильностью. Основная цель аудита — подтвердить, что планы по обеспечению непрерывности и восстановлению (BCP/DRP) являются полными, актуальными и эффективными[60]. Исследования также показывают связь между увеличением трат на аудит и сокращением числа инцидентов[61].

Ключевые выгоды аудита непрерывности бизнеса включают:

  • Адаптация к новым угрозам и реалиям. Планы, разработанные в период пандемии COVID-19, часто не учитывают актуальные риски. Аудит помогает пересмотреть стратегии с учётом геополитических изменений, санкций, нарушения цепочек поставок и ухода зарубежных поставщиков[59], а также возросшей интенсивности кибератак;
  • Повышение устойчивости и снижение финансовых потерь. Эффективные и проверенные в ходе аудита планы позволяют значительно сократить время простоя и минимизировать прямые убытки от инцидентов[62]. По данным отчёта IBM, средняя стоимость утечки данных в 2023 году составила 4,45 млн долларов США, а наличие протестированных планов BCDR является одним из ключевых факторов снижения этих издержек[63];
  • Защита репутации и доверия. Способность компании быстро восстановиться после сбоя демонстрирует её надёжность, укрепляя доверие клиентов, инвесторов и партнёров[62]. Аудит предоставляет руководству и заинтересованным сторонам уверенность в готовности организации к кризисам[64];
  • Совершенствование управления рисками. Аудит является инструментом системной оценки рисков, который позволяет не только выявить угрозы, но и проверить адекватность мер по их смягчению[64]. Это способствует формированию в компании культуры готовности к инцидентам и обеспечивает постоянное улучшение планов[65];
  • Соответствие нормативным требованиям. Для многих отраслей, особенно для финансового сектора, наличие и регулярное тестирование планов непрерывности деятельности являются обязательными требованиями регуляторов[65]. Аудит подтверждает соблюдение таких стандартов, как ISO 22301, и помогает избежать штрафных санкций[66];
  • Оптимизация ИТ-инфраструктуры и процессов. В ходе аудита часто выявляются слабые места не только в планах, но и в самой ИТ-инфраструктуре[67]. Тестирование планов восстановления (DRP) позволяет проверить работоспособность резервных систем, каналов связи и процедур восстановления данных, что в итоге повышает общую надёжность ИТ-сервисов[65].

Методология планирования и тестирования

Современная методология разработки плана восстановления после сбоев (DRP) представляет собой циклический, многоэтапный процесс, регламентированный такими стандартами, как NIST SP 800-34[68] и ISO/IEC 27031. Для большей части периода 2015—2025 годов основной являлась версия ISO/IEC 27031:2011 (в России — ГОСТ Р ИСО/МЭК 27031-2012), которую в мае 2025 года сменила обновлённая редакция ISO/IEC 27031:2025[69]. Этот структурированный подход является развитием более ранних фреймворков, предложенных, в частности, Джеффри Волдом (англ. Geoffrey H. Wold) в Disaster Recovery Journal, которые также включали ключевые этапы, такие как оценка рисков, определение приоритетов и тестирование плана. Классическая методология NIST включает семь основных этапов[68]:

Инициация и формирование политики
На начальном этапе определяется необходимость создания DRP, формируется команда из представителей топ-менеджмента, бизнес-подразделений, ИТ и службы безопасности, а также закладываются цели и общие принципы плана[70].
Анализ влияния на бизнес (BIA) и оценка рисков (RA)
Фундаментальный этап, на котором определяются критически важные для компании процессы и оцениваются потенциальные финансовые, репутационные и операционные потери от их простоя (BIA). Параллельно проводится оценка рисков (RA), в ходе которой идентифицируются потенциальные угрозы — от природных катастроф до кибератак и человеческих ошибок. Результаты анализа позволяют приоритизировать восстановление систем и данных.
Определение целевых показателей (RTO и RPO)
На основе BIA устанавливаются два ключевых показателя: целевое время восстановления (англ. Recovery Time Objective, RTO) — максимальный промежуток времени, в течение которого система должна быть восстановлена, и целевая точка восстановления (англ. Recovery Point Objective, RPO) — максимальный допустимый объём потери данных. Для наиболее критичных сервисов эти показатели стремятся к нулю, тогда как для менее важных систем они могут составлять несколько часов.
Разработка стратегии восстановления
Выбираются технические и организационные решения для достижения установленных RTO и RPO. Современные стратегии включают резервное копирование, виртуализацию, использование резервных ЦОД («горячих», «тёплых» или «холодных»), а также облачные сервисы, такие как восстановление как услуга (англ. Disaster Recovery as a Service, DRaaS), которые позволяют реплицировать инфраструктуру в облако провайдера. Этот подход тесно интегрирует DRP с общей стратегией непрерывности бизнеса (BCP).
Документирование плана
Все процедуры, роли, обязанности и технические детали фиксируются в едином документе — DRP. План должен содержать пошаговые инструкции по восстановлению, контактные данные команды, схемы сетей, перечень критического оборудования и план коммуникаций[71][72].
Тестирование плана
DRP должен регулярно тестироваться для выявления недостатков и проверки его работоспособности до реального сбоя. Тестирование помогает убедиться в достижимости целевых показателей RTO и RPO и подготовить команду к действиям в кризисной ситуации. Современные подходы включают автоматизацию и оркестровку процессов тестирования для минимизации влияния на бизнес-процессы.
Поддержка и обновление
План является «живым» документом и требует постоянной актуализации. Его необходимо пересматривать при любых значительных изменениях в ИТ-инфраструктуре или бизнес-процессах, а также по результатам проведённых тестов. Рекомендуется проводить аудит и обновление плана не реже одного раза в год[71].

Недостатки и спорные моменты

Внедрение систем ОНБ и ВПС сопряжено с рядом сложностей и распространённых ошибок, которые могут свести на нет все усилия. Помимо высокой стоимости, критика часто направлена на организационные и технические просчёты. Например, ещё в 2010 году компания Dell выделяла пять классических ошибок[73]:

  • Отсутствие поддержки менеджмента: если руководство воспринимает ВПС как «формальную формальность».
  • Неполные RTO/RPO: недоучёт критичных процессов/данных приводит к угрозе функционированию целых отделов.
  • Миопия по системам: фокус только на ИТ-часть «отсекает» влияние инфраструктурных сбоев, например, потеря офиса — рост нагрузки на VPN и ИТ-поддержку.
  • Слабая безопасность: после сбоя возрастает роль защиты данных и каналов передачи (например, срочная блокировка/стирание мобильных устройств).
    • Организация криптоанализа для разбора событий post-mortem.
    • Блокировка/удалённое стирание потерянных устройств.

Актуальные вызовы и ошибки (2020—2025 годы)

В период с 2020 по 2025 год российские компании столкнулись с комплексом новых вызовов, которые обострили старые проблемы и создали новые. Ключевыми факторами стали уход зарубежных ИТ-вендоров, санкционное давление и беспрецедентный рост кибератак[74][75][76]. По данным за 2024 год, 93 % российских компаний столкнулись с критическими инцидентами, а средняя продолжительность простоя выросла до 4 часов[77]. Более 60 % организаций понесли прямые финансовые потери, причём средняя стоимость одного серьёзного инцидента приблизилась к 2 млн рублей[78].

На фоне внешних вызовов компании часто допускают внутренние ошибки в планировании и реализации стратегий непрерывности.

Стратегические и организационные ошибки:

  • Недооценка рисков и отсутствие бизнес-анализа (BIA). Многие проекты по внедрению BCDR начинаются без чёткого понимания, какие бизнес-процессы являются критичными и в какие сроки их необходимо восстанавливать[79]. Это приводит к тому, что планы не соответствуют реальным потребностям компании[80].
  • Игнорирование человеческого фактора. Ошибки персонала, такие как неверная конфигурация оборудования или случайное удаление данных, остаются одной из частых причин сбоев[74]. Кроме того, в кризисной ситуации растерянность и отсутствие у сотрудников чётких инструкций могут парализовать работу[75].
  • Недостаточное внимание со стороны руководства. Делегирование задач по управлению непрерывностью руководителям без необходимых полномочий и ресурсов является распространённой ошибкой, которая обрекает проект на неудачу[81].

Технические и процессные ошибки:

  • Пренебрежение резервным копированием. Несмотря на то, что резервное копирование является фундаментом стратегии восстановления, лишь малая часть компаний делает бэкапы ежедневно, что оставляет их уязвимыми перед потерей критически важных данных[78].
  • Отсутствие регулярного тестирования планов. Компании, не проводящие регулярные учения по проверке своих планов BCP и DRP, живут в иллюзии безопасности. Практика показывает, что без тестирования планы быстро устаревают и оказываются неработоспособными в реальной ситуации сбоя[77].
  • Проблемы импортозамещения и интеграции. Уход иностранных вендоров привёл к использованию устаревшего оборудования без поддержки, а попытки его замены сопряжены со сложностями интеграции решений от различных, в том числе новых российских, поставщиков[81].
  • Формальный или устаревший план. План восстановления должен быть детальным документом, включающим актуальные контакты, пошаговые инструкции и процедуры реагирования. Отсутствие регулярного обновления этих планов делает их бесполезными[82].

Стратегии и принятие решений

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

Выбор площадки и стратегии восстановления

Классический подход к выбору площадки резервирования предполагает использование собственных или арендованных центров обработки данных (ЦОД) с разной степенью готовности:

  • «Холодная» площадка (англ. cold site) — подготовленное помещение с коммуникациями, куда оборудование завозится после сбоя.
  • «Тёплая» площадка (англ. warm site) — площадка с базовым оборудованием, требующая времени на запуск полных копий систем.
  • «Горячая» площадка (англ. hot site) — полностью дублирующая основную инфраструктуру, готовая к почти мгновенному переключению.

Однако в 2024—2025 годах доминирующей тенденцией стал переход к облачным и гибридным моделям, в первую очередь к аварийному восстановлению как услуге (англ. Disaster Recovery as a Service, DRaaS). Эта модель предполагает, что компания передаёт задачи по аварийному восстановлению облачному провайдеру, который реплицирует физические или виртуальные серверы клиента в своё облако и обеспечивает их быстрый запуск в случае сбоя на основной площадке[83]. Также популярны гибридные модели, объединяющие локальное хранилище для быстрого восстановления и облачное — для защиты от масштабных катастроф[84][85].

В этом контексте роль аудитора заключается в оценке экономической обоснованности выбранной стратегии (собственный ЦОД против DRaaS), анализе соглашений об уровне обслуживания (SLA) с провайдером и проверке фактической реализуемости плана восстановления.

Аудит резервного копирования

Аудит резервного копирования (бэкапа) сместился от простой проверки регулярности процедур к оценке комплексной киберустойчивости, особенно в контексте защиты от программ-вымогателей. Современные подходы к аудиту базируются на международных стандартах, таких как ISO/IEC 27001 и фреймворк NIST CSF 2.0[86][87].

Одной из ключевых лучших практик, проверяемых аудитором, является эволюционировавшее правило «3-2-1-1-0»:

  • 3 — хранить не менее трёх копий данных;
  • 2 — использовать как минимум два разных типа носителей;
  • 1 — как минимум одна копия должна храниться за пределами основной площадки (off-site);
  • 1 — как минимум одна из копий должна быть неизменяемой (англ. immutable) или находиться в физической изоляции (англ. air-gapped), что защищает её от шифрования или удаления злоумышленниками;
  • 0 — процедуры восстановления должны регулярно тестироваться и проходить с нулевым количеством ошибок.

В ходе аудита проверяются:

  • Политика и охват: наличие актуальной политики резервного копирования и полнота охвата всех критически важных систем;
  • Защита резервных копий: применение шифрования и строгий контроль доступа к резервным копиям как при хранении, так и при передаче;
  • Тестирование восстановления: наличие доказательств (журналов) регулярного тестирования процедур восстановления. Аудитор должен убедиться, что компания не просто создаёт резервные копии, но и способна успешно восстановить из них данные в соответствии с установленными RTO и RPO.

Прочие аспекты

Страхование

Аудитор оценивает полноту и актуальность страхового покрытия, особенно по имуществу и рискам ущерба, исследует страховые документы, анализирует достаточность объёма покрытия и кредитоспособность страховых организаций.

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

Коммуникации

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

Методы аудита включают:

  • тестирование процедур, интервьюирование сотрудников, сопоставление с отраслевыми стандартами,
  • анализ регламентов и инструкций,
  • проверку доступности экстренных контактов.

Аварийные процедуры

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

Экологические аспекты

Аудитор изучает готовность компании к вне-ИТ ситуациям — авариям электропитания, пожарам, утечкам газа.

  • Требуется наличие фонарей, свечей и средств индивидуальной защиты.
  • Описаны правила поведения при экстренных происшествиях данного рода.

Примечания

  1. ↑ Сертификат ГОСТ Р ИСО 22301-2021. Серт-рекорд. Дата обращения: 4 ноября 2025.
  2. ↑ Управление непрерывностью бизнеса. Security Vision. Дата обращения: 4 ноября 2025. Архивировано 5 августа 2025 года.
  3. ↑ 1 2 Susan Snedaker. Business Continuity and Disaster Recovery Planning for IT Professionals. — 2. — Burlington : Elsevier Science, 2013. — ISBN 9780124114517.
  4. ↑ DRP-план для бизнеса. DRP-plan. Дата обращения: 4 ноября 2025. Архивировано 2 августа 2025 года.
  5. ↑ What Is the Difference Between Disaster Recovery and Business Continuity (англ.). Cloudian (25 ноября 2019). Дата обращения: 10 июня 2024. Архивировано 19 августа 2025 года.
  6. ↑ ISO 22301:2019 Системы менеджмента непрерывности деловой деятельности. РИА «Стандарты и качество». Дата обращения: 4 ноября 2025. Архивировано 16 декабря 2024 года.
  7. ↑ 1 2 3 4 5 6 7 ГОСТ Р ИСО 22301-2021. Безопасность и устойчивость. Системы менеджмента непрерывности бизнеса. Требования. Кодекс. Дата обращения: 4 ноября 2025. Архивировано 22 марта 2023 года.
  8. ↑ ГОСТ Р ИСО 22301-2021. PQM-online (2021). Дата обращения: 4 ноября 2025. Архивировано 28 июня 2022 года.
  9. ↑ Управление непрерывностью бизнеса: система управления для обеспечения устойчивости. DQS. Дата обращения: 4 ноября 2025.
  10. ↑ 1 2 What are the ISO 22301 Requirements? (англ.). Schellman. Дата обращения: 4 ноября 2025. Архивировано 8 сентября 2025 года.
  11. ↑ ISO 22301 Clause 8.2: Business Impact Analysis and Risk Assessment (англ.). ISO-DOCS. Дата обращения: 4 ноября 2025. Архивировано 22 апреля 2025 года.
  12. ↑ ISO 22301:2019 is here! (англ.). Business Continuity Blog (11 ноября 2019). Дата обращения: 4 ноября 2025.
  13. ↑ 1 2 ISO 22301 СИСТЕМА УПРАВЛЕНИЯ НЕПРЕРЫВНОСТЬЮ БИЗНЕСА. Astor Mayer. Дата обращения: 4 ноября 2025.
  14. ↑ ГОСТ Р ИСО 22301-2021. metall.world (2021). Дата обращения: 4 ноября 2025.
  15. ↑ DRP: как подготовиться к аварийному восстановлению. Habr. Дата обращения: 4 ноября 2025.
  16. ↑ 1 2 RTO и RPO. Depit. Дата обращения: 4 ноября 2025. Архивировано 21 июня 2025 года.
  17. ↑ Что такое Business Impact Анализ? RiskControl GRC. Дата обращения: 4 ноября 2025. Архивировано 7 августа 2025 года.
  18. ↑ Методы оценки риска: Анализ воздействия на бизнес (BIA — Business Impact Analysis). upravlenie-riskami.ru. Дата обращения: 4 ноября 2025.
  19. ↑ RPO и RTO: различия в показателях резервного копирования. ITC.by. Дата обращения: 4 ноября 2025. Архивировано 18 июля 2025 года.
  20. ↑ Business continuity and crisis management plans (англ.). ICAEW. Дата обращения: 4 ноября 2025. Архивировано 8 августа 2025 года.
  21. ↑ 1 2 Главные риски для бизнеса в 2024 году и как ими управлять. TerraLink. Дата обращения: 4 ноября 2025. Архивировано 12 июля 2025 года.
  22. ↑ Internal Audit Best Practices (англ.). ComplianceQuest. Дата обращения: 4 ноября 2025. Архивировано 8 сентября 2025 года.
  23. ↑ Risk in Focus 2025 (англ.). The Institute of Internal Auditors. Дата обращения: 4 ноября 2025.
  24. ↑ 1 2 The IIA’s 2025 Internal Audit Standards: A Guide for Community Banks (англ.). CSH. Дата обращения: 4 ноября 2025. Архивировано 6 августа 2025 года.
  25. ↑ 1 2 3 Business continuity for financial services internal auditors (англ.). Wolters Kluwer. Дата обращения: 4 ноября 2025. Архивировано 11 февраля 2025 года.
  26. ↑ Защита бизнеса от кибератак. T-Bank. Дата обращения: 4 ноября 2025.
  27. ↑ Как обеспечить непрерывность бизнеса в новых реалиях. Habr. Дата обращения: 4 ноября 2025.
  28. ↑ 2025 IIA Standards: Key Changes & Considerations (англ.). CBH. Дата обращения: 4 ноября 2025. Архивировано 23 июня 2025 года.
  29. ↑ Опубликованы новые Международные стандарты внутреннего аудита. assurance.by. Дата обращения: 4 ноября 2025. Архивировано 15 мая 2025 года.
  30. ↑ The Ultimate 2025 Guide to Internal Audit Best Practices and Strategies (англ.). ACI Learning. Дата обращения: 4 ноября 2025. Архивировано 15 июня 2025 года.
  31. ↑ Билл Абрам. 5 советов по эффективному плану восстановления после сбоев (англ.). Small Business Computing (14 июня 2012). Дата обращения: 9 августа 2012. Архивировано 25 июня 2012 года.
  32. ↑ ГОСТ Р ИСО/МЭК 27031-2012 Информационная технология. Методы и средства обеспечения безопасности. Руководящие указания по готовности информационно-коммуникационных технологий к обеспечению непрерывности бизнеса. Кодекс. Дата обращения: 4 ноября 2025. Архивировано 22 сентября 2016 года.
  33. ↑ Wold, Geoffrey H. Процесс планирования восстановления после сбоев (англ.). Disaster Recovery Journal. Disaster Recovery World (1997). Дата обращения: 8 августа 2012. Архивировано 15 августа 2012 года.
  34. ↑ Что такое Disaster Recovery и как составить DRP-план. Maxiplace. Дата обращения: 4 ноября 2025. Архивировано 20 апреля 2025 года.
  35. ↑ 1 2 План аварийного восстановления (Disaster Recovery Plan, DRP). Acronis. Дата обращения: 4 ноября 2025. Архивировано 19 мая 2025 года.
  36. ↑ Шесть этапов создания плана аварийного восстановления. CNews (22 апреля 2023). Дата обращения: 4 ноября 2025. Архивировано 17 марта 2025 года.
  37. ↑ ISO/IEC 27031:2011 Preview (англ.). ANSI Webstore. Дата обращения: 4 ноября 2025. Архивировано 9 августа 2024 года.
  38. ↑ Почему резервные копии должны эволюционировать, чтобы оставаться актуальными в 2025 году. TTK Cloud. Дата обращения: 4 ноября 2025.
  39. ↑ 5 steps to implementing an effective disaster recovery strategy (англ.). Colobridge (16 июля 2024). Дата обращения: 4 ноября 2025. Архивировано 9 сентября 2025 года.
  40. ↑ 1 2 Publications By Latest Release (англ.). NIST Computer Security Resource Center. Дата обращения: 4 ноября 2025. Архивировано 7 ноября 2024 года.
  41. ↑ Резервное копирование ЦОД: стратегии и решения 2025. DataCheap. Дата обращения: 4 ноября 2025.
  42. ↑ PR.IP-4: Backups of information are conducted, maintained, and tested (англ.). CSF.Tools. Дата обращения: 4 ноября 2025. Архивировано 22 мая 2022 года.
  43. ↑ Аудит системы резервного копирования (pdf). Wone IT. Дата обращения: 4 ноября 2025. Архивировано 12 ноября 2024 года.
  44. ↑ 1 2 ISO 22301: The Ultimate Guide to Business Continuity (англ.). isms.online. Дата обращения: 4 ноября 2025. Архивировано 15 августа 2025 года.
  45. ↑ 1 2 Business Continuity Plan: How to structure it according to ISO 22301 (англ.). Advisera. Дата обращения: 4 ноября 2025. Архивировано 7 сентября 2025 года.
  46. ↑ Continuity of Operations Plan (COOP): A Cornerstone of Disaster Recovery (англ.). Tidal Basin. Дата обращения: 4 ноября 2025. Архивировано 21 апреля 2025 года.
  47. ↑ Continuity of Operations (COOP)/ Business Continuity Planning (англ.). ASPR TRACIE. Дата обращения: 4 ноября 2025. Архивировано 19 февраля 2020 года.
  48. ↑ Incident Response Plan (англ.). Advisera. Дата обращения: 4 ноября 2025. Архивировано 6 сентября 2025 года.
  49. ↑ Understanding ISO 22301 and ISO 22320 (англ.). 911Cellular. Дата обращения: 4 ноября 2025. Архивировано 15 августа 2025 года.
  50. ↑ 1 2 Why ISO 22301 crucial for Business continuity and Disaster recovery? (англ.). SIS Certifications. Дата обращения: 4 ноября 2025. Архивировано 21 мая 2025 года.
  51. ↑ Business Continuity & Disaster Recovery Planning (англ.). Infosec.ge. Дата обращения: 4 ноября 2025.
  52. ↑ 1 2 3 Это катастрофа! Построение эффективного плана обеспечения непрерывности бизнеса. Cleverics (апрель 2024). Дата обращения: 4 ноября 2025. Архивировано 18 мая 2025 года.
  53. ↑ 1 2 Непрерывность бизнеса в гибридном мире. CIO.ru / OSP (13 марта 2012). Дата обращения: 4 ноября 2025. Архивировано 9 сентября 2025 года.
  54. ↑ Tabletop exercise: как провести учения по кибербезопасности. Habr (14 марта 2022). Дата обращения: 4 ноября 2025.
  55. ↑ 1 2 Управление непрерывностью бизнеса. Часть 1. Свод правил. Jet Info. Дата обращения: 4 ноября 2025. Архивировано 15 июня 2025 года.
  56. ↑ Руководство по обеспечению непрерывности бизнеса для вашей организации (pdf). OCS. Дата обращения: 4 ноября 2025. Архивировано 14 марта 2022 года.
  57. ↑ 1 2 Непрерывность бизнеса и кризисное реагирование. Hock Training. Дата обращения: 4 ноября 2025. Архивировано 18 июня 2025 года.
  58. ↑ Disaster Recovery (DRP): план восстановления IT-инфраструктуры. Zerobit. Дата обращения: 4 ноября 2025.
  59. ↑ 1 2 Непрерывность деятельности в новых реалиях (pdf). ФБК. Дата обращения: 4 ноября 2025. Архивировано 13 мая 2024 года.
  60. ↑ Аудит обеспечения непрерывности бизнеса. Портал «Управление производством». Дата обращения: 4 ноября 2025. Архивировано 13 августа 2025 года.
  61. ↑ Li, He; No, Won Gyun; Boritz, J. Efrim (24 ноября 2021). “Are External Auditors Concerned about Cyber Risk disclosure”. Auditing: A Journal of Practice & Theory. DOI:10.2139/ssrn.2880928. S2CID 168198159.
  62. ↑ 1 2 What Are the Benefits of Business Continuity and Disaster Recovery? (англ.). TOTLCOM. Дата обращения: 4 ноября 2025. Архивировано 9 августа 2025 года.
  63. ↑ Business continuity and disaster recovery (англ.). IBM. Дата обращения: 4 ноября 2025. Архивировано 16 сентября 2025 года.
  64. ↑ 1 2 Аудит непрерывности бизнеса. RTM Group. Дата обращения: 4 ноября 2025. Архивировано 15 мая 2025 года.
  65. ↑ 1 2 3 Семь шагов к непрерывности бизнеса. Softline. Дата обращения: 4 ноября 2025. Архивировано 14 августа 2025 года.
  66. ↑ Управление непрерывностью бизнеса. in4security. Дата обращения: 4 ноября 2025. Архивировано 18 мая 2025 года.
  67. ↑ Непрерывность деятельности: синергия ИТ и бизнеса. Jet Info. Дата обращения: 4 ноября 2025. Архивировано 16 июля 2025 года.
  68. ↑ 1 2 SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (англ.). NIST (май 2010). Дата обращения: 4 ноября 2025. Архивировано 17 августа 2025 года.
  69. ↑ ISO/IEC 27031:2025 Information security, cybersecurity and privacy protection — ICT readiness for business continuity (англ.). iso27001security.com. Дата обращения: 4 ноября 2025. Архивировано 18 июля 2025 года.
  70. ↑ DRP: три простых вопроса для непростых решений. Xelent. Дата обращения: 4 ноября 2025. Архивировано 8 сентября 2025 года.
  71. ↑ 1 2 Disaster Recovery Plan: как обеспечить непрерывность бизнеса. True Engineering. Дата обращения: 4 ноября 2025. Архивировано 23 мая 2025 года.
  72. ↑ Disaster Recovery и Disaster Recovery Plan. Смофф. Дата обращения: 4 ноября 2025. Архивировано 30 сентября 2023 года.
  73. ↑ Five Mistakes That Can Kill a Disaster Recovery Plan (англ.) (25 октября 2010). Дата обращения: 8 августа 2012. Архивировано 16 января 2013 года.
  74. ↑ 1 2 Влияние санкций на непрерывность бизнеса: опыт российских компаний. CyberLeninka. Дата обращения: 4 ноября 2025.
  75. ↑ 1 2 Более 60% компаний столкнулись. CNews. Дата обращения: 4 ноября 2025. Архивировано 23 января 2025 года.
  76. ↑ Развитие информационно-сетевой среды и девиантное поведение: киберпреступность как новая социальная угроза. CyberLeninka. Дата обращения: 4 ноября 2025.
  77. ↑ 1 2 Компании, которые не проводят регулярные учения и не тестируют свои планы BCP и DRP, живут в иллюзии безопасности. GlobalCIO. Дата обращения: 4 ноября 2025.
  78. ↑ 1 2 Более 60% российских компаний понесли финансовые потери из-за сбоев в IT-системах в 2024 году. SuccessCorp. Дата обращения: 4 ноября 2025. Архивировано 21 июня 2025 года.
  79. ↑ Ключевые риски цифровой трансформации бизнеса. CyberLeninka. Дата обращения: 4 ноября 2025.
  80. ↑ Дайджест трендовых уязвимостей. Август 2024. Positive Technologies. Дата обращения: 4 ноября 2025.
  81. ↑ 1 2 Почти две трети российских компаний испытывают трудности с обеспечением бесперебойной работы ИТ-инфраструктуры. ComNews (29 августа 2023). Дата обращения: 4 ноября 2025. Архивировано 23 июня 2025 года.
  82. ↑ Непрерывность бизнеса в условиях глобального карантина. Forbes.kz. Дата обращения: 4 ноября 2025.
  83. ↑ DRaaS: как использовать аварийное восстановление в облаке. mClouds (август 2024). Дата обращения: 4 ноября 2025. Архивировано 11 сентября 2024 года.
  84. ↑ Backup Solutions for Small Business (англ.). is*hosting. Дата обращения: 4 ноября 2025. Архивировано 20 мая 2025 года.
  85. ↑ Обеспечение непрерывности бизнеса. Облакотека. Дата обращения: 4 ноября 2025. Архивировано 13 июня 2025 года.
  86. ↑ ISO 27001 Annex A 8.13 Information Backup (англ.). High Table. Дата обращения: 4 ноября 2025. Архивировано 14 июля 2025 года.
  87. ↑ NIST CSF 2.0 Updates on Backup and Recovery (англ.). Acsense. Дата обращения: 4 ноября 2025. Архивировано 17 мая 2025 года.

Литература

  • Месье, W. F. мл. Аудит и услуги обеспечения достоверности: систематический подход : [англ.]. — 8-е. — Нью-Йорк : McGraw-Hill/Irwin, 2011. — ISBN 9780077520151.
  • Гальегос, Ф. Контроль и аудит информационных технологий : [англ.] / Ф. Гальегос, S. Зенфт, A. L. Дэвис. — 4-е. — Boca Raton, FL : Auerbach Publications, 2012. — ISBN 9781439893203.

Категории