Договор на IT-обслуживание: какие пункты важны и на что смотреть

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

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

Зачем нужен хороший договор

Договор на IT-обслуживание решает три задачи, и ни одну из них нельзя закрыть «на доверии».

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

Вторая — задать измеримые обязательства по срокам. IT-сбой стоит денег за каждый час простоя. Договор без SLA (Service Level Agreement — соглашение об уровне сервиса) не даёт заказчику рычага: подрядчик «приедет, когда сможет», и формально ничего не нарушит. SLA превращает обещание «мы быстро» в проверяемое «реагируем за N минут, восстанавливаем за N часов».

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

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

Ключевые разделы договора

Ниже — разделы, которые в рабочем договоре на IT-обслуживание должны быть проработаны. Это не юридический шаблон, а перечень содержательных блоков, на которые смотрит заказчик.

1. Предмет и состав услуг

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

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

2. SLA с метриками

SLA — сердце договора на IT-обслуживание. Он должен оперировать числами, а не прилагательными. Минимальный набор метрик:

• Классификация инцидентов по приоритетам — обычно от критичного (сервер/сеть/1С недоступны для всех) до низкого (вопрос одного пользователя). Для каждого приоритета — свои сроки.
• Время реакции — за сколько подрядчик подтверждает приём заявки и начинает работу. Для критичных инцидентов это минуты, для рутинных — часы.
• Время восстановления — целевой срок устранения. Здесь важна честная формулировка: время восстановления часто зависит от факторов вне контроля подрядчика (поломка оборудования, сроки поставщика, авария у провайдера). Корректный SLA это учитывает.
• Доступность сервиса — целевой процент аптайма (например, 99,9%), если подрядчик отвечает за конкретные системы.
• Режим поддержки — 8×5 (рабочее время) или 24×7 (круглосуточно). Разница в цене и в смысле существенная.

Подробный разбор того, как устроен SLA именно в договоре аутсорсинга, мы давали в материале «SLA в IT-аутсорсинге: что должно быть в договоре». Базовую теорию термина — на странице вики SLA.

3. Время реакции и восстановления

Это часть SLA, но стоит вынести отдельно, потому что именно здесь чаще всего спрятан подвох. Опасная конструкция — когда в договоре есть только «время реакции», а «время восстановления» отсутствует. Подрядчик формально отреагировал за 15 минут («приняли заявку»), а чинит потом сутками — и нарушения нет. Рабочий договор фиксирует обе метрики и разделяет их: реакция (приняли и начали) и восстановление (вернули сервис в строй). Желательно — с разными числами под разные приоритеты инцидентов.

4. Штрафы и финансовая ответственность за SLA

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

5. Конфиденциальность и информационная безопасность

Подрядчик по IT-обслуживанию получает доступ к самому чувствительному: серверам, базам, паролям, иногда персональным данным сотрудников и клиентов. Раздел должен закрывать: обязанность хранить конфиденциальность, правила доступа сотрудников подрядчика к системам, порядок хранения и передачи паролей, ведение журнала доступа, обязанность уведомить об инциденте ИБ. Если в обслуживании затрагиваются персональные данные, появляется отдельный пласт — требования 152-ФЗ (Федеральный закон «О персональных данных»), и здесь без юриста точно не обойтись.

6. Ответственность и её пределы

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

7. Передача дел и знаний

Раздел, о котором вспоминают слишком поздно. В договоре должна быть прописана обязанность подрядчика при расторжении: передать актуальную документацию (схемы сети, паспорта систем), все пароли и доступы, лицензии, оформленные на заказчика, и сопроводить нового исполнителя в течение переходного периода. Без этого пункта смена подрядчика превращается в выкуп заложников. Заодно стоит проверить, что доступы и лицензии изначально оформлены на компанию-заказчика, а не на физлицо конкретного инженера.

8. Порядок расторжения

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

9. Акты и отчётность

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

Красные флаги формулировок

Несколько формулировок, которые в договоре на IT-обслуживание должны включить внимание. Каждая из них не обязательно «обман» — но повод задать вопрос и при необходимости поправить.

• «Услуги оказываются в разумные сроки». «Разумный срок» — это отсутствие срока. Под него подходит и час, и неделя. Нужны числа.
• «Исполнитель прилагает максимальные усилия». Звучит красиво, не обязывает ни к чему измеримому. Усилия невозможно проверить — результат и срок можно.
• SLA есть, штрафов нет. Метрики прописаны, а последствий за их нарушение в договоре нет. Значит, метрики ни к чему не обязывают.
• Только «время реакции», без «времени восстановления». Классическая ловушка: отреагировали быстро, чините бесконечно.
• Ответственность ограничена символической суммой (например, 10% месячной платы) при том, что простой стоит бизнесу кратно дороже.
• Нет ни слова о передаче дел при расторжении. Прямой риск остаться без паролей и документации.
• Асимметричное расторжение: подрядчику легко уйти, заказчику — дорого и долго.
• Доступы и лицензии на физлицо. Если в договоре или на практике пароли и подписки оформлены на конкретного инженера, при его уходе компания теряет контроль над собственной инфраструктурой.
• Размытый предмет вида «обслуживание техники» без приложения с составом услуг — почва для бесконечных споров «входит / не входит».
• Автопролонгация с молчаливым согласием и одновременно жёсткий штраф за досрочный выход — связывает заказчика на годы.

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

Короткий проход по договору перед тем, как нести его юристу. Если на каком-то пункте ответ «нет» или «не нашёл» — это вопрос к подрядчику.

1. Предмет договора конкретен, есть приложение с составом услуг.
2. Чётко разграничено, что входит в абонентскую плату, а что оплачивается отдельно.
3. Есть SLA с классификацией инцидентов по приоритетам.
4. Прописано и время реакции, и время восстановления — отдельными числами.
5. Указан режим поддержки: 8×5 или 24×7.
6. Есть штрафы или сервисные кредиты за нарушение SLA.
7. Прописана конфиденциальность и правила доступа к системам.
8. Если затрагиваются персональные данные — есть отсылка к требованиям 152-ФЗ (проверяет юрист).
9. Понятен предел ответственности подрядчика, и он соотнесён с реальной ценой простоя.
10. Есть раздел о передаче дел и знаний при расторжении.
11. Доступы и лицензии оформлены на компанию-заказчика, а не на физлицо.
12. Порядок расторжения симметричен для обеих сторон.
13. Прописана периодическая отчётность и порядок подписания актов.
14. Нет красных флагов из раздела выше (либо они согласованы и понятны).
15. Реквизиты, сроки оплаты, порядок изменения цены — на месте.

Что остаётся юристу

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

К юристу — формулировки об ответственности и форс-мажоре, соответствие требованиям по персональным данным (152-ФЗ) и, если применимо, по объектам критической инфраструктуры, налоговые и договорные риски, корректность претензионного и судебного порядка, проверка полномочий подписанта и реквизитов сторон. Мы как подрядчик помогаем сделать договор содержательно рабочим со стороны IT — но не заменяем правовую экспертизу. Это честная граница: каждый отвечает за свою зону.

Роль аутсорсера в договоре

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

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

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

FAQ

Чем договор на IT-обслуживание отличается от обычного договора оказания услуг?

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

Что важнее в договоре — низкая цена или прописанный SLA?

SLA. Цена без измеримых обязательств по времени реакции и восстановления превращается в абонентскую плату «за доброе слово»: формально подрядчик обслуживает, по факту сроки реакции не зафиксированы и не подлежат проверке. Низкая цена при отсутствии SLA почти всегда означает, что критичные инциденты вы будете решать в режиме переписки без рычага.

Нужно ли отдельно прописывать конфиденциальность, если есть NDA?

Раздел о конфиденциальности и информационной безопасности полезно иметь в самом договоре, даже когда подписан отдельный NDA (Non-Disclosure Agreement — соглашение о неразглашении). В договоре фиксируются практические вещи: кто из сотрудников подрядчика имеет доступ к каким системам, как хранятся пароли и доступы, что происходит с ними при расторжении, как ведётся журнал доступа. NDA закрывает обязанность хранить тайну, а раздел в договоре — операционные правила доступа. Это практический взгляд IT-подрядчика — финальную правовую оценку формулировок и их соответствие 152-ФЗ даёт юрист.

Какой срок передачи дел при расторжении считается нормальным?

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

Можно ли подписать типовой договор подрядчика без правок?

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

Кто должен составлять договор — заказчик или подрядчик?

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

Вывод

Договор на IT-обслуживание стоит читать не как формальность, а как инструкцию на случай сбоя. Девять разделов — предмет и состав услуг, SLA с метриками, время реакции и восстановления, штрафы, конфиденциальность и ИБ, пределы ответственности, передача дел, порядок расторжения, акты и отчётность — это каркас рабочего договора. Красные флаги вроде «разумных сроков», SLA без штрафов и отсутствия раздела о передаче дел проверяются за один проход по чек-листу.

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

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