Когда подрядчик — это риск
В 2026 году основу работы почти каждого крупного бизнеса составляют подрядчики. Например, инфраструктуру обслуживает интегратор. Систему управления производством сопровождает внешняя команда. Резервные копии делает сторонний сервис, а мониторинг безопасности ведет внешний центр.
Руководство при этом убеждено: «У нас все на аутсорсе, значит, все под контролем». И вот здесь начинается самая опасная иллюзия последних лет — ведь большинство серьезных инцидентов в промышленности, ретейле и других отраслях бизнеса происходят не потому, что не было технологий, а потому, что никто не отвечает за конечный результат.
Как это выглядит в реальности
Несколько лет назад для одной промышленной компании я выступал в роли внешнего эксперта по кризисному реагированию. Произошел следующий кейс. Производство полного цикла, несколько линий, круглосуточная работа, миллионы рублей оборота в час. Инфраструктура была выведена на аутсорс, поскольку руководство полагало, что так легче: у подрядчиков узкопрофильные специалисты, а не ноунеймы с рынка. Резервные копии делались по той же логике, а отчеты предоставлялись регулярно: совет директоров был в восторге от красивых информативных графиков и лишних вопросов никто не задавал.
Ночью случилась компрометация служебной учетной записи. Через нее — доступ к домену, а оттуда — к серверам. Началось шифрование.
Созваниваемся. Для каждого лица ситуация выглядела по-своему.
Подрядчик говорит: «Мы реагируем».
ИТ говорит: «Нужно согласование на отключение».
Руководство требует немедленного восстановления.
Бэкапы есть, но восстановление занимает больше суток. Планировали устранить инцидент за четыре часа, а получилось за тридцать.
Почему? Потому что никто никогда не тестировал реальное восстановление под нагрузкой. Потому что время восстановления существовало лишь в презентации, но не было закреплено как обязательство. Потому что в договоре написано «обеспечивает резервное копирование», а не «гарантирует восстановление бизнеса в X часов».
Подрядчик формально ничего не нарушил. Но бизнес потерял сутки производства. И это не единичная история.
Что произошло в 2025 году публично
В 2025 году крупный автопроизводитель был вынужден останавливать сборочные линии после атаки, которая пришла через подрядчика. Остановка продлилась на недели. Поставщики простаивали. Цепочка поставок посыпалась. Формально атаковали компанию. Фактически — атаковали слабое звено в цепочке.
Еще один случай — крупная розничная сеть. Атака через внешнего поставщика ИТ-услуг. Несколько дней парализованы логистика и заказы. Пустые полки. Миллионные потери. И снова — технологии были, а вот управляемости зависимости нет.
Или недавний инцидент с крупной авиакомпанией, где утечка персональных данных произошла не из-за взлома ее инфраструктуры напрямую, а через подрядчика, обслуживавшего контакт-центр. Клиенты пострадали. Репутация — тоже.
Все эти истории объединяет одно: проблема не в отсутствии средств защиты. Проблема в том, что зависимость от подрядчика не была встроена в модель управления риском.
Почему соглашение об уровне сервиса не спасает
Я часто слышу: «У нас все прописано. Время реакции — 30 минут».
Скажите честно: вам что важнее — чтобы специалист ответил через 30 минут или чтобы система управления производством заработала через 4 часа?
В одном FMCG-кейсе подрядчик отреагировал быстро. Все по регламенту. Но изоляция зараженного сегмента заняла 5 часов, потому что подрядчик не имел закрепленного права отключать сервер без письменного подтверждения заказчика. За это время вредоносное ПО распространилось дальше.
Если в договоре не указано время восстановления, нет порядка аварийного отключения, нет приоритета сервисов, то это не инструмент устойчивости. Это документ для спокойствия.
Бизнесу важно четко знать три вещи:
- за сколько часов восстановится критичная система;
- кто принимает решение в кризисе;
- кто отвечает за последствия, если время превышено.
Если этого нет — у вас не управление, а надежда на лучшее.
Где проходит граница между интегратором и заказчиком
Самый неудобный вопрос, который редко обсуждают на старте проекта — это граница ответственности. И вот здесь я скажу честно как человек, который работает на стороне интегратора. Интегратор отвечает за операционную реализацию: архитектуру, настройку, обновления, сопровождение, контроль конфигураций. Это наша зона. И если мы взялись за проект — мы обязаны профессионально нести ответственность за эту область.
Но интегратор не может в одиночку определить, что для конкретного бизнеса критично и сколько стоит простой. Мы можем предложить модель, показать риски, посчитать сценарии. Но финальное решение о допустимом времени простоя и приоритетах восстановления — это управленческий выбор заказчика.
Если собственник или генеральный директор не зафиксировал, что для него критично, не утвердил приоритеты сервисов, не согласовал порядок аварийной остановки, то в кризисе никто не сможет действовать жестко и быстро.
Поэтому в наших проектах мы принципиально делаем одну вещь заранее: до запуска решения мы фиксируем модель кризисного реагирования:
- кто имеет право изолировать сегмент при атаке;
- кто принимает решение об аварийной остановке;
- какой сервис поднимается первым;
- какой реальный целевой срок восстановления согласован и подтвержден тестом.
Мы не оставляем это «на потом». Потому что «потом» — это обычно 02:47 ночи и остановленное производство.
Интегратор не должен быть сторонним персонажем. Но и подменять собой управленческую функцию бизнеса он не может. Ответственность должна быть распределена осознанно. Если граница размыта — в момент атаки начинается паралич. Если она проговорена, зафиксирована и проверена на учениях — появляется управляемость. Я видел обе модели. Разница — в миллионах рублей и в количестве бессонных ночей.
Почему пилот — это мина замедленного действия
Большинство пилотов — это демонстрация интерфейса. Система работает. Отчеты строятся. Все красиво.
Но никто не проверяет, как система поведет себя при реальной нагрузке. Никто не моделирует одновременный отказ нескольких сервисов. Никто не фиксирует пределы масштабирования.
В одном промышленном кейсе система мониторинга безопасности прошла пилот на тестовом объеме данных. После выхода в промышленную эксплуатацию поток событий оказался в три раза выше. Часть событий перестала анализироваться. Формально система внедрена, фактически видимость снизилась.
Пилот должен фиксировать ограничения. Если он этого не делает — вы покупаете иллюзию.
Санкции. Почему штрафы не работают
Штраф в 5% от ежемесячного платежа не мотивирует подрядчика строить резервную архитектуру. Если час простоя стоит компании миллионы, а ответственность подрядчика ограничена символической суммой, модель не работает.
Реально дисциплинирует только то, что связано со временем восстановления и его превышением.
Если подрядчик знает, что превышение согласованного времени восстановления обойдется ему дорого, он будет инвестировать в процессы, резервирование и контроль. Если нет — он будет выполнять договор. И это логично.
Киберстрахование
Отдельная иллюзия последних лет — страхование киберрисков как «последний рубеж». Многие собственники думают так: если что-то случится, страховая компенсирует убытки. Но в реальности страхование работает только тогда, когда у вас выстроены процессы. Страховая компания не платит за хаос. Она платит за подтвержденный управляемый риск.
В 2025 году несколько крупных компаний столкнулись с отказами в компенсациях именно потому, что не могли документально подтвердить регулярное тестирование восстановления, контроль привилегированных действий и соблюдение регламентов реагирования. Если вы не можете показать, когда в последний раз тестировали резервное восстановление, кто имел административный доступ и как фиксировались его действия, страхование превращается в спор юристов, а не в финансовую защиту.
Без корректной договорной архитектуры с подрядчиком страховой полис — это бумага. Потому что страховая всегда задает один вопрос: а вы сами управляли риском или просто надеялись?
Технологии — это не галочки, а фиксаторы ответственности
Сегментация сети нужна не ради моды, а чтобы заражение не гуляло по всей инфраструктуре.
Контроль привилегированных доступов нужен не ради отчета, а чтобы фиксировать действия подрядчиков.
Доступ по принципу «нулевого доверия» нужен не ради красивого слова, а чтобы убрать постоянные «дыры» в виде доверенных подключений.
Независимые проверки и стресс-тесты нужны не ради презентации, а чтобы проверить реальность.
Если эти инструменты не встроены в модель ответственности, они превращаются в декорацию.
Проверьте себя
Если вы генеральный директор, ИТ-директор или директор по безопасности — задайте себе несколько простых вопросов.
- Сколько реально занимает восстановление критичной системы?
- Когда вы последний раз тестировали это не на бумаге, а в реальности?
- Кто имеет право отключить зараженный сегмент в 3 часа ночи?
- Фиксируются ли действия подрядчика с административными правами?
- Сколько стоит час простоя вашего бизнеса?
Если вы не знаете ответов — у вас не управляемость. У вас доверие и зависимость. А доверие и зависимость — плохая стратегия для 2026 года.
Советы для инженера
Если вы инженер и понимаете, что зависимость от подрядчика выглядит опасно — не надо идти к руководству со словами «у нас все плохо». Руководству не интересны эмоции. Руководству интересны цифры и последствия.
Чтобы доказательно подсветить проблему, сделайте три вещи.
Первое — зафиксируйте фактическое время восстановления. Не теоретическое, не из регламента, а реальное. Проведите тест. Поднимите систему из резервной копии. Замерьте время. Это самый сильный аргумент. Когда вместо «примерно 4 часа» на стол ложится «27 часов», разговор становится другим.
Второе — опишите критичность сервисов в бизнес-метриках. Не «ERP важна», а «час простоя ERP = X рублей прямых потерь + Y репутационных». Даже приблизительная оценка меняет восприятие. Руководство мыслит не серверами, а деньгами.
Третье — покажите зону размытости ответственности. Возьмите реальный сценарий инцидента и разберите его пошагово: кто принимает решение об изоляции? Кто подтверждает? Кто запускает восстановление? Где требуется согласование?
Если в этой схеме больше двух уровней согласований — вы покажете управленческий риск, а не техническую проблему.
И главное — не приходите с требованием «нужно срочно внедрить еще одну систему». Приходите с формулировкой: «У нас есть неопределенность в зоне ответственности, которая может стоить бизнесу X миллионов. Вот факты».
Когда разговор переводится в плоскость управляемости и денег, а не «айтишной тревожности», вас начинают слушать.
Итог
Подрядчик — это не ваш враг. Но и не спаситель. Он — элемент вашей модели риска. И если вы не встроили его в управляемую архитектуру ответственности, он станет вашим слабым звеном.
В момент следующего инцидента не будет времени на обсуждение договора. Будет только счетчик простоя и вопрос: кто отвечает? Если ответа нет — значит, вы все это время играли в безопасность.
Опубликовано 04.03.2026
