Dyrektor IT w firmie zatrudniającej kilkaset osób rzadko dochodzi do outsourcingu drogą strategicznej refleksji. Dochodzi do niego drogą arytmetyki: dwie osoby odeszły, trzecia bierze na siebie dyżury, a lista systemów do utrzymania nie skróciła się ani o jeden. Pytanie „zlecić czy nie zlecić” pojawia się wtedy jako pytanie o przetrwanie zespołu, a nie o model operacyjny. I właśnie dlatego bywa źle postawione.
Bo outsourcing usług IT nie jest decyzją binarną. Jest decyzją o tym, gdzie przebiega granica odpowiedzialności — a ta granica przesuwa się w inne miejsce przy każdym z modeli współpracy i nigdy nie znika. To, co zostaje po stronie firmy, zostaje niezależnie od tego, jak obszerną umowę podpiszesz: właścicielstwo danych, decyzje o akceptacji ryzyka i nadzór nad tym, czy dostawca robi to, za co mu płacisz. Ten tekst jest o rysowaniu tej granicy świadomie, zanim narysuje ją za Ciebie czyjś wzorzec umowy.
Czym jest outsourcing usług IT, a czego nim nie nazwiemy?
Definicję pojęcia — zakres, warianty, słownikowe rozróżnienia — znajdziesz w haśle outsourcing usług IT. Tutaj potrzebujemy tylko jednego rozróżnienia, bo od niego zależy cała reszta: outsourcing usługi to przeniesienie odpowiedzialności za rezultat, a nie za czynność.
Firma, która kupuje czas trzech administratorów, nadal odpowiada za wynik ich pracy — bo to ona wyznacza im zadania, ustala priorytety i decyduje, co robić najpierw. Firma, która kupuje usługę utrzymania środowiska z określoną dostępnością, kupuje rezultat: dostawca sam decyduje, ilu ludzi i jakich narzędzi użyje, a rozliczany jest z tego, czy rezultat wystąpił.
Różnica jest kontraktowa, nie techniczna. Te same osoby mogą wykonywać te same czynności w obu modelach i różnić się będzie wyłącznie to, kto ponosi konsekwencje, gdy coś nie zadziała. Wiele nieporozumień z dostawcami bierze się stąd, że umowa opisuje jeden model, a oczekiwania obu stron — drugi.
Które modele współpracy realnie masz do wyboru?
W praktyce polskiego rynku średnich firm wybór sprowadza się do trzech modeli, między którymi da się jeszcze mieszać. Poniższa tabela pokazuje nie tyle różnice w usłudze, ile różnice w rozkładzie odpowiedzialności — bo to jest właściwa oś porównania.
| Model | Kto odpowiada za wynik | Kto zarządza ludźmi | Rozliczenie | Kiedy ma sens |
|---|---|---|---|---|
| Wsparcie na godziny (body leasing) | firma zamawiająca | dostawca formalnie, firma operacyjnie | za czas | znany zakres, brak rąk, praca projektowa |
| Managed services (usługa z SLA) | dostawca | dostawca | za usługę i dotrzymane parametry | powtarzalne utrzymanie, potrzeba mierzalności |
| Pełny outsourcing IT | dostawca | dostawca | ryczałt za zdefiniowany zakres | brak własnego zespołu, stabilny i opisany zakres |
To nie są trzy poziomy zaawansowania, tylko trzy odpowiedzi na trzy różne sytuacje. Wsparcie na godziny jest najtańsze w uruchomieniu i najdroższe w utrzymaniu dyscypliny, bo ciężar planowania zostaje po Twojej stronie. Pełny outsourcing zdejmuje najwięcej pracy operacyjnej, ale wymaga zakresu opisanego na tyle dokładnie, żeby dało się o nim rozstrzygać spory. Managed services jest środkiem ciężkości rynku właśnie dlatego, że wymusza mierzalność, nie wymagając oddania wszystkiego.
Wybór rzadko jest trwały: firmy przechodzą od godzin do usługi, gdy zakres się ustabilizuje, i wracają do godzin przy projektach, których nikt nie umie jeszcze opisać jako usługi.
Co zostaje po Twojej stronie, nawet przy pełnym outsourcingu?
Zawsze zostają trzy rzeczy i warto wypisać je w umowie wprost, zamiast zakładać, że są oczywiste.
Pierwsza to właścicielstwo danych — wraz z prawem dostępu do nich w każdej chwili, w formacie nadającym się do użycia poza infrastrukturą dostawcy. Druga to decyzje o ryzyku: dostawca może zarekomendować wyłączenie przestarzałego protokołu, ale to Ty decydujesz, czy przyjmujesz ryzyko wynikające z jego pozostawienia, bo to Ty ponosisz skutki biznesowe. Trzecia to nadzór nad dostawcą, czyli sprawdzanie, czy usługa jest wykonywana tak, jak umówiono.
Trzecia rzecz gubi się najczęściej, bo wygląda na czynność techniczną, a nie jest. Nadzór to nie zaglądanie do panelu dostawcy raz na kwartał, tylko utrzymywanie własnego, niezależnego obrazu tego, co dzieje się w Twoim środowisku.
Jak podzielić obowiązki bezpieczeństwa, żeby nic nie wypadło między stronami?
Najskuteczniejszą metodą jest rozpisanie obowiązków na konkretne, przypisywalne czynności i nadanie każdej z nich właściciela. Dobrym rusztowaniem jest tu zestaw CIS Controls, publikowany przez Center for Internet Security — w wersji 8.1 obejmuje osiemnaście kontroli rozbitych na pojedyncze zabezpieczenia (stan strony sprawdzony 10 września 2026 r.). Osobna, piętnasta kontrola nosi nazwę Service Provider Management i wymaga wprost opracowania procesu oceny dostawców, którzy przechowują wrażliwe dane albo odpowiadają za krytyczne platformy i procesy IT.
Warto zwrócić uwagę na kierunek tego wymagania: nie brzmi ono „wybierz dobrego dostawcę”, tylko „miej proces oceny”. Proces zostaje po Twojej stronie także wtedy, gdy samą ocenę zlecasz na zewnątrz.
W praktyce podział rozpisuje się w tabeli o czterech kolumnach: czynność, kto wykonuje, kto zatwierdza, kto weryfikuje. Nudne — i skuteczne, bo pola puste w kolumnie „weryfikuje” są dokładnie tymi miejscami, w których po incydencie nikt nie umie odpowiedzieć, dlaczego nikt tego nie zauważył. Inwentaryzacja zasobów, zarządzanie podatnościami, kopie zapasowe i ich testowe odtworzenia oraz przegląd uprawnień — to cztery obszary, w których granica rozmywa się najczęściej.
Dlaczego nadzór nad dostawcą jest funkcją zarządczą, a nie zadaniem administratora?
Bo taki jest jego charakter w każdym poważnym układzie odniesienia. NIST Cybersecurity Framework 2.0 umieszcza zarządzanie ryzykiem łańcucha dostaw — kategorię oznaczoną GV.SC — wewnątrz funkcji GOVERN, czyli tej, która opisuje ład organizacyjny, a nie codzienną obsługę techniczną. Sama nazwa kategorii brzmi „Cybersecurity Supply Chain Risk Management” i rozpisuje się na dziesięć wymagań szczegółowych.
Kilka z nich czyta się jak lista rzeczy, których firmy zwykle nie robią. GV.SC-02 oczekuje, że obowiązki bezpieczeństwa zostaną przypisane i zakomunikowane w całej relacji — nie tylko wewnątrz własnej organizacji, ale też wobec dostawcy i partnerów dalej w łańcuchu. GV.SC-04 mówi, że dostawcy mają być znani i uszeregowani według krytyczności; to zdanie zakłada rejestr dostawców, którego w wielu organizacjach po prostu nie ma. GV.SC-08 wymaga włączenia istotnych dostawców w planowanie reagowania na incydenty — czyli ustalenia, kogo budzisz o trzeciej w nocy, zanim będzie trzeba to zrobić.
Umiejscowienie w funkcji GOVERN ma konsekwencję organizacyjną: jeżeli nadzór nad dostawcą zjeżdża do jednego administratora, który „ma kontakt z ich supportem”, to nie jest nadzór, tylko relacja robocza — pożyteczna i niewystarczająca jako mechanizm kontroli.
Jak ocenić dostawcę, zanim podpiszesz umowę?
NIST CSF 2.0 poświęca temu osobne wymaganie: GV.SC-06 mówi o planowaniu i badaniu dostawcy przed wejściem w formalną relację, właśnie po to, żeby zmniejszyć ryzyko przed jego materializacją. Brzmi to jak truizm, dopóki nie zestawi się tego z faktem, że due diligence dostawcy IT bywa w praktyce sprowadzone do sprawdzenia referencji i wpisu w KRS.
Kontekst, w którym warto to czytać, dostarcza Agencja Unii Europejskiej ds. Cyberbezpieczeństwa. Raport ENISA Threat Landscape 2025, opublikowany 1 października 2025 r., analizuje incydenty odnotowane w okresie od 1 lipca 2024 r. do 30 czerwca 2025 r. i opisuje krajobraz zagrożeń, z którymi mierzy się Unia — a bezpieczeństwo relacji z dostawcami jest w tym krajobrazie tematem trwałym, nie sezonowym. W polskich realiach ten sam wątek ma odpowiednik regulacyjny: dyrektywa NIS2 wymienia bezpieczeństwo łańcucha dostaw wśród środków zarządzania ryzykiem, wraz z aspektami dotyczącymi relacji z bezpośrednimi dostawcami i usługodawcami. Jeśli Twoja firma jest podmiotem kluczowym albo ważnym, ocena dostawcy przestaje być dobrą praktyką i staje się obowiązkiem — o czym szerzej piszemy w tekście o audycie łańcucha dostaw pod NIS2.
Praktyczne minimum przed podpisem to pięć pytań: kto konkretnie będzie obsługiwał Twoje środowisko i czy są to pracownicy dostawcy, czy podwykonawcy; jak wygląda ich proces zarządzania dostępem uprzywilejowanym; co dokładnie dostawca loguje i jak długo przechowuje; jak wygląda jego własny plan reagowania na incydent, który dotknie wielu klientów jednocześnie; oraz czy przedstawi wyniki niezależnego audytu, a jeśli nie — dlaczego.
Które zapisy umowy rozstrzygają spór, zanim on nastąpi?
Umowa outsourcingowa jest dokumentem czytanym najuważniej w najgorszym możliwym momencie — kiedy coś już się stało. Warto pisać ją z myślą o tym czytelniku.
NIST CSF 2.0 formułuje to jako GV.SC-05: wymagania dotyczące ryzyk w łańcuchu dostaw mają być ustalone, uszeregowane i wpisane do umów z dostawcami i innymi stronami trzecimi. To jest istota rzeczy — deklaracja z prezentacji handlowej nie jest zobowiązaniem, dopóki nie stanie się paragrafem.
Cztery zapisy niosą największą wartość praktyczną. Po pierwsze, obowiązek zgłoszenia incydentu wraz z konkretnym terminem liczonym od wykrycia i wskazanym kanałem — bez tego dowiadujesz się o incydencie u dostawcy z mediów. Po drugie, prawo do audytu albo, jako wariant realistyczny, obowiązek przedstawienia raportu z audytu niezależnego w ustalonym cyklu. Po trzecie, jawna zgoda na podwykonawców wraz z ich listą; outsourcing bez tego zapisu bywa łańcuchem dłuższym, niż sądzisz. Po czwarte, zasady dostępu do danych i logów — również po zakończeniu współpracy.
Jak czytać SLA, żeby mierzyło to, co dla Ciebie ważne?
Umowa o poziomie usług mierzy zawsze coś konkretnego, tylko nie zawsze to, na czym Ci zależy. Klasyczny rozjazd dotyczy czasu reakcji i czasu naprawy: zobowiązanie do szybkiej reakcji na zgłoszenie mówi wyłącznie o tym, kiedy ktoś potwierdzi przyjęcie sprawy, a nie o tym, kiedy system wróci do działania.
Dlatego przy czytaniu SLA warto sprawdzić cztery rzeczy. Jak zdefiniowano dostępność i z jakiego punktu jest mierzona — z perspektywy użytkownika czy z perspektywy interfejsu zarządzania. Co jest wyłączone z pomiaru: okna serwisowe, awarie łącza, usterki po stronie dostawcy chmury. Jak liczony jest czas w godzinach roboczych, a jak poza nimi. I wreszcie — kto dostarcza dane do rozliczenia, bo jeśli jedynym źródłem pomiaru jest system dostawcy, to dostawca ocenia sam siebie.
Ostatni punkt to nie podejrzliwość wobec konkretnej firmy, tylko higiena pomiaru. Własne, choćby proste źródło danych zamienia rozmowę o dotrzymaniu SLA z dyskusji o interpretacjach w rozmowę o liczbach.
Po czym poznasz, że oferty są porównywalne?
Najczęstszy błąd w porównywaniu ofert nie polega na złym liczeniu, tylko na porównywaniu dwóch różnych usług. Zanim zestawisz ceny, zestaw zakresy: tę samą listę systemów, tę samą liczbę użytkowników i urządzeń, te same godziny obsługi, te same wykluczenia.
Drugi krok to policzenie kosztu całkowitego zamiast stawki miesięcznej. Do abonamentu dochodzą: jednorazowe wdrożenie i przejęcie usługi, prace rozliczane poza ryczałtem, licencje narzędzi dostawcy, koszt utrzymania kompetencji po Twojej stronie oraz koszt wyjścia z umowy. Dwie oferty różniące się o kilkanaście procent na abonamencie potrafią zamienić się miejscami po dodaniu tych pozycji.
Trzeci krok bywa pomijany: sprawdź, ile z zakresu oferty dotyczy rzeczy, których dziś nie robicie wcale. Jeżeli dostawca proponuje przegląd uprawnień i testowe odtworzenia kopii, a Wy nie robicie ani jednego, ani drugiego, to nie jest droższa oferta — to inna oferta.
Jak zaplanować przejęcie usługi i wyjście z umowy?
O wyjściu najlepiej rozmawia się przed wejściem, kiedy obie strony są jeszcze zadowolone. NIST CSF 2.0 stawia to wprost w GV.SC-10: plany zarządzania ryzykiem łańcucha dostaw mają obejmować także działania po zakończeniu partnerstwa lub umowy o świadczenie usług.
W praktyce plan wyjścia jest krótkim dokumentem, który odpowiada na cztery pytania. Co dokładnie dostajesz przy zakończeniu — dokumentację środowiska, dane w uzgodnionym formacie, hasła i klucze, konfiguracje. W jakim terminie i za jaką odpłatnością. Kto przekazuje wiedzę i przez ile dni. Oraz jak potwierdzacie usunięcie Twoich danych po stronie dostawcy.
Przejęcie usługi na wejściu rządzi się tą samą logiką, tylko w drugą stronę. Warto zaplanować okres równoległej pracy, w którym dotychczasowy zespół i nowy dostawca działają razem, i wyznaczyć jawne kryterium zakończenia tego okresu. Bez takiego kryterium przejęcie „trwa”, dopóki komuś nie skończy się cierpliwość.
Które kryteria zestawić w jednej tabeli, żeby podjąć decyzję?
Poniższa tabela jest narzędziem do wypełnienia, nie do czytania. Każde kryterium oceń w skali 0–2 dla każdego rozważanego wariantu, a wynik potraktuj jako punkt wyjścia do rozmowy z zarządem — nie jako werdykt.
| Kryterium | Na co patrzysz | Sygnał ostrzegawczy |
|---|---|---|
| Zakres i wykluczenia | czy lista systemów i wykluczeń jest zamknięta | „wszystko, co potrzebne” bez załącznika |
| Podział obowiązków | tabela: wykonuje / zatwierdza / weryfikuje | puste pola w kolumnie „weryfikuje” |
| Pomiar SLA | definicja, źródło danych, wyłączenia | jedynym źródłem pomiaru jest dostawca |
| Zgłaszanie incydentów | termin od wykrycia, kanał, adresat | brak terminu albo termin „niezwłocznie” |
| Podwykonawcy | lista, zgoda, odpowiedzialność | milczenie umowy w tej sprawie |
| Dostęp do danych i logów | format, częstotliwość, okres po umowie | dane wyłącznie w narzędziu dostawcy |
| Plan wyjścia | co, kiedy, za ile, kto przekazuje wiedzę | „ustalimy w razie potrzeby” |
| Koszt całkowity | abonament plus wdrożenie, prace dodatkowe, wyjście | porównanie na samej stawce miesięcznej |
Ramka do zapamiętania: dobra umowa outsourcingowa jest testowalna. Jeśli po jej przeczytaniu nie umiesz wskazać, kto sprawdza wykonanie każdej pozycji i skąd bierze dane do tego sprawdzenia, to nie masz jeszcze umowy — masz opis zamiaru.
Kiedy który model ma sens, a kiedy nie warto zlecać?
Wsparcie na godziny sprawdza się, gdy zakres jest znany, a brakuje wyłącznie rąk — na przykład przy migracji o wyznaczonym terminie. Traci sens jako model stały, bo cały ciężar priorytetyzacji wraca do Twojego zespołu, czyli dokładnie tam, gdzie było ciasno.
Managed services ma sens wtedy, gdy zakres jest powtarzalny i daje się zmierzyć, a Tobie zależy na przewidywalności kosztu i jakości. Wymaga w zamian dojrzałości po obu stronach: dostawca musi umieć raportować, a Ty musisz umieć czytać raporty i reagować na to, co w nich widać. Tak realizujemy Managed IT Services — z rozpisanym podziałem obowiązków i pomiarem, który da się zweryfikować po Twojej stronie, a nie tylko po naszej.
Pełny outsourcing bywa właściwą odpowiedzią, gdy własnego IT praktycznie nie ma i nie ma planu, żeby je budować. Warunek jest jeden i twardy: musi zostać ktoś, kto po Twojej stronie sprawuje nadzór — choćby w wymiarze części etatu albo roli zewnętrznego doradcy. Firma bez tej roli nie kupuje spokoju, tylko zamienia ryzyko techniczne na ryzyko kontraktowe, którego nikt nie obserwuje.
A kiedy nie warto zlecać? Wtedy, gdy proces jest nieopisany, a jego kształt zmienia się co miesiąc. Outsourcing utrwala to, co zastanie — jeśli zastanie chaos, otrzymasz chaos z fakturą i pomiarem. Tańszym pierwszym krokiem jest wtedy uporządkowanie zakresu i choćby zgrubna inwentaryzacja środowiska, a dopiero potem rozmowa o modelu. Ten sam wniosek dotyczy sytuacji, w której nie potrafisz nazwać oczekiwanego rezultatu. Umowa nie nazwie go za Ciebie.
Źródła:
- Center for Internet Security, The 18 CIS Critical Security Controls (CIS Controls v8.1) — Control 15: Service Provider Management; stan strony sprawdzony 10 września 2026 r.
- NIST, Cybersecurity Framework (CSF) 2.0 — funkcja GOVERN, kategoria Cybersecurity Supply Chain Risk Management (GV.SC), podkategorie GV.SC-02, GV.SC-04, GV.SC-05, GV.SC-06, GV.SC-08, GV.SC-10; stan zasobu sprawdzony 10 września 2026 r.
- ENISA, ENISA Threat Landscape 2025, data publikacji 1 października 2025 r. (wersja 1.2 z 9 stycznia 2026 r.) — analiza incydentów z okresu 1 lipca 2024 r. – 30 czerwca 2025 r.
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) — art. 21 ust. 2 lit. d) w zakresie bezpieczeństwa łańcucha dostaw.
