Договор оказания услуг в сфере ИТ — это базовый документ, регулирующий отношения между заказчиком и исполнителем (разработчиком, интегратором, администратором систем и т.д.). Грамотно составленный договор минимизирует риски споров, четко фиксирует объем работ, сроки, стоимость и права на интеллектуальную собственность.

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

Основные отличия договора ИТ-услуг от смежных договоров

Перед составлением документа необходимо определить его правовую природу, так как от этого зависят налоговые последствия, порядок приемки и переход прав:

• Договор подряда (ГК РФ, ст. 702–761) — применяется, если результат — конкретный материальный или осязаемый цифровой продукт (сайт, программа, настроенный сервер). Ключевой признак: есть осязаемый результат, подлежащий приемке по акту.
• Договор возмездного оказания услуг (ГК РФ, ст. 779–783) — применяется к процессным деятельности: техподдержка, мониторинг, консультации, администрирование, аудит. Результат не осязаем (процесс выполнен — услуга оказана). Приемка часто подтверждается актами сверки или календарным планом.
• Смешанные договоры, на практике чаще всего встречаются гибриды (разработка + внедрение + поддержка). В преамбуле и предмете договора нужно четко разделять этапы: какие — подряд, какие — услуги.

Обязательная структура договора (по ст. 432 ГК РФ)

Преамбула (Шапка)

Содержит полные реквизиты сторон:

• Полные наименования (для ИП — ФИО, ОГРНИП, ИНН; для юрлиц — ОГРН, ИНН, КПП, юрадрес).
• Основание действия представителей (Устав, Доверенность, Решение о назначении директора).
• Место и дата заключения.

Предмет договора (Самое важное условие)

Четкое описание что именно делает исполнитель. Недопустимы формулировки вроде «IT-аутсорсинг» или «разработка ПО» без деталей.

Рекомендуемая структура пункта:

1. Наименование услуги/работы.
2. Ссылка на Техническое задание (ТЗ) или Спецификацию как неотъемлемое приложение (Приложение №1).
3. Перечень этапов/мажорных вех (Milestones) с описанием результата каждого этапа.
4. Критерии приемки (Definition of Done) для каждого этапа.
5. Исключения из объема (Out of Scope) — что исполнитель не делает (например: «Написание текстов для сайта», «Закупка лицензий на стороннее ПО», «Обучение персонала заказчика»).

Сроки выполнения и календарный план

• Дата начала работ (обычно, дата подписания акта приема-передачи исходных данных или получения аванса).
• Дата завершения (дедлайн) или сроки по этапам.
• Порядок переноса сроков: форс-мажор, задержка исходных данных заказчиком, согласование изменений (Change Request).
• Штрафные санкции за просрочку (пени, штрафы) — должны быть пропорциональны и обоснованы.

Цена и порядок расчетов

Модели оплаты в ИТ:

• Fixed Price (Фиксированная цена), за весь проект или этап. Риск переработок на исполнителе.
• Time & Materials (T&M) — оплата фактически затраченного времени (по ставкам) и материалов. Гибкость заказчику, риск бюджета на заказчике.
• Dedicated Team / Retainer — фиксированная ежемесячная плата за команду/специалиста.

Обязательные детали:

• Валюта расчетов (в РФ — только рубли, ст; 317 ГК РФ).
• Наличие/отсутствие НДС (обязательно указывать: «Цена включает НДС 20%» или «Без НДС по ст. 346.11 НК РФ» для УСН).
• График платежей: аванс (обычно 30–50%), промежуточные платежи по актам, финальный платеж.
• Порядок выставления счетов и сроки оплаты (например, «в течение 5 рабочих дней со дня подписания Акта»).

Порядок приемки-сдачи результатов

Критически важный раздел для избежания «вечной доработки».

• Форма акта приема-передачи (Приложение №2).
• Процедура: Исполнитель передает результат + Акт -> Заказчик проверяет в течение N дней (обычно 5–10 рабочих дней).
• Режим «молчания = согласие»: если заказчик не прислал замечания в срок, работа считается принятой.
• Порядок устранения замечаний (баг-репорты): сроки фикса, повторная приемка.
• Приемка по этапам (для крупных проектов) vs единая приемка в конце.

Интеллектуальные права (ИП) — «Сердце» ИТ-договора

Согласно ст. 1295 ГК РФ, исключительное право на результат (программу для ЭВМ, базу данных, дизайн) изначально возникает у автора (исполнителя/сотрудников). Переход прав к заказчику требует письменного договора.

• Полный переход исключительных прав (Assignment) — заказчик становится полноправным владельцем. Стандарт для аутсорсинга разработки.
• Лицензия (простая / исключительная), исполнитель оставляет права, дает заказчику право использования. Часто используется для SaaS, коробочных продуктов, библиотек.
• Момент перехода прав: при подписании акта приемки? При полной оплате? (Рекомендуется: при полной оплате по данному этапу/проекту).
• Фоновые технологии (Background IP): обязательно прописать, что права на фреймворки, библиотеки, шаблоны, ноу-хау исполнителя, использованные в проекте, не переходят к заказчику, а предоставляются по лицензии.
• Право на портфолио: право исполнителя указывать проект в портфолио, демонстрировать скриншоты/функционал (с согласованием конфиденциальных данных).

Конфиденциальность и защита данных (NDA)

• Определение конфиденциальной информации (технические, коммерческие, персональные данные).
• Срок действия обязательств (обычно 3–5 лет после расторжения договора).
• Обязательства по защите персональных данных (152-ФЗ): роль сторон (Оператор / Уполномоченное лицо), меры безопасности, запрет трансграничной передачи без согласия.
• Штрафы за утечку (предусмотреть штрафные санкции, не связанные с убытками, так как убытки доказать сложно).

Ответственность сторон

• Исполнитель: за качество (соответствие ТЗ), сроки, утечку данных, нарушение ИП третьих лиц (гарантия «чистоты» кода).
• Заказчик: за своевременную оплату, предоставление доступа/данных/апробаций, корректность ТЗ.
• Ограничение ответственности (Liability Cap): стандартная практика — ограничить макс. ответственность суммой договора или суммой оплаченных за последний год услуг. Исключить ответственность за упущенную выгоду, косвенные убытки, репутационный вред.
• Force Majeure (Форс-мажор): ссылка на ст. 401 ГК РФ и постановление Правительства РФ № 124 (для ИТ важно: DDoS-атаки, сбои дата-центров, блокировки Роскомнадзором — прописать явно, являются ли они форс-мажором).

Срок действия, расторжение и последствия

• Срок действия: до полного исполнения обязательств или фиксированный срок (для поддержки).
• Право одностороннего отказа (ст. 717, 782 ГК РФ): Заказчик может отказаться в любой момент, оплатив выполненную работу + убытки. Исполнитель — только по веской причине (неоплата, невозможность работы).
• Порядок расчетов при расторжении: приемка выполненного, возврат аванса за невыполненное, передача исходников/доступов.

Прочие условия (Boilerplate)

• Порядок разрешения споров: досудебный претензионный порядок (обязателен для Б2Б), арбитраж (по месту нахождения ответчика или по соглашению).
• Уведомления: как и куда отправлять (почта, ЭДО, мессенджеры — лучше только почта/ЭДО).
• Неабьюз (Non-solicitation / Non-compete): запрет на найм сотрудников друг друга (обычно 6–12 мес после окончания).
• Применяемое право (для внутренних договоров, РФ).
• Подписи и печати (если есть).

Необходимый пакет приложений

Договор без приложений часто неработоспособен. Минимальный набор:

Типовые риски и как их закрыть в договоре

Риск 1: «Размытое ТЗ» и Scope Creep (неконтролируемый рост объема)

Решение: Жесткий процесс Change Request. Любая правка, выходящая за ТЗ, отдельное доп. соглашение / заказ на доработку с оценкой часов/стоимости и сдвигом дедлайна. Запрет на выполнение работ без подписанного CR.

Риск 2: Заказчик не принимает работу / «Вечная доработка»

Решение: Механизм «Deemed Acceptance» (считается принятой при молчании). Четкие критерии приемки (чек-листы, автотесты). Ограничение количества итераций фиксов (например, 2 раунда правок в цене, дальше, за отдельные деньги).

Риск 3: Использование Open Source / GPL-кода

Решение: Гарантия исполнителя: «Результат не содержит код с вирусными лицензиями (GPL, AGPL), обязывающими открывать исходный код заказчика». Индемнификация (возмещение убытков) за нарушение лицензий третьих сторон.

Риск 4: Потеря доступа к инфраструктуре (Git, Cloud, Domains)

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

Риск 5: Налоговые риски (переквалификация в трудовые отношения)

Решение (для работы с ИП/Самозанятыми):

• Исключить из договора признаки трудовых отношений: график работы, подчинение внутреннему распорядку, оплата за «процесс/время» без результата, отпускные/больничные, предоставление оборудования заказчиком.
• Акцент на результате и подрядчике (использование своих инструментов, своих сотрудников, риск случайной гибели результата на исполнителе до приемки).
• Наличие Актов приемки-передачи результатов (не табелей учета рабочего времени).

Пример формулировки ключевого пункта «Предмет договора»

ПРЕДМЕТ ДОГОВОРА
Исполнитель обязуется оказать Заказчику услуги по разработке веб-приложения «Название проекта» (далее — Результат), а Заказчик обязуется принять Результат и оплатить его в порядке, установленном настоящим Договором.

Объем, состав, технические характеристики, функциональные требования и критерии приемки Результата определены в Техническом задании (Приложение №1), Календарном плане (Приложение №2) и Спецификации по этапам (Приложение №3), являющимися неотъемлемыми частями настоящего Договора.

Работы выполняются поэтапно в соответствии с Календарным планом. Перечень Этапов и соответствующих им Результатов:
 Этап 1: Проектирование архитектуры и UI/UX дизайн (Результат: Тех. дизайн, макеты в Figma, утвержденные Заказчиком).
 Этап 2: Разработка Backend API и админ-панели (Результат: Исходный код в репозитории Git, развернутое на стенде demo-окружение, документация API Swagger).
 Этап 3: Разработка Frontend и интеграция (Результат: Работающее приложение на staging).
 Этап 4: Тестирование, баг-фиксинг, деплой на продакшн (Результат: Приложение на продакшн-сервере Заказчика, инструкция по администрированию).

К выполнению Исполнителем не относятся (Out of Scope):
 ⎻ Закупка и продление доменных имен и SSL-сертификатов;
 ‒ Написание контентных текстов, статей, новостей для наполнения приложения;
 ‒ Настройка и оплата сторонних SaaS-сервисов (рассылки, платежные шлюзы, карты) за счет Заказчика;
 ‒ Обучение сотрудников Заказчика работе с админ-панелью (оформляется отдельным Договором).

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

1. [ ] Проверены реквизиты сторон (ЕГРЮЛ/ЕГРИП, сайт налоговой).
2. [ ] ТЗ приложено, пронумеровано, подписано инициалами на каждой странице (или подписано ЭЦП).
3. [ ] Четко прописан момент перехода ИП прав (при оплате / при подписании акта).
4. [ ] Есть пункт о фоновых технологиях (Background IP).
5. [ ] Прописан порядок Change Request (управления изменениями).
6. [ ] Механизм приемки: сроки проверки, правило молчания, порядок фикса багов.
7. [ ] График платежей привязан к подписанию Актов, а не к календарным датам.
8. [ ] Ограничение ответственности (Cap) и исключение косвенных убытков.
9. [ ] Конфиденциальность и 152-ФЗ (если есть ПДн).
10. [ ] Порядок передачи доступов/исходников при расторжении.
11. [ ] Договор подписан уполномоченными лицами (печати, ЭЦП).

Качественный договор ИТ-услуг, это не просто формальность, а инструмент управления проектом. Он заставляет стороны на береге согласовать ожидания, разграничить зоны ответственности и заложить правила игры на случай форс-мажоров и споров. Использование типового шаблона без адаптации под специфику проекта (SaaS, разработка под ключ, аутстаффинг, поддержка) несет высокие риски. Инвестиции в юридическую проработку на старте экономят значительные средства и нервы на финише.