Код, доступы, данные: что закрепить заранее

В договоре должны быть явно записаны четыре вещи.

1. 1.Кому и когда переходят права. Код — результат интеллектуальной деятельности, поэтому переход прав нужно прописать в договоре, а не предполагать; как именно оформить передачу, подскажет юрист. Уточните момент: после оплаты каждого этапа или только после всего проекта. Второй вариант оставляет вас ни с чем, если на полпути возник спор (подробнее в статье «Гарантии и договор»).
2. 2.Где лежит код. Репозиторий (хранилище кода и истории изменений) должен быть создан в организации вашей компании, а подрядчику выданы ограниченные права. У GitHub для этого есть роли от Read до Admin: исполнителю обычно достаточно Write, а Admin остаётся у вас.
3. 3.Что входит в передачу. Не только исходный код, но и история изменений, описание того, как собрать и запустить продукт, макеты и исходники дизайна, данные для подключения к сервисам.
4. 4.Сторонние компоненты. Значительная часть любого продукта — чужие библиотеки с открытыми лицензиями и платные сервисы. Они не передаются вам «в собственность», вы получаете право ими пользоваться на условиях лицензии. Попросите список ключевых компонентов и лицензий, чтобы знать, не возникнет ли обязательств или платежей позже.

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

Заведите реестр. Вот минимальная таблица:

Реестр заполняется подрядчиком по мере проекта и вычитывается вами на каждом демо. Секретные ключи (пароли к базе, ключи доступа к платёжным сервисам) не отправляются в переписке и мессенджерах: используйте менеджер паролей с общим доступом или защищённую передачу. Вместе с реестром нужны ответы на два вопроса: что произойдёт, если подрядчик внезапно исчезнет, и как отозвать его доступы за час. Проверка этих пунктов подробно разобрана в статье «Как проверить качество продукта и работу подрядчика».

Данные, которые накапливает продукт (клиенты, заказы, документы), принадлежат вашему бизнесу, но физически лежат там, где их развернул исполнитель. Закрепите письменно:

• Хозяин и доступ. Вы получаете полный доступ к базе или к регулярной выгрузке в открытом формате, например в таблицу или файл с данными.
• Резервные копии. Расписание, место хранения, срок хранения, кто и как восстанавливает данные и когда это последний раз проверялось.
• Что с данными после окончания договора. Исполнитель передаёт всё, что у него есть, затем удаляет свои копии и подтверждает это письменно.
• Тестовые данные. Для работы разработчикам нужны примеры, но реальные клиентские данные лучше заменять обезличенными. Если реальные нужны, это должно быть оговорено в соглашении о конфиденциальности.

Если в продукте есть данные физических лиц (ФИО, телефоны, почты, адреса, заказы), включается отдельное регулирование. По закону Республики Казахстан «О персональных данных и их защите» хранение персональных данных осуществляется собственником и (или) оператором, а также третьим лицом в базе и (или) цифровом объекте, которые находятся на территории Республики Казахстан (ст. 12, п. 2 в редакции, которую мы смотрели 24.10.2026). Для бизнеса это означает вопрос, которого нет в обычных договорах: где физически работает сервер с базой клиентов? Если исполнитель предлагает облачный сервис за границей, хранение базы там может противоречить этой норме.

Что сделать:

1. 1.Выясните, будут ли в продукте персональные данные, и составьте их перечень.
2. 2.Спросите у исполнителя, в каком регионе и у какого провайдера будет храниться база, и запишите ответ в договор.
3. 3.Покажите юристу эту норму и ответ исполнителя. Закон содержит и другие требования (согласие субъекта, передача за границу, отзыв согласия), а редакция может меняться; здесь мы даём ориентир, а не гарантию соответствия.

Заранее запишите сценарий расторжения: что подрядчик передаёт, в какой срок, что считается оплаченным и как закрываются доступы. Он нужен, даже если вы рассчитываете на долгое сотрудничество. Если проект идёт хорошо, этот пункт ничего не стоит; если плохо, он сэкономит месяцы.

Заполните реестр для вашего продукта. Ответы сохраняются в вашем браузере; красным (в тексте — пометкой «НЕ НА КОМПАНИИ») отметьте всё, что оформлено не на вашу компанию.

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