Компании часто заключают договор на IT-услуги по шаблону из интернета, а затем обнаруживают, что подрядчик формально прав, хотя серверы месяцами работают с перебоями. Формулировки вроде «техническая поддержка» или «настройка оборудования» суды трактуют широко, и доказать невыполнение работ становится почти невозможно. Разбираем, какие разделы договора чаще всего создают риски для заказчика и как их закрыть уже на этапе согласования текста.
Нужна помощь? Юридическая экспертиза IT контрактов — оценка задачи бесплатно.
Предмет договора: перечень систем, а не общие фразы
Первая ошибка — размытое описание объекта обслуживания. Если в тексте указано только «сопровождение IT-инфраструктуры», подрядчик вправе трактовать объем работ по-своему. Зафиксируйте количество серверов, рабочих мест, конкретные программные продукты и версии систем, которые исполнитель принимает на обслуживание. Технические детали лучше вынести в приложение — это позволяет обновлять список услуг без переподписания основного договора, но не снижает юридическую силу перечня.
SLA: какие показатели фиксировать
Раздел о качестве услуг (SLA) превращает договор из формальности в работающий инструмент контроля. Без конкретных метрик заказчик платит за процесс, а не за результат. В тексте договора и приложениях к нему имеет смысл прописать:
- время реакции на инциденты по уровням приоритета;
- максимальный срок восстановления работоспособности сервиса;
- допустимый процент простоя систем в месяц (Uptime);
- периодичность регламентных работ и резервного копирования.
Каждый параметр нуждается в системе фиксации: как стороны регистрируют время поступления заявки и момент ее закрытия. Обычно для этого используют Helpdesk-системы — логи из них становятся основным доказательством в спорах о качестве услуг.
Ответственность подрядчика и штрафные санкции
Исполнители нередко ограничивают ответственность суммой ежемесячного платежа. Для заказчика это опасно: убытки от простоя бизнеса могут в разы превышать абонентскую плату. Отдельного внимания требует процедура фиксации сбоев — если заказчик не уведомит исполнителя вовремя и не приложит подтверждающие логи, доказать вину подрядчика в суде будет сложно. Пропишите ответственных лиц с обеих сторон и каналы связи, по которым фиксируется факт обращения.
Конфиденциальность, персональные данные и права на код
IT-подрядчик получает доступ к базам клиентов, финансовым отчетам и коммерческим секретам, поэтому договор должен содержать условия о неразглашении (NDA) и соответствовать требованиям 152-ФЗ, если исполнитель обрабатывает персональные данные по поручению заказчика. Отдельно стоит закрыть вопрос интеллектуальной собственности: если в договоре не прописана передача исключительных прав на скрипты и доработки, которые создает подрядчик, авторство остается за исполнителем. При смене подрядчика это создает прямой риск — новый специалист не сможет легально использовать прежние наработки.
Оплата, приемка и расторжение
Абонентскую плату стоит отделять от стоимости разовых проектов и фиксировать объем включенных часов — работы сверх лимита требуют отдельного согласования цены. Приемку удобно строить на ежемесячных актах и отчетах из Helpdesk, с правом заказчика на мотивированный отказ при несоблюдении SLA. Процедуру расторжения нужно прописывать отдельно: срок уведомления обычно составляет 30–60 дней, а передачу паролей, ключей доступа и документации по инфраструктуре имеет смысл ограничить конкретным сроком, например пятью рабочими днями, — иначе заказчик рискует остаться заложником прежнего подрядчика.
| Раздел договора | Типичный риск |
| Предмет договора | Размытые формулировки не позволяют доказать невыполнение работ |
| SLA | Отсутствие метрик превращает оплату в плату «за факт наличия» подрядчика |
| Ответственность | Штраф ограничен суммой платежа, убытки от простоя не компенсируются |
| Конфиденциальность | Нет NDA и условий по 152-ФЗ при доступе к базам клиентов |
| Интеллектуальная собственность | Права на доработки и скрипты остаются у исполнителя |
| Расторжение | Не закреплен срок передачи паролей и документации |
Частые вопросы
Обязательно ли указывать SLA в самом договоре, а не в приложении?
Нет, юридическую силу имеет и приложение, если в основном тексте есть ссылка на него как на неотъемлемую часть договора. Важно, чтобы приложение было подписано обеими сторонами и содержало конкретные, измеримые показатели.
Что делать, если типовой договор подрядчика ограничивает ответственность абонентской платой?
Такое условие можно и нужно обсуждать на этапе согласования: договориться о повышенных штрафах за критичные инциденты либо об отдельной компенсации за простой, если он превышает согласованный порог Uptime.
Как подтвердить нарушение SLA в суде?
Основным доказательством служат логи Helpdesk-системы, переписка о факте обращения и время закрытия заявки. Поэтому договор должен прямо называть систему учета заявок как источник доказательств.
Нужно ли отдельно прописывать передачу прав на доработанный код?
Да. Без прямого указания на переход исключительных прав заказчику доработки, скрипты и настройки, созданные подрядчиком, по умолчанию остаются его собственностью.
Проверка готового договора на IT-услуги требует одновременно юридической и технической экспертизы — важно увидеть риски, которые не очевидны без практики споров с подрядчиками. Такую проверку проводит команда юридической экспертизы IT контрактов Ви Эф Эс Консалтинг.
Этими задачами занимается наша профильная практика — юридическое сопровождение IT-компаний.