Как провести IT due diligence в компании

Сделка по покупке выглядит убедительно до того момента, когда после подписания обнаруживаются устаревшая инфраструктура, неупорядоченные лицензии, слабый контроль доступа и резервные копии, которым нельзя доверять. Именно поэтому вопрос о том, как провести IT due diligence, — это не техническая формальность, а оценка бизнес-рисков. Если IT-среда поддерживает продажи, обслуживание клиентов, финансовые процессы и безопасность данных, то её качество напрямую влияет на стоимость компании.

Цель IT due diligence — не только найти проблемы. Его задача — понять, что именно компания купила или планирует купить с точки зрения технологий, насколько стабильна среда, сколько будет стоить её упорядочивание и существуют ли риски, которые могут повлиять на интеграцию, непрерывность или соответствие требованиям. Хорошая оценка помогает принимать решение с открытыми глазами, а не на основе предположений.

Как проводить IT due diligence с бизнес-подходом

Самая распространённая ошибка — начинать со списка серверов, лицензий и систем, прежде чем станет ясно, что именно в сделке нужно защитить. Сначала необходимо определить бизнес-контекст. Речь идёт о покупке, инвестиции, слиянии, реструктуризации или начале сотрудничества? Что важнее всего: кибербезопасность, сложность интеграции, устойчивость инфраструктуры или прозрачность затрат? От этого будет зависеть глубина проверки.

В небольшой компании IT due diligence обычно не требуется в виде сотен страниц. Однако он должен охватывать критические области, в которых скрываются финансовые и операционные риски. Руководству важно видеть не только техническую ситуацию, но и её влияние на способность компании работать без перебоев.

Начните с картирования систем

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

На этом этапе важно выяснить, какие системы критичны для работы, а какие являются лишь вспомогательными решениями. Например, ERP, бухгалтерия, управление складом, CRM и электронная почта обычно имеют высокое бизнес-влияние. Если какая-либо из этих систем основана на устаревшей платформе или знаниях одного конкретного человека, это уже важный сигнал.

Проверьте права собственности, доступы и зависимости

На бумаге у компании может быть «всё IT», но на практике учётные записи, лицензии или административные доступы могут принадлежать аутсорсинговому поставщику, бывшему сотруднику или даже третьей стороне в другой стране. Это одно из самых неприятных открытий после сделки, потому что без контроля над доступами невозможно обеспечить ни безопасность, ни управление.

Нужно выяснить, кому принадлежат домены, среда Microsoft 365 или Google Workspace, межсетевые экраны, системы резервного копирования, облачные серверы, SaaS-подписки и права администратора. Также следует оценить зависимость от одного поставщика или одного сотрудника. Если работу компании поддерживает один внешний специалист без документации, риск высок даже тогда, когда в повседневной работе всё функционирует.

Основные области, которые нужно оценивать в процессе IT due diligence

IT due diligence — это не только аудит кибербезопасности. Это более широкая проверка, где безопасность — лишь одна из частей. Чтобы оценка была полезной для руководства, необходимо рассмотреть как минимум следующие области.

Состояние инфраструктуры и её поддерживаемость

Следует оценить, насколько старое оборудование, есть ли гарантии, получают ли системы обновления и документирована ли среда. Устаревшая инфраструктура не всегда означает немедленную катастрофу, однако почти всегда означает близкие инвестиции. Если серверы, сетевое оборудование или рабочие места находятся в конце жизненного цикла, это должно быть отражено в модели сделки.

Важен также архитектурный принцип. Является ли среда простой и понятной, или же за годы она была собрана из разных решений без общей логики? Во втором случае интеграция после сделки будет дороже и медленнее.

Кибербезопасность и защита данных

Следует оценить, есть ли у компании многофакторная аутентификация, защита конечных устройств, контроль доступа, журналы безопасности, управление уязвимостями и процесс реагирования на инциденты. Также нужно посмотреть, были ли инциденты безопасности и как они документированы.

В малых и средних компаниях часто встречается ситуация, когда безопасность внедрена частично. Например, для электронной почты защита есть, но у серверов нет централизованного мониторинга, или резервные копии существуют, но регулярные тесты восстановления не проводятся. Это означает, что риск не теоретический, а практический.

Если компания обрабатывает персональные данные, информацию о клиентских договорах или конфиденциальные финансовые данные, необходимо оценить и аспект соответствия требованиям. Здесь недостаточно фразы, что «мы соблюдаем GDPR». Должно быть понятно, как хранятся данные, кто имеет к ним доступ и насколько быстро компания способна реагировать на инцидент.

Резервные копии, восстановление и непрерывность деятельности

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

Также следует оценить способность бизнеса к непрерывной работе. Как долго компания может работать без конкретной системы? Определены ли цели восстановления? Документированы ли критические процессы? Компания с хорошей выручкой, но без реального плана восстановления может оказаться гораздо более рискованной, чем более скромная, но дисциплинированно управляемая компания.

Лицензии, договоры и фактические затраты

IT-затраты нередко бывают вводящими в заблуждение. Часть видна в ежемесячных счетах, но часть скрывается в неактуализированных договорах, неэффективных облачных ресурсах, несоответствующих лицензиях или дорогих локальных решениях, которые вскоре придётся менять. Во время due diligence необходимо выяснить не только сегодняшние расходы, но и потребности в инвестициях на ближайшие 12–24 месяца.

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

Как проводить IT due diligence без ненужного усложнения

Лицам, принимающим решения, обычно не нужен технический документ с десятками скриншотов. Нужна ясная оценка: что работает, что критично, сколько это будет стоить и каково будет влияние на бизнес. Поэтому процесс следует выстраивать структурированно.

Обычно он начинается с запроса документов и интервью с ответственными лицами. Затем следует проверка доступов, оценка конфигураций, классификация рисков и подведение итогов. Если доступная информация неполная, это само по себе является выводом — признаком низкой зрелости управления.

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

Если оценка выполняется профессионально, она не ограничивается констатацией «среда устарела». Она должна объяснять, что это означает на практике. Например, потребуется ли менять всё управление идентификацией, перестраивать политику резервного копирования, стандартизировать конечные устройства или переводить критические системы на другую модель размещения. Именно здесь due diligence становится инструментом управления, а не просто техническим отчётом.

Наиболее распространённые ошибки, которые удорожают сделку

Самая распространённая ошибка — слишком позднее привлечение IT. Финансовая и юридическая проверка проводится вовремя, а IT рассматривается лишь поверхностно или в самом конце. В результате проблемы не влияют ни на цену, ни на план перехода, хотя их устранение после этого требует значительных ресурсов.

Вторая ошибка — полагаться только на описания, предоставленные целевой компанией. Если говорится, что есть резервные копии, нужно проверить их работоспособность. Если утверждается, что безопасность приведена в порядок, нужно понять, как это реализовано на практике. Без верификации due diligence теряет смысл.

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

Для компаний, у которых нет собственной большой внутренней IT-команды, такую оценку обычно полезно проводить с независимым и ориентированным на бизнес партнёром. Подход KSK IT в таких случаях заключается в оценке не только технической среды, но и её влияния на непрерывность, способность к восстановлению и качество управления.

Хороший процесс IT due diligence не создаёт иллюзию, что риск полностью исчезнет. Он позволяет понять, где риск приемлем, где его нужно устранить до сделки, а где — включить в бюджет интеграции. Если эту работу выполнить вовремя, технологии не застанут врасплох ни владельцев, ни инвесторов, ни руководство в момент, когда ошибки уже дорого стоят.