7 рисков ИТ-аутсорсинга и как их закрыть договором

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

По опросу «СерчИнформ» за 2025 год, главный сдерживающий фактор при передаче ИБ-функции внешней команде — необходимость допуска третьих лиц к конфиденциальным данным. Страх описан верно, а вывод из него делают неправильный: отказаться от допуска нельзя, иначе подрядчик не сможет работать. Решается вопрос не отказом, а условиями, на которых допуск даётся, и последствиями, если им воспользуются не так, как вы рассчитывали.

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

Чем компания рискует на самом деле

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

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

Первая группа перестала быть теоретической. По исследованию УЦСБ SOC, не менее 30% всех подтверждённых кибератак в 2025 году были проведены через компрометацию ИТ-подрядчиков. Там же приводится другая цифра: средний объём одной утечки в России достиг 3,27 млн записей, на 26% больше, чем годом раньше. Для атакующего подрядчик — удобный путь к нескольким компаниям сразу, причём к компаниям, у которых безопасность нередко выстроена лучше, чем у него самого.

Договор остаётся единственным инструментом, который начинает действовать именно в момент инцидента.

Семь рисков в одной таблице

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

Доступ к инфраструктуре и персональные данные

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

Риск 1. Подрядчик становится точкой входа в ваш периметр

Типовая картина на старте: подрядчику выдают доменную учётку с правами администратора, добавляют в VPN, передают пароли от панелей управления. Через полгода этой учёткой пользуются пятеро инженеров поочерёдно, пароль лежит в их внутреннем хранилище, а кто именно заходил в контроллер домена в субботу вечером, установить невозможно.

Дальше ситуация развивается по одному из двух сценариев. Инженер по ошибке удаляет не то, и вы не можете ни доказать, кто это сделал, ни оценить, что ещё он успел посмотреть. Либо инфраструктуру подрядчика взламывают, и вместе с его доступами атакующий получает ваши. Второй сценарий и даёт те 30% атак из исследования УЦСБ: ломать защищённую крупную компанию напрямую дороже, чем небольшого подрядчика с правами администратора у десяти заказчиков.

Что должно быть в договоре и в регламенте доступа к нему:

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

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

Риск 2. Ответственность за персональные данные остаётся на вас

Если подрядчик обслуживает серверы с CRM, почтой или 1С, он получает доступ к персональным данным ваших клиентов и сотрудников. Юридически это называется поручением обработки и регулируется статьёй 6 закона № 152-ФЗ. Важная деталь, которую часто упускают: по части 5 статьи 6 перед субъектом персональных данных отвечает оператор, то есть вы, в том числе за действия того, кому поручили обработку. Подрядчик отвечает перед вами, а не перед вашим клиентом и не перед Роскомнадзором.

Цена вопроса изменилась 30 мая 2025 года, когда вступили в силу поправки по закону № 420-ФЗ. Штрафы для организаций по статье 13.11 КоАП: от 3 до 5 млн рублей за утечку данных от 1 до 10 тысяч человек, от 5 до 10 млн при утечке до 100 тысяч, от 10 до 15 млн свыше этого. За повторную утечку штраф считается от выручки: от 1 до 3% за предыдущий календарный год, минимум 20 млн, максимум 500 млн рублей.

Отдельная ловушка — сроки. Статья 21 закона № 152-ФЗ требует уведомить Роскомнадзор в течение 24 часов с момента обнаружения утечки, а в течение 72 часов направить результаты внутреннего расследования. Если утечка произошла у подрядчика, а он сообщил вам о ней через неделю, нарушителем сроков будете вы.

Поэтому в договоре нужны:

• оформленное поручение обработки с обязательным составом по части 3 статьи 6: перечень данных, перечень действий, цели, обязанность соблюдать конфиденциальность, требования к защите, обязанность предоставлять по вашему запросу подтверждающие документы;
• срок уведомления вас об инциденте с данными, заведомо меньше 24 часов: на наших проектах мы закладываем от двух до шести часов, иначе заказчик не укладывается в собственный срок перед регулятором;
• обязанность участвовать во внутреннем расследовании и предоставить журналы;
• порядок возврата и уничтожения данных при завершении договора, с подтверждающим актом;
• регресс: право взыскать с подрядчика штраф, который вы заплатили из-за его действий.

Последний пункт вызывает самое длинное обсуждение на согласовании, и это нормально. Именно он превращает ответственность из формальной в настоящую.

SLA и ответственность

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

Риск 3. SLA, из которого ничего не следует

Фраза «время реакции — 1 час» не означает ничего, пока не определены три вещи: что считается реакцией, с какого момента идёт отсчёт и кто ведёт учёт.

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

С отсчётом сложнее. Инцидент начинается тогда, когда у вас встал сервис, а заявка регистрируется тогда, когда сотрудник дошёл до helpdesk. Между этими моментами проходит от десяти минут до нескольких часов, и всё это время по договору не считается.

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

Шкала критичности в договоре может выглядеть так:

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

Что ещё стоит проверить в разделе про сервис: окно обслуживания, потому что 8×5 и 12×7 означают разные деньги и разные обязательства; перечень исключений, в которых SLA не действует; обязанность предоставлять отчётность с установленной периодичностью и состав этой отчётности.

«Самый частый спор на действующих договорах идёт не про качество работ, а про то, когда началась заявка. У заказчика инцидент начался в 9:40, когда встала касса, у подрядчика — в 10:15, когда сотрудник написал в helpdesk. Поэтому мы отдельным пунктом описываем, что считается моментом регистрации и что делать, если об инциденте сообщили не через систему заявок», — Станислав Гуляев, ведущий технический эксперт ОБИТ.

Риск 4. Ответственность, ограниченная абонентской платой

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

Само ограничение законно. Верховный Суд в определении от 21 августа 2019 года № 307-ЭС19-5190 исходил из того, что закон не ограничивает размер убытков ценой договора, но стороны вправе такое ограничение установить. Пункт работает, и оспаривать его в суде придётся долго.

Исключение одно, и оно важное: по пункту 4 статьи 401 Гражданского кодекса заключённое заранее соглашение об устранении или ограничении ответственности за умышленное нарушение обязательства ничтожно. Ответственность за халатность ограничить можно, за умысел нельзя. На практике умысел трудно доказать, поэтому рассчитывать на эту норму как на основную защиту не стоит.

Рабочая конструкция выглядит так:

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

Лимит по инцидентам с данными в размере 10–20% годовой стоимости договора — вполне достижимое условие в переговорах. Если подрядчик отказывается обсуждать этот пункт в принципе, вы уже получили важную информацию о том, как он оценивает свои риски.

Зависимость и границы ответственности

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

Риск 5. Знания и доступы уходят вместе с подрядчиком

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

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

Что закрывает риск:

• обязанность вести документацию в вашей системе или передавать её по установленному графику, с перечнем обязательных документов;
• все учётные данные в вашем корпоративном хранилище секретов: подрядчик получает доступ, а не владение;
• принадлежность вам конфигураций, скриптов и схем, созданных в рамках договора;
• переходный период при расторжении, 30–60 дней, в которые подрядчик передаёт дела, отвечает на вопросы новой команды и проводит консультации, с оплатой по обычной ставке;
• порядок немедленного отзыва всех доступов в день прекращения договора, с актом;
• условия использования или замены собственного ПО подрядчика, если он работает на своём мониторинге, своей системе заявок и своих скриптах автоматизации.

«Проверить, не попали ли вы в зависимость, можно одним вопросом: если завтра договор закончится, сможет ли новый подрядчик войти в инфраструктуру без помощи прежнего. Если ответ отрицательный, дело обычно не в сложности инфраструктуры, а в том, что документация и пароли живут не у вас», — Станислав Гуляев, ведущий технический эксперт ОБИТ.

Риск 6. Серая зона: «этой системы нет в перечне»

Договор на обслуживание всегда содержит перечень объектов: столько-то рабочих мест, столько-то серверов, такое-то сетевое оборудование. Через год в компании появились новый филиал, два виртуальных сервера и система видеонаблюдения, которые в перечень никто не внёс. Пока всё работает, вопросов нет. Когда встаёт как раз эта система, выясняется, что обязательств по ней нет.

Та же история с функциями. Входит ли в «обслуживание серверов» установка обновлений? Настройка резервного копирования или только контроль того, что оно выполняется? Восстановление из резервной копии при потере данных? У заказчика и подрядчика ответы расходятся ровно в тот момент, когда данные уже потеряны.

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

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

Люди, которые работают на вашей инфраструктуре

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

Риск 7. Состав команды и субподряд

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

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

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

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

Как подойти к договору перед подписанием

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

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

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