Dobra prezentacja produktu, atrakcyjna cena i rozbudowane SLA nie wystarczą, aby bezpiecznie wybrać dostawcę systemu IT. Przy zakupie oprogramowania trzeba sprawdzić nie tylko to, czy kontrahent istnieje i może podpisać umowę, ale także czy rzeczywiście potrafi wykonać projekt, właściwie chroni dane, ma prawa do oferowanego rozwiązania i będzie w stanie zapewnić ciągłość usług. W przypadku części przedsiębiorców takie działania nie są już wyłącznie dobrą praktyką. Od 3 kwietnia 2026 r. obowiązuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrażająca NIS2, a RODO od lat wymaga odpowiedniej oceny podmiotów, którym administrator powierza przetwarzanie danych.
Czy weryfikacja dostawcy IT jest obowiązkiem prawnym?
Nie istnieje jedna ustawa nakazująca każdemu przedsiębiorcy przeprowadzenie identycznego „due diligence kontrahenta”. Zakres obowiązków zależy od tego, kim jesteś, jakiego dostawcę wybierasz i jakie ryzyka wiążą się ze współpracą.
W przypadku dostawców technologicznych szczególne znaczenie mają obecnie dwa reżimy: KSC/NIS2 oraz RODO.
KSC i NIS2: ryzyko dostawcy stało się częścią cyberbezpieczeństwa
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 r. i rozszerzyła system m.in. o podmioty kluczowe i podmioty ważne. Podmiot powinien ustalić, czy podlega ustawie, przede wszystkim na podstawie rodzaju prowadzonej działalności, odpowiedniego sektora oraz kryteriów wskazanych w ustawie.
Dla procesu zakupowego szczególnie istotny jest art. 8 ustawy o KSC. System zarządzania bezpieczeństwem informacji ma obejmować m.in. bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT i procesów ICT. Przy ocenie ryzyka ustawa nakazuje również brać pod uwagę m.in. podatności związane z dostawcą, jakość dostarczanych produktów i usług oraz wyniki określonych ocen bezpieczeństwa.
Pamiętaj jednak o ważnym rozróżnieniu. Jeżeli mały dostawca oprogramowania sam nie jest podmiotem objętym KSC, nie staje się automatycznie podmiotem kluczowym lub ważnym tylko dlatego, że sprzedaje rozwiązanie przedsiębiorstwu podlegającemu ustawie. Obowiązek zarządzania ryzykiem dostawcy spoczywa przede wszystkim na podmiocie objętym KSC, ale w praktyce wymagania będą przenoszone na dostawców przez ankiety bezpieczeństwa, audyty i postanowienia umowne.
Nowelizacja już obowiązuje, lecz dla części obowiązków ustawodawca przewidział okres dostosowawczy. Ministerstwo Cyfryzacji wskazuje m.in. 3 kwietnia 2027 r. jako termin wdrożenia obowiązków przez określone podmioty, które spełniały kryteria w dniu wejścia nowelizacji w życie.
Ryzyka nie warto bagatelizować także z powodów finansowych. W odniesieniu do podmiotów kluczowych ustawa przewiduje w określonych przypadkach karę sięgającą 10 mln euro albo 2% przychodów z działalności gospodarczej – z zastosowaniem kwoty wyższej. Dla podmiotów ważnych maksymalny pułap wynosi 7 mln euro albo 1,4% przychodów. Przy najpoważniejszych naruszeniach ustawa przewiduje również karę do 100 mln zł.
RODO: sprawdź procesora, zanim powierzysz mu dane
Drugi przypadek dotyczy danych osobowych.
Jeżeli dostawca będzie przetwarzał dane w imieniu administratora, zastosowanie ma art. 28 RODO. Administrator powinien korzystać wyłącznie z usług podmiotów przetwarzających zapewniających wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych.
Nie oznacza to, że każdy producent programu automatycznie jest procesorem. Trzeba ustalić rzeczywisty model współpracy. Dostawca lokalnego programu, który nie ma dostępu do danych użytkownika, może w ogóle ich nie przetwarzać. Dostawca rozwiązania SaaS przechowującego bazę klientów na własnej infrastrukturze zazwyczaj będzie natomiast wykonywał operacje na danych na rzecz administratora.
Przed podpisaniem umowy sprawdź między innymi:
- gdzie będą przechowywane i przetwarzane dane,
- jakie zabezpieczenia stosuje dostawca,
- z jakich podmiotów podprzetwarzających korzysta,
- w jaki sposób obsługuje incydenty i naruszenia,
- jak wykonywane są kopie bezpieczeństwa,
- na jakich zasadach dane są zwracane albo usuwane po rozwiązaniu umowy,
- czy dochodzi do transferu danych poza Europejski Obszar Gospodarczy.
Sama umowa powierzenia nie rozwiązuje problemu. Jeżeli kontrahent deklaruje w dokumentach określony poziom bezpieczeństwa, ale organizacja nie próbuje ustalić, czy deklaracje są wiarygodne, dokumentacja może okazać się niewystarczająca z punktu widzenia rzeczywistego zarządzania ryzykiem.
ISO 27001 i SOC 2 pomagają, ale nie zastępują weryfikacji dostawcy
Przy dostawcach technologicznych często pojawiają się ISO/IEC 27001 oraz raporty SOC 2.
Są wartościowym źródłem informacji, ale nie powinny automatycznie przesądzać o akceptacji kontrahenta.
W przypadku certyfikatu ISO 27001 sprawdź przede wszystkim:
- zakres certyfikacji – czy obejmuje usługę, z której zamierzasz korzystać,
- jednostkę certyfikującą,
- okres ważności certyfikatu,
- czy wskazane lokalizacje i procesy odpowiadają modelowi oferowanemu twojej firmie.
W przypadku SOC 2 warto natomiast zweryfikować okres objęty raportem, rodzaj raportu, zakres badanych kontroli oraz ewentualne wyjątki i zastrzeżenia.
Certyfikat albo raport jest dowodem wspierającym ocenę, a nie gwarancją, że dostawca za rok będzie działał w taki sam sposób.
Najczęstszy błąd: prawnik pojawia się dopiero przed podpisaniem umowy
Jednym z najdroższych błędów jest traktowanie działu prawnego jako ostatniego punktu przed złożeniem podpisu.
Wyobraź sobie, że dział operacyjny przez dwa miesiące wybiera system do obsługi klientów. Dostawca zostaje wyłoniony, zarząd zna już cenę, migracja ma rozpocząć się w poniedziałek, a prawnik otrzymuje 70-stronicową umowę w czwartek po południu.
Formalnie można jeszcze przeprowadzić weryfikację. W rzeczywistości organizacja podjęła już decyzję biznesową, a każda poważniejsza uwaga prawna będzie odbierana jako próba zatrzymania projektu.
Dlatego due diligence powinno rozpoczynać się przed ostatecznym wyborem dostawcy.
Prawnik, compliance, IT, cyberbezpieczeństwo i przyszli użytkownicy rozwiązania powinni otrzymać możliwość oceny kontrahenta jeszcze wtedy, gdy organizacja może realnie wybrać inną ofertę.
Przykład 1: tani SaaS okazuje się drogi po podpisaniu umowy
Spółka „Nordline” z Wrocławia planuje w 2026 r. wdrożenie chmurowego systemu kadrowego dla około 900 pracowników. Oferta dostawcy jest o 18% tańsza od konkurencji i przewiduje szybkie uruchomienie.
Dopiero podczas weryfikacji przeprowadzonej przed ostatecznym wyborem okazuje się, że część infrastruktury i wsparcia technicznego zapewnia podwykonawca spoza EOG, którego nie uwzględniono w pierwszej wersji dokumentacji. Dodatkowo umowa nie gwarantuje klientowi wymaganych parametrów odtworzenia systemu po awarii.
Firma nie musi od razu rezygnować z dostawcy. Może zażądać wyjaśnień, zmienić model przetwarzania danych, rozszerzyć postanowienia dotyczące podwykonawców i dopiero wtedy podjąć decyzję.
Gdyby problem został wykryty tydzień po uruchomieniu systemu, pozycja negocjacyjna klienta byłaby zupełnie inna.
Nie ograniczaj due diligence do KRS, NIP i list sankcyjnych
Sprawdzenie podstawowych rejestrów jest potrzebne, ale odpowiada głównie na pytanie: z kim formalnie mamy do czynienia?
Przy istotnym kontrakcie trzeba odpowiedzieć również na pytanie: czy ten kontrahent będzie w stanie bezpiecznie i prawidłowo wykonać umowę?
Co sprawdzić oprócz danych rejestrowych?
Zakres zależy od ryzyka, ale w przypadku ważnego dostawcy IT warto ocenić cztery obszary.
1. Wiarygodność kontrahenta
Sprawdź strukturę właścicielską, sposób reprezentacji, beneficjentów rzeczywistych oraz sankcje mające zastosowanie do danej relacji. Jeżeli transakcja lub polityka przedsiębiorstwa uzasadnia sprawdzenie dodatkowych reżimów sankcyjnych, można odpowiednio rozszerzyć zakres weryfikacji.
2. Zdolność operacyjna
Ustal, ile osób faktycznie będzie realizować projekt, jakie kompetencje posiada zespół i czy dostawca wykonał już wdrożenia o podobnej skali.
Referencje warto weryfikować, a nie wyłącznie gromadzić.
3. Bezpieczeństwo i dane
Ważne są nie tylko deklaracje typu „stosujemy najwyższe standardy”, lecz konkretne informacje o architekturze, szyfrowaniu, backupach, zarządzaniu dostępem, podwykonawcach i reagowaniu na incydenty.
4. Prawa do oprogramowania
Szczególną uwagę zwróć na własność intelektualną. System może zawierać elementy stworzone przez pracowników, podwykonawców oraz komponenty open source lub komercyjne biblioteki osób trzecich.
Umowa powinna odpowiadać na pytanie, jakie prawa otrzymuje klient i co stanie się, jeżeli osoba trzecia zgłosi roszczenie dotyczące wykorzystanego kodu.
SLA trzeba czytać razem z definicją awarii i ograniczeniami odpowiedzialności
Samo stwierdzenie „czas reakcji na awarię krytyczną: 30 minut” wygląda dobrze w ofercie.
Nie mówi jednak prawie nic, dopóki nie sprawdzisz:
- czym według umowy jest awaria krytyczna,
- od którego momentu liczony jest czas reakcji,
- czy reakcja oznacza rozpoczęcie analizy, czy usunięcie problemu,
- jakie są czasy przywrócenia usługi,
- jakie zdarzenia zostały wyłączone z SLA,
- jakie konsekwencje ponosi dostawca,
- czy suma rekompensat ma ekonomiczne znaczenie.
SLA może być bardzo szczegółowe i jednocześnie praktycznie nie chronić klienta.
Dotyczy to również zapewnień dotyczących zespołu. Jeżeli o wyborze dostawcy przesądziło doświadczenie określonych specjalistów, zastanów się, czy umowa rzeczywiście gwarantuje ich udział albo przynajmniej odpowiedni poziom kompetencji zespołu zastępczego.
Test produktu jest częścią weryfikacji kontrahenta
Rozdzielenie „due diligence prawnego” od „testów produktu” bywa sztuczne.
Jeżeli system nie spełnia podstawowych potrzeb operacyjnych, nawet znakomicie napisana umowa nie zmieni go w dobre rozwiązanie.
Przed wyborem kluczowego narzędzia warto więc przewidzieć:
- środowisko demonstracyjne albo pilotaż,
- testy wykonane przez przyszłych użytkowników,
- scenariusze odpowiadające rzeczywistym procesom przedsiębiorstwa,
- potwierdzenie integracji z obecnymi systemami,
- test uprawnień i sposobu obsługi danych,
- udokumentowanie funkcji, które dostawca dopiero zobowiązuje się stworzyć.
Szczególnie ryzykowne jest opieranie decyzji wyłącznie na prezentacji prowadzonej przez handlowca na przygotowanych wcześniej danych.
Aplikacja mobilna? Sprawdź nie tylko programistę, ale także doświadczenie w publikacji
Jeżeli przedmiotem projektu jest aplikacja mobilna, dochodzi jeszcze jeden element ryzyka: zasady dystrybucji w App Store i Google Play.
Apple poddaje zgłoszone aplikacje procesowi review i stosuje wymagania dotyczące m.in. bezpieczeństwa, prywatności, funkcjonalności i modelu biznesowego. Aktualne wytyczne App Review Guidelines były aktualizowane także w 2026 r.
Google również regularnie zmienia zasady programu deweloperskiego. Przykładowo w lipcu 2026 r. ogłoszono kolejne zmiany dotyczące m.in. danych użytkowników, uprawnień oraz wymogów związanych z rejestracją aplikacji.
Dlatego dostawca powinien umieć nie tylko napisać kod, ale również przeprowadzić produkt przez etap publikacji.
Przykład 2: aplikacja działa, ale nie trafia do sklepu
Spółka „Verda Finance” zleca stworzenie aplikacji do obsługi wybranych usług finansowych. Projekt ma kosztować 760 tys. zł. Dostawca ma dobrych programistów i atrakcyjne portfolio stron internetowych, ale nie wykazuje wcześniejszych publikacji aplikacji dla regulowanej branży.
W umowie odbiór został powiązany jedynie z technicznym przekazaniem działającej aplikacji. Nie określono odpowiedzialności za dostosowanie produktu do wymogów sklepów ani udziału wykonawcy w procesie review.
Jeżeli aplikacja zostanie następnie odrzucona z powodu rozwiązania przyjętego przez wykonawcę, klient może mieć gotowy technicznie produkt, którego nie potrafi wykorzystać zgodnie z planowanym modelem biznesowym.
Przy takim projekcie już na etapie zapytania ofertowego warto wymagać doświadczenia w publikacji aplikacji oraz dokładnie ustalić, kto odpowiada za usuwanie przyczyn ewentualnego odrzucenia.
Due diligence nie kończy się w dniu podpisania umowy
Kontrahent może być wiarygodny w dniu zawarcia umowy, a dwa lata później funkcjonować zupełnie inaczej.
Może zmienić właściciela, centrum danych albo podwykonawców. Może utracić certyfikat, ograniczyć zespół odpowiedzialny za usługę lub zacząć wykorzystywać inną infrastrukturę.
Dlatego przy kontraktach wieloletnich potrzebny jest monitoring dostawcy uzależniony od poziomu ryzyka.
Dla dostawcy krytycznego można przykładowo przewidzieć okresowe sprawdzanie:
- aktualności certyfikatów i raportów bezpieczeństwa,
- istotnych zmian właścicielskich,
- podwykonawców,
- lokalizacji przetwarzania danych,
- incydentów bezpieczeństwa,
- parametrów SLA,
- sytuacji finansowej,
- zmian dotyczących kluczowej usługi.
Przy KSC takie podejście ma dodatkowe znaczenie, ponieważ system zarządzania ryzykiem obejmuje łańcuch dostaw i nie sprowadza się do jednorazowego sprawdzenia kontrahenta przed podpisaniem umowy.
Kto powinien odpowiadać za wybór kontrahenta?
Błędem jest zarówno stwierdzenie „prawnik zaakceptował dostawcę”, jak i całkowite przerzucenie odpowiedzialności na biznes.
Każdy obszar powinien ocenić to, na czym rzeczywiście się zna:
biznes – funkcjonalność, model współpracy, potrzeby użytkowników i opłacalność;
IT i cyberbezpieczeństwo – architekturę, integracje, bezpieczeństwo, dostępność i odporność rozwiązania;
dział prawny – warunki umowy, własność intelektualną, odpowiedzialność, rozwiązanie umowy, regulacje i mechanizmy egzekwowania obowiązków;
compliance lub IOD – odpowiednio wymagania regulacyjne i kwestie ochrony danych;
osoba podejmująca decyzję biznesową – ostateczną akceptację ryzyka.
Szczególnie ważna jest ostatnia kwestia. Jeżeli prawnik identyfikuje ryzyko, które można zaakceptować biznesowo, decyzja o jego przyjęciu powinna być udokumentowana przez osobę uprawnioną do podjęcia takiej decyzji.
Prawnik nie powinien stawać się właścicielem ryzyka operacyjnego tylko dlatego, że opisał je w opinii.
W przypadku KSC odpowiedzialność kierownictwa ma dodatkowy wymiar ustawowy. Nowelizacja przewiduje odpowiedzialność kierownika podmiotu za realizację określonych obowiązków cyberbezpieczeństwa, a w określonych sytuacjach także możliwość nałożenia kary na kierownika.
Checklista weryfikacji dostawcy IT przed podpisaniem umowy
Przy istotnej umowie sprawdź przynajmniej poniższe kwestie.
Kontrahent
- Czy dane kontrahenta i sposób reprezentacji zgadzają się z właściwymi rejestrami?
- Czy ustalono strukturę właścicielską i – tam, gdzie ma to znaczenie – beneficjentów rzeczywistych?
- Czy przeprowadzono odpowiednią kontrolę sankcyjną?
- Czy istnieją postępowania albo inne zdarzenia mogące istotnie zagrozić wykonaniu umowy?
Zdolność wykonania projektu
- Czy dostawca wykonał wcześniej porównywalne wdrożenia?
- Czy referencje zostały rzeczywiście zweryfikowane?
- Czy znany jest skład i doświadczenie zespołu realizującego projekt?
- Czy dostawca posiada wystarczające zasoby techniczne i organizacyjne?
Produkt i cyberbezpieczeństwo
- Czy produkt został przetestowany na scenariuszach odpowiadających rzeczywistemu zastosowaniu?
- Czy oceniono bezpieczeństwo rozwiązania i łańcucha jego dostaw?
- Czy certyfikaty i raporty bezpieczeństwa obejmują usługę, którą rzeczywiście kupujesz?
- Czy zidentyfikowano podwykonawców i kluczowe zależności technologiczne?
Dane osobowe
- Czy ustalono role stron na gruncie RODO?
- Gdzie będą przetwarzane dane i czy mogą być przekazywane poza EOG?
- Jak dostawca obsługuje naruszenia, backup, usuwanie danych i zmianę podprocesorów?
Umowa i własność intelektualna
- Czy SLA daje mierzalne i egzekwowalne zobowiązania?
- Czy odpowiedzialność dostawcy nie została ograniczona w sposób nieproporcjonalny do ryzyka?
- Czy wiadomo, jakie prawa do oprogramowania, dokumentacji i modyfikacji otrzymuje klient oraz kto odpowiada za roszczenia osób trzecich?
Po podpisaniu
- Kto monitoruje wykonanie umowy?
- Jak często dostawca będzie ponownie oceniany i jakie zdarzenia uruchamiają kontrolę nadzwyczajną?
CSDDD – ważny kierunek, ale nie należy przypisywać jej obecnie zbyt szerokiego zastosowania
CSDDD warto obserwować, jednak w tym obszarze stan prawny istotnie zmienił się w stosunku do pierwotnego kształtu dyrektywy.
Dyrektywa (UE) 2026/470 ograniczyła zakres CSDDD. W podstawowym wariancie próg dla przedsiębiorstw unijnych został podniesiony do ponad 5 tys. pracowników i ponad 1,5 mld euro światowego obrotu netto. Jednocześnie termin transpozycji CSDDD został przesunięty do 26 lipca 2028 r., a stosowanie odpowiednich przepisów krajowych ma rozpocząć się zasadniczo od 26 lipca 2029 r.
Dlatego we wrześniu 2026 r. nie należy przedstawiać CSDDD jako powszechnie obowiązującej w Polsce podstawy prawnej do weryfikowania każdego dostawcy IT. Jest natomiast wyraźnym sygnałem kierunku regulacyjnego dla największych przedsiębiorstw i ich łańcuchów działalności.
Podobną ostrożność należy zachować przy planowanych zmianach dotyczących odpowiedzialności podmiotów zbiorowych. Na dzień 4 września 2026 r. w wykazie prac rządu nadal znajdują się projekty zmian tej regulacji, dlatego projektowanych rozwiązań nie należy opisywać jako obowiązującego już systemu odpowiedzialności.
Podsumowanie
Weryfikacja kontrahenta IT nie powinna sprowadzać się do sprawdzenia KRS i podpisania standardowego formularza compliance.
Jeżeli umowa jest istotna dla działalności przedsiębiorstwa, sprawdź kontrahenta, produkt, zespół, bezpieczeństwo, dane, prawa własności intelektualnej oraz realną treść SLA. Zaangażuj prawników i specjalistów technicznych przed wyborem dostawcy, a nie dzień przed podpisaniem umowy.
Pamiętaj też, że ryzyko zmienia się w czasie. Dobry proces obejmuje nie tylko onboarding dostawcy, lecz także jego późniejszy monitoring.
W przypadku podmiotów objętych KSC takie podejście ma już wymiar regulacyjny: bezpieczeństwo łańcucha dostaw stanowi część systemu zarządzania bezpieczeństwem informacji. Gdy dostawca jest procesorem danych osobowych, dodatkowe wymagania wynikają z RODO.
Najbezpieczniejsza umowa to więc nie ta, która ma najwięcej stron. To umowa zawarta z kontrahentem, którego organizacja sprawdziła odpowiednio wcześnie, zadała mu właściwe pytania i wie, kto będzie monitorował współpracę po złożeniu podpisów.
Podstawa prawna
art. 8 ust. 1–2, art. 8c, art. 67b ust. 15–16, art. 73 ust. 3–5, art. 73a – ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, z uwzględnieniem zmian wprowadzonych ustawą z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. z 2026 r. poz. 252).
art. 28 ust. 1–4, art. 32 – rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych).
art. 2, art. 37 – dyrektywa Parlamentu Europejskiego i Rady (UE) 2024/1760 z dnia 13 czerwca 2024 r. w sprawie należytej staranności przedsiębiorstw w zakresie zrównoważonego rozwoju oraz zmieniająca dyrektywę (UE) 2019/1937 i rozporządzenie (UE) 2023/2859, w brzmieniu uwzględniającym dyrektywę Parlamentu Europejskiego i Rady (UE) 2026/470 z dnia 24 lutego 2026 r.
Tematy porad zawartych w poradniku
- weryfikacja dostawcy IT 2026
- due diligence kontrahenta IT
- NIS2 weryfikacja dostawców
- RODO dostawca oprogramowania
- umowa z dostawcą SaaS