Dostępność systemu urzędu często zależy od zewnętrznego dostawcy, hostingu, łącza, serwisu lub producenta oprogramowania. Sam zapis o dostępności na poziomie 99 procent nie wyjaśnia jednak, co wydarzy się w pierwszej godzinie awarii, kto podejmie decyzję ani jak urząd odzyska dane i konfigurację.
Poniższe pytania pomagają uporządkować operacyjną rozmowę z dostawcą przed zakupem, odnowieniem umowy albo testem ciągłości. Nie są gotowymi klauzulami i nie zastępują analizy prawnej, zamówieniowej ani technicznej. Konkretne zapisy trzeba dopasować do przedmiotu zamówienia, ryzyka usługi i aktualnego stanu prawnego.
Najpierw nazwij usługę i jej granice
SLA powinno dotyczyć mierzalnego rezultatu, a nie niejasnej deklaracji, że system jest utrzymywany. Przed rozmową warto wskazać usługę z rejestru usług krytycznych, powiązane systemy, godziny pracy, kluczowe zależności oraz akceptowalny czas przerwy. Dopiero na tej podstawie można ocenić, czy oferta dostawcy wspiera wymagania urzędu.
12 operacyjnych pytań do SLA i umowy
1. Jaki dokładnie rezultat jest objęty usługą?
Czy dostawca odpowiada wyłącznie za działanie aplikacji, czy również za bazę danych, integracje, certyfikaty, kopie, infrastrukturę i pomoc użytkownikom? Granice powinny pokazywać także elementy po stronie urzędu oraz innych podmiotów.
2. W jakich godzinach mierzona jest dostępność?
Trzeba rozróżnić dostępność całodobową, godziny pracy urzędu i okna serwisowe. Ważne jest również, kto zatwierdza planowaną przerwę, z jakim wyprzedzeniem jest ogłaszana oraz czy czas częściowej degradacji liczy się jako niedostępność.
3. Z jakiego źródła pochodzą pomiary?
Raport dostawcy może mierzyć inny punkt niż ten, który widzi użytkownik. Ustalcie źródło czasu, sposób wykrycia początku i końca przerwy, częstotliwość raportu oraz możliwość porównania z monitoringiem urzędu.
4. Jak klasyfikowane są zgłoszenia i kiedy zaczyna biec czas reakcji?
Definicje priorytetów powinny odnosić się do wpływu na usługę, nie tylko liczby uszkodzonych urządzeń. Warto rozdzielić czas potwierdzenia zgłoszenia, rozpoczęcia diagnozy, obejścia i przywrócenia działania.
5. Jak działa kontakt, gdy podstawowy kanał jest niedostępny?
Portal serwisowy nie pomoże, jeśli awaria obejmuje tożsamość, pocztę lub łącze. Potrzebny jest kanał zapasowy, aktualna lista uprawnionych osób, sposób ich weryfikacji i procedura na wypadek braku odpowiedzi pierwszej linii.
6. Kto może eskalować i podejmować decyzje po obu stronach?
Imienny opiekun nie wystarcza. Ustalcie role, zastępstwa, kolejne poziomy eskalacji oraz decyzje wymagające zgody urzędu: odcięcie integracji, użycie kopii, zmiana konfiguracji lub podłączenie odbudowanego systemu.
7. Jakie są cele odtworzenia usługi i danych?
RTO oraz RPO urzędu trzeba porównać z realnymi możliwościami dostawcy. Należy ustalić, od jakiego momentu liczy się czas, jaki poziom funkcji oznacza odtworzenie oraz kiedy właściciel procesu potwierdza użyteczność usługi. Pomocny jest materiał o BIA, RTO i RPO.
8. Jak i kiedy testowane jest odtworzenie?
Zapytajcie o zakres testu, środowisko, częstotliwość, udział urzędu i dowody wyniku. Raport powinien pokazywać nie tylko uruchomienie komponentu, ale także zależności oraz akceptację usługi. Minimalny układ dowodów zawiera protokół testu odtworzeniowego.
9. Kto odpowiada za kopie, ich integralność i bezpieczne udostępnienie?
Trzeba rozdzielić wykonanie kopii, kontrolę wyniku, retencję, szyfrowanie, test odzysku i decyzję o użyciu. Urząd powinien wiedzieć, gdzie znajdują się dane, jak uzyskuje dostęp w sytuacji awaryjnej i co dzieje się po zakończeniu współpracy.
10. Jak zarządzani są podwykonawcy i zależności łańcucha dostaw?
Zapytajcie, które elementy wykonują inne podmioty, jak dostawca ocenia ich ryzyko, informuje o zmianach i zapewnia ciągłość po ich stronie. Odpowiedzialność operacyjna nie powinna znikać w wielopoziomowym łańcuchu zgłoszeń.
11. Jak obsługiwane są zmiany, podatności i koniec wsparcia?
Ustalcie terminy informacji o podatnościach, krytycznych poprawkach i zakończeniu wsparcia, sposób uzgadniania zmian oraz plan wycofania przestarzałego komponentu. Zmiana wprowadzona bez kontroli może sama stać się przyczyną przerwy.
12. Jak wygląda bezpieczne wyjście z usługi?
Plan wyjścia powinien obejmować format i kompletność danych, dokumentację konfiguracji, przeniesienie wiedzy, cofnięcie dostępów, zwrot lub usunięcie danych oraz czas wsparcia migracji. Testowalna przenośność ogranicza ryzyko uzależnienia od jednego podmiotu.
Jak zamienić odpowiedzi w wymagania
Dla każdego pytania zapiszcie cztery elementy: oczekiwany wynik, sposób pomiaru, właściciela po stronie urzędu i dostawcy oraz dowód realizacji. Przykładowo zamiast „dostawca wykonuje kopie” lepiej ustalić częstotliwość, zakres, raport błędów, okres retencji, termin testu odzysku i osobę akceptującą wynik.
Wymagania związane z oceną dostawcy i monitorowaniem współpracy porządkuje moduł M11 — Dostawcy i łańcuch dostaw IT. Jeżeli odpowiedzi mają zostać przełożone na przygotowanie postępowania, powiązanym obszarem jest moduł M12 — Cyberbezpieczeństwo w zamówieniach publicznych. Parametry odtworzenia i testy pozostają częścią modułu M10 — Ciągłość działania IT.
Trzy sygnały ostrzegawcze
- SLA bez wpływu na usługę. Mierzy dostępność komponentu, ale nie pokazuje, czy pracownik lub mieszkaniec może wykonać czynność.
- Jedna osoba i jeden kanał. Eskalacja zależy od opiekuna i portalu, który może być niedostępny razem z usługą.
- Brak dowodów testu. Dostawca deklaruje możliwość odtworzenia, lecz urząd nie zna czasu, wyniku ani zakresu ostatniej próby.
Materiał ma charakter organizacyjny i edukacyjny. Przed wykorzystaniem w konkretnym postępowaniu lub umowie powinien zostać zweryfikowany przez osoby odpowiedzialne za zamówienia, prawo, bezpieczeństwo, ochronę danych i architekturę danej usługi.
Źródła i data weryfikacji
Stan źródeł zweryfikowano 21 lipca 2026 r. UZP publikuje praktyczne rekomendacje dotyczące działań rozważanych podczas planowania i przygotowania zamówienia na system informatyczny. ENISA wskazuje na technologicznie neutralne wymagania bezpieczeństwa i odporności obejmujące cały cykl życia produktu lub usługi ICT.