Митигация рисков IT-компании

1️⃣Подходы к управлению юридическими рисками, выявленными при приобретении технологических компаний, существенно не изменились по сравнению предыдущими периодами. Как и ранее, покупатели стремятся максимально снизить уровень рисков до сделки, а продавцы — быстрее заключить сделку, а риски перераспределить с помощью договорных механизмов.

2️⃣В 2025 г. на buy-side сформировался тренд — покупатели стали:
📌тщательнее анализировать юридические и регуляторные риски;
📌стремиться максимально устранить критичные риски, выявленные по итогам due diligence, до подписания транзакционной документации.

3️⃣Процесс управления рисками, как и ранее, предполагает:
📌согласование позиций сторон относительно приемлемости рисков, определения наиболее критичных из них, приоритизации работы по их устранению;
📌согласование перечня мероприятий фактического характера, направленных на устранение рисков; 📌предпродажную реструктуризация / «пересборка» активов и формирование периметра сделки;
📌разработку системы транзакционных механизмов защиты покупателя и ее согласование с продавцом и компанией;
📌корректировку положений документов по сделке с учетом устранения рисков до закрытия сделки.

4️⃣ Часть рисков можно устранить путем реализации фактических мероприятий. К ним чаще всего относят корректировку документов, оформляющих отношения по разработке ПО, в ситуации, когда в компании не фиксировалось документально, что конкретно делал каждый разработчик.

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

Форма служебного задания не установлена и может быть любой, это упрощает задачу. Однако ввести ретроактивно ЛНА, устанавливающий порядок использования трекеров и систем управления кодовой базой — невозможно по ТК, об этом нужно помнить.

5️⃣ Далеко не все IT-риски, например в отношении титула на ПО, могут быть устранены ретроспективно.

Если DD не подтверждает наличие у компании исключительных прав на часть ПО в составе продукта, такие риски не могут быть устранены:
📌подписанием документов в рамках трудовых отношений с ретроспективной оговоркой;
📌заключением соглашений о передаче исключительного права на ПО с ретроспективной оговоркой;
📌подписанием актов приема-передачи между авторами-разработчиками и компанией, а также любых других документов, «назначающих» каких-либо лиц авторами ретроспективно или «согласующих» наличие у компании исключительных прав на ПО в прошлом, даже если авторы-разработчики согласны подписать такие документы.

Ретроактивно невозможно изменить должностные обязанности, как и передать титул по договору об отчуждении или заказной разработке.

6️⃣Исправить ситуацию с отсутствием титула на ПО можно только на будущее путем заключения компанией с разработчиками договоров об отчуждении исключительных прав.

Устранить ответственность за использование ПО без правового основания в прошлом можно путем заключения лицензионного договора с ретроспективной оговоркой, распро- страняющей действие лицензии на периоды фактического ис- пользования ПО до даты ее подписания. Однако такая лицензия сама по себе не устранит проблему исторического отсутствия у компании титула.

7️⃣Заключение договоров об отчуждении исключительных прав между авторами и приобретаемой компанией в целях консолидации прав на продукт может быть сопряжено с существенными налоговыми последствиями (см. пост). В связи с этим предварительно целесообразно оценить налоговые аспекты всех операций в рамках такой реструктуризации применительно ко всем участникам сделки M&A, включая компанию.

#DD_ПО
#митигация_IT_рисков
💠💠💠

💠 M&A | IB