Kiedy model mieszany ma sens
Model mieszany ma sens, gdy wewnętrzne IT zna organizację, jej procesy i priorytety, lecz nie powinno lub nie może samodzielnie pokrywać wszystkich kompetencji oraz godzin pracy. Przykładowo pracownik albo mały dział IT może pełnić rolę partnera dla biznesu, właściciela architektury lub koordynatora aplikacji, podczas gdy dostawca wspiera użytkowników, administruje wybranymi systemami, realizuje powtarzalne czynności albo uzupełnia specjalistyczną wiedzę.
W praktyce taki układ może być dobry, gdy:
Nie jest to jednak automatycznie rozwiązanie problemu przeciążenia. Jeżeli firma nie ma osoby zdolnej do podejmowania decyzji, nie prowadzi listy usług albo oczekuje, że dostawca domyśli się reguł działania aplikacji biznesowej, model mieszany może zwiększyć liczbę przekazań między zespołami. NCSC wskazuje, że zarządzanie ryzykiem cyberbezpieczeństwa obejmuje między innymi zarządzanie zasobami, tożsamością i dostępem, incydentami oraz bezpieczeństwem łańcucha dostaw.[6] To dobra podpowiedź dla projektu modelu mieszanego: granice odpowiedzialności powinny obejmować nie tylko helpdesk, ale też dostawców, dane, uprawnienia i sposób reagowania.
- liczba zgłoszeń lub projektów zmienia się w ciągu roku i nie uzasadnia stałego rozbudowywania zespołu;
- organizacja ma systemy branżowe, których kontekst biznesowy zna tylko osoba wewnętrzna, ale potrzebuje administracji infrastrukturą, tożsamością lub urządzeniami;
- wewnętrzny informatyk nie powinien być jedyną osobą posiadającą wiedzę o wszystkich kontach, kopiach i konfiguracjach;
- firma chce oddzielić bieżące wsparcie użytkowników od prac rozwojowych lub strategicznych;
- do pojedynczych obszarów potrzebne są kompetencje, których nie warto utrzymywać etatowo w pełnym wymiarze;
- zarząd chce zachować kontrolę nad priorytetami, budżetem i ryzykiem, ale nie zarządzać każdym zgłoszeniem technicznym.
Najpierw usługi i decyzje, dopiero potem osoby
Częsty błąd to rozpoczęcie od nazw stanowisk: „wewnętrzny IT robi rzeczy strategiczne, a firma zewnętrzna resztę”. Takie zdanie nie pozwala obsłużyć awarii ani zatwierdzić zmiany. Zamiast tego należy zbudować katalog usług i procesów, a następnie przypisać odpowiedzialności.
Katalog nie musi być rozbudowany. Na początku zwykle wystarczy lista obejmująca: tożsamość i konta, urządzenia użytkowników, sieć, serwery lub chmurę, kopie zapasowe, pocztę, aplikacje biznesowe, integracje, telefonie, domeny i DNS, bezpieczeństwo oraz relacje z dostawcami aplikacji. Dla każdej pozycji trzeba opisać funkcję biznesową, właściciela biznesowego, właściciela technicznego, zależności i stan dokumentacji.
**Właściciel biznesowy** nie musi być informatykiem. To osoba, która potrafi odpowiedzieć, co zatrzymuje dana usługa, kto odczuje przerwę, jakie są dopuszczalne ograniczenia i kto może zaakceptować zmianę. Dyrektor finansowy może być właścicielem biznesowym systemu finansowego, kierownik sprzedaży CRM, a osoba odpowiedzialna za operacje systemu produkcyjnego. Właściciel biznesowy nie konfiguruje systemu, lecz ustala priorytet i odbiera rezultat z perspektywy pracy firmy.
**Właściciel techniczny** odpowiada za utrzymanie określonego komponentu w uzgodnionym zakresie: konfigurację, dokumentację, monitoring lub koordynację działań. Może nim być pracownik firmy albo dostawca. Nie należy mylić tej roli z prawnym właścicielem konta, domeny czy subskrypcji. Kluczowe konta i dane rozliczeniowe powinny pozostać pod kontrolą firmy; dostawca może uzyskać potrzebne uprawnienia do wykonywania pracy, ale nie powinien być jedynym podmiotem zdolnym do odzyskania kontroli nad zasobem.
RACI: prosta macierz, która kończy domysły
Najbardziej użyteczna macierz odpowiedzialności rozróżnia cztery role:
RACI nie jest umową SLA ani opisem usługi. Jest roboczym narzędziem do wyjaśnienia, kto ma zrobić następny krok. Umowa, zakres prac i procedury mogą zawierać dodatkowe szczegóły: godziny działania, kanały zgłoszeń, wyłączenia, warunki odbioru i sposób rozliczenia. Macierz trzeba więc utrzymywać razem z katalogiem usług, a nie zostawiać jako jednorazowy załącznik z warsztatu.
Poniższy przykład pokazuje możliwy punkt wyjścia dla firmy z jednym lub kilkoma osobami IT wewnątrz oraz zewnętrznym dostawcą. Nie jest obietnicą konkretnej usługi ani gotowym podziałem dla każdego środowiska.
Przykładowy podział odpowiedzialności można zapisać jako listę: priorytet usługi i akceptację ryzyka zatwierdza firma (A), wewnętrzne IT i dostawca są konsultowani (C); dzienną obsługę uzgodnionych zgłoszeń wykonuje dostawca (R), a wewnętrzne IT utrzymuje odpowiedzialność operacyjną w uzgodnionym wariancie (A/C); standard urządzeń zatwierdza firma (A), przygotowuje wewnętrzne IT (R), a dostawca konsultuje (C); zmiany wpływające na proces biznesowy zatwierdza firma (A), a zespoły techniczne realizują lub konsultują według zakresu (R/C); kopie, testy odtworzenia, konta uprzywilejowane, incydenty oraz kontakt z producentem wymagają wskazania jednego A i jawnego R/C dla każdej usługi; budżet, licencje i odnowienia zatwierdza firma (A), wewnętrzne IT koordynuje (R/C), a dostawca konsultuje (C).
Jedna tabela nie zastępuje rozmowy. Jeżeli w komórce pojawia się „A lub R”, należy ustalić wariant dla konkretnej usługi. Na przykład dostawca może wykonywać odtworzenie techniczne, ale właściciel biznesowy akceptuje moment przełączenia użytkowników na tryb awaryjny. Im większy wpływ decyzji na pracę firmy, tym ważniejsze jest oddzielenie wykonania technicznego od biznesowej akceptacji.
- R — Responsible (wykonuje): realizuje zadanie lub prowadzi czynność operacyjną;
- A — Accountable (odpowiada za decyzję i wynik): zatwierdza, ponosi odpowiedzialność za rezultat i powinien występować tylko raz dla danego działania;
- C — Consulted (konsultowany): wnosi wiedzę przed decyzją lub wykonaniem;
- I — Informed (informowany): otrzymuje informację o rezultacie albo ryzyku.
L1, L2 i L3: użyteczne oznaczenia, nie obietnica usługi
Poziomy L1/L2/L3 pomagają uporządkować zgłoszenia, ale same nie mówią nic o rzeczywistym zakresie, godzinach ani czasie reakcji. W modelu mieszanym należy traktować je wyłącznie jako przykład sposobu klasyfikacji, który wymaga dopasowania do umowy i środowiska.
Przykładowo **L1** może obejmować rejestrację zgłoszenia, podstawową diagnozę, wsparcie użytkownika i rozwiązania według zatwierdzonych instrukcji. **L2** może obejmować analizę wymagającą dostępu administracyjnego, zmianę konfiguracji lub współpracę z inną usługą. **L3** może oznaczać producenta aplikacji, zespół developerski, operatora telekomunikacyjnego albo eksperta od specjalistycznego komponentu.
Najważniejsza zasada brzmi: poziom nie może być pretekstem do przekazywania problemu bez właściciela. Dla każdego typu zgłoszenia trzeba wskazać, kto kontroluje dalszą eskalację i kto informuje użytkownika. Wewnętrzne IT może mieć rolę właściciela komunikacji dla systemu biznesowego, nawet jeśli dostawca prowadzi analizę infrastruktury, a producent aplikacji poprawia błąd w swoim produkcie.
Warto opisać w procedurze co najmniej: kanał zgłoszenia, dane niezbędne do diagnozy, kryteria priorytetu, osobę zatwierdzającą wpływową zmianę, punkt przekazania do dostawcy aplikacji oraz osobę odpowiedzialną za aktualizację statusu. Dzięki temu użytkownik nie musi sam ustalać, który z trzech zespołów powinien zająć się problemem.
Dostęp uprzywilejowany: firma zachowuje kontrolę, zespoły otrzymują tylko potrzebne uprawnienia
Konta uprzywilejowane wymagają oddzielnego procesu, ponieważ umożliwiają zmianę konfiguracji, nadawanie ról, dostęp do danych lub odtworzenie systemu. NIST SP 800-53 opisuje katalog kontroli bezpieczeństwa i prywatności dla organizacji; zagadnienia kontroli dostępu stanowią w nim odrębną rodzinę kontroli.[5] W praktyce dla modelu mieszanego oznacza to konieczność zaprojektowania procesu, a nie tylko rozdania „kont administratora”.
Dobrym punktem wyjścia są następujące zasady:
Szczególnej uwagi wymagają konto rejestratora domeny, DNS, tenant pocztowy, panel chmurowy, system backupu, system zarządzania urządzeniami i narzędzia bezpieczeństwa. Utrata dostępu do któregokolwiek z nich może uniemożliwić zmianę dostawcy albo reakcję na incydent. Właściciel biznesowy i osoba reprezentująca firmę powinny wiedzieć, gdzie znajduje się procedura odzyskania kontroli, ale nie trzeba wpisywać sekretów do dokumentacji operacyjnej.
- firma wskazuje co najmniej dwie uprawnione osoby zdolne do odzyskania dostępu do kont krytycznych, zgodnie ze swoimi zasadami;
- osoby administrujące korzystają z imiennych kont, a nie ze wspólnego loginu „admin”;
- uprawnienia są nadawane do konkretnej roli, systemu i celu, a nie „na wszelki wypadek”;
- nadanie, zmiana i odebranie dostępu są rejestrowane oraz zatwierdzane przez uprawnioną osobę;
- konta techniczne, integracje i automatyzacje są identyfikowane przed rotacją haseł lub sekretów;
- okresowy przegląd sprawdza, czy dostęp nadal jest potrzebny i czy listy administratorów są aktualne;
- informacje o sekretach przechowuje się w uzgodnionym bezpiecznym mechanizmie, nie w arkuszu, zwykłym e-mailu ani komunikatorze.
Zmiany: kto zatwierdza, kto wykonuje, kto odbiera
W modelu mieszanym zmiana nie powinna być definiowana wyłącznie jako „ticket techniczny”. Każda istotna zmiana wymaga odpowiedzi na pięć pytań: czego dotyczy, jaki będzie wpływ, kto ją zatwierdza, jak sprawdzimy powodzenie i co robimy, gdy wynik testu jest negatywny.
Dla zmian standardowych można przygotować zatwierdzone instrukcje: na przykład dodanie użytkownika według istniejącego procesu, wymiana zatwierdzonego urządzenia czy aktualizacja uzgodnionej konfiguracji. Zmiany normalne powinny mieć właściciela, okno wykonania, plan komunikacji i kryteria odbioru. Zmiany pilne nie powinny oznaczać braku zapisu: po wykonaniu trzeba udokumentować decyzję, wpływ, wykonawcę i działania następcze.
Granica jest szczególnie ważna przy aplikacjach biznesowych. Dostawca IT może przygotować serwer, połączenie, konto lub kopię konfiguracji, ale nie powinien samodzielnie zmieniać parametrów biznesowych systemu finansowego, kadrowego czy sprzedażowego bez wskazania właściciela i odpowiedniego zakresu. Podobnie osoba wewnętrzna nie powinna oczekiwać od dostawcy odpowiedzialności za wynik zmiany, której nie mógł ocenić ani zatwierdzić.
Incydenty i awarie: jeden dowódca biznesowy, jedna ścieżka komunikacji
Incydent nie jest zwykłym zgłoszeniem o niskim priorytecie. NIST SP 800-61 Rev. 3 zaleca włączenie przygotowania, wykrywania, reagowania i odtwarzania po incydentach do działań związanych z zarządzaniem ryzykiem cyberbezpieczeństwa.[4] W modelu mieszanym szczególnie ważne jest wcześniejsze ustalenie, kto może podjąć decyzję o odłączeniu systemu, pracy w trybie awaryjnym, powiadomieniu zarządu lub kontakcie z dostawcą aplikacji.
Prosta procedura powinna rozdzielać role:
Nie należy nazywać każdej awarii incydentem bezpieczeństwa. Z drugiej strony podejrzenie nieautoryzowanego dostępu, wycieku, szyfrowania danych lub aktywnej infekcji nie powinno być obsługiwane jak zwykły onboarding czy rutynowa zmiana. Należy uruchomić obowiązującą procedurę, ograniczyć działania mogące zniszczyć dowody i skierować sprawę do uprawnionych osób.
- koordynator incydentu zbiera informacje, utrzymuje chronologię i pilnuje kolejnych decyzji;
- właściciel biznesowy ocenia wpływ na proces, zatwierdza decyzje mające istotne skutki dla działalności i wskazuje priorytety;
- wewnętrzne IT zapewnia kontekst środowiska i procesu, może koordynować pracę użytkowników oraz dostawców;
- dostawca zewnętrzny działa technicznie w ustalonym zakresie, dokumentuje ustalenia i eskaluje poza ten zakres;
- producent aplikacji lub operator odpowiada za swój produkt albo usługę, gdy problem leży po jego stronie.
Backup i odtwarzanie: odpowiedzialność za kopię to za mało
Deklaracja „dostawca robi backup” nie wyjaśnia, czy kopia obejmuje właściwe dane, czy można ją odtworzyć i kto podejmie decyzję o odtworzeniu. NIST przedstawia planowanie ciągłości jako proces obejmujący określenie wymagań i priorytetów, strategie odtworzenia, testy oraz utrzymanie planu.[3] W hybrydowym modelu warto rozbić ten temat na konkretne obowiązki.
Dla każdej usługi krytycznej ustalcie:
Dostawca może prowadzić techniczną stronę procesu, wewnętrzne IT może sprawdzać raporty i dokumentację, a biznes może definiować priorytety. Żadna z tych ról nie jest wymienna. Test odtworzenia ma wartość tylko wtedy, gdy sprawdza uzgodniony rezultat, a nie samo istnienie pliku kopii.
- właściciela biznesowego i maksymalny akceptowany wpływ niedostępności;
- zakres danych oraz konfiguracji objętych kopią;
- miejsce przechowywania kopii i uprawnienia do jej użycia;
- kolejność odtwarzania wynikającą z zależności;
- osobę, która wykonuje techniczne odtworzenie;
- osobę, która zatwierdza rozpoczęcie i odbiera rezultat;
- sposób oraz częstotliwość uzgodnionych testów;
- znane ograniczenia, których nie wolno ukrywać pod skrótem „backup”.
Dostawcy aplikacji: odróżnij środowisko od produktu
Wiele sporów wynika z mieszania odpowiedzialności za aplikację z odpowiedzialnością za środowisko, w którym działa. Producent może odpowiadać za błąd w funkcji programu, zewnętrzny IT za system operacyjny, sieć lub tożsamość, a wewnętrzne IT za konfigurację integracji i kontakt z właścicielem procesu. Każda z tych odpowiedzi może być prawdziwa jednocześnie.
Dla aplikacji krytycznej utwórz kartę zależności. Powinna wskazywać: właściciela biznesowego, producenta lub partnera aplikacji, kontakt do wsparcia, serwer albo usługę chmurową, bazę danych, konto techniczne, domenę, połączenia sieciowe, backup, licencję oraz osobę decydującą o aktualizacji. Gdy wystąpi problem, zespół może rozpocząć od diagnozy warstwy, a nie od przekazywania użytkownika między infoliniami.
Dostawca IT nie powinien deklarować wsparcia merytorycznego dla aplikacji, której nie ma w uzgodnionym zakresie. Może natomiast koordynować zgłoszenie techniczne, zebrać objawy, sprawdzić dostępność zależności i uczestniczyć w eskalacji. To rozróżnienie warto zapisać w RACI oraz w komunikacji do użytkowników.
Onboarding i offboarding: model mieszany musi działać również przy zmianie ludzi
Onboarding pracownika, administratora lub dostawcy jest sprawdzianem jakości podziału odpowiedzialności. Firma powinna ustalić, kto zatwierdza utworzenie konta, kto przygotowuje urządzenie, kto nadaje role biznesowe, kto przekazuje instrukcje oraz kto potwierdza gotowość. Ta sama logika dotyczy zmian stanowiska: użytkownik nie powinien zachowywać uprawnień tylko dlatego, że konto pozostało technicznie aktywne.
Offboarding wymaga listy działań i właściciela dla każdego kroku: wyłączenia konta, odebrania sesji i tokenów, odzyskania urządzenia, przekazania danych służbowych zgodnie z zasadami firmy, odebrania uprawnień do aplikacji oraz aktualizacji list dystrybucyjnych i kontaktów. Dostawca może wykonywać czynności techniczne, ale wewnętrzny przełożony albo właściciel procesu musi przekazać wiarygodną informację o dacie i zakresie odebrania dostępu.
Równie ważny jest offboarding dostawcy. Przed zakończeniem współpracy firma powinna potwierdzić kontrolę nad kontami właścicielskimi, dostępem do dokumentacji, kopiami, domenami, licencjami, konfiguracją i kontaktami do innych dostawców. NCSC podkreśla, że łańcuch dostaw może być złożony, a podatności w nim mogą prowadzić do zakłóceń.[2] Dlatego w planie wyjścia nie wystarczy zapis o „przekazaniu haseł”; potrzebny jest kontrolowany odbiór zasobów i wiedzy.
Regularne przeglądy: bez nich RACI szybko staje się nieaktualne
Model mieszany nie powinien być zarządzany wyłącznie w chwili awarii. Dobrym minimum jest cykliczny przegląd operacyjny, w którym uczestniczą właściciele kluczowych usług, wewnętrzne IT i przedstawiciel dostawcy odpowiedni do uzgodnionego zakresu. Częstotliwość zależy od skali i ryzyka, ale ważniejsza od rytmu jest lista podejmowanych decyzji.
Agenda przeglądu może obejmować:
Po spotkaniu powinien pozostać krótki zapis decyzji, właścicieli i terminów. To nie jest biurokracja dla samej dokumentacji: podczas następnej awarii zespół może sprawdzić, co zostało zaakceptowane, kto odpowiada za ryzyko i jaką drogę eskalacji uzgodniono. Praktycznym uzupełnieniem takiego rytmu jest artykuł o zawartości miesięcznego raportu z obsługi IT.
- otwarte incydenty, powtarzające się problemy i ich właścicieli;
- zmiany wykonane, odrzucone oraz planowane;
- stan kopii, wyniki uzgodnionych testów odtworzenia i otwarte ograniczenia;
- konta uprzywilejowane, wyjątki i daty kolejnego przeglądu;
- zmiany w aplikacjach, licencjach, dostawcach i zależnościach;
- ryzyka wymagające decyzji biznesowej;
- priorytety na następny okres oraz elementy poza bieżącym zakresem.
Antywzorce, które psują model mieszany
Poniższe sytuacje pojawiają się częściej niż brak narzędzi technicznych:
- „Wszyscy są odpowiedzialni”. W rzeczywistości nikt nie ma prawa podjąć decyzji. Dla działania krytycznego musi być jeden Accountable.
- RACI według działów, a nie usług. Hasło „dostawca odpowiada za infrastrukturę” nie pomaga, gdy CRM zależy od DNS, MFA, integracji i aplikacji producenta.
- Wspólne konto administratora. Utrudnia ustalenie, kto wykonał zmianę, komplikuje odebranie dostępu i zwiększa ryzyko niekontrolowanego użycia.
- Przekazywanie użytkownika między zespołami. Zgłaszający nie powinien diagnozować granic odpowiedzialności. Jeden zespół powinien prowadzić komunikację do zakończenia albo uzgodnionego przekazania.
- Backup bez testu i bez odbioru biznesowego. Plik kopii nie dowodzi możliwości przywrócenia działania procesu.
- Dostawca jako jedyny właściciel domeny lub tenantów. Firma traci zdolność do samodzielnego odzyskania kontroli i bezpiecznego zakończenia współpracy.
- Zmiany w aplikacji bez właściciela biznesowego. Technicznie poprawna zmiana może zaburzyć proces księgowy, sprzedażowy lub operacyjny.
- Cichy zakres. Oczekiwanie, że dostawca obsłuży producenta programu, telekomunikację lub projekt rozwojowy, mimo że nie zostało to opisane.
- Raportowanie samych liczb zgłoszeń. Liczba ticketów nie pokazuje otwartego ryzyka, nieaktualnych dostępów ani zależności bez właściciela.
Jak rozpocząć bez wielomiesięcznej reorganizacji
Nie trzeba czekać na idealną dokumentację. Pierwszym krokiem może być warsztat dotyczący usług krytycznych, a następnie lista właścicieli, dostępów i zależności. Drugi krok to prosta RACI dla kilku najważniejszych obszarów: tożsamości, poczty, backupu, systemu finansowego, sieci oraz urządzeń. Dopiero po uzgodnieniu tych podstaw warto rozszerzać model na pozostałe systemy.
Przed rozmową o zakresie przygotuj liczbę użytkowników i lokalizacji, listę usług krytycznych, znane terminy, obecne role wewnętrznego IT oraz listę innych dostawców. Nie przesyłaj w pierwszej wiadomości haseł, kodów MFA, kluczy prywatnych, eksportów konfiguracji z sekretami ani danych o aktywnej podatności. Wystarczy opis problemu i granic, które firma chce uporządkować.
Jeśli celem jest połączenie kompetencji wewnętrznych z zewnętrzną obsługą, sprawdź zakres outsourcingu IT w Warszawie. W rozmowie warto zacząć od usług, odpowiedzialności i otwartych ryzyk, a nie od założenia, że jeden zespół automatycznie przejmie wszystkie zadania.
Podsumowanie
Model mieszany może zwiększyć odporność organizacji, bo łączy kontekst biznesowy i kontrolę firmy z dodatkowymi zasobami technicznymi. Nie działa jednak dzięki samej obecności dwóch zespołów. Potrzebuje jednego właściciela dla decyzji, widocznych granic zakresu, bezpiecznego dostępu, procedur zmian i incydentów oraz regularnych przeglądów.
Najlepszym miernikiem dojrzałości nie jest liczba osób po każdej stronie. Jest nim zdolność firmy do odpowiedzi na proste pytania: kto podejmie decyzję przy awarii, kto może odzyskać dostęp do kluczowego konta, kto zatwierdza zmianę, kto sprawdza odtworzenie i kto prowadzi eskalację do producenta aplikacji. Gdy odpowiedzi są zapisane i znane zespołom, outsourcing oraz wewnętrzne IT mogą uzupełniać się zamiast wzajemnie blokować.
Ograniczenia i ryzyka
Opisane działania ograniczają ryzyko, ale nie gwarantują braku przestoju, odzyskania danych ani powodzenia zmiany bez sprawdzenia zależności, dostępów, testów i uzgodnionego zakresu. Otwarte ograniczenia należy przypisać właścicielowi i terminowi przeglądu.
Checklista dalszych kroków
Przed rozpoczęciem prac zbierz fakty, przypisz właścicieli i uzgodnij sposób potwierdzenia wyniku. Poniższa lista pomaga rozpocząć rozmowę bez przekazywania sekretów.
- Wskaż usługi lub procesy krytyczne dla codziennej pracy.
- Zapisz znane zależności, otwarte ryzyka i ważne terminy.
- Wyznacz właściciela biznesowego decyzji oraz kontakt techniczny.
- Ustal, jaki wynik lub test będzie potwierdzał kolejny etap.
Kiedy potrzebna jest pomoc specjalisty
Pomoc jest potrzebna, gdy firma nie potrafi wiarygodnie ustalić właścicieli, zależności, zakresu dostępu albo kolejności bezpiecznych zmian. Przed rozmową przygotuj jedynie ogólny obraz środowiska i terminów; nie przesyłaj haseł, kodów MFA, kluczy ani danych aktywnej podatności.
Źródła
Źródła zewnętrzne zweryfikowane podczas aktualizacji 2026-09-15. Przed działaniem sprawdź ich bieżącą wersję.