Skip to content 
Dariusz Rycek
Do napisania tego kolejnego wpisu w naszych aktualnościach zachęcił mnie pewien zbieg okoliczności. Z jednej strony uczestniczyłem w spotkaniu w ramach planowanej inwestycji IT polegającej na przejęciu przez firmę na przestrzeni 3 lat SOC – Security Operation Center, gdyż firma świadczy swoje usługi także jako operator usług kluczowych, a z drugiej strony wpadło mi do ręki nowe wydanie miesięcznika Financier z tytułowym artykułem „Znaczenie IT due diligence”. Niemalże jak opatrzność boska, bo jako świadek tego wydarzenia byłem mocno zdziwiony nie tylko przebiegiem rozmowy, ale przede wszystkim zapisami umowy.
Rozumiem, że nie było to przejęcie firmy, tylko transfer technologii z obsługą, jednakże koszt i tak robił wrażenie. Mimo, że w negocjacjach uczestniczył IT Manager, to w zapisach umownych nie było nic o badaniu due diligence, czy chociażby audytach IT, w tym audytach bezpieczeństwa – przynajmniej jako etap wstępny. Posiadanie certyfikatu ISO/IEC 27001 nie jest żadnym gwarantem sprawności, odpowiedniej organizacji, i mimo wszystko także bezpieczeństwa. Powiedziałem o tym w kuluarach koledze, który zaprosił mnie na spotkanie jako „shadow expert” starając się unikać oceny konkurencji, aby nie być posądzanym o stronniczość. Pamiętając jednak wiele zastrzeżeń do certyfikatora zasugerowałem aby zrobić audyt na miejscu, oraz sprawdzić zapisy z audytu, dopytać obsługę o kluczowe elementy ich systemu bezpieczeństwa i sprawdzić je „namacalnie”, nie mówiąc już o innych możliwych działaniach. Czas pokaże jak odniesie się zaprzyjaźniona firma przynajmniej do powyższej informacji. Uznałem jednak za stosowne aby podzielić się przynajmniej informacją o artykule, bo badanie due diligence w IT jest standardem na zachodzie, a u nas po raz kolejny widzę jakąś niefrasobliwość.
W artykule Richarda Summerfielda w „Finannacier Worldwide” wydanie 01-2022 jest kilka ważnych motywów dotyczących due diligence, jak np. cel takiego badania, sposób jego przeprowadzenia, czy też jak je doskonalić aby dostarczało wartości.
A co powinno być głównym celem badania due diligence IT. Otóż w badaniu powinno określić się czy istnieją ryzyka duże, niemalże nie do przezwyciężenia, które mogłyby wpłynąć na transakcję lub proces integracji po transakcji. Musimy mieć gwarancję, że w procesie tym konieczne jest dokładne zrozumienie wszystkich aspektów funkcjonowania firmy docelowej, w tym przeglądu oprogramowania korporacyjnego, istniejących ram IT oraz charakteru kluczowych danych. Dodałbym jeszcze udziału stron trzecich i sposobu nadzoru nad nimi, oraz zakresu prac i wpływu na kluczowe procesy. Strona techniczna i systemowa oparta o kryteria odwołująca się do standardów ISO/IEC 27001, ISO 22301 to niezbędne minimum, jednakże warto rozszerzyć je o kilka innych norm odniesienia, jak chociażby rodzinę ISO/IEC 27035 w zakresie reakcji na incydenty. Norma jest tylko kryterium audytu, jednakże może nam pomóc zbudować zakres badania audytowego.
Mottem przewodnim artykułu jest sentencja „due diligence powinno badać fundamenty wartości w przejmowanej spółce, aby zapewnić lepszy obraz perspektyw potencjalnej transakcji, jak również możliwych ryzyk, które mogłyby ją podważyć”. Pokrywa się to także z wnioskami końcowymi.
Dlatego też na końcu artykułu podsumowując całą jego treść napisano, że badanie due diligence w obszarze IT powinno zbadać fundamenty wartości w firmie docelowej, aby zapewnić lepszy obraz perspektyw potencjalnej transakcji, jak również możliwych ryzyk, które mogłyby ją podważyć. Biorąc pod uwagę zależność firm od technologii, due diligence IT nie powinno być pomijane w procesie fuzji i przejęć. A w przypadku, gdy jak w opisywanym studium inwestycja (przejęcie) zorganizowanej części firmy powinna być także wymaganym elementem zabezpieczającym interesariuszy przed chybioną inwestycją.
Zapraszamy do współpracy
Zespół Centre of Excellence