IT Due Diligence – Kompletny przewodnik dla procesów M&A (Buy-side i Sell-side)

W dobie cyfrowej gospodarki technologie stanowią fundament działania biznesu i jego główną przewagę konkurencyjną. Dlatego w procesach fuzji i przejęć (M&A) analiza technologiczna przestała być opcjonalnym dodatkiem, a stała się krytycznym elementem wyceny ryzyka.

IT Due Diligence to szczegółowa analiza kondycji technologicznej przedsiębiorstwa, która pozwala zrozumieć całe środowisko IT – od systemów i infrastruktury, przez procesy i zespół, aż po bezpieczeństwo i zgodność z regulacjami.

Specjalista IT przeprowadzający analizę due diligence infrastruktury technologicznej w centrum danych – ocena ryzyk technologicznych przed transakcją M&A

Audytor IT w centrum danych – IT Due Diligence wymaga bezpośredniego dostępu do infrastruktury, dokumentacji i zespołu technicznego, aby rzetelnie ocenić kondycję technologiczną firmy przed transakcją.

Czym jest IT Due Diligence i dlaczego decyduje o powodzeniu transakcji?

Prawidłowo przeprowadzone badanie daje obu stronom pełny obraz stanu technologii, zanim dojdzie do wiążącej transakcji. IT Due Diligence odpowiada na fundamentalne pytanie: czy technologia firmy jest atutem, który uzasadnia wycenę, czy ukrytym obciążeniem, które ją zawyża?

IT Due Diligence vs Audyt IT – kluczowe różnice

W SparkSome kładziemy nacisk na rozróżnienie tych pojęć. Podczas gdy typowy audyt IT to skrupulatne prześwietlenie technologii pod kątem jej bieżącej solidności, badanie Due Diligence idzie krok dalej – ocenia przydatność technologii dla celów biznesowych inwestora i identyfikuje ryzyka, które przechodzą na niego po transakcji.


Aspekt	Audyt IT	IT Due Diligence
Cel	Ocena bieżącego stanu IT	Ocena ryzyk technologicznych dla transakcji M&A
Perspektywa	Wewnętrzna (operacyjna)	Zewnętrzna (inwestorska / transakcyjna)
Zakres czasowy	Aktualny stan	Aktualny stan + prognoza kosztów i ryzyk
Odbiorca raportu	CTO / zarząd firmy	Inwestor / doradca M&A / fundusz PE
Wpływ na decyzję	Rekomendacje naprawcze	Wpływ na wycenę i warunki transakcji
Częstotliwość	Cykliczny (np. roczny)	Jednorazowy – przed transakcją

Dlaczego brak IT DD kosztuje?

Rzetelne badanie chroni obie strony przed stratami finansowymi i reputacyjnymi:

Unikanie kosztownych niespodzianek: Pozwala uniknąć nagłych inwestycji w modernizację zaniedbanej infrastruktury tuż po zakupie.
Właściwa wycena: Negatywne odkrycia (np. dług technologiczny) to argument do negocjacji ceny w dół dla kupującego, natomiast dla sprzedającego kompletna wiedza pozwala przygotować kontrargumenty i wzmocnić pozycję przetargową.
Zaufanie i transparentność: Jasny obraz stanu technologii, architektury i ryzyk operacyjnych ułatwia domknięcie transakcji oraz ogranicza ryzyko sporów po jej finalizacji.
Integracja Post-Merger (PMI): Badanie IT Due Diligence pozwala oszacować budżet i czas potrzebny na połączenie systemów obu firm.

Kiedy przeprowadzić IT Due Diligence?

Moment przeprowadzenia badania jest kluczowy. Zbyt późno – i wyniki nie wpłyną na warunki transakcji. Zbyt wcześnie – i dane mogą się zdezaktualizować.

Buy-side: Najlepiej po podpisaniu listu intencyjnego (LOI), a przed wiążącą umową (SPA). Daje to czas na analizę i renegocjację warunków.
Sell-side (Vendor DD): 3–6 miesięcy przed planowaną sprzedażą. Pozwala to na naprawienie krytycznych problemów i przygotowanie profesjonalnego Data Room.
Wejście inwestora (VC/PE): Przed rundą finansowania – nawet na etapie Seed/Series A, gdy technologia jest głównym aktywem startupu.

Kluczowe obszary ryzyka technologicznego – Pełna mapa analizy

Podczas pełnego badania IT Due Diligence prześwietlamy każdy zakamarek ekosystemu IT. Oto 8 filarów, na których opieramy nasze raporty:

1. Bezpieczeństwo informacji i regulacje

To priorytet dla inwestorów. Sprawdzamy szyfrowanie danych, politykę haseł, systemy backupów i plany awaryjne. Weryfikujemy zgodność z RODO oraz standardami branżowymi, aby incydenty z przeszłości nie stały się problemem i kosztem (karami) nowego właściciela.

Na co zwracamy szczególną uwagę:

Historia incydentów bezpieczeństwa i wycieków danych
Aktualne polityki bezpieczeństwa i ich egzekwowanie
Mechanizmy ochrony poczty firmowej (SPF, DKIM, DMARC)
Procedury wycofywania sprzętu IT i niszczenia danych
Certyfikaty bezpieczeństwa (ISO 27001, SOC 2)
Zagrożenia związane z deepfake i syntetycznymi tożsamościami

2. Dług technologiczny i jakość kodu

Ujawniamy stare wersje systemów, nieaktualizowane biblioteki i prowizoryczne „obejścia" w kodzie. Analizujemy, czy kupującego czeka „kapitalny remont technologiczny".

Typowe sygnały ostrzegawcze:

Kluczowe systemy działające na wersjach oprogramowania EOL (End of Life)
Brak testów jednostkowych lub integracyjnych
Monolityczna architektura bez możliwości skalowania
Zależności od przestarzałych frameworków (np. PHP 5.x, Python 2.x)
„Prowizoryczne" rozwiązania, które działają od lat bez dokumentacji

3. Infrastruktura IT i niezawodność

Weryfikujemy wydajność sprzętu, serwerów i chmury oraz to, czy systemy są skalowalne i gotowe na dalszy rozwój biznesu. Sprawdzamy mechanizmy wysokiej dostępności i procedury odtwarzania po awarii. Kluczowe znaczenie ma tutaj sposób zaprojektowania architektury IT.

Kluczowe pytania:

Czy infrastruktura jest on-premise, cloud, czy hybrydowa? Jakie są argumenty za chmurą i jakie za własnym serwerem?
Jaki jest wiek sprzętu i kiedy kończą się gwarancje?
Czy istnieją procedury Disaster Recovery i czy były testowane?
Ile kosztuje godzina przestoju w analizowanej firmie?
Jak wygląda monitorowanie infrastruktury (Zabbix, Prometheus, Grafana)?

4. Jakość procesów wytwórczych (DevOps)

Oceniamy dojrzałość procesów CI/CD, testów automatycznych oraz sposobu wdrażania zmian w oprogramowaniu. Brak powtarzalnych procesów wdrożeniowych to sygnał, że każde wydanie nowej wersji niesie ryzyko awarii.

Elementy oceny:

Czy wdrożenia są zautomatyzowane, czy manualne?
Czy istnieje system kontroli wersji (Git) i code review?
Jak szybko zespół może wycofać błędne wdrożenie (rollback)?
Czy środowiska dev/staging/prod są odizolowane?
Jak wygląda proces zarządzania zmianami (change management)?

5. Własność intelektualna (IP) i licencje

Upewniamy się, że spółka posiada pełne prawa do kodu źródłowego i technologii. Weryfikujemy licencje open source pod kątem ryzyk prawnych dla komercyjnego wykorzystania.

Najczęstsze pułapki:

Licencje copyleft (GPL, AGPL) wymuszające udostępnienie kodu źródłowego
Własność kodu napisanego przez zewnętrznych freelancerów – czy prawa zostały poprawnie przeniesione?
Oprogramowanie wykorzystywane bez ważnych licencji komercyjnych
Kluczowe komponenty oparte na projektach open source o niepewnej przyszłości (single maintainer)

6. Zespół IT i ryzyko personalne

Analizujemy kompetencje zespołu i tzw. „bus factor" – sprawdzamy, czy kluczowa wiedza nie jest skupiona w rękach tylko jednej osoby, której odejście mogłoby sparaliżować firmę.

Obszary analizy:

Struktura zespołu IT i poziom specjalizacji
Wskaźnik rotacji pracowników technicznych (attrition rate)
Klauzule zakazu konkurencji (non-compete) w umowach kluczowych osób
Dostępność dokumentacji operacyjnej – czy wiedza jest w głowach ludzi, czy w systemach?
Zaplanowane procesy onboardingu i standaryzacji stacji roboczych

7. Dostawcy zewnętrzni i wsparcie (SLA)

Badamy umowy z zewnętrznymi dostawcami pod kątem poziomu świadczonych usług (SLA) oraz ryzyka uzależnienia od jednego dostawcy (vendor lock-in).

Checklist:

Lista wszystkich dostawców IT i miesięczne/roczne koszty
Warunki wypowiedzenia umów – czy istnieją klauzule lock-in?
Jakie dane przechowywane są u dostawców?
Czy możliwa jest migracja systemu do innego dostawcy bez utraty danych?
Poziomy SLA i historyczne wskaźniki dostępności (uptime)

8. Dokumentacja jako ryzyko transakcyjne

Brak aktualnych schematów sieci, diagramów architektury czy dokumentacji technicznej świadczy o niskim profesjonalizmie i jest sygnałem alarmowym dla audytorów. Firmy bez dokumentacji ponoszą wyższe koszty utrzymania IT.

Minimum dokumentacyjne, które oczekujemy:

Diagram architektury systemu (high-level i komponentowy)
Schemat sieci z adresacją i segmentacją VLAN
Lista wszystkich systemów, serwisów i ich zależności
Procedury backupu, odtwarzania i eskalacji
Dokumentacja API (jeśli firma udostępnia API)
Rejestr przetwarzania danych osobowych (RODO)

Przebieg badania IT Due Diligence – etap po etapie

Poniżej opisujemy typowy przebieg procesu IT DD, jaki realizujemy w SparkSome. Znajomość poszczególnych etapów pozwala obu stronom lepiej przygotować się do badania.

Etap 1: Kick-off i określenie zakresu (1–2 dni)

Spotkanie z inwestorem / doradcą M&A w celu ustalenia:

Zakresu analizy (pełny IT DD vs fokus na wybrane obszary)
Harmonogramu i terminów
Listy dokumentów do przygotowania (Information Request List – IRL)
Osób kontaktowych po stronie analizowanej spółki

Etap 2: Analiza dokumentacji (3–5 dni)

Przegląd dokumentów udostępnionych w Data Room:

Diagramy architektury, procedury operacyjne, umowy licencyjne
Raport z poprzednich audytów i testów penetracyjnych
Lista pracowników IT z opisem kompetencji
Rejestry incydentów bezpieczeństwa

Etap 3: Wywiady techniczne i sesje Q&A (2–5 dni)

Rozmowy z kluczowymi osobami w firmie:

CTO / Head of Engineering – strategia technologiczna
DevOps / SysAdmin – infrastruktura i procesy
Security Officer – bezpieczeństwo i compliance
Product Owner – roadmapa produktowa i dług technologiczny

Etap 4: Analiza techniczna i testy (3–7 dni)

W zależności od zakresu:

Skanowanie podatności infrastruktury (Nessus, OpenVAS)
Przegląd kodu źródłowego i analiza statyczna (SonarQube)
Weryfikacja konfiguracji chmury (AWS Config, Azure Policy)
Test odtwarzania z backupu (jeśli dozwolony)
Analiza logów i monitoringu

Etap 5: Raport i prezentacja wyników (2–3 dni)

Dostarczamy raport zawierający:

Executive Summary – kluczowe wnioski dla zarządu / inwestora
Matryca ryzyk – z klasyfikacją (krytyczne / wysokie / średnie / niskie)
Szacunek kosztów naprawczych – dla każdego zidentyfikowanego ryzyka
Rekomendacje – priorytetyzowane działania naprawcze
Wpływ na wycenę – sugerowane korekty lub zabezpieczenia transakcyjne

Jak przygotować firmę do sprzedaży (Sell-side) – Praktyczny poradnik

Dobre przygotowanie nie tylko ułatwia proces, ale podnosi wartość firmy w oczach inwestora. Firmy, które przechodzą Vendor Due Diligence (czyli zamawiają badanie same na siebie przed sprzedażą), osiągają średnio o 10–20% wyższe wyceny, ponieważ eliminują „efekt zaskoczenia" u kupującego.

Krok 1: Zbiór dokumentacji technicznej

Skompletuj diagramy architektury, listy serwerów/usług chmurowych, procedury backupu i dokumenty formalne (regulaminy, polityki bezpieczeństwa, umowy licencyjne). Jeśli nie masz dokumentacji – to znak, że warto ją stworzyć zanim inwestor zapyta. Przeczytaj więcej o tym, dlaczego dokumentacja jest kluczowa.

Krok 2: Wewnętrzny audyt próbny (Pre-Due Diligence)

Samodzielnie zweryfikuj prawa własności intelektualnej, zgodność z RODO i status umów B2B. Wykryj i napraw problemy (np. wdrożenie 2FA, aktualizacja firewalli, aktualizacja certyfikatów SSL), zanim odkryje je inwestor.

Typowe „quick wins" przed sprzedażą:

Wdrożenie 2FA/MFA na wszystkich systemach
Aktualizacja systemów do wspieranych wersji
Uporządkowanie licencji oprogramowania
Stworzenie brakującej dokumentacji
Przeprowadzenie testu odtwarzania z backupu

Krok 3: Przygotowanie Data Room i zespołu

Wyznacz kluczowe osoby (CTO, Tech Lead) do kontaktu z audytorami i przygotuj bezpieczną przestrzeń (SharePoint, Google Drive) z odpowiednimi uprawnieniami do wymiany dokumentów i kodu.

Struktura Data Room IT (przykładowa):

Architektura – diagramy, schematy, opis stosu technologicznego
Infrastruktura – lista serwerów, usług chmurowych, dostawców
Bezpieczeństwo – polityki, certyfikaty, historia incydentów
Zespół – struktura, kompetencje, umowy
Licencje i IP – rejestr oprogramowania, prawa autorskie
Procesy – CI/CD, monitoring, procedury operacyjne
Finanse IT – budżet, koszty licencji, amortyzacja sprzętu

Red flags – sygnały alarmowe w IT Due Diligence

Na podstawie dziesiątek przeprowadzonych analiz, zebraliśmy listę najczęstszych „czerwonych flag", które natychmiast alarmują inwestorów:


Red flag	Ryzyko	Potencjalny wpływ na wycenę
Brak testów odtwarzania z backupu	Utrata danych bez możliwości odzyskania	–5% do –15%
Jeden administrator bez dokumentacji (bus factor = 1)	Paraliż IT po odejściu tej osoby	–5% do –10%
Systemy na EOL (np. Windows Server 2012, CentOS 6)	Brak aktualizacji bezpieczeństwa	–3% do –8%
Nieuregulowane licencje komercyjne	Ryzyko kar finansowych od dostawcy	–2% do –10%
Brak polityki bezpieczeństwa i RODO	Ryzyko kar UODO do 4% obrotu	–5% do –20%
Klucze API / hasła w kodzie źródłowym	Ryzyko wycieku i nieautoryzowanego dostępu	–3% do –7%
Brak segmentacji sieci (VPN/VLAN)	Atak na jeden system = kompromitacja wszystkich	–3% do –10%
Vendor lock-in bez planu migracji	Brak kontroli nad kosztami i dostępnością	–2% do –5%

Przykłady z praktyki – realne ryzyka ukryte w IT

Przypadek 1: Spółka usługowa – backup, który nie działał

W jednym z analizowanych przypadków spółka usługowa deklarowała nowoczesne i skalowalne środowisko IT. W trakcie IT Due Diligence wykryliśmy jednak kilka krytycznych problemów:

brak testów odtwarzania backupów (backup był, ale nie działał),
uzależnienie kluczowych systemów od jednego administratora (wysoki „bus factor"),
nieuregulowane licencje oprogramowania.

Efekt: Inwestor zdecydował się na obniżenie wyceny o około 15%, a część środków została zabezpieczona na pokrycie ryzyk technologicznych po przejęciu.

Przypadek 2: Startup SaaS – licencje GPL w komercyjnym produkcie

Startup oferujący produkt SaaS wykorzystywał w swoim rdzeniu bibliotekę open source na licencji AGPL, nie zdając sobie sprawy z konsekwencji. Licencja AGPL wymaga udostępnienia kodu źródłowego użytkownikom korzystającym z aplikacji przez sieć. Wykrycie tego w trakcie IT DD oznaczało konieczność przepisania kluczowego komponentu lub zmianę modelu licencyjnego.

Efekt: Transakcja została opóźniona o 4 miesiące, a inwestor wynegocjował escrow na 200 tys. PLN na pokrycie kosztów refaktoryzacji.

Przypadek 3: Firma produkcyjna – shadow IT

Firma produkcyjna oficjalnie korzystała z jednego systemu ERP. W trakcie badania okazało się, że pracownicy stworzyli równoległy „ekosystem" złożony z kilkudziesięciu arkuszy Excel połączonych makrami VBA, na którym opierały się kluczowe procesy logistyczne. System nie miał dokumentacji, backup'u ani właściciela.

Efekt: Inwestor zażądał dodatkowego zabezpieczenia transakcyjnego i planu migracji shadow IT do formalnego systemu.

Operacyjna perspektywa zarządu – Koszty i decyzje po transakcji

W SparkSome kładziemy nacisk na to, co dzieje się po podpisaniu umowy. IT Due Diligence pozwala oszacować budżet i czas potrzebny na integrację oraz identyfikuje ukryte koszty CAPEX i OPEX, które wpłyną na rentowność w okresie Day 1 – Day 100.

Plan integracji IT – Day 1, Day 30, Day 100


Faza	Działania	Cel
Day 1	Zabezpieczenie dostępów, zmiana haseł admin, audyt kont	Kontrola nad infrastrukturą
Day 1–30	Ujednolicenie narzędzi komunikacji, integracja VPN, SSO	Ciągłość operacyjna
Day 30–60	Konsolidacja monitoringu, migracja pierwszych systemów	Widoczność i kontrola
Day 60–100	Harmonizacja procesów DevOps, ujednolicenie stack techno.	Synergie operacyjne
Day 100+	Optymalizacja kosztów, renegocjacja licencji, kontynuacja migracji	ROI z integracji

Badanie to zabezpiecza realizację strategii wzrostu i chroni przyszłe wypłaty typu earn-out przed negatywnymi skutkami zaniedbań technologicznych.

Rola SparkSome i nasza odpowiedzialność doradcza

Jesteśmy butikową firmą IT z Polski, specjalizującą się we wsparciu technologicznym procesów M&A.

Dla kupujących (Investor / M&A): Oferujemy kompleksowy audyt potencjalnej inwestycji, dostarczając raporty napisane prostym językiem, które wskazują konkretne ryzyka wpływające na biznes i wycenę.
Dla sprzedających (Founder / Software House): Pomagamy w audytach pre-due-diligence i przygotowaniu firmy do sprzedaży, działając jako „tłumacz" między Twoim zespołem a audytorami inwestora.
Dla funduszy PE/VC: Dostarczamy techniczny „second opinion" przy ocenie portfolio company, pomagając oszacować realne koszty post-merger integration.

Naszym atutem jest eksperckie podejście inżynierów i architektów, którzy dostarczają realne wnioski (actionable insights) zamiast powierzchownych checklist. Weryfikujemy systemy oparte na Linuxie oraz architekturę chmurową, dbając o to, by technologia stała się Twoim atutem, a nie źródłem ryzyka.

Skontaktuj się z nami już dziś na niezobowiązującą konsultację.

FAQ – najczęstsze pytania o IT Due Diligence

1. Ile trwa IT Due Diligence?

Zazwyczaj od 2 do 6 tygodni, w zależności od skali infrastruktury, dostępności dokumentacji i zakresu badania. Małe firmy (do 50 pracowników) to zwykle 2–3 tygodnie. Firmy średnie i duże – 4–6 tygodni. Na czas wpływa również responsywność zespołu analizowanej spółki.

2. Ile kosztuje IT Due Diligence?

Koszt zależy od zakresu analizy, ale najczęściej stanowi 0,1–0,5% wartości transakcji. Dla spółek o wycenie 5–50 mln PLN typowy koszt to 30–150 tys. PLN. W porównaniu z potencjalnymi stratami wynikającymi z nieodkrytych ryzyk, jest to inwestycja, która wielokrotnie się zwraca.

3. Kiedy warto wykonać IT Due Diligence?

Przed zakupem firmy, wejściem inwestora lub sprzedażą biznesu – wszędzie tam, gdzie technologia wpływa na wycenę. W szczególności: po podpisaniu LOI (buy-side), 3–6 miesięcy przed planowaną sprzedażą (sell-side) lub przed rundą finansowania (startup).

4. Czy małe firmy też powinny robić IT Due Diligence?

Tak – w mniejszych organizacjach ryzyka są często większe, bo brakuje formalnych procesów i dokumentacji. Paradoksalnie, firmy 10–50 osobowe mają zwykle najwyższy „bus factor" i najmniej udokumentowaną infrastrukturę, co czyni je bardziej ryzykownymi z perspektywy inwestora.

5. Co najczęściej wychodzi w trakcie analizy?

Najczęstsze odkrycia to: problemy z backupami (brak testów odtwarzania), brak dokumentacji technicznej, vendor lock-in, niejasności w licencjach oprogramowania, wysoki bus factor oraz systemy na wersjach EOL bez aktualizacji bezpieczeństwa.

6. Czym różni się Buy-side od Sell-side IT DD?

Buy-side IT DD jest zamawiane przez kupującego i ma na celu identyfikację ryzyk, które mogą wpłynąć na wycenę lub warunki transakcji. Sell-side (Vendor DD) jest zamawiane przez sprzedającego i ma na celu proaktywne odkrycie i naprawę problemów przed rozpoczęciem sprzedaży, co buduje zaufanie inwestora i przyspiesza proces transakcyjny.

7. Co to jest Vendor Due Diligence i czy opłaca się je robić?

Vendor DD to badanie zamówione przez sprzedającego zanim rozpocznie się proces sprzedaży. Opłaca się, ponieważ: eliminuje efekt zaskoczenia u kupującego, pozwala naprawić problemy zanim wpłyną na wycenę, przyspiesza transakcję i buduje profesjonalny wizerunek firmy. Firmy z przeprowadzonym Vendor DD osiągają średnio 10–20% wyższe wyceny.

8. Jak IT Due Diligence wpływa na wycenę firmy?

Negatywne odkrycia mogą obniżyć wycenę od kilku do nawet 20–30%. Typowe mechanizmy to: obniżenie ceny transakcyjnej, utworzenie escrow na pokrycie kosztów naprawczych, klauzule earn-out uzależnione od naprawy problemów IT, lub indemnification clauses chroniące kupującego przed konkretnymi ryzykami.

9. Czy IT DD obejmuje testy penetracyjne?

Nie zawsze. Standardowe IT DD obejmuje przegląd polityk bezpieczeństwa, konfiguracji i procesów. Testy penetracyjne (pentest) mogą być dodatkowym obszarem analizy, jeśli inwestor tego wymaga. Warto je przeprowadzić, szczególnie gdy firma przetwarza wrażliwe dane klientów lub działa w sektorze regulowanym (finanse, medycyna).

10. Jakie dokumenty przygotować do Data Room?

Minimum to: diagramy architektury, lista systemów i dostawców IT, polityki bezpieczeństwa, rejestr licencji oprogramowania, umowy z dostawcami IT, struktura zespołu IT, procedury backupu i DR, rejestr przetwarzania danych RODO, historia incydentów bezpieczeństwa.

11. Co to jest „bus factor" i dlaczego jest ważny w M&A?

Bus factor to minimalna liczba osób, których odejście sparaliżowałoby kluczowe procesy IT. Jeśli bus factor = 1 (cała wiedza w jednej głowie), to ogromne ryzyko dla inwestora. Rozwiązaniem jest dokumentacja, szkolenia krzyżowe i redundancja kompetencji. Więcej o tym piszemy w artykule o bus factor i odporności IT.

12. Czy IT Due Diligence jest potrzebne dla firm SaaS?

Zdecydowanie tak – dla firm SaaS technologia jest głównym aktywem. IT DD w kontekście SaaS obejmuje dodatkowo: analizę architektury multi-tenant, skalowalność, koszty infrastruktury chmurowej (unit economics), bezpieczeństwo danych klientów, zgodność z SOC 2 oraz jakość kodu jako produktu.

13. Jak wygląda raport z IT Due Diligence?

Raport SparkSome zawiera: executive summary (1–2 strony dla zarządu), matrycę ryzyk z klasyfikacją (krytyczne/wysokie/średnie/niskie), szczegółową analizę każdego z 8 filarów, szacunek kosztów naprawczych, rekomendacje z priorytetyzacją oraz sugerowane zabezpieczenia transakcyjne. Raport jest napisany zrozumiałym językiem, nie tylko dla inżynierów, ale też dla prawników i zarządu.

14. Co to jest escrow w kontekście IT DD?

Escrow to mechanizm zabezpieczenia transakcyjnego, w którym część ceny zakupu zostaje zamrożona na specjalnym koncie do momentu spełnienia określonych warunków (np. naprawy krytycznych problemów IT wykrytych w DD). Chroni kupującego przed ryzykiem, którego nie da się w pełni ocenić w momencie transakcji.

15. Czy SparkSome może pomóc w naprawie problemów wykrytych w IT DD?

Tak. Po zakończeniu badania oferujemy wsparcie w fazie remediacji – pomagamy naprawić wykryte problemy, wdrożyć brakujące procedury i przygotować środowisko IT do integracji post-merger. Działamy zarówno po stronie kupującego, jak i sprzedającego.