76,8% компаний закладывают на восстановление ИТ-среды больше четырех часов

До восьми часов требуется 19,6% организаций, до 12 часов – 17%, до суток – 20,6%; еще 21,6% рассчитывают на восстановление от двух суток до недели и более. Одновременно доля компаний, столкнувшихся с вымогателями, выросла с 22% в 2025 году до 25% в 2026-м.

Резервные копии есть у большинства, но сами по себе они не гарантируют быстрого возврата сервисов в работу. Логический или физический air gap используют 75,6% организаций, неизменяемые копии есть у 62,8%. Однако после крупной атаки требуется восстановить не один сервер и не отдельную базу данных. В работу нужно вернуть виртуализацию, сеть, доменную инфраструктуру, системы аутентификации, средства защиты, прикладные сервисы, базы данных, интеграции с контрагентами, сертификаты, ключи шифрования и учетные записи администраторов. Сбой на любом из этих уровней сдвигает запуск зависимых систем, даже когда данные уже доступны.

Почти половина компаний, 48,2%, установили RTO менее четырех часов. Полное восстановление ИТ-среды за тот же срок подтверждают только 17%. Эти цифры показывают разницу между нормативом для отдельного сервиса и реальной готовностью вернуть в работу весь технологический контур. Разрыв в 31 процентный пункт – это разница между тем, что написано в политике непрерывности, и тем, что происходило в последнем реальном инциденте. В последнем тесте или инциденте 26,8% организаций не уложились в собственный RTO. Чаще всего проблема проявляется не в скорости развертывания резервной копии, а на этапе проверки целостности данных, синхронизации зависимых систем и подтверждения, что среда не содержит следов компрометации.

Проверку восстановления из резервных копий за последние 12 месяцев проводили 50,8% организаций. Сценарий восстановления после кибератаки тестировали лишь 34,6%. Разница существенна: отказ оборудования и компрометация инфраструктуры требуют разных действий. Почти треть компаний, планируя DR, репетирует не тот сценарий: развернуть бэкап после сгоревшего диска и развернуть бэкап, в котором, возможно, сидит шифровальщик, – разные по сложности задачи, а тестируют обычно только первую. После аппаратной аварии ИТ-команда может развернуть известную рабочую конфигурацию. После ransomware, захвата привилегированных учетных записей или внутреннего инцидента сначала приходится устанавливать масштаб проникновения, изолировать скомпрометированные сегменты, менять пароли и ключи, проверять резервные копии на отсутствие вредоносного кода. Среди организаций, которые высоко оценивают свою способность противостоять ransomware, 57% вообще не тестировали восстановление после кибератаки.

Векторы атак дополнительно усложняют расчеты. С вредоносным ПО столкнулись 42,6% участников исследования, с фишингом – 30,6%, с ИИ-атаками и дипфейками – 24,6%, с ransomware – 22,4%, с социальной инженерией – 21%, с внутренними нарушениями – 15,2%, с DDoS – 14,4%. Из всех векторов ИИ-угрозы выросли быстрее прочих – вдвое за год, обогнав по динамике даже ransomware. Тревожно не количество дипфейков, а то, что они бьют по самому слабому месту DR-плана – верификации личности при восстановлении привилегированного доступа. Вредоносное ПО и шифровальщики ставят под вопрос чистоту резервных копий. Фишинг и социальная инженерия нередко дают злоумышленникам доступ к административным учетным записям, поэтому восстановление приходится начинать с контура идентификации и управления доступом. DDoS не повреждает данные, но может заблокировать внешние каналы и помешать возвращать клиентские сервисы в штатный режим. Внутренний нарушитель способен изменить конфигурации, удалить журналы событий и нарушить работу самих процессов резервного копирования.

Сложность ИТ-ландшафта назвали главным препятствием для повышения устойчивости 38% организаций. Дефицит специалистов мешает 32,4% компаний, недостаточная интеграция процессов устойчивости – 29,2%, зависимость от поставщиков – 26,4%, устаревшие системы – 26%. Каждый внешний элемент в цепочке восстановления – облачная консоль, лицензионный сервер, API подрядчика - точка, где план может остановиться не по вине ИТ-команды, а потому что нужный человек у вендора недоступен в 3 часа ночи. . Почти половина участников исследования, 44%, уже переносили часть данных или систем из публичного облака в частную или локальную среду ради контроля, безопасности либо устойчивости. Еще 30,8% рассматривают такой перенос в ближайшие 12 месяцев.

В выборке наиболее широко представлены технологические компании – 40,4%, банковский и финансовый сектор – 9,2%, ритейл – 8,6%, производство – 7,8% и профессиональные услуги – 6%. Цена часа простоя разная по отраслям: для ритейла это остановленная касса и склад, для банка - недоступные платежи, для производства - стоящий конвейер. Одинаковый RTO в четыре часа означает разный уровень ущерба в зависимости от того, что именно стоит.

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