Договор оказания IT-услуг
Образец договора на IT-услуги 2026 — поддержка ПО, разработка, аутсорсинг, SLA и время реакции, штрафы за простой, права на результаты работ и лицензия на ПО
Обновлено:
Договор оказания IT-услуг — соглашение, по которому исполнитель (IT-компания, студия разработки, фрилансер) обязуется выполнить работы и оказать услуги в сфере информационных технологий: разработать программное обеспечение, обеспечить его поддержку, администрировать инфраструктуру заказчика, передать лицензию на готовый продукт. Это один из самых разнородных типов договоров — внутри него уживаются и подряд (разработка под ТЗ), и возмездное оказание услуг (мониторинг, поддержка), и лицензионные элементы (передача прав на ПО).
Правовое регулирование комплексное: глава 39 ГК РФ — для услуг поддержки и сопровождения; глава 37 ГК РФ — для разработки на заказ как разновидности подряда; глава 69 ГК РФ — для интеллектуальных прав на программу; ст. 1235 ГК РФ — для лицензионных условий, если по договору передаётся право использовать ПО. Грамотный IT-договор разделяет эти блоки и устанавливает свой правовой режим для каждого.
Подробно об общих правилах гл. 39 ГК, моделях оплаты и одностороннем отказе по ст. 782 ГК — в опорной статье «Договор оказания услуг». Здесь — практика именно для IT-договоров 2026 года, включая SLA, лицензию на ПО и пограничные случаи между услугами и подрядом.
Скачать договор оказания IT-услуг
Виды IT-услуг и предмет договора
Внутри IT-договора различают несколько принципиально разных моделей. От выбранной модели зависит распределение рисков, права на результат, налоговые последствия.
Разработка ПО на заказ (custom development) — исполнитель создаёт программное обеспечение по техническому заданию заказчика. Применяются нормы о подряде. Существенные условия: предмет (объект разработки), сроки начала и окончания, цена, требования к качеству (через ТЗ). Без подписанного ТЗ договор разработки заведомо проблемный — нечем доказать соответствие результата ожиданиям.
Аутстаффинг и аутсорсинг — предоставление команды разработчиков для работы под управлением заказчика (time & material) либо передача функции целиком (outsourcing). По форме это договор оказания услуг. Главное отличие от подряда — нет фиксированного результата, оплачивается процесс. Удобен при гибких требованиях, но требует чёткой системы биллинга и приёмки.
Поддержка и сопровождение (maintenance, L1-L3) — реактивные и проактивные услуги по обеспечению работоспособности ПО или инфраструктуры. Регулируется через SLA (Service Level Agreement) — отдельный раздел или приложение, фиксирующее измеримые показатели качества.
Передача лицензии на готовое ПО — самостоятельный лицензионный договор по ст. 1235 ГК РФ; в составе IT-договора часто встречается как условие («заказчик получает неисключительную лицензию на использование разработанного ПО на территории всего мира бессрочно»).
Когда нужно ТЗ как приложение
Для договоров разработки и доработки техническое задание — обязательный документ. ТЗ должно содержать: функциональные требования (что должна делать система), нефункциональные требования (производительность, безопасность, совместимость), архитектурные ограничения, перечень интеграций, критерии приёмки, формат поставки артефактов. Изменения ТЗ оформляются дополнительными соглашениями — change requests с пересчётом сроков и стоимости. Устные договорённости «мы там немного добавим» — главный источник конфликтов в индустрии.
Стоимость в IT-договорах варьируется от модели:
- Fixed price — фиксированная цена за весь объём работ по ТЗ. Подходит, когда ТЗ детально проработано. Риск изменения объёма лежит на исполнителе.
- Time & material (T&M) — оплата по фактически затраченным человеко-часам по согласованным ставкам. Ставки 2026 года: middle-разработчик 3 500 – 6 500 ₽/час, senior 6 500 – 12 000 ₽/час, тимлид 9 000 – 15 000 ₽/час.
- Capped T&M — почасовая оплата с верхней границей бюджета, что страхует заказчика от неконтролируемого роста стоимости.
- Абонентская плата — фиксированная сумма в месяц за поддержку и определённое количество часов работы; превышение оплачивается отдельно по почасовой ставке.
При просрочке оплаты неустойка обычно рассчитывается по ключевой ставке ЦБ (14% годовых) либо по фиксированному проценту от просроченной суммы (0,1% за каждый день просрочки — стандартная коммерческая практика).
SLA, время реакции, штрафы за простой
SLA (Service Level Agreement) — приложение к договору, фиксирующее измеримые показатели качества услуги. Без SLA термин «поддержка ПО» юридически беспредметен.
Базовые параметры SLA:
- Уровни критичности инцидентов — обычно 3–4 уровня (critical, high, medium, low). Critical — полный отказ системы или невозможность ключевых бизнес-операций; high — частичный отказ функциональности; medium — ошибка с обходным путём; low — косметические дефекты.
- Время реакции (response time) — срок от регистрации обращения до начала работы над ним. Для critical — 15–60 минут; для high — 1–4 часа; для medium — рабочий день; для low — 3–5 рабочих дней.
- Время решения (resolution time) — срок от регистрации обращения до устранения. Critical — 4–8 часов; high — рабочий день; medium — 3–5 рабочих дней.
- Доступность системы (uptime) — целевой процент времени, в течение которого система работоспособна. Стандарт enterprise — 99,5% (около 44 часов простоя в год), 99,9% (около 9 часов), 99,99% (около 53 минут). Каждая «девятка» удорожает услугу в полтора-два раза.
- Окна обслуживания — заранее объявленные периоды плановых работ, не учитываемые при расчёте uptime.
Штрафы за нарушение SLA
Стандартная структура санкций — service credits: при недостижении показателей SLA исполнитель возвращает или зачитывает в счёт следующих платежей часть абонентской платы. Шкала обычно ступенчатая: uptime 99,5–99,0% — возврат 10% месячной платы; 99,0–98,0% — 25%; ниже 98% — 50%. Сверх service credits возмещение прямых убытков — только если они доказаны и не покрываются кредитами. Полное возмещение упущенной выгоды (потерянная прибыль из-за простоя) допускается, если прямо предусмотрено договором; иначе суды его существенно ограничивают.
Точка измерения параметров SLA — критична. Должен быть определён мониторинг: какие метрики собираются, какими инструментами, кто имеет доступ к данным, как разрешаются разногласия по фиксации инцидентов. Без согласованной системы измерения SLA — декларативный документ.
Распределение ответственности при инцидентах:
- инциденты по вине исполнителя (ошибки в коде, сбои инфраструктуры исполнителя, нарушение SLA) — компенсируются исполнителем;
- инциденты по вине заказчика (некорректное использование, отказ от обновлений, действия третьих лиц со стороны заказчика) — не покрываются SLA;
- инциденты внешнего характера (DDoS-атаки, отказы магистральных провайдеров, форс-мажор) — оговариваются отдельно; обычно исполнитель обязан минимизировать последствия, но не несёт ответственности за сам факт инцидента.
Права на результаты работ и лицензия на ПО
Самый болезненный раздел для IT-договоров — кому принадлежат исключительные права на созданное ПО. Базовое правило: по умолчанию исключительное право на программу, созданную по договору, предметом которого было её создание, принадлежит заказчику (ст. 1296 ГК РФ). Если же программа создаётся при выполнении договора, не направленного прямо на её создание (например, по договору НИОКР или подряда), право принадлежит исполнителю (ст. 1297 ГК РФ). Поэтому в IT-договоре всегда фиксируют этот вопрос явно — какие именно объекты создаются и кому переходят права.
Возможные модели:
- Полная передача исключительных прав — заказчик становится единственным правообладателем; исполнитель утрачивает право использовать код в других проектах. Применяется в кастомных enterprise-разработках. Удорожает проект на 20–50%.
- Исключительная лицензия — права остаются у исполнителя, но заказчик получает право использовать ПО, при этом исполнитель не может передавать лицензию третьим лицам в рамках территории и срока.
- Неисключительная лицензия — стандартная модель для SaaS и тиражируемого ПО. Исполнитель сохраняет права полностью и вправе лицензировать программу другим клиентам.
Лицензионные условия по ст. 1235 ГК РФ должны содержать: предмет лицензии (программу с указанием версий), способы использования, территорию (если не указана — РФ), срок (если не указан — 5 лет), вознаграждение или указание на безвозмездность. Лицензионный договор с физическим лицом — лицензиаром на возмездной основе требует письменной формы; нарушение формы влечёт ничтожность.
Open source-компоненты — отдельный риск. В договоре фиксируют: исполнитель гарантирует, что использованные в продукте open source-компоненты лицензированы корректно и не нарушают прав третьих лиц; либо предоставляет SBOM (Software Bill of Materials) — перечень компонентов с указанием лицензий. Это защищает заказчика от исков владельцев авторских прав и от вирусных лицензий (GPL, AGPL), способных «инфицировать» проприетарный код.
Для смежных задач — заказная разработка веб-проектов, отдельные лицензионные соглашения — изучите параллельно договор на разработку сайта и лицензионный договор на ПО, где условия о приёмке, гарантиях и правах раскрыты применительно к более узким сценариям.