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

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

Статья пригодится тем, кто готовит или согласовывает договор со стороны заказчика: ИТ-директору, руководителю ИТ-отдела, юристу, которому принесли подрядчиков шаблон на вычитку.

Что это за договор с точки зрения права

Отдельного вида договора «на ИТ-обслуживание» в законе нет. По своей природе это договор возмездного оказания услуг, и к нему применяется глава 39 Гражданского кодекса. Из статьи 779 следует главное: предметом услуги считаются действия или деятельность исполнителя. Овеществлённого результата здесь нет: подрядчик обязуется обслуживать инфраструктуру, и обязанность гарантировать, что она не сломается, из закона не вытекает.

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

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

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

Структура договора: какие разделы должны быть

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

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

Предмет договора и перечень услуг

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

Что входит в обслуживание

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

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

Перечень обслуживаемого оборудования и ПО

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

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

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

Что в обслуживание не входит

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

Соглашение об уровне сервиса

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

Приоритеты обращений

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

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

Время реакции и время решения

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

Числа в таблице — типовой ориентир для офисной инфраструктуры среднего размера. Под конкретную компанию они пересчитываются: для склада, который работает в три смены, «рабочие часы» означают другое, а для торговой сети сроки по кассовому узлу жёстче, чем по офисному принтеру.

Часы обслуживания и дежурство

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

Доступность и как её считают

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

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

Порядок взаимодействия и зоны ответственности

Этот раздел определяет, откуда берутся данные для SLA. Без него соглашение об уровне сервиса не работает: невозможно посчитать время решения, если не зафиксировано время старта.

Каналы обращений и регистрация

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

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

Отчётность за период закрывает контроль. Минимум: количество обращений по приоритетам, соблюдение сроков, перечень нарушений SLA, выполненные плановые работы. Отчёт удобно сделать основанием для подписания акта.

Матрица ответственности

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

Обязанности заказчика

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

Цена, расчёты и работы вне абонентской платы

Цена описывается так, чтобы было понятно, что меняется при изменении объёма. Фиксированная абонентская плата, привязанная к перечню из приложения, — основной вариант. К ней нужны ставки на то, что в абонемент не входит: часовая ставка инженера, ставка за выезд, ставка за работы вне часов обслуживания, стоимость обслуживания дополнительной единицы оборудования или рабочего места.

Что проверить в этом разделе:

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

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

Конфиденциальность и персональные данные

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

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

Поручение на обработку персональных данных

Это обязательный документ. По части 3 статьи 6 закона № 152-ФЗ, если оператор поручает обработку персональных данных другому лицу, в поручении должны быть указаны перечень персональных данных, перечень действий с ними, цели обработки, обязанность соблюдать конфиденциальность и обеспечивать безопасность, требования к защите по статье 19 того же закона, а также обязанность подрядчика по запросу оператора представлять документы, подтверждающие соблюдение требований, в том числе до начала обработки.

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

Отдельно стоит срок уведомления об инциденте. Оператор обязан сообщить в Роскомнадзор об утечке в течение 24 часов, а о результатах внутреннего расследования — в течение 72 часов. Значит, подрядчик должен уведомить заказчика существенно быстрее: практический ориентир — два-четыре часа с момента обнаружения. Цена вопроса выросла: с 30 мая 2025 года по закону № 420-ФЗ штраф для юридического лица за утечку составляет от 3 до 15 миллионов рублей в зависимости от числа пострадавших, за повторную — от 1 до 3% годовой выручки, но не менее 20 миллионов, а за неуведомление регулятора — от 1 до 3 миллионов.

Привилегированный доступ

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

Ответственность и выход из договора

Пределы ответственности

Неустойка за нарушение SLA — рабочий инструмент, но только если её размер сопоставим с ущербом. Скидка 1% от месячной платы за сутки простоя никого ни к чему не мотивирует. Практичная схема — прогрессивная шкала: процент от абонентской платы за каждый час или сутки нарушения, с нарастанием и с потолком.

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

Передача дел при расторжении

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

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

Коротко о главном

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

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

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