Lista serwerów, komputerów i aplikacji mówi, co urząd posiada. Nie mówi jeszcze, co powinno wrócić jako pierwsze, gdy awaria obejmuje kilka systemów jednocześnie. Priorytet odtwarzania trzeba budować od usług świadczonych mieszkańcom i pracownikom, a dopiero potem przejść do wspierających je zasobów technicznych.
Ten artykuł nie jest pełną metodyką BIA ani kolejnym opisem rejestru aktywów. Pokazuje mniejszy krok: jak podczas jednego warsztatu wskazać pierwszych pięć usług i utworzyć rejestr, który nadaje się do dalszej pracy.
Usługa to nie to samo co system
System dziedzinowy, serwer bazodanowy i łącze internetowe są zasobami. Usługą jest rezultat potrzebny odbiorcy, na przykład obsługa wniosku, wypłata świadczenia, rejestracja dokumentu albo dostęp pracownika do obiegu spraw. Jedna usługa może zależeć od kilku systemów, a jeden system może wspierać wiele usług.
Dlatego dobry rejestr zaczyna się od zdania: „urząd musi być w stanie…”. Dopiero pod nim zapisuje aplikacje, dane, ludzi, dostawców, lokalizacje i połączenia. Jeżeli punktem wyjścia jest wyłącznie inwentaryzacja sprzętu, przydatny będzie najpierw materiał o rejestrze aktywów i podatności w JST.
Pięć pytań kwalifikujących usługę
Nie istnieje uniwersalna lista pięciu usług dla każdej gminy, powiatu czy jednostki organizacyjnej. Wybór powinien wynikać z lokalnego zakresu zadań. Każdą kandydaturę warto ocenić tym samym zestawem pytań:
- Kogo dotknie przerwa? Ilu mieszkańców, pracowników lub jednostek nie będzie mogło wykonać ważnej czynności.
- Jak szybko rośnie skutek? Czy problem staje się poważny po godzinie, po dniu czy dopiero po kilku dniach.
- Czy istnieje bezpieczne obejście? Czy sprawę można czasowo obsłużyć ręcznie, w innym miejscu albo przez uzgodniony kanał.
- Od czego usługa zależy? Tożsamość, sieć, poczta, obieg dokumentów, baza danych, dostawca, podpis elektroniczny lub łączność z systemem zewnętrznym.
- Jaki jest skutek prawny i organizacyjny? Terminy, płatności, bezpieczeństwo ludzi, dostęp do dokumentacji i możliwość podjęcia decyzji przez kierownictwo.
Odpowiedzi mają służyć ustaleniu kolejności, nie tworzeniu pozornej matematycznej precyzji. Wystarczy prosty podział skutku na niski, średni i wysoki oraz uzasadnienie zapisane jednym zdaniem.
Warsztat 60 minut: od listy do pierwszej piątki
0–10 minut: ustal zakres
Zaproś osobę z IT, przedstawiciela kierownictwa lub sekretarza oraz właścicieli dwóch lub trzech kluczowych procesów. Zdecydujcie, czy analizujecie cały urząd, wybrany wydział czy jednostkę organizacyjną. Mieszanie kilku poziomów odpowiedzialności utrudnia porównanie.
10–25 minut: nazwij rezultaty, nie aplikacje
Każdy uczestnik zapisuje usługi, bez których jego obszar szybko przestaje działać. Nazwy powinny być zrozumiałe dla osoby spoza IT. Zamiast nazwy programu zapisz „rejestracja i obsługa korespondencji”, a nazwę programu dodaj później jako zależność.
25–40 minut: oceń skutek i obejście
Dla każdej usługi określ moment, w którym przerwa staje się nieakceptowalna, oraz możliwy tryb zastępczy. Usługa bez obejścia może otrzymać wyższy priorytet niż usługa równie ważna, którą przez kilka godzin można realizować ręcznie.
40–50 minut: narysuj zależności
Wskaż wspólne elementy, bez których kilka usług nie ruszy: uwierzytelnianie, sieć, baza danych, dostęp do kluczy, dostawca lub obieg dokumentów. To często pokazuje, że pierwszy techniczny krok nie jest tym samym co pierwsza usługa widoczna dla mieszkańca.
50–60 minut: zatwierdź pięć usług i właścicieli
Wybierzcie pięć pozycji, nadajcie im roboczą kolejność i przypiszcie osobę odpowiedzialną za uzupełnienie danych. Wynik nie musi być ostateczny. Musi mieć właściciela i datę przeglądu.
Minimalne pola rejestru usług krytycznych
- nazwa usługi sformułowana jako rezultat dla odbiorcy;
- właściciel usługi i zastępstwo;
- główni odbiorcy oraz skutek niedostępności;
- maksymalny akceptowalny czas przerwy;
- minimalny poziom działania podczas zakłócenia;
- procedura obejściowa i warunek jej uruchomienia;
- systemy, dane, infrastruktura, ludzie i dostawcy;
- kolejność odtworzenia zależności;
- data ostatniego przeglądu i testu.
RTO i RPO warto dopisać dopiero wtedy, gdy uczestnicy rozumieją konsekwencje tych wartości. Artykuł o BIA, RTO/RPO i testach pokazuje, jak połączyć wymagania usługi z planem technicznym.
Przykład roboczy, nie gotowa lista dla każdego urzędu
Pierwsza piątka może obejmować na przykład rejestrację korespondencji, dostęp do rejestrów stanu cywilnego, realizację płatności, obsługę świadczeń oraz komunikację wewnętrzną. W innej jednostce kolejność będzie odmienna. Ośrodek pomocy społecznej, urząd miasta i starostwo mają inne zadania, terminy i zależności.
Dla każdej pozycji zapisz jedno zdanie uzasadnienia. Przykład: „usługa otrzymuje priorytet 2, ponieważ po czterech godzinach powstaje kolejka spraw bez bezpiecznej procedury zastępczej, a jej uruchomienie zależy od tożsamości, bazy danych i połączenia z systemem centralnym”. Takie zdanie jest bardziej użyteczne niż sama cyfra.
Najczęstsze błędy
- Ranking według głośności zgłoszeń. Najczęściej używany system nie zawsze wspiera najważniejszą usługę.
- Brak właściciela poza IT. Informatyk może odtworzyć system, ale nie powinien sam potwierdzać poprawności całej usługi.
- Pomijanie dostawców i danych dostępowych. Umowa serwisowa nie gwarantuje dostępności osoby, instrukcji i poświadczeń w chwili awarii.
- Brak procedury zastępczej. Priorytet techniczny bez planu pracy wydziału pozostawia mieszkańca bez informacji.
- Brak przeglądu. Rejestr traci wartość po zmianie systemu, zakresu zadań albo dostawcy.
Jak przejść od rejestru do działania
Po wyborze pięciu usług sprawdź, czy dla każdej istnieje aktualny właściciel, instrukcja uruchomienia, kopia danych, kolejność zależności i prosty test. Luki organizacyjne można uporządkować w module M09 — System zarządzania bezpieczeństwem informacji, a priorytety, RTO/RPO i scenariusze odtworzeniowe w module M10 — Ciągłość działania IT.
Jeżeli urząd nadal nie potrafi wskazać pierwszej usługi, zacznij od ścieżki diagnostycznej „Nie mam planu na wypadek awarii lub ataku”. Celem pierwszej wersji rejestru nie jest kompletność. Celem jest wspólna, zatwierdzona kolejność decyzji.
Źródła i data weryfikacji
Stan źródeł zweryfikowano 21 lipca 2026 r. NIST SP 800-34 Rev. 1 opisuje BIA jako podstawę określania wymagań i priorytetów planowania awaryjnego. Materiał Gov.pl wskazuje na analizę wpływu, zabezpieczenia, testowanie scenariuszy oraz procedury działania i komunikacji.