В 2026 году основу работы почти каждого крупного бизнеса сейчас составляют подрядчики. Например, инфраструктуру обслуживает интегратор. Систему управления производством сопровождает внешняя команда. Резервные копии делает сторонний сервис, а мониторинг безопасности ведёт внешний центр.

Руководство при этом убеждено: «У нас всё на аутсорсе, значит, всё под контролем».

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

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

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

Ночью случилась компрометация служебной учётной записи. Через неё — доступ к домену, а оттуда — к серверам. Началось шифрование.

Созваниваемся. Для каждого лица ситуация выглядела по-своему.

Подрядчик говорит: «Мы реагируем».
ИТ говорит: «Нужно согласование на отключение».
Руководство требует немедленного восстановления.

Бэкапы есть, но восстановление занимает больше суток. Планировали устранить инцидент за четыре часа, а получилось за тридцать.

Почему? Потому что никто никогда не тестировал реальное восстановление под нагрузкой. Потому что время восстановления существовало лишь в презентации, но не было закреплено как обязательство. Потому что в договоре написано «обеспечивает резервное копирование», а не «гарантирует восстановление бизнеса в X часов».

Подрядчик формально ничего не нарушил. Но бизнес потерял сутки производства.

И это не единичная история.

Что произошло в 2025 году публично
В 2025 году крупный автопроизводитель был вынужден останавливать сборочные линии после атаки, которая пришла через подрядчика. Остановка длилась неделями. Поставщики простаивали. Цепочка поставок посыпалась. Формально атаковали компанию. Фактически — атаковали слабое звено в цепочке.

Ещё один случай — крупная розничная сеть. Атака через внешнего поставщика ИТ-услуг. Несколько дней парализованы логистика и заказы. Пустые полки. Миллионные потери. И снова — технологии были, а вот управляемости зависимости нет.

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

Все эти истории объединяет одно: проблема была не в отсутствии средств защиты. Проблема была в том, что зависимость от подрядчика не была встроена в модель управления риском.

Почему соглашение об уровне сервиса не спасает
Я часто слышу: «У нас всё прописано. Время реакции — 30 минут».

Скажите честно: вам что важнее — чтобы специалист ответил через 30 минут или чтобы система управления производством заработала через 4 часа?

В одном FMCG-кейсе подрядчик отреагировал быстро. Всё по регламенту. Но изоляция заражённого сегмента заняла пять часов, потому что подрядчик не имел закреплённого права отключать сервер без письменного подтверждения заказчика. За это время вредоносное ПО распространилось дальше.

Если в договоре нет времени восстановления, нет порядка аварийного отключения, нет приоритета сервисов, то это не инструмент устойчивости. Это документ для спокойствия.

Бизнесу важно четко знать три вещи:

  • за сколько часов восстановится критичная система;
  • кто принимает решение в кризисе;
  • кто несёт последствия, если время превышено.

Если этого нет — у вас не управление, а надежда на лучшее.

Где проходит граница между интегратором и заказчиком
Самый неудобный вопрос, который редко обсуждают на старте проекта — это граница ответственности.

И вот здесь я скажу честно как человек, который работает на стороне интегратора.

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

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

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

Поэтому в наших проектах мы принципиально делаем одну вещь заранее: до запуска решения мы фиксируем модель кризисного реагирования:

  • кто имеет право изолировать сегмент при атаке
  • кто принимает решение об аварийной остановке
  • какой сервис поднимается первым
  • какой реальный целевой срок восстановления согласован и подтверждён тестом

Мы не оставляем это «на потом». Потому что «потом» — это обычно 02:47 ночи и остановленное производство.

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

Если граница размыта — в момент атаки начинается паралич. Если она проговорена, зафиксирована и проверена на учениях — появляется управляемость.

Я видел обе модели. Разница — в миллионах рублей и в количестве бессонных ночей.

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

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

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

Пилот должен фиксировать ограничения. Если он этого не делает — вы покупаете иллюзию.

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

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

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

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

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

Без корректной договорной архитектуры с подрядчиком страховой полис — это бумага. Потому что страховая всегда задаёт один вопрос: а вы сами управляли риском или просто надеялись?

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

Контроль привилегированных доступов нужен не ради отчёта, а чтобы фиксировать действия подрядчиков.

Доступ по принципу «нулевого доверия» нужен не ради красивого слова, а чтобы убрать постоянные «дыры» в виде доверенных подключений.

Независимые проверки и стресс-тесты нужны не ради презентации, а чтобы проверить реальность.

Если эти инструменты не встроены в модель ответственности, они превращаются в декорацию.

Проверьте себя
Если вы генеральный директор, ИТ-директор или директор по безопасности — задайте себе несколько простых вопросов.

1) Сколько реально занимает восстановление критичной системы?
2) Когда вы последний раз тестировали это не на бумаге, а в реальности?
3) Кто имеет право отключить заражённый сегмент в 3 часа ночи?
4) Фиксируются ли действия подрядчика с административными правами?
5) Сколько стоит час простоя вашего бизнеса?

Если вы не знаете ответов — у вас не управляемость. У вас доверие и зависимость.

А доверие и зависимость — плохая стратегия для 2026 года.


//Отключение проверки мультисайтовой конфигурации