Покупая IT-компанию, вы можете приобрести не только команду и продукт, но и обязательства перед третьими лицами, требования к раскрытию кода, технический долг и миллионные штрафы. Эти риски не видны в обычном балансе, но их последствия способны в разы превысить сумму самой сделки. В этой статье мы разберем, какие скрытые IT-обязательства реально встретить на due diligence, как их выявить и грамотно переложить на продавца.
Какие IT-обязательства не попадают в обычный баланс
Лицензионные риски и «вирусное» open source
Использование open-source компонентов - дешево и удобно, но без контроля превращается в риск. Copyleft-лицензии (GPL) обязывают раскрыть исходный код всего продукта, что девальвирует ваш главный актив. Кроме того, необходимо проверять, включено ли ПО в реестры Роспатента и Минцифры.
Также важно проверить объем прав: есть ли у лицензиара полный объем прав. При отсутствии такой проверки реальный правообладатель может запретить использование ПО. Отдельного внимания заслуживает проверка договоров с авторами: часто встречаются случаи, когда ПО зарегистрировано на физлицо (генерального директора), а не на компанию - это прямой путь к претензиям от налоговой и бывших разработчиков.
Контрактные обязательства по договорам разработки и поддержки
Даже если код куплен и оплачен, часто остаются:
- Неисполненные обязательства подрядчика (не передана документация, исходники находятся у третьей стороны, не оплачен последний этап работ).
- Требования о выплате вознаграждения авторам.
- Условия, обязывающие вас финансировать дальнейшую разработку.
Vendor lock-in и неочевидные платежи
Vendor lock-in - когда из-за технологических, финансовых или организационных издержек переключение на другого поставщика становится практически невозможным. Особенно это актуально для облаков: платформа сама по себе дешевая, но «привязать» к себе клиента помогают проприетарные форматы данных и отсутствие экспортных механизмов. В сделке это означает, что будущий рост расходов полностью в руках вендора.
Кибербезопасность и регуляторные риски
Скрытые инциденты ИБ, неисправленные уязвимости, атаки через подрядчиков - все это «долг безопасности», который перейдет к вам. Также нельзя забывать о регуляторных требованиях: например, для банковского сектора обязательна оценка соответствия требованиям Банка России. Ваша оценка должна включать анализ уровней доступа, инцидентов, комплаенса и действующих санкций.
Технологический due diligence: как найти скрытые обязательства
Приобретая IT-компанию, покупка актива - это всего лишь половина дела. Важно грамотно проверить его технологическое здоровье.
Статический и динамический анализ: проверка безопасности, поиск критических уязвимостей и закладок, анализ качества и структуры кода, проверка соответствия документации реальному коду.
Высокая связанность компонентов, отсутствие документации, зависимость от конкретных сотрудников, устаревшие библиотеки.
Проверка лицензий компонентов, выявление «вирусных» ограничений.
Нужно понять, где и на каких условиях используются все активы: софт, библиотеки, базы данных, оборудование, специализированное ПО.
Инструменты перекладывания рисков на продавца
Главная задача юридической защиты - чтобы все найденные риски не легли на ваши плечи после сделки.
Гарантии и заверения (Representations & Warranties)
Продавец в договоре купли-продажи письменно гарантирует, что:
- все права на ПО у продавца «чистые»;
- нет нераскрытых исков или санкций;
- весь open source совместим с коммерческой моделью.
Нарушение гарантии - прямое основание для взыскания убытков.
Индемнити (Indemnity / возмещение потерь)
Индемнити - соглашение, по которому продавец обязуется компенсировать конкретные потери покупателя при наступлении определенных обстоятельств. Распространенная практика - включать в договор перечень «индемнифицируемых рисков» (лицензионные иски, налоговые претензии, требования авторов).
Software Escrow (депонирование исходного кода)
Покупатель может потребовать разместить исходный код и документацию у независимого эскроу-агента. Это гарантирует, что даже при банкротстве вендора или отказе от поддержки у вас будут все материалы для дальнейшей работы. Для российских сделок - критично в условиях ухода иностранных вендоров.
Механизмы удержания и ограничения ответственности
Эффективный способ - удержание части покупной цены (escrow денег) на срок 12-24 месяца для покрытия выявленных рисков. При этом важно разумно ограничить ответственность продавца и определить, что именно считается «индемнифицируемым событием», а также зафиксировать франшизу и потолок ответственности.
| Инструмент | Что закрывает | Когда срабатывает |
|---|---|---|
| Гарантии и заверения | Чистота прав, отсутствие исков, совместимость open source | Нарушение - основание взыскать убытки |
| Индемнити | Перечень конкретных рисков: лицензии, налоги, авторы | При наступлении оговорённого обстоятельства |
| Software Escrow | Доступ к коду и документации | Банкротство вендора, отказ от поддержки |
| Удержание цены | Покрытие выявленных рисков из денег продавца | В течение 12-24 месяцев после сделки |
Заключение
Скрытые долги в сфере лицензий, open source, облачной зависимости, безопасности и технического долга способны не только уничтожить бизнес-модель, но и привести к многомиллионным искам. Чтобы защитить себя, необходимо выявить эти риски и с помощью грамотных юридических конструкций (гарантий, индемнити, эскроу и удержаний) переложить их на продавца.
Технологический due diligence под защиту вашей сделки
G-Invest проводит аудит лицензий, исходного кода, open source и технического долга, выявляет скрытые ИТ-обязательства вне отчётности и встраивает в договор гарантии, индемнити и эскроу, чтобы переложить риски на продавца - с сопровождением сделки до закрытия.
Частые вопросы
Что такое технологический due diligence в сделках M&A?
Технологический due diligence (Tech DD) - это углубленная проверка IT-активов, кода, архитектуры, лицензионной чистоты, открытых компонентов, безопасности и инфраструктуры целевой компании. В отличие от финансового или юридического DD, технологический направлен на выявление скрытых технических рисков, которые не отражаются в бухгалтерском балансе, но могут привести к многомиллионным убыткам после сделки.
Почему обычный due diligence не видит скрытые ИТ-обязательства?
Классический due diligence (финансовый, юридический, налоговый) оперирует отчётностью, договорами, судебными исками, реестрами. А IT-обязательства часто не имеют материальной формы и не фиксируются в учёте:
- использование open source без договора;
- неопубликованные требования авторов кода;
- технический долг, заложенный в архитектуру;
- зависимость от вендора, которая не оформлена как финансовое обязательство.
Без анализа исходного кода, лицензий библиотек и прав на ИС такие риски остаются «невидимыми».
Как проверить код на чистоту прав при покупке IT-компании?
Проверка включает несколько этапов:
- Инвентаризация кода - все репозитории, библиотеки, фреймворки, скрипты.
- Анализ лицензий каждого компонента (в т.ч. transitive зависимостей) на предмет совместимости с коммерческой моделью покупателя.
- Анализ истории коммитов - кто, когда и на каких условиях вносил изменения.
- Проверка договоров с разработчиками (трудовых, ГПХ, авторских заказов) - есть ли передача исключительных прав компании.
- Сверка с реестрами Роспатента и Минцифры (для аккредитованных IT-компаний, налоговых льгот).
Такой аудит должен проводить независимый технолог совместно с юристом по ИС.
Обязательно ли проверять реестры Роспатента и Минцифры перед покупкой?
Да, особенно если вы покупаете аккредитованную IT-компанию, претендующую на налоговые льготы (например, пониженные ставки страховых взносов, налог на прибыль 0% для резидентов Сколково). Реестры содержат сведения о зарегистрированных программах для ЭВМ, базах данных, топологиях интегральных схем. Несовпадение реально используемого ПО с зарегистрированным - основание для доначисления налогов и штрафов. Кроме того, если права на ПО зарегистрированы на физлицо (даже гендиректора), компания не может считаться правообладателем - это прямое нарушение для получения льгот.
Какие документы нужны для проверки ПО при покупке бизнеса?
Минимальный чек-лист:
- Опись всех объектов интеллектуальной собственности (ПО, базы данных, ноу-хау).
- Свидетельства о регистрации ПО в Роспатенте (если есть).
- Договоры с авторами (трудовые, ГПХ, авторского заказа) с актами приёма-передачи исключительных прав.
- Лицензионные договоры на использование стороннего ПО (коммерческого и open source с указанием версий лицензий).
- Отчёт о сканировании open source-компонентов (SBOM - Software Bill of Materials).
- Техническая документация (архитектурная, API, пользовательская, администраторская).
- Политики безопасности и отчёты о пентестах за последние 2 года.
- Договоры с подрядчиками на разработку и поддержку.
- Доступы к репозиториям, CI/CD, системам мониторинга, базам инцидентов.
Важно: все документы должны позволять проследить цепочку прав от автора к продавцу и от продавца к вам.