Перевірка кіберризиків компанії до її придбання або злиття (M&A)

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

У найгіршому випадку всередині інфраструктури вже може бути зловмисник, скомпрометований обліковий запис або прихований механізм віддаленого доступу.

Саме тому cybersecurity due diligence, або перевірка кіберризиків компанії перед її придбанням чи злиттям (Mergers & Acquisitions, M&A), має бути такою ж важливою частиною оцінки активу, як фінансовий, юридичний і податковий due diligence.

Особливо це актуально для технологічних компаній, SaaS-бізнесів, фінансових організацій, e-commerce, healthcare, виробничих підприємств та компаній, які працюють із великими обсягами персональних або конфіденційних даних.

У цій статті розберемо, що перевіряти з кібербезпеки перед придбанням або злиттям компаній, як провести cybersecurity due diligence, які red flags шукати та як виявлені кіберризики можуть вплинути на вартість і умови M&A-угоди.

Що таке cybersecurity due diligence при придбанні або злитті компаній (M&A

Cybersecurity due diligence — це комплексна оцінка кіберризиків компанії перед її придбанням, злиттям або значною інвестицією.

Мета такої перевірки — зрозуміти не просто те, чи встановлений у компанії антивірус або firewall, а наскільки реальний стан її кібербезпеки відповідає вартості та ризик-профілю активу.

Фактично покупець повинен отримати відповіді на кілька ключових питань:

• чи була компанія скомпрометована раніше;
• чи може вона бути скомпрометована зараз;
• які критичні вразливості існують в IT-інфраструктурі;
• наскільки добре захищені дані, продукти та інтелектуальна власність;
• чи виконуються вимоги законодавства, контрактів і стандартів безпеки;
• які інвестиції в кібербезпеку знадобляться після закриття угоди;
• чи можуть виявлені проблеми призвести до штрафів, витоку даних, простою або судових претензій.

Це принципово відрізняє cybersecurity due diligence від звичайного vulnerability scan або penetration test.

Пентест відповідає переважно на питання «чи можна зламати певну систему?». Due diligence повинен відповісти на ширше питання:

«Який кіберризик ми фактично купуємо разом із цим бізнесом?»

Чому кібербезпека важлива при купівлі компанії

Кіберризики мають одну особливість: вони далеко не завжди очевидні на момент підписання угоди.

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

Ще небезпечніша ситуація — коли компрометація вже відбулася, але компанія про неї не знає.

Зловмисники можуть тривалий час залишатися всередині корпоративної мережі, використовувати викрадені credentials, cloud access keys, VPN-доступ або скомпрометовані адміністративні акаунти.

Після M&A-угоди така інфраструктура часто інтегрується з системами покупця.

У результаті ризик однієї компанії може перетворитися на ризик усієї групи.

Саме тому cybersecurity due diligence варто проводити до завершення угоди та до повної інтеграції IT-середовищ.

Що саме потрібно перевіряти під час M&A cybersecurity due diligence

Повноцінна перевірка не повинна обмежуватися одним скануванням інфраструктури. Вона має охоплювати технології, процеси, людей, дані та історію кіберінцидентів.

1. IT-інфраструктура та attack surface

Спочатку потрібно зрозуміти, що саме належить компанії та доступне потенційному атакувальнику.

Перевіряються домени та субдомени, IP-адреси, сервери, VPN, firewalls, віддалені сервіси, SaaS-платформи, хмарні ресурси, вебзастосунки, API та інші зовнішні точки входу.

Особливу увагу варто приділити так званому shadow IT — системам і сервісам, які використовуються співробітниками, але формально не контролюються IT-відділом.

Наприклад, команда розробки могла створити окремий AWS-акаунт кілька років тому, розгорнути там production-сервіс і залишити його поза централізованим контролем.

Такі активи часто стають слабкою ланкою безпеки.

2. Критичні та невиправлені вразливості

Наступне питання — наскільки великим є накопичений security debt.

Потрібно перевірити операційні системи, сервери, мережеве обладнання, вебзастосунки, VPN, middleware, бази даних, endpoint-системи та інші критичні компоненти.

Важливо дивитися не лише на кількість знайдених CVE.

Наприклад, десять низькоризикових вразливостей у внутрішній системі можуть бути значно меншою проблемою, ніж одна критична вразливість у публічно доступному VPN-шлюзі.

Тому кожну проблему потрібно оцінювати в контексті її експлуатованості, доступності системи, критичності активу та потенційного бізнес-впливу.

3. Identity & Access Management

Облікові записи — одна з найважливіших зон перевірки.

Потрібно визначити:

 - чи використовується MFA;

 - як управляються адміністративні акаунти;

 - чи існують shared accounts;

 - чи контролюються service accounts;

 - як відбувається onboarding та offboarding;

 - чи залишилися активними акаунти колишніх співробітників;

 - як зберігаються API keys, tokens та passwords;

 - хто має доступ до production-середовища;

 - чи застосовується принцип least privilege.

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

Після M&A вони можуть залишитися непоміченими й перетворитися на прихований канал доступу до інфраструктури.

4. Active Directory та корпоративна мережа

Для компаній із Microsoft-інфраструктурою окремої уваги потребує Active Directory.

Слабка конфігурація AD може дозволити атакувальнику після компрометації одного звичайного endpoint отримати привілеї адміністратора домену.

Під час перевірки оцінюються privileged groups, service accounts, password policies, delegation, legacy protocols, lateral movement paths та інші потенційні шляхи підвищення привілеїв.

Для великих M&A-угод особливо важливо зробити це до встановлення trust або інших інтеграцій між доменами покупця та придбаної компанії.

5. Cloud security

Якщо компанія використовує AWS, Microsoft Azure або Google Cloud, необхідна окрема перевірка cloud security.

Аналізуються IAM-політики, privileged access, security groups, публічно доступні storage buckets, secrets, encryption, logging, network configuration та cloud security posture.

Окремий ризик становлять довгоживучі access keys.

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

6. Безпека продукту та SDLC

Для SaaS, software development та інших технологічних компаній продукт часто є головним активом угоди.

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

Варто оцінити архітектуру застосунку, безпеку API, authentication та authorization, dependency management, CI/CD, secrets management, code repositories, процес виправлення вразливостей та використання open-source компонентів.

За необхідності проводиться penetration testing або security review критичних компонентів продукту.

Особливе питання — хто має доступ до source code та production deployment.

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

7. Захист корпоративних даних

Покупець повинен розуміти, які саме дані він отримує разом із компанією і як ці дані захищаються.

Це можуть бути персональні дані клієнтів, фінансова інформація, платіжні дані, медична інформація, комерційні таємниці, source code, інтелектуальна власність або конфіденційні дані партнерів.

Потрібно визначити:

 - де зберігаються дані;

 - хто має до них доступ;

 - чи використовується encryption at rest та in transit;

 - чи існують резервні копії;

 - чи перевіряється можливість відновлення;

 - чи застосовуються retention та deletion policies;

 - чи можуть співробітники неконтрольовано копіювати дані.

Особливо важливо перевірити, чи відповідає фактична практика роботи з даними тому, що компанія обіцяє клієнтам у договорах та privacy policy.

8. Попередні кіберінциденти

Одне з найважливіших питань під час due diligence:

«Чи були у компанії кіберінциденти?»

Але відповіді «ні» недостатньо.

Відсутність зафіксованих інцидентів може означати не високий рівень безпеки, а відсутність необхідного моніторингу.

Тому потрібно перевірити incident records, SIEM/EDR alerts, журнали автентифікації, security tickets, результати попередніх penetration tests, vulnerability scans та forensic investigations.

Варто окремо шукати ознаки компрометації корпоративних credentials, витоків даних і появи інформації компанії в Dark Web.

9. Чи немає атакувальника всередині системи вже зараз

Це один із ризиків, який найбільше недооцінюють при M&A.

Питання полягає не тільки в тому, чи можна атакувати компанію, а й у тому, чи не була вона вже атакована.

Тому для угод із високою вартістю або високим ризиком доцільно проводити compromise assessment або threat hunting.

Перевіряються аномальні входи, підозрілі процеси, persistence mechanisms, незвичні адміністративні акаунти, C2-комунікації, підозрілі PowerShell-команди, нетипові cloud sessions та інші Indicators of Compromise.

Це дозволяє зменшити ризик ситуації, коли покупець отримує компанію разом із уже присутнім у її інфраструктурі атакувальником.

10. Third-party та supply chain risks

Компанія може бути добре захищена сама по собі, але залежати від десятків сторонніх сервісів.

Потрібно перевірити критичних SaaS-провайдерів, MSP/MSSP, хостинг, cloud providers, development contractors, payment processors та інші сторонні компанії, які мають доступ до систем або даних.

Важливо зрозуміти не просто перелік постачальників, а який рівень доступу має кожен із них.

Компрометація стороннього адміністратора з доступом до production може мати такий самий ефект, як компрометація внутрішнього співробітника.

11. Compliance та регуляторні ризики

Cyber due diligence повинен включати перевірку вимог, які застосовуються до конкретного бізнесу.

Залежно від географії, галузі та типу даних це можуть бути GDPR, NIS2, DORA, PCI DSS, ISO/IEC 27001, SOC 2 та локальні вимоги.

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

Компанія може заявляти про compliance, але фактичний стан контролів може суттєво відрізнятися від документації.

Тому важливо перевіряти не тільки наявність політик і сертифікатів, а й реальне виконання security controls.

Red flags під час кібербезпекового due diligence

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

До найбільш серйозних сигналів належать:

• відсутність MFA для критичних систем;
• невідомий або неповний перелік IT-активів;
• End-of-Life операційні системи та обладнання;
• критичні вразливості, які не виправлялися місяцями;
• shared administrator accounts;
• відсутність централізованого logging;
• відсутність EDR або іншого endpoint monitoring;
• необмежений доступ розробників до production;
• secrets та passwords у source code;
• відсутність перевірених backup;
• активні акаунти колишніх співробітників;
• відсутність формального incident response process;
• невідомі сторонні користувачі з privileged access;
• попередні витоки даних, які не були належним чином розслідувані;
• відсутність контролю cloud environments;
• невідповідність фактичних security practices контрактним або regulatory requirements.

Один такий фактор може бути виправлений за декілька днів. Інший може вимагати повної перебудови архітектури.

Тому важливо не просто скласти список проблем, а перевести їх у фінансовий та операційний ризик.

Як кіберризики впливають на ціну M&A-угоди

Це одна з головних причин проводити cybersecurity due diligence до підписання угоди.

Уявімо, що компанія коштує $20 млн.

Під час перевірки виявляється, що їй необхідно:

 - замінити застарілу інфраструктуру;

 - впровадити MFA та PAM;

 - перебудувати cloud IAM;

 - закрити критичні вразливості;

 - впровадити EDR та централізований моніторинг;

 - провести remediation Active Directory;

 - перебудувати backup;

 - привести процеси у відповідність до вимог compliance.

Якщо для цього потрібно ще $500 000–$1 млн, це вже не просто «IT-проблеми».

Це фактичні майбутні витрати покупця, які мають враховуватися при оцінці активу.

Ще серйознішими можуть бути невизначені liabilities: потенційний витік персональних даних, regulatory investigation, порушення клієнтських контрактів або компрометація інтелектуальної власності.

Тому результати cybersecurity due diligence можуть впливати на:

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

Таким чином, кібербезпека безпосередньо стає частиною фінансової моделі M&A.

Як оцінювати виявлені ризики

Одна з поширених помилок під час перевірки кібербезпеки — передати інвестору технічний звіт із переліком сотень вразливостей без пояснення їхнього реального впливу на бізнес.

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

Технічні результати потрібно переводити мовою бізнес-ризиків.

Для кожної суттєвої проблеми варто визначити:

Імовірність реалізації ризику — наскільки реально зловмисник може скористатися виявленою вразливістю.

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

Активи під загрозою — які системи, дані та бізнес-процеси можуть постраждати.

Складність усунення — скільки часу та ресурсів знадобиться для виправлення проблеми.

Орієнтовна вартість усунення — які витрати необхідно передбачити для зниження або повного усунення ризику.

Терміни усунення — чи потрібно виправити проблему до завершення угоди, у перші 30 днів після придбання або протягом наступних 3–12 місяців.

Наприклад, замість суто технічного формулювання:

Критична вразливість CVE-XXXX з оцінкою CVSS 9.8.

бізнес має отримати зрозумілий висновок:

Публічно доступний VPN-сервіс має критичну вразливість, яка потенційно може дозволити зловмиснику отримати початковий доступ до корпоративної мережі. Система використовується для віддаленого доступу співробітників, тому її компрометація створює ризик подальшого проникнення у внутрішню інфраструктуру компанії. Рекомендовано усунути вразливість до об’єднання ІТ-інфраструктури придбаної компанії з інфраструктурою покупця.

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

Коли проводити перевірку кібербезпеки

Оптимально проводити перевірку до завершення угоди, коли покупець ще може врахувати виявлені ризики під час оцінки вартості компанії та визначення умов угоди.

На практиці перевірку можна розділити на кілька етапів.

Етап 1. Початкова оцінка кіберризиків.

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

Етап 2. Поглиблена технічна перевірка.

Після отримання необхідних доступів проводять детальнішу оцінку хмарної інфраструктури, облікових записів і прав доступу, кінцевих пристроїв, мереж, застосунків, вразливостей та систем моніторингу безпеки. За необхідності додатково проводять тестування на проникнення, перевірку Active Directory, оцінку безпеки хмарної інфраструктури або аналіз вихідного коду.

Етап 3. Перевірка на ознаки компрометації.

Для великих або високоризикових угод варто окремо перевірити, чи немає в інфраструктурі ознак поточної або попередньої присутності зловмисників, шкідливого програмного забезпечення чи прихованих механізмів доступу.

Етап 4. Перевірка перед інтеграцією.

До об’єднання ІТ-інфраструктури необхідно усунути критичні ризики. Це особливо важливо перед з’єднанням корпоративних мереж, налаштуванням довірчих відносин між доменами, об’єднанням систем керування обліковими записами та наданням спільного доступу до хмарних ресурсів.

Етап 5. Усунення ризиків після придбання.

Після завершення угоди формується план дій на перші 30, 60 і 90 днів, а також довгостроковий план приведення кібербезпеки придбаної компанії до вимог і стандартів покупця.

Що перевіряти з кібербезпеки перед придбанням компанії

Перед придбанням компанії мінімальний перелік перевірок має охоплювати такі напрями:

ІТ-інфраструктура: сервери, кінцеві пристрої, мережі, VPN, міжмережеві екрани, домени та зовнішня поверхня атаки.

Облікові записи та доступи: багатофакторна автентифікація (MFA), Active Directory, привілейовані та службові облікові записи, неактивні користувачі, політики доступу.

Хмарна інфраструктура: конфігурації AWS, Azure та GCP, керування ідентифікацією та доступом, сховища даних, ключі й секрети, журналювання подій та мережева безпека.

Застосунки: вебзастосунки, API, автентифікація, авторизація, сторонні компоненти та критичні вразливості.

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

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

Виявлення загроз та реагування: SIEM, EDR/XDR, журналювання подій, процес реагування на кіберінциденти та історія попередніх інцидентів.

Ознаки зовнішніх загроз: скомпрометовані облікові дані, витоки інформації, згадки у даркнеті та індикатори компрометації.

Сторонні постачальники: підрядники, постачальники ІТ-послуг та інші треті сторони, які мають доступ до систем, даних або критичної інфраструктури.

Відповідність вимогам: GDPR, NIS2, DORA, PCI DSS, ISO 27001, SOC 2 та інші нормативні, галузеві й договірні вимоги.

Безперервність бізнесу: резервне копіювання, аварійне відновлення, плани безперервності роботи та фактична здатність компанії відновити критичні системи після атаки програм-вимагачів або іншого серйозного кіберінциденту.

Що має отримати покупець після перевірки

Результатом якісної перевірки кібербезпеки не повинен бути великий технічний звіт із сотнями виявлених проблем без зрозумілих висновків.

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

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

Виявлені проблеми доцільно розділити на три групи:

Усунути до завершення угоди — критичні ризики, які необхідно виправити ще до придбання компанії.

Усунути до інтеграції — проблеми, які потрібно вирішити до підключення інфраструктури придбаної компанії до середовища покупця.

Усунути після придбання — системні покращення, які можна реалізувати після завершення угоди відповідно до визначеного плану та пріоритетів.

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

Чи достатньо пентесту перед придбанням компанії?

Ні.

Тестування на проникнення є важливою, але лише однією частиною комплексної перевірки кібербезпеки.

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

Тому перед придбанням або злиттям компаній потрібен комплексний підхід, заснований на оцінці ризиків.

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

Скільки часу займає перевірка кібербезпеки?

Тривалість залежить від розміру, структури та складності ІТ-середовища компанії.

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

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

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

Кібербезпека після придбання або злиття: ризики під час інтеграції

Завершення угоди не означає завершення кіберризиків.

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

У цей період можуть виникнути нові прогалини в захисті та додаткові шляхи для атак.

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

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

І лише після усунення критичних ризиків варто переходити до повної інтеграції інфраструктури.

Висновок

При придбанні або злитті компаній покупець отримує не лише бізнес.

Він отримує і його цифрову історію.

Застарілі сервери, невиправлені вразливості, хмарні облікові записи, доступи колишніх співробітників, ключі API, конфігурації, створені багато років тому, наслідки попередніх атак і дані клієнтів. А іноді — доступи, про існування яких сама компанія вже не пам’ятає.

Тому перед угодою важливо відповісти не лише на питання:

«Скільки коштує ця компанія?»

А й:

«Скільки коштуватиме зробити її безпечною та які кіберризики ми отримаємо разом із нею?»

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

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

Поширені запитання

Що таке перевірка кібербезпеки при придбанні або злитті компаній?

Це комплексна оцінка кіберризиків компанії перед її придбанням, злиттям або інвестуванням. Вона охоплює ІТ-інфраструктуру, хмарні середовища, облікові записи та права доступу, застосунки, дані, попередні кіберінциденти, відповідність нормативним вимогам і ризики, пов’язані зі сторонніми постачальниками.

Що перевіряти з кібербезпеки перед придбанням компанії?

Насамперед потрібно оцінити зовнішню поверхню атаки, критичні вразливості, багатофакторну автентифікацію, привілейовані доступи, Active Directory, хмарну інфраструктуру, захист даних і застосунків, резервне копіювання, журналювання та моніторинг подій, реагування на інциденти, попередні витоки даних і доступи третіх сторін.

Чи потрібен пентест перед придбанням або злиттям компаній?

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

Чи можуть кіберризики знизити вартість компанії?

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

Коли проводити перевірку кібербезпеки — до чи після угоди?

Основну перевірку доцільно проводити до завершення угоди. Критичні ризики бажано усунути до інтеграції ІТ-середовищ. Після придбання варто провести додаткову перевірку та реалізувати план усунення виявлених проблем.

Що таке перевірка на ознаки компрометації?

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