Технический
Due-Diligence IT-актива

Ситуация

Платформа стабильно работает на текущей базе клиентов, однако заявленный бизнес-план предполагает кратное увеличение клиентской базы. Технический аудит выявил критическую архитектурную недостаточность: используется монолитная база данных с общей схемой, не предусматривающая изоляции данных клиентов. Нагрузка от операционных транзакций (OLTP) и аналитических запросов (OLAP) конкурирует за одни и те же физические ресурсы. При достижении определённых порогов объёмов данных деградация производительности становится нелинейной. Текущая архитектура не способна обеспечить заявленный рост без полной переработки слоя хранения, что требует остановки разработки новых функций на длительный срок.

Что сделали

• Оценён разрыв между текущей архитектурой и требованиями бизнес-плана покупателя
• Подтверждено отсутствие механизмов шардирования и логической изоляции данных компаний-клиентов. Это создаёт риски нарушения комплаенса (GDPR) и невозможность гранулярного управления данными
• Рассчитана стоимость устранения ограничений (CAPEX)
• Сопоставлены прогнозы роста нагрузки с физическими лимитами вертикального масштабирования
• Подготовлен поэтапный план доработок с оценкой рисков

Результат

• Выявленные архитектурные ограничения классифицированы как критический технический долг. Объём необходимых капитальных вложений (бюджет на инфраструктуру и фонд оплаты труда команды на период доработок) учтён в качестве дисконта к итоговой стоимости сделки
• Покупатель получил объективные данные вместо прогнозов продавца. В структуру сделки включён механизм Earn-out: часть выплаты привязана к успешному завершению этапа изоляции данных, что защищает покупателя от приобретения нефункционального актива
• Срок технической готовности платформы к масштабированию (6–9 месяцев) теперь учитывается отдельно от юридических сроков закрытия сделки
• Сформирован реалистичный график расходов на ближайшие 12 месяцев. Покупатель понимает, что в первый год владения активом маржинальность снизится из-за необходимости финансирования экстренной модернизации, не заложенной в исходный бизнес-план продавца

Ситуация

Значительная часть кодовой базы платформы была разработана внешними подрядчиками. В ходе предварительного аудита выявлено отсутствие непрерывной цепочки перехода исключительных прав: по ряду этапов работ не были оформлены договоры отчуждения или акты приёма-передачи. Юридический статус части кода оставался неопределённым – формально исключительные права на эти модули не перешли к компании-продавцу. Риск усугублялся тем, что часть подрядчиков прекратила деятельность, а в ряде договоров содержались формулировки, допускающие двойное толкование (например, предоставление простой неисключительной лицензии вместо полного отчуждения прав).

Что сделали

• Проведён аудит цепочки прав путём сопоставления юридических документов с фактической историей разработки
• История изменений кодовой базы сопоставлена со списком подрядчиков и периодами действия договоров. Спорные участки кода выделены с точностью до модулей и авторов
• По каждому спорному участку определено текущее состояние прав на основании текстов договоров и актов (согласно ст. 1296 ГК РФ)
• Сформирован перечень компонентов, по которым отсутствует документальное подтверждение перехода прав
• Разработан план урегулирования: для каждого такого компонента определён алгоритм действий – от подписания дополнительных соглашений о ретроспективном отчуждении прав до получения нотариально заверенных заявлений от бывших сотрудников и фрилансеров

Результат

• Риск срыва сделки устранён. Все права на код подтверждены документально до момента подписания договора купли-продажи
• Покупатель получил юридическое подтверждение того, что приобретаемый нематериальный актив соответствует своей балансовой и рыночной стоимости
• Риск предъявления претензий со стороны бывших подрядчиков после закрытия сделки (в течение срока исковой давности) снят. В договоре купли-продажи удалось избежать расширения раздела заверений и гарантий по данному пункту
• Сформирован актуальный реестр компонентов системы, где по каждой строке указан правовой статус и документ-основание (договор, акт, служебное задание)
• Устранена зависимость от третьих лиц. Новый владелец может свободно модифицировать, продавать или лицензировать платформу, не опасаясь блокировки со стороны авторов отдельных модулей

Ситуация

Кодовая база продукта содержала компоненты с открытым исходным кодом. В ходе аудита выявлены зависимости, распространяемые на условиях «вирусных» лицензий, в частности GNU GPL/AGPL. Данные лицензии юридически обязывают владельца продукта раскрыть исходный код всего продукта при его распространении. Для коммерческой SaaS-модели или поставки on-premise это означало бы полную потерю исключительных прав на проприетарную часть продукта и передачу конкурентам всей интеллектуальной собственности.

Что сделали

• Проведён полный программно-лицензионный аудит состава ПО
• С помощью специализированного ПО и ручного анализа составлен полный перечень всех компонентов, включая транзитивные зависимости
• Каждая лицензия сопоставлена с бизнес-моделью распространения продукта. Выделены компоненты, создающие обязательство раскрытия кода
• Для каждого проблемного компонента подготовлен план перехода на альтернативные решения
• Результаты аудита оформлены в виде карты лицензионных рисков, переходящих к покупателю вместе с активом

Результат

• Стоимость замены проблемных компонентов учтена как дисконт к стоимости сделки
• Исключён риск судебного иска со стороны правообладателей Open Source зависимостей после сделки, который мог бы привести к принудительному открытию кода или запрету на продажу продукта
• Покупатель получил подтверждение, что приобретаемый актив не обременён обязательствами, связанными с его коммерческой тайной
• Сформирован полный реестр с подтверждённым лицензионным статусом каждого компонента
• Внедрена политика использования Open Source и автоматизированные проверки, предотвращающие попадание «вирусных» лицензий в код при дальнейшей разработке

Ситуация

В ходе операционной деятельности продукта накоплен массив персональных данных клиентов (миллионы записей). На момент проверки выявлены критические нарушения Федерального закона № 152-ФЗ: нарушение принципа целеполагания – сроки хранения данных не установлены и не привязаны к целям обработки (ч. 7 ст. 5 152-ФЗ); в тестовых средах использовались полные копии продуктивных баз данных, что создавало риск утечки и нарушало требование локализации (ч. 5 ст. 18 152-ФЗ); учёт обращений субъектов к своим данным и логирование доступа не велись, что делает невозможной защиту при проверках Роскомнадзора. Ответственность по ст. 13.11 КоАП РФ за данные нарушения (штрафы до 3% от выручки или до 18 млн рублей) переходит к покупателю в полном объёме вместе с активом.

Что сделали

• Проведён комплексный аудит управления жизненным циклом персональных данных
• Проведён анализ процессов сбора и хранения, определены точные категории данных, их местонахождение (включая тестовые среды) и объём в количественном выражении
• Рассчитана потенциальная сумма штрафов по ст. 13.11 КоАП с учётом масштаба системы
• Разработан план устранения: установлены юридически обоснованные сроки хранения для каждой категории данных; сформулированы требования к очистке тестовых сред и внедрению деперсонализации данных; разработана архитектура внедрения журналов обращений и системы управления согласиями

Результат

• Выявленный регуляторный риск отражён в соглашении о купле-продаже в виде обязательств продавца по устранению нарушений до закрытия сделки
• Покупатель получил количественную оценку объёма данных, подлежащих очистке, что позволило точно рассчитать бюджет на приведение системы в соответствие
• Запущены работы по плану приведения процессов обработки персональных данных в соответствие с 152-ФЗ с оценкой трудоёмкости в человеко-часах
• Устранение использования полных копий в тестовых средах исключает риск катастрофической утечки и блокировки ресурса Роскомнадзором
• Внедрение журналов обращений и сроков хранения переводит компанию из зоны «неконтролируемого риска» в зону прозрачного комплаенса, готовую к плановым и внеплановым проверкам регулятора

Ситуация

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

Что сделали

• Проведён аудит архитектуры, программного кода и процессов разработки
• С помощью специализированных инструментов проведён анализ модулей с высокой частотой изменений
• Рассчитан объём работ по рефакторингу критических модулей, внедрению автоматизированного тестирования и устранению дублирования бизнес-правил
• Сроки достижения поставленных целей пересчитаны с учётом необходимости выделения 20–30% времени на борьбу с техническим долгом

Результат

• Стоимость приведения кода в порядок учтена как дисконт к стоимости сделки
• Покупатель получил объективный график выпуска модулей, учитывающий время на стабилизацию платформы, вместо завышенных обещаний
• Сформирован реестр технического долга, ранжированный по приоритетам. Компания понимает, какие модули блокируют развитие (высокая сложность, дублирование), а какие требуют лишь косметического рефакторинга
• Внедрение автоматизированного тестирования позволит снизить стоимость поддержки продукта