Software due diligence: що перевірити перед M&A-угодою

Компанія-розробник ПЗ може демонструвати зростання. Проте її вартість часто залежить від активів, яких не охоплює фінансова перевірка бізнесу: коду, архітектури, даних, інфраструктури, прав інтелектуальної власності (IP) та команди розробки.

Software due diligence перевіряє, чи підтверджують ці активи інвестиційну тезу. Неврегульовані права на код, нестійка інфраструктура, застарілі залежності або технічний борг можуть змінити оцінку бізнесу, умови угоди та план інтеграції.

Ключові висновки

• Аналіз коду — лише одна частина software due diligence.
• Права на продукт мають підтверджувати договори та історія створення коду.
• Сертифікат або заявлена відповідність фреймворку не доводить, що продукт захищений.
• Технічні висновки пов’язують із вартістю виправлень, строками, умовами угоди та планом після закриття.

Що таке software due diligence

Software due diligence — це технічна перевірка продукту та пов’язаних процесів перед інвестицією або M&A-угодою. Її замовляє покупець чи інвестор, а продавець може перевірити себе перед IPO або відкриттям data room.

У центрі уваги — продукт, що приносить дохід, і системи для його розробки, розгортання, підтримки та захисту. Внутрішні інструменти теж важливі, якщо їхній збій зупинить сервіс, відкриє несанкціонований доступ до даних або створить залежність від однієї людини.

Це не повний IT due diligence, не аудит коду й не тест на проникнення. Перевірка зіставляє заяви менеджменту з доказами та пояснює вплив прогалин на угоду, але не доводить відсутність помилок.

Що перевіряють під час software due diligence

Архітектура та масштабування

Фахівці описують продукт, хостинг, бази даних, інтеграції та потоки даних. Для SaaS-компанії важливі конфігурація хмари, доступність, відновлення, навантаження й витрати. Архітектурна схема не доводить здатності продукту масштабуватися: її звіряють із показниками роботи, інцидентами та тестами відновлення.

Код та інженерні процеси

Код оцінюють разом з історією репозиторіїв, документацією, тестами, релізами й дефектами. Слабка документація, нерегулярне тестування або залежність від одного інженера підвищують вартість інтеграції.

Права на продукт і open-source компоненти

Для української компанії важливо простежити ланцюг передання прав інтелектуальної власності від авторів до юридичної особи, яка продає продукт. Код могли створювати працівники, ФОПи, підрядники й гіг-спеціалісти. Перевіряють договори, технічні завдання, акти, умови передання прав та історію репозиторіїв.

Закон України «Про авторське право і суміжні права» визначає базові правила для службових і замовлених творів, але договір може змінити розподіл майнових прав. Якщо компанія є резидентом Дія.City, перевіряють її статус в офіційному реєстрі та умови гіг-контрактів щодо належності й передання майнових прав. Належність прав має підтвердити юридичний радник.

Якщо розробка, продажі й IP розподілені між кількома юрособами, встановлюють, кому належать код, домени й акаунти, яка юрособа є стороною клієнтських договорів та чи містять вони обмеження на передання прав або зміну контролю.

Open-source ПЗ можна використовувати комерційно, але кожна ліцензія має власні умови. Залежно від способу використання, модифікації, поєднання та розповсюдження компонента можуть виникати вимоги щодо повідомлень, атрибуції або розкриття відповідного вихідного коду.

Залежності та ланцюг постачання ПЗ

Сучасний продукт залежить від бібліотек, API, хмарних сервісів і постачальників. Перевірка шукає непідтримувані компоненти, відомі вразливості, конфлікти ліцензій, слабке керування оновленнями та єдині точки відмови. Специфікація складу програмного забезпечення (SBOM) містить перелік компонентів, але не доводить відсутність вразливостей чи ліцензійних проблем.

Критичних постачальників варто включити до перевірки третіх сторін, особливо якщо вони мають доступ до даних, робочого середовища або релізів. Для української угоди оцінюють прямі й непрямі санкційні ризики, зокрема через власників і контролерів.

Кібербезпека, персональні дані та compliance

Перевірка кіберризиків перед угодою охоплює доступи, керування вразливостями, шифрування, логування, інциденти, безпечну розробку та відновлення. NIST CSF і NIST SSDF допомагають структурувати оцінку, але заявлена відповідність не доводить, що заходи працюють на практиці.

Для української компанії перевіряють мету й підстави обробки даних, договори з розпорядниками, строки зберігання, захист, інциденти та міжнародні передачі за Законом України «Про захист персональних даних». GDPR може діяти, якщо бізнес підпадає під його територіальну сферу. Інші вимоги залежать від продукту, клієнтів і ринків.

Сертифікація ISO/IEC 27001 підтверджує наявність системи управління інформаційною безпекою лише в зазначених межах. Вона не гарантує безпеку кожного продукту, середовища чи набору даних.

Технічний борг та операційна стійкість

Технічний борг — це майбутні витрати або ризики, створені попередніми архітектурними й інженерними рішеннями. Варто відрізняти керований перелік завдань від структурних проблем, що загрожують надійності, безпеці або плану розвитку продукту.

Для команд та інфраструктури в Україні перевіряють резервне живлення і зв’язок, резервні копії в різних регіонах, тести відновлення, процедури аварійного доступу й розподіл критичних обов’язків. Заяв про безперервність роботи недостатньо без доказів.

Як провести software due diligence

1. Визначити питання угоди

Починайте з рішення, а не з універсального чекліста. Інвестору може бути важливе масштабування, стратегічному покупцю — інтеграція, IP і сумісність систем. У межах перевірки визначають продукти, репозиторії, середовища, юрособи та періоди.

2. Зібрати докази

До data room варто додати схеми архітектури, репозиторії, план розвитку, хмарні витрати, тести, журнали інцидентів, політики безпеки, ліцензії та договори. Інтерв’ю з командою доповнюють ці матеріали. У звіті відділяють підтверджені факти від тверджень менеджменту та відкритих питань.

3. Перевірити заяви за кількома джерелами

Жодна метрика не доводить якість продукту. Дані репозиторіїв, релізів, інцидентів і робочого середовища зіставляють з описаними процесами. Сканери знаходять потенційні проблеми, але команда перевірки оцінює суттєвість і відкидає хибні спрацювання.

4. Перекласти висновки мовою угоди

Корисний звіт ранжує проблеми за силою доказів, імовірністю, впливом і терміновістю. Де можливо, він оцінює вартість, строки та відповідальних за виправлення. Результати можуть вплинути на ціну, гарантії продавця, спеціальні зобов’язання щодо відшкодування збитків, умови до закриття угоди, утримання ключових інженерів або план після закриття.

Software due diligence — лише одна частина перевірки

Технічно зрілий продукт не усуває ризиків самої компанії-власника. Покупцю все одно потрібно перевірити структуру власності, засновників, ключових керівників, пов’язані сторони, судові справи, санкційні ризики, постачальників і публічні заяви.

Due diligence-послуги Molfar Intelligence доповнюють технічну та юридичну перевірку аналізом корпоративних, репутаційних, санкційних і кіберризиків. Поєднання цих напрямів дає інвестиційній команді підстави продовжити угоду, змінити її умови або призупинити процес до усунення критичних прогалин.

‍