Zmiana firmy IT bez przestoju: procedura przejęcia administracji
Zmiana firmy IT rzadko kończy się źle z powodu technologii. Kończy się źle, gdy ktoś wypowie umowę, zanim ustali, kto jest abonentem domeny, kto ma konta administratorów i gdzie naprawdę są kopie zapasowe. Poniżej kolejność, która chroni ciągłość działania, i lista dostępów do odebrania po zakończeniu współpracy z informatykiem.

Decyzja o rozstaniu z dotychczasowym dostawcą IT zapada zwykle wcześniej, niż ktokolwiek ją wypowie na głos. Zgłoszenia wiszą po kilka dni, nikt nie potrafi powiedzieć, czy backup się wykonał, a pytanie o dokumentację kończy się obietnicą, że „wszystko jest u nas w systemie”. Sama decyzja niczego jednak nie rozwiązuje, a źle poprowadzona zmiana firmy IT potrafi kosztować więcej niż kolejny rok słabej obsługi.
Ryzyko rzadko leży po stronie technologii. Leży w kolejności działań. Firma wypowiada umowę, licząc na czystą kartę, i dopiero wtedy odkrywa, że domena jest zarejestrowana na prywatne konto byłego administratora, licencje kupiono przez partnera, który przestał nim być, a jedyna kopia bazy danych leży na dysku w serwerowni, do której nikt nie zna hasła.
Kolejność, która chroni ciągłość działania, jest prosta: najpierw ustalcie, co posiadacie i kto tym steruje, potem zabezpieczcie kontrolę, a dopiero na końcu kończcie współpracę. Ta sama zasada dotyczy rozstania z firmą IT i z pojedynczym informatykiem, który przez lata „wszystko ustawiał”. Opisujemy procedurę operacyjną; fragmenty dotyczące umowy wymagają rozmowy z radcą prawnym i wprost to zaznaczamy.
Kiedy zmiana dostawcy jest uzasadniona
Nie każda frustracja uzasadnia zmianę. Część problemów wynika z zakresu, którego nikt nigdy nie ustalił. Jeśli umowa obejmuje reakcję na awarie, a firma oczekuje rozwoju infrastruktury, nowy dostawca odtworzy ten sam konflikt kilka miesięcy później.
Zmiana ma sens wtedy, gdy problem jest strukturalny i powtarzalny:
- Brak przejrzystości. Nie wiecie, co zostało zrobione, dlaczego i za co płacicie. Nie dostajecie raportów albo dostajecie zestawienia, z których nic nie wynika.
- Ryzyko skupione na jednej osobie. Całe środowisko zna jeden człowiek, nic nie jest udokumentowane, a jego urlop jest problemem operacyjnym firmy.
- Dostępy na prywatnych kontach. Domena, konto administratora albo kontroler sieci są założone na prywatny adres technika.
- Nieweryfikowalny backup. Dostawca deklaruje kopie zapasowe, ale nie potrafi pokazać dowodu odtworzenia.
- Brak reakcji na zgłoszone ryzyko. Zgłaszacie sprzęt bez wsparcia producenta, brak segmentacji albo wspólne konto administratora i przez rok nic się nie dzieje.
- Konflikt interesów. Dostawca zarabia wyłącznie na interwencjach, więc stabilne środowisko jest sprzeczne z jego modelem przychodu.
Jeśli powodem jest jednorazowa awaria albo spór o fakturę, najpierw wyczerpcie rozmowę. Przejęcie administracji to projekt, który zajmuje kilka tygodni i angażuje ludzi po Waszej stronie.
Jeżeli rozpoznajecie co najmniej dwa punkty z powyższej listy, dalsza część pokazuje, jak przeprowadzić zmianę bez zatrzymania firmy. Na co zwracać uwagę przy wyborze następcy, opisaliśmy w poradniku jak wybrać firmę do outsourcingu IT.
Najpierw umowa i własność zasobów
To moment, w którym najczęściej popełnia się błąd nieodwracalny. Wypowiedzenie umowy przed inwentaryzacją odbiera Wam jedyną realną dźwignię: dopóki trwa współpraca, dostawca ma umowny obowiązek działać. Po wypowiedzeniu zostaje dobra wola i okres wypowiedzenia, który zwykle mija szybciej, niż udaje się ustalić, gdzie są hasła.
Kolejność, która działa: inwentaryzacja → potwierdzenie własności → zabezpieczenie kontroli → wypowiedzenie → przekazanie.
Zanim cokolwiek wypowiecie, odpowiedzcie na cztery pytania.
Kto jest abonentem domeny? Liczy się osoba lub firma wpisana jako abonent w rejestrze, niezależnie od tego, kto domenę „obsługuje”. Domena zarejestrowana na dostawcę albo na prywatne konto jego pracownika to pojedynczy punkt, który może zatrzymać pocztę i stronę całej firmy.
Kto jest właścicielem subskrypcji i licencji? Microsoft 365 i Google Workspace bywają kupowane przez partnera. Zakończenie relacji z partnerem potrafi wpłynąć na rozliczenie subskrypcji. To samo dotyczy licencji na oprogramowanie serwerowe i systemy branżowe.
Gdzie fizycznie są kopie zapasowe i kto ma do nich dostęp? Backup działający na koncie dostawcy w jego chmurze jest w praktyce jego kopią Waszych danych, z zupełnie inną sytuacją prawną i operacyjną.
Czy istnieje umowa powierzenia przetwarzania danych? Jeśli dostawca ma dostęp do systemów z danymi osobowymi, przetwarza je w Waszym imieniu. Urząd Ochrony Danych Osobowych przypomina, że zgodnie z art. 28 RODO przetwarzanie przez podmiot przetwarzający odbywa się na podstawie pisemnej umowy, która określa m.in. przedmiot, czas trwania, rodzaj danych i obowiązki stron. Administrator powinien też sprawdzić, czy dostawca daje wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych.
Wytyczne brytyjskiego National Cyber Security Centre dotyczące wyboru dostawcy usług zarządzanych idą w tym samym kierunku: umowa powinna zawierać macierz odpowiedzialności, określać, co robi dostawca i czego oczekuje się od klienta, oraz uwzględniać ryzyka jego łańcucha dostaw.
Pytania do radcy prawnego
Poniższe kwestie rozstrzyga prawnik na podstawie Waszej konkretnej umowy:
- Jaki jest okres wypowiedzenia i od kiedy biegnie?
- Czy umowa zawiera obowiązek współdziałania przy zakończeniu współpracy i przekazania dokumentacji?
- Kto jest właścicielem wytworzonej dokumentacji i konfiguracji?
- Jakie są konsekwencje wypowiedzenia przed terminem?
- Czy istnieją zapisy o karach, wyłączności albo automatycznym przedłużeniu?
Wynikiem tej części ma być jedna kartka: lista zasobów, przy każdym nazwa właściciela formalnego i informacja, czy Wasza firma ma do niego samodzielny dostęp.
Lista dostępów do przekazania po zakończeniu współpracy z informatykiem
Nieprzekazane dostępy rzadko wynikają ze złej woli. Częściej to zwykłe zaniedbanie: konto założone na szybko na prywatny adres, hasło podane przez telefon, które nigdy nie trafiło do żadnej listy. Skutek jest ten sam niezależnie od intencji: żeby cokolwiek zmienić we własnym środowisku, firma potrzebuje jednej konkretnej osoby.
Dlatego przekazanie kompletu dostępów traktujcie jako standardowy element odbioru prac. Przed ostatnim dniem współpracy przejdźcie przez listę poniżej.
| Obszar | Co odebrać | Na co uważać |
|---|---|---|
| Domeny | Dostęp do panelu rejestratora, dane abonenta, kod authinfo | Abonentem ma być firma, a adres kontaktowy w rejestrze ma należeć do firmy |
| DNS | Dostęp do serwerów nazw i eksport strefy | DNS bywa u innego dostawcy niż rejestrator |
| Poczta i tożsamość | Konta globalnego administratora Microsoft 365, Google Workspace lub Active Directory | Co najmniej jedno konto administratora firmy, do którego informatyk nie ma dostępu |
| Licencje i subskrypcje | Lista subskrypcji, właściciel, data odnowienia, partner rozliczający | Subskrypcje kupione przez partnera i karty płatnicze przypięte do kont prywatnych |
| Hosting i strona | Panel hostingu, dostęp do systemu zarządzania treścią i kopii strony | Konto hostingu na dane informatyka |
| Sieć | Konto właściciela w kontrolerze sieci, hasła lokalne routera, zapory, przełączników i punktów dostępowych | Konto w chmurze producenta założone na prywatny e-mail |
| Serwery i wirtualizacja | Konta administracyjne, zdalne zarządzanie serwerem, hasła szyfrowania | Konta serwisowe, o których nikt nie pamięta |
| Backup | Dostęp do konsoli kopii i klucze szyfrowania kopii | Kopie zaszyfrowane kluczem, który zna tylko jedna osoba |
| Zdalny dostęp | Konta VPN, narzędzia zdalnego pulpitu, agent zarządzania stacjami | Aktywne sesje i agenty, które dalej łączą się z kontem informatyka |
| Systemy branżowe i ERP | Konta administratora, umowy wsparcia z producentem, osoba kontaktowa | Producent kontaktuje się wyłącznie z byłym informatykiem |
| Operatorzy | Dostęp do paneli operatora łącza i telefonii, numery umów | Umowa na łącze wystawiona na inny podmiot |
| KSeF | Lista uprawnień i tokenów nadanych osobom spoza firmy | Token pozostaje ważny do czasu unieważnienia |
| Hasła | Eksport z firmowego menedżera haseł albo przekazanie sejfu | Hasła przekazane w formie, której nie da się potem zmienić |
Dwie pozycje wymagają komentarza. W domenie .pl rejestrator, zgodnie z informacjami NASK o prawach abonenta, nie może bez wiedzy i zgody abonenta zmienić abonenta ani przenieść domeny do innego rejestratora, a na żądanie abonenta ma niezwłocznie wydać kod authinfo potrzebny do transferu. NASK zaleca też aktualny adres e-mail w rejestrze, bo tam trafiają potwierdzenia ważnych zmian. Z kolei token KSeF, jak wyjaśnia Ministerstwo Finansów, działa bezterminowo, dopóki ktoś go nie unieważni. Więcej o uprawnieniach w tym systemie piszemy w tekście o KSeF po 1 kwietnia 2026.
Przy sieci zmiana hasła Wi-Fi niczego nie załatwia. Hasło sieci bezprzewodowej i dostęp administracyjny do kontrolera oraz urządzeń to dwa osobne poziomy. Firma powinna mieć własne konto z pełnymi uprawnieniami właściciela, założone na adres e-mail w domenie firmy. Jeżeli producent przewiduje procedurę przeniesienia własności konsoli, ustalcie z wykonawcą, czy z niej skorzystano, czy sieć od początku była założona na konto firmy.
Co zrobić zaraz po przekazaniu dostępów
- Zmieńcie hasła kont administracyjnych, nawet jeśli formalnie zostały przekazane.
- Wyłączcie konta osób, które nie powinny mieć dalszego dostępu, zamiast zakładać, że same przestaną z nich korzystać.
- Sprawdźcie, czy konto właściciela ma pełne uprawnienia administracyjne.
- Unieważnijcie tokeny i klucze API wydane byłemu informatykowi, w tym w KSeF i w integracjach.
- Zapiszcie, gdzie fizycznie stoją urządzenia zarządzające siecią i kto ma do nich dostęp.
- Poproście o dokumentację w edytowalnej formie, którą firma może sama aktualizować.
Jeśli jedynym kontem administracyjnym było konto byłego wykonawcy, a on nie odpowiada, odzyskanie kontroli zależy od producenta i dostępnych u niego mechanizmów odzyskiwania. Zwykle wymaga to dostępu fizycznego do urządzenia, a czasem przywrócenia ustawień fabrycznych i odtworzenia konfiguracji.
Plan przejęcia krok po kroku
Zaczynamy od zasobów, których utrata jest najbardziej dotkliwa i najtrudniejsza do odwrócenia, a kończymy na tych, które da się odtworzyć.
Domeny i DNS
Domena jest pierwsza, bo steruje pocztą i obecnością firmy w internecie, a jej odzyskanie wbrew abonentowi bywa procesem na tygodnie.
Ustalcie abonenta i uzyskajcie dostęp do panelu rejestratora, najlepiej przez przeniesienie domeny na konto firmowe założone na adres w Waszej domenie. Zróbcie pełny eksport strefy DNS i zapiszcie go poza środowiskiem dostawcy. To zwykły plik tekstowy, ale bez niego odtwarzanie konfiguracji poczty odbywa się metodą prób i błędów na działającej firmie.
Na tym etapie nie zmieniajcie rekordów MX. Celem jest kontrola nad strefą; przełączanie usług przyjdzie później.
Tożsamość i uwierzytelnianie
Drugi w kolejności jest system tożsamości: Microsoft Entra ID, Google Workspace albo Active Directory. Kto ma tożsamość, ten ma wszystko, co jest do niej podłączone.
Potwierdźcie, że Wasza firma ma co najmniej jedno konto globalnego administratora, do którego dostawca nie ma dostępu, chronione uwierzytelnianiem wieloskładnikowym. W Microsoft Entra ID producent zaleca dodatkowo co najmniej dwa konta dostępu awaryjnego: wyłącznie chmurowe, niepowiązane z konkretnym pracownikiem ani jego telefonem, z metodą odporną na phishing i sprawdzane co najmniej co 90 dni oraz po zmianach w obsłudze IT. NCSC zaleca dwuetapową weryfikację kont administracyjnych i dawanie dostawcy wyłącznie uprawnień niezbędnych do zadania.
Zinwentaryzujcie konta uprzywilejowane: kto je ma, od kiedy, po co i kiedy ostatnio ich użyto. Sprawdźcie konta serwisowe i aplikacyjne. Przetrwają rozstanie z dostawcą, jeśli nikt o nich nie pomyśli, i najczęściej zostają jako niewidoczne wejście do środowiska.
Na tym etapie nie usuwajcie kont dostawcy. Będzie jeszcze potrzebny do przekazania wiedzy. Usunięcie następuje po odbiorze.
Urządzenia i zarządzanie stacjami
Ustalcie, czym zarządzane są komputery: rozwiązaniem klasy RMM (narzędzie do zdalnego monitorowania i zarządzania), Intune, polityką domenową czy niczym. Jeśli agent zarządzający należy do dostawcy, po rozstaniu straci wsparcie i trzeba zaplanować jego wymianę na stacjach. To prosta, ale czasochłonna operacja, którą lepiej rozłożyć w czasie.
Sporządźcie spis sprzętu z numerami seryjnymi, przypisaniem do osób, datami zakupu i statusem wsparcia producenta. Osobno wypiszcie urządzenia bez wsparcia; to lista ryzyk, którą przejmuje nowy dostawca. NCSC wskazuje, że umowa powinna określać, kto śledzi daty zakończenia wsparcia i działa przed ich upływem.
Sprawdźcie szyfrowanie dysków. Jeśli stacje są zaszyfrowane, klucze odzyskiwania muszą być zdeponowane w Waszym systemie tożsamości, poza narzędziem dostawcy. Utrata kluczy przy zmianie zarządzania oznacza utratę danych na urządzeniu.
Sieć
Zbierzcie dostępy administracyjne do routera, zapory, przełączników i punktów dostępowych oraz aktualne kopie konfiguracji. Zapiszcie, jak wygląda segmentacja, jakie są reguły dostępu z zewnątrz i kto ma zdalny dostęp przez VPN. Plan sieci, lista VLAN-ów z przeznaczeniem i adresacja to minimum; bez nich nawet pełne dostępy nie dają realnej kontroli.
Kontrakty na łącza i dostęp do paneli operatorów bywają pomijane, a potrafią zablokować diagnostykę awarii. Sprawdźcie, na kogo są wystawione.
Osobno wypiszcie każdy zdalny dostęp: konta VPN, przekierowania portów, narzędzia zdalnego pulpitu. Po zakończeniu współpracy trzeba tę listę przejrzeć punkt po punkcie.
Chmura i licencje
Wypiszcie wszystkie subskrypcje: kto jest właścicielem, kto płaci, kiedy wygasają, przez jakiego partnera zostały kupione. Sprawdźcie, czy firmowe dane nie żyją na kontach prywatnych; to wychodzi zwykle dopiero przy migracji.
Systemy branżowe i ERP mają zwykle osobne umowy wsparcia z producentem, niezależne od umowy z dostawcą IT, i wymagają osobnej zmiany osoby kontaktowej.
Backup
Backup jest na końcu sekwencji, bo wymaga najwięcej uwagi i najczęściej rozczarowuje. Zacznijcie od rozróżnienia, które w rozmowach bywa zacierane:
| Mechanizm | Co robi | Czego nie robi |
|---|---|---|
| Synchronizacja (OneDrive, Dysk Google) | Utrzymuje te same pliki na wielu urządzeniach | Nie chroni przed skasowaniem ani zaszyfrowaniem, zmiana replikuje się do wszystkich kopii |
| Replikacja | Utrzymuje bliźniaczą kopię systemu, zwykle dla dostępności | Powiela błąd i szkodliwą zmianę; nie cofa w czasie |
| Snapshot | Zapisuje stan maszyny w punkcie czasu | Zwykle leży na tej samej infrastrukturze i dzieli jej los |
| Backup | Tworzy odrębną, odtwarzalną kopię z historią wersji | Bez testu odtworzenia nie wiadomo, czy zadziała |
| Archiwizacja | Przechowuje dane długoterminowo dla zgodności | Nie służy do szybkiego przywrócenia po awarii |
Następnie zadajcie dostawcy trzy pytania i poproście o dowody: co dokładnie jest objęte kopią, gdzie leżą kopie i kto ma do nich dostęp, kiedy ostatnio wykonano test odtworzenia i jaki był jego wynik.
Ustalcie też dwa parametry, które określają, na co firma faktycznie się godzi. RPO to maksymalna akceptowalna utrata danych liczona w czasie: „ile godzin pracy możemy stracić”. RTO to maksymalny czas przywrócenia usługi: „jak długo możemy nie działać”. Jeśli nikt w firmie nie zna tych wartości, backup jest jedynie włączony, bez projektu.
Przed przejściem dalej wykonajcie niezależną kopię krytycznych danych, do której dostęp ma wyłącznie Wasza firma. To jedyny element całej procedury, którego nie należy odkładać ani delegować. Jak odróżnić działający backup od pozornego, opisaliśmy w tekście o backupie danych w firmie.
Okres przejściowy i komunikacja
Okres równoległy, w którym stary dostawca jeszcze odpowiada za środowisko, a nowy już je poznaje, jest najbezpieczniejszym wariantem zmiany. Zwykle trwa od dwóch do sześciu tygodni, zależnie od złożoności środowiska i tego, ile udało się ustalić podczas inwentaryzacji.
Podział odpowiedzialności powinien być jednoznaczny: stary dostawca odpowiada za działanie, nowy za poznanie i przygotowanie. Rozmycie tej granicy kończy się sytuacją, w której przy awarii każdy wskazuje na drugiego, a firma stoi.
Wyznaczcie jedną osobę po swojej stronie, która prowadzi projekt i podejmuje decyzje. Nie musi być techniczna, ale musi mieć mandat.
Komunikacja z odchodzącym dostawcą powinna być rzeczowa i pisemna: termin, zakres przekazania, osoby kontaktowe i potwierdzenie odbioru. Nie trzeba uzasadniać decyzji ani wchodzić w spór o przeszłość. Oddzielcie ocenę dotychczasowej współpracy od technicznego transferu; dostawca w konflikcie przekazuje minimum, a Wy potrzebujecie maksimum. Poprzednik powinien też dostać jasny termin usunięcia swoich kont po zakończeniu przekazania.
Pracownikom wystarczy prosty komunikat: zmieniamy firmę obsługującą IT, od dnia X zgłoszenia kierujcie tutaj, w okresie przejściowym może wystąpić krótka przerwa w wybranych usługach. Nadmiar szczegółów technicznych mnoży pytania.
Protokół odbioru
Przekazanie środowiska bez protokołu to rozmowa, którą za miesiąc każdy pamięta inaczej. Protokół nie musi być dokumentem prawniczym. Wystarczy lista pozycji z kryterium zaliczenia i podpisem.
Każda pozycja powinna mieć trzy elementy: zasób, dowód wykonania i kryterium zaliczenia. Zdanie „przekazano hasła” dowodem nie jest. Dowodem jest potwierdzone logowanie osoby z Waszej firmy albo z firmy przejmującej.
| Obszar | Dowód wykonania | Kryterium zaliczenia |
|---|---|---|
| Domena | Zrzut ekranu panelu rejestratora z danymi abonenta | Firma figuruje jako abonent i loguje się samodzielnie |
| DNS | Eksport strefy | Plik zapisany poza środowiskiem starego dostawcy |
| Tożsamość | Lista kont uprzywilejowanych | Konto administratora firmy i konta awaryjne działają |
| Backup | Raport z testu odtworzenia | Odtworzono wskazany plik lub system i potwierdzono jego poprawność |
| Sieć | Kopie konfiguracji urządzeń | Nowy dostawca loguje się do każdego urządzenia |
| Licencje | Zestawienie subskrypcji z właścicielem | Firma jest właścicielem lub zna ścieżkę przejęcia |
| Dokumentacja | Przekazany komplet | Nowy dostawca potwierdza kompletność po przeglądzie |
| Konta dostawcy | Lista kont do usunięcia | Konta wyłączone, następnie usunięte po okresie karencji |
Ostatnią pozycję wykonuje się po potwierdzeniu, że wszystko inne działa. Kolejność: wyłączcie konta, odczekajcie ustalony okres karencji, sprawdźcie, czy nic nie przestało działać, i dopiero potem usuńcie. Natychmiastowe usunięcie potrafi zatrzymać zadanie, o którym nikt nie wiedział, i odebrać możliwość szybkiego cofnięcia zmiany.
Przejrzyjcie też konta serwisowe i integracje. Powiązania z systemami zewnętrznymi bywają wystawione na adres e-mail dostawcy.
Brak dokumentacji lub współpracy
Zdarza się, że dostawca nie przekazuje wiedzy: nie odpowiada, zasłania się brakiem czasu albo twierdzi, że dokumentacja nie istnieje. Zwykle stoi za tym prozaiczny fakt: w wielu małych firmach IT dokumentacja nigdy nie powstała, a wiedza żyła w głowie jednej osoby.
Nie eskalujcie konfliktu przed zabezpieczeniem kontroli. Awantura kosztuje dostęp, którego jeszcze potrzebujecie.
Praktyczna kolejność w takiej sytuacji:
- Wystąpcie pisemnie z konkretną listą pozycji i terminem. Pismo dokumentuje próbę współpracy i przyda się, jeśli sprawa trafi do prawnika.
- Odtwórzcie stan z systemów. Panel rejestratora domen, panel operatora, konsole Microsoft 365 lub Google Workspace, konfiguracje urządzeń sieciowych i faktury. Faktury są niedocenianym źródłem: pokazują, za co firma faktycznie płaci, a więc jakie usługi istnieją.
- Odzyskajcie kontrolę tam, gdzie jesteście właścicielem. Abonent domeny może zażądać od rejestratora kodu authinfo, a gdy rejestrator odmawia, NASK przyjmuje reklamację. Właściciel subskrypcji zwykle może przejść procedurę odzyskania dostępu u dostawcy usługi.
- Przyjmijcie, że wiedza przepadła, i zaplanujcie jej odtworzenie. Nowy dostawca inwentaryzuje środowisko od zera. To kosztuje czas, ale jest wykonalne i policzalne.
- Skonsultujcie się z prawnikiem, jeżeli umowa przewiduje obowiązek współdziałania, a dostawca go nie realizuje.
Sytuacja wymagająca natychmiastowej reakcji: dostawca odmawia współpracy i nadal ma aktywny dostęp do środowiska. Wtedy zabezpieczenie kont uprzywilejowanych staje się pilne i wykonuje się je niezależnie od stanu rozmów, z zapisem, kto i kiedy zmienił dostęp.
Pierwsze 30 dni nowego dostawcy
Przejęcie kończy się wtedy, gdy środowisko jest opisane, a firma wie, czego się spodziewać. Sam dzień przekazania to dopiero początek.
Dni 1-7. Nowy dostawca weryfikuje inwentaryzację i konfrontuje ją z rzeczywistością; na tym etapie zwykle wychodzą rzeczy, o których nie było mowy w protokole. Uruchamia monitoring i kanał zgłoszeń. Priorytetem jest wykrywanie awarii, optymalizacja przychodzi później.
Dni 8-14. Weryfikacja backupu własnymi narzędziami i pierwszy test odtworzenia. Przegląd kont uprzywilejowanych i usunięcie tych, które zostały po poprzedniej współpracy. Lista ryzyk krytycznych: sprzęt bez wsparcia, brak segmentacji, konta współdzielone.
Dni 15-30. Uzupełnienie dokumentacji do stanu, w którym środowisko może przejąć inna osoba. Ustalenie priorytetów zgłoszeń, zasad ich obsługi i tego, czym różni się czas reakcji od czasu naprawy. Pierwszy raport dla zarządu: co zastano, co naprawiono, co wymaga decyzji i pieniędzy.
Ten raport jest dobrym miernikiem jakości pierwszego miesiąca. Jeśli po trzydziestu dniach nowy dostawca nie potrafi opisać, co zastał, zmiana była przeprowadzką bez przejęcia odpowiedzialności. Przejęcie jest zakończone, gdy firma kontroluje konta właścicielskie, nowy zespół obsłuży incydent bez pomocy poprzednika, monitoring obejmuje uzgodnione elementy, backup został zweryfikowany, a otwarte ryzyka mają priorytety.
Zbiorcza lista kontrolna
Skrócona lista całej procedury. Punkty wykonujcie w tej kolejności.
Przed wypowiedzeniem umowy
- [ ] Ustalono abonenta domeny i uzyskano dostęp do panelu rejestratora
- [ ] Wyeksportowano strefę DNS i zapisano poza środowiskiem dostawcy
- [ ] Firma ma własne konto administratora z MFA i konta awaryjne w systemie tożsamości
- [ ] Zinwentaryzowano konta uprzywilejowane, serwisowe i aplikacyjne
- [ ] Ustalono właściciela każdej subskrypcji i licencji
- [ ] Potwierdzono, gdzie są kopie zapasowe i kto ma do nich dostęp
- [ ] Wykonano niezależną kopię krytycznych danych
- [ ] Spisano sprzęt z numerami seryjnymi i statusem wsparcia
- [ ] Zebrano konfiguracje urządzeń sieciowych i konto właściciela kontrolera sieci
- [ ] Sprawdzono, czy istnieje umowa powierzenia przetwarzania danych
- [ ] Prawnik ocenił warunki wypowiedzenia i obowiązek współdziałania
Okres przejściowy
- [ ] Ustalono podział odpowiedzialności między dostawcami na piśmie
- [ ] Wyznaczono osobę prowadzącą projekt po stronie firmy
- [ ] Zakomunikowano zmianę pracownikom
- [ ] Ustalono termin i zakres przekazania
Odbiór
- [ ] Każda pozycja protokołu ma dowód wykonania i kryterium zaliczenia
- [ ] Wykonano test odtworzenia z backupu i potwierdzono wynik
- [ ] Nowy dostawca potwierdził kompletność dokumentacji
- [ ] Zmieniono hasła administracyjne i unieważniono tokeny wydane poprzednikowi, także w KSeF
- [ ] Konta starego dostawcy wyłączono, odczekano karencję i usunięto
- [ ] Przejrzano zdalne dostępy: VPN, przekierowania portów, zdalny pulpit
- [ ] Zmieniono osoby kontaktowe u producentów, operatorów i rejestratora domen
Pierwsze 30 dni
- [ ] Monitoring i kanał zgłoszeń działają
- [ ] Backup zweryfikowany narzędziami nowego dostawcy
- [ ] Powstała lista ryzyk krytycznych
- [ ] Dokumentacja pozwala przejąć środowisko innej osobie
- [ ] Zarząd otrzymał raport otwarcia
Zmiana firmy IT jako zaplanowany projekt
W całej procedurze najważniejsza jest kolejność. Firmy, które tracą dane albo stają na kilka dni, prawie zawsze zaczynają od wypowiedzenia umowy, a inwentaryzację robią pod presją czasu i emocji. Firmy, które przechodzą przez to spokojnie, najpierw ustalają, co posiadają, potem zabezpieczają kontrolę, a rozmowę o zakończeniu współpracy prowadzą z pozycji kogoś, kto ma już klucze do własnego domu.
Jeśli planujecie zmianę dostawcy, zacznijmy od inwentaryzacji i mapy odpowiedzialności w ramach stałej obsługi informatycznej; dopiero na tej podstawie da się powiedzieć, co jest wykonalne i w jakim czasie.
Zastrzeżenie
Materiał ma charakter informacyjny i opisuje praktykę operacyjną. Nie stanowi porady prawnej. Ocena zapisów konkretnej umowy, warunków jej wypowiedzenia, kwestii własności zasobów oraz obowiązków wynikających z przepisów o ochronie danych osobowych wymaga konsultacji z radcą prawnym znającym Waszą dokumentację.
Źródła
- National Cyber Security Centre, Choosing a Managed Service Provider (MSP), publikacja 24.11.2025, przegląd 24.06.2026, https://www.ncsc.gov.uk/guidance/choosing-a-managed-service-provider-msp (dostęp 2.10.2026)
- Urząd Ochrony Danych Osobowych, Powierzenie przetwarzania danych trzeba udokumentować, 21.09.2022, https://uodo.gov.pl/pl/138/2485 (dostęp 2.10.2026)
- NASK, Prawa abonenta i postępowanie reklamacyjne, https://www.dns.pl/prawa_abonenta_domeny_pl (dostęp 2.10.2026)
- Microsoft Learn, Manage emergency access admin accounts - Microsoft Entra ID, https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access (dostęp 2.10.2026)
- Ministerstwo Finansów, Certyfikaty KSeF, https://ksef.podatki.gov.pl/informacje-ogolne-ksef-20/certyfikaty-ksef/ (dostęp 2.10.2026)
Stan na 2 października 2026 r.