Инцидент произошел: данные уничтожены, система простаивала длительное время, услуги не оказаны, клиенты ушли. Вы открываете договор с подрядчиком и обнаруживаете, что формально он выполнил все обязательства: SLA соблюден, метрики в норме, претензий по бумагам нет. Тем не менее компания понесла вполне реальный бизнес-ущерб.

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

• Сценарий первый: инцидент есть, ущерб очевиден, виноватых нет. Система упала, но подрядчик восстановил ее в рамках согласованного времени. Время реакции — в пределах SLA. Все по договору. То, что за эти часы бизнес потерял выручку и репутацию, в договоре не фигурирует.
• Сценарий второй: регламент соблюден, а система пострадала.Подрядчик проводил регламентные работы: все прошло по графику, в окно согласованного времени. Но в процессе был задет соседний сегмент сети — и он «лег». Подрядчик выявил проблему только после жалобы пользователей, устранил ее в рамках SLA. Формально — никаких нарушений. По факту — бизнес потерял полдня работы отдела.
• Сценарий третий: ТЗ согласовали, подписали, но не договорились. Заказчик и подрядчик согласовали техзадание. Подрядчик выполнил работы в срок, система была запущена. Но спустя неделю выясняется: заказчик ожидал одного функционала, а получил другой. Формально — все по ТЗ. Просто формулировки в документе были размытыми и привели к двум разным трактовкам. В итоге — доработки за новые деньги.

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

Что нужно зафиксировать до старта
Договориться заранее о времени простоя
Любые работы по изменению или модернизации инфраструктуры влекут остановку систем. Это нормально. Ненормально, когда заказчик узнает о простое по факту. Поэтому в договоре должно быть зафиксировано: когда начнутся технические работы, сколько продлятся, когда система будет возвращена в работу. Под это закладывается резерв на форс-мажор. Все стороны уведомлены заранее.

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

Определить критерии приемки — конкретные, а не общие
«Система работает корректно» — не критерий. «Почтовый сервер доступен для всех пользователей в рабочее время, время доставки письма не превышает 30 секунд» — критерий. Именно по нему принимается работа, и именно он становится основой для претензий, если что-то пошло не так.

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

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

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

Конфиденциальность: почему NDA подписывают до договора
Соглашение о неразглашении — отдельная история. Многие воспринимают его как формальность, которую подписывают вместе с основным договором. Это ошибка.

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

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

В договоре прописывается и финансовая ответственность за разглашение: если утечка данных произошла по вине подрядчика и этот факт доказан, заказчик вправе предъявить финансовые претензии. Формулировка с оговоркой «при условии доказанности» — важный элемент: она делает пункт реалистичным, а не формальным.

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

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

Когда ответственный один — есть с кого спросить. Когда двое — начинается «это сделал не я».

Страхование ИТ-рисков: рынок развивается, но требования высокие
Отдельного обсуждения заслуживает тема страхования киберрисков. Рынок в России пока еще молодой, тем не менее уже заметный: в 2025 году он вырос на 20–30%, страховые взносы прибавили 60%. В 2026 году рост продолжится, аналитики прогнозируют диапазон в 10–30%.

Что вообще покрывает страхование ИТ-рисков? Утечку данных, простой бизнеса, оборотные штрафы за нарушение законодательства о персональных данных. Последнее — особенно актуально: с 30 мая 2025 года штрафы за утечки персональных данных существенно выросли. 

За первичную утечку грозит от 3 млн руб., за очень крупную (более 100 тыс. человек) или за спецкатегории данных — 15 млн. При этом Верховный суд в 2026 году подтвердил: ответственность несет оператор персональных данных, а не подрядчик — даже если фактический доступ к системе был у него. 

Впрочем, застраховаться легким и простым способом не получится. Страховая компания перед заключением договора потребует аудит инфраструктуры: либо от аккредитованной ИТ-компании, либо проведет его своими силами за отдельную плату. Аудит нужен, чтобы убедиться, что меры защиты реально внедрены, а не существуют только на бумаге. Только после этого страховая будет готова обсуждать условия.

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

Что делать, если инцидент уже случился
Даже при грамотно составленном договоре спорные ситуации могут все равно возникнуть, и ключевая задача — урегулировать их до перехода в претензионную плоскость. Судебное разбирательство — это дорого, долго и разрушает рабочие отношения.

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

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

Что важно зафиксировать до подписания
Договор с ИТ-подрядчиком защищает бизнес ровно настолько, насколько точно в нем прописаны условия. По моему опыту, перед подписанием нужно убедиться, что:

• время простоя при технических работах согласовано и задокументировано;
• ответственность за сохранность данных явно возложена на подрядчика с момента начала работ;
• соглашение о неразглашении NDA подписано до передачи любой технической информации и организации доступа к инфраструктуре;
• критерии приемки сформулированы конкретно;
• зоны ответственности разграничены (кто управляет каким сегментом инфраструктуры и на какой период).

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

Что в итоге
Ответственность ИТ-подрядчика не должна быть размытой. Она начинается с договора: измеримые критерии приемки, согласованное время простоя, ответственность за сохранность данных и конфиденциальность. До старта работ — NDA, плюс подготовлены резервные копии до внесения изменений в систему. Весь процесс работ важно четко поделить на зоны: один сегмент — один ответственный.

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