IT Due Diligence – Kompletny przewodnik dla procesów M&A (Buy-side i Sell-side)
- 1. Czym jest IT Due Diligence i dlaczego decyduje o powodzeniu transakcji?
- 2. Kluczowe obszary ryzyka technologicznego – Pełna mapa analizy
- 3. Przebieg badania IT Due Diligence – etap po etapie
- 4. Jak przygotować firmę do sprzedaży (Sell-side) – Praktyczny poradnik
- 5. Red flags – sygnały alarmowe w IT Due Diligence
- 6. Przykłady z praktyki – realne ryzyka ukryte w IT
- 7. Operacyjna perspektywa zarządu – Koszty i decyzje po transakcji
- 8. Rola SparkSome i nasza odpowiedzialność doradcza
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.
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.
