Umowa SLA w IT nie powinna ograniczać się do obietnicy, że dostawca „szybko zareaguje” na awarię. Profesjonalny Service Level Agreement przekłada znaczenie systemu dla biznesu na mierzalne parametry dostępności, czasy przywrócenia usług, zasady współpracy podczas cyberincydentu oraz realne konsekwencje niewykonania zobowiązań. Dopiero wtedy SLA staje się narzędziem zarządzania ryzykiem, a nie technicznym załącznikiem, którego strony używają dopiero podczas sporu.
System obsługuje sprzedaż, produkcję albo klientów, lecz umowa nie wyjaśnia, kiedy rozpoczyna się pomiar awarii, co oznacza „naprawa”, kto podejmuje decyzje kryzysowe i czy dostawca musi pomóc przy zgłoszeniu incydentu do CSIRT lub UODO.
Dobre SLA mierzy działanie procesu biznesowego
W praktyce SLA najczęściej jest częścią umowy utrzymaniowej, outsourcingowej, SaaS albo umowy wdrożeniowej. Może stanowić osobny dokument, ale zawsze musi być spójne z zakresem usług, odpowiedzialnością, procedurą zmian, zasadami ochrony danych, prawami do oprogramowania i warunkami zakończenia współpracy.
Każdy parametr powinien mieć definicję, sposób pomiaru, źródło danych, okres rozliczeniowy, dopuszczalne wyłączenia oraz konsekwencję niedotrzymania.
Czym jest SLA i czego powinno chronić?
Service Level Agreement określa uzgodniony poziom świadczenia usług. Z perspektywy prawnej nie wystarczy wpisać do umowy wartości „99,9%” albo „reakcja w 30 minut”. Trzeba wcześniej ustalić, jaka usługa jest mierzona, dla jakich użytkowników, w jakich godzinach oraz z którego punktu infrastruktury.
System może formalnie odpowiadać na zapytania, a jednocześnie nie pozwalać klientowi zakończyć zakupu, pracownikowi wystawić faktury albo magazynowi wydać towaru. Dostępność techniczna serwera nie zawsze oznacza dostępność funkcji biznesowej. Dlatego profesjonalne SLA zaczyna się od katalogu usług i procesów, a dopiero później przechodzi do czasów i procentów.
Co musi działać?
- funkcje krytyczne i zależności między systemami,
- grupy użytkowników oraz lokalizacje objęte usługą,
- godziny biznesowe i systemy wymagające wsparcia 24/7,
- dopuszczalny czas przestoju i utraty danych,
- sezonowe okresy podwyższonej krytyczności.
Co gwarantuje dostawca?
- zakres utrzymania i czynności poza abonamentem,
- parametry jakości oraz sposób ich pomiaru,
- obsadę dyżurów i ścieżkę eskalacji,
- bezpieczeństwo dostępu i współpracę przy incydentach,
- raportowanie, kary, odpowiedzialność i plan wyjścia.
Taki zapis nie gwarantuje czasu, kompetencji ani priorytetu. Jeżeli system jest krytyczny, umowa powinna określać minimalną obsadę, dostępność specjalistów, zastępstwa, dyżury oraz procedurę działania w przypadku równoczesnych awarii u wielu klientów.
Jak zdefiniować mierzalny poziom usług?
W umowie warto rozróżnić trzy poziomy. SLI jest miernikiem, na przykład odsetkiem poprawnie zakończonych transakcji. SLO określa cel dla tego miernika, przykładowo 99,9% poprawnych transakcji w miesiącu. SLA nadaje uzgodnionemu poziomowi znaczenie kontraktowe i określa skutki jego niedotrzymania.
Najwięcej sporów powstaje nie wokół samej wartości, lecz sposobu jej obliczania. Umowa musi określać co najmniej:
- okres rozliczeniowy i strefę czasową,
- punkt pomiaru oraz narzędzie będące źródłem danych,
- częstotliwość próbkowania i regułę zaokrąglania wyników,
- sposób traktowania częściowej degradacji i błędnych transakcji,
- planowane przerwy, awarie zależności i zdarzenia wyłączone z pomiaru,
- procedurę zakwestionowania raportu przygotowanego przez dostawcę.
Ile przestoju dopuszcza dostępność?
Wybierz deklarowany poziom. Kalkulator przyjmuje miesiąc 30-dniowy i rok 365-dniowy.
Wartość nie przesądza, czy SLA jest właściwe. Pięć minut przestoju w systemie sterującym produkcją może być poważniejsze niż kilka godzin niedostępności narzędzia pomocniczego.
Czas reakcji nie jest czasem przywrócenia usługi
Moment zapisany w uzgodnionym kanale, od którego rozpoczyna się pomiar.
Potwierdzenie przyjęcia i faktyczne rozpoczęcie diagnostyki przez właściwy zespół.
Odzyskanie uzgodnionej funkcji biznesowej, nawet jeżeli przyczyna nie została usunięta.
Usunięcie przyczyny i zakończenie działania rozwiązania tymczasowego.
Raport przyczyn źródłowych, wpływu, przebiegu reakcji i działań zapobiegawczych.
Wykonawca zareaguje na awarię krytyczną w ciągu 30 minut.
Umowa określa początek pomiaru, kanał zgłoszenia, rozpoczęcie diagnostyki, czas przywrócenia funkcji, dopuszczalne obejście, termin trwałej naprawy oraz dowód wykonania każdej czynności.
Obejście nie powinno automatycznie zamykać zgłoszenia. Jeżeli rozwiązanie tymczasowe ogranicza funkcjonalność, zwiększa ryzyko bezpieczeństwa albo wymaga dodatkowej pracy użytkowników, umowa powinna wskazywać maksymalny okres jego stosowania i termin trwałej poprawki.
Klasyfikacja błędów i przebieg obsługi zgłoszenia
Priorytet nie powinien zależeć wyłącznie od uznania konsultanta dostawcy. Klasyfikacja musi wynikać z mierzalnego wpływu na proces, liczby użytkowników, dostępności obejścia, ryzyka regulacyjnego i zagrożenia dla bezpieczeństwa. W razie sporu warto przyznać zamawiającemu prawo do tymczasowego nadania wyższego priorytetu, z późniejszą weryfikacją.
| Priorytet | Przykładowy wpływ | Obsługa | Parametry do ustalenia |
|---|---|---|---|
| P1 – krytyczny | Całkowite zatrzymanie kluczowej usługi, cyberatak, utrata kontroli nad kontami uprzywilejowanymi albo ryzyko utraty danych. | Tryb 24/7, nieprzerwane działania do przywrócenia, natychmiastowa eskalacja. | Czas reakcji, przywrócenia, aktualizacji statusu, powiadomienia o incydencie i RCA. |
| P2 – poważny | Znaczna degradacja, niedostępność ważnej funkcji albo wielu użytkowników, przy istniejącym ograniczonym obejściu. | Przyspieszona obsługa i regularne komunikaty do koordynatorów. | Czas reakcji, obejścia, naprawy i częstotliwość raportowania. |
| P3 – standardowy | Ograniczony błąd bez istotnego wpływu na ciągłość procesu, dostępne skuteczne obejście. | Obsługa w godzinach serwisowych według kolejki. | Czas reakcji i rozwiązania albo termin wydania poprawki. |
| P4 – niski | Problem kosmetyczny, pytanie, usprawnienie lub zmiana niemająca charakteru błędu. | Planowany backlog albo odrębna procedura zmian. | Czas odpowiedzi, wyceny i decyzji o realizacji. |
Tabela nie powinna kopiować przypadkowych wartości z innej umowy. Czasy należy powiązać z analizą wpływu na biznes, RTO, możliwościami zespołu i ceną usługi. Deklarowanie P1 w trybie 24/7 nie ma sensu, jeżeli dostawca poza godzinami pracy nie utrzymuje dyżuru specjalisty zdolnego wykonać naprawę.
Kiedy zegar SLA może zostać zatrzymany?
Dostawcy często proponują zawieszenie pomiaru na czas oczekiwania na informacje lub dostęp ze strony klienta. Mechanizm jest uzasadniony, ale powinien działać tylko wtedy, gdy żądana czynność jest rzeczywiście niezbędna, została precyzyjnie opisana i skierowana do właściwej osoby. Zegar nie powinien zatrzymywać się przez ogólne pytanie albo brak odpowiedzi poza godzinami ustalonej dostępności klienta.
System ticketowy jest dowodem, ale nie powinien być jedynym sędzią
Umowa powinna zapewniać obu stronom dostęp do historii zgłoszeń, statusów, czasów i komentarzy, możliwość eksportu danych oraz odpowiednią retencję. Raport wygenerowany jednostronnie przez dostawcę musi podlegać weryfikacji na podstawie monitoringu zamawiającego i uzgodnionej procedury reklamacyjnej.
Cyberbezpieczeństwo, dostęp i współpraca przy incydencie
Usługa utrzymaniowa często zapewnia dostawcy szeroki dostęp do systemów produkcyjnych, logów, konfiguracji i danych. Samo NDA nie reguluje sposobu logowania, nadawania uprawnień ani zachowania dowodów. Umowa powinna łączyć poufność z konkretnymi wymaganiami technicznymi i organizacyjnymi.
Imienne konta, MFA, zasada minimalnych uprawnień, akceptacja dostępu, rejestrowanie sesji i okresowe przeglądy.
Autoryzowany VPN lub bastion, zakaz współdzielenia kont, bezpieczny kanał awaryjny i kontrola transferu plików.
Krótki termin pierwszego powiadomienia, zakres danych, stałe aktualizacje, zachowanie dowodów i wsparcie zgłoszeń.
Terminy oceny podatności, priorytety aktualizacji, testy, awaryjna ścieżka zmian i obowiązek informowania o ryzyku.
Lista dostawców, obowiązek uprzedniej informacji lub zgody, równoważne wymagania i odpowiedzialność wykonawcy.
Zakres logowania, synchronizacja czasu, retencja, integralność, eksport i współpraca z zespołem prowadzącym analizę.
Podmiot objęty UoKSC może mieć 24 godziny na przekazanie wczesnego ostrzeżenia o incydencie poważnym. Dostawca nie może więc zagwarantować sobie kilku dni na poinformowanie klienta. Kontrakt powinien wymagać powiadomienia niezwłocznie, ale nie później niż w konkretnym, krótkim terminie od wykrycia zdarzenia mogącego wpływać na usługę, dane lub klienta.
Pierwszy komunikat nie musi zawierać pełnej analizy. Powinien jednak wskazywać czas wykrycia, systemy objęte zdarzeniem, możliwy wpływ, podjęte działania, aktualne wskaźniki kompromitacji i dane osoby prowadzącej obsługę. Kolejne aktualizacje powinny być przekazywane w ustalonych odstępach aż do opanowania sytuacji.
NDA, RODO i okres poufności
Dziesięcioletni okres poufności może być odpowiedni dla części informacji, ale nie powinien być automatycznie stosowany do każdego rodzaju danych. Tajemnica przedsiębiorstwa powinna być chroniona tak długo, jak zachowuje poufny charakter, a obowiązki dotyczące danych osobowych powinny uwzględniać cel, retencję i polecenia administratora.
Jeżeli wykonawca przetwarza dane osobowe w imieniu zamawiającego, potrzebne są postanowienia zgodne z art. 28 RODO. Powinny regulować między innymi instrukcje administratora, środki bezpieczeństwa, dalszych przetwarzających, pomoc przy naruszeniach i realizacji praw, audyty oraz zwrot lub usunięcie danych po zakończeniu usługi.
Planowane okna ograniczają ryzyko zmian, lecz krytyczna podatność może wymagać działania natychmiastowego. Umowa powinna przewidywać awaryjną ścieżkę wdrożenia poprawki, wymagane testy, osoby zatwierdzające i zasady komunikowania ryzyka.
Kary umowne, limity odpowiedzialności i ubezpieczenie
Mechanizmy finansowe mają skłonić dostawcę do utrzymywania odpowiedniego poziomu usług i ułatwić rozliczenie naruszenia. Nie zastąpią jednak ciągłości działania. Kara odpowiadająca niewielkiej części miesięcznego abonamentu może być dla wykonawcy akceptowalnym kosztem, podczas gdy zamawiający poniesie wielokrotnie większe straty.
Service credit
Obniżenie kolejnej opłaty lub zwrot części abonamentu. Łatwy w rozliczeniu, ale często zbyt niski, aby kompensować rzeczywisty skutek awarii.
Kara umowna
Określona suma za naruszenie zobowiązania niepieniężnego, na przykład przekroczenie czasu przywrócenia lub brak raportu.
Odszkodowanie
Roszczenie o naprawienie szkody. Jeżeli ma przewyższać karę umowną, kontrakt powinien wyraźnie zachować takie uprawnienie.
Kary można powiązać z czasem przekroczenia, priorytetem, liczbą naruszeń albo stopniem niedostępności. Warto określić sposób naliczania, maksymalną wysokość, termin zapłaty i możliwość potrącenia, z uwzględnieniem ustawowych przesłanek potrącenia oraz zapisów umowy.
Kara umowna może zostać zmniejszona przez sąd
Kodeks cywilny pozwala żądać miarkowania kary, gdy zobowiązanie zostało w znacznej części wykonane albo kara jest rażąco wygórowana. Konstrukcja powinna być proporcjonalna do znaczenia obowiązku, czasu naruszenia i potencjalnych skutków.
Jak ocenić limit odpowiedzialności?
Cap odpowiadający wynagrodzeniu z ostatnich 12 miesięcy pojawia się w wielu projektach umów, lecz nie jest uniwersalnym standardem prawnym. Przy systemie krytycznym roczny abonament może pozostawać bez związku z możliwym kosztem przestoju, odtworzenia danych, obsługi incydentu i roszczeń klientów.
Negocjacje powinny obejmować osobne limity albo wyjątki dla:
- szkody wyrządzonej umyślnie, której odpowiedzialności nie można skutecznie wyłączyć,
- rażącego niedbalstwa, jeżeli zamawiający chce wyłączyć je spod capu,
- naruszenia poufności i tajemnicy przedsiębiorstwa,
- naruszeń ochrony danych oraz obowiązków bezpieczeństwa,
- wad prawnych kodu i roszczeń osób trzecich,
- kosztów reakcji na incydent, odtworzenia i wymaganych zawiadomień.
Warto również zweryfikować polisę OC zawodowego i cyber wykonawcy: sumę ubezpieczenia, zakres terytorialny, udział własny, wyłączenia dotyczące podwykonawców, ransomware, danych i kar oraz obowiązek utrzymywania ochrony przez cały okres umowy.
Prawa do kodu, dane i bezpieczne zakończenie współpracy
Poprawki, skrypty, konfiguracje, dokumentacja i nowe moduły mogą stanowić utwory chronione prawem autorskim. Samo opłacenie prac nie przenosi praw. Umowa powinna określić, czy zamawiający nabywa autorskie prawa majątkowe, czy otrzymuje licencję oraz kiedy i na jakich polach może korzystać z rezultatów.
W przypadku licencji należy zadbać o możliwość:
- korzystania z poprawek bez ograniczenia do czasu obowiązywania SLA,
- zwielokrotniania, instalowania, uruchamiania i archiwizacji oprogramowania,
- wprowadzania zmian i wykonywania praw zależnych w niezbędnym zakresie,
- udostępnienia kodu i dokumentacji kolejnemu dostawcy utrzymania,
- udzielania sublicencji podmiotom z grupy lub partnerom technicznym,
- korzystania na wymaganym terytorium i przez odpowiednio długi czas.
Open Source i bezpieczeństwo łańcucha oprogramowania
Ogólne zapewnienie, że wykonawca „może korzystać z Open Source”, jest niewystarczające. Zamawiający powinien otrzymać wykaz komponentów i licencji, informację o ograniczeniach copyleft, zasady zatwierdzania nowych bibliotek oraz obowiązek usunięcia naruszenia licencji. Dla systemów o podwyższonym ryzyku warto wymagać aktualnego SBOM oraz informacji o podatnościach komponentów.
Exit plan powinien powstać przed rozpoczęciem usługi
Najlepszy moment na ustalenie zasad migracji przypada przed podpisaniem umowy, gdy zamawiający ma jeszcze siłę negocjacyjną. Plan wyjścia powinien określać:
- format i termin eksportu danych, konfiguracji, logów i dokumentacji,
- przekazanie repozytoriów, kluczy, kont, haseł oraz listy zależności,
- okres i stawki wsparcia przejściowego dla nowego dostawcy,
- ciągłość usługi podczas migracji i zakaz nieuzasadnionego wstrzymania danych,
- usunięcie pozostałych kopii oraz przekazanie potwierdzenia usunięcia,
- odebranie dostępów personelowi i podwykonawcom po zakończeniu współpracy.
Bez wskazania formatu, kompletności, terminu i kosztu zamawiający może otrzymać zbiór, którego nie da się wykorzystać u kolejnego wykonawcy. Odbiór eksportu powinien podlegać testowi kompletności i możliwości odtworzenia.
Checklista przed podpisaniem umowy SLA
Zaznacz elementy, które zostały precyzyjnie opisane w projekcie umowy. Wynik nie zastępuje audytu prawnego i technicznego, ale szybko pokazuje, czy dokument obejmuje cały cykl utrzymania usługi.
Parametry trzeba testować przed podpisaniem
Warto przeprowadzić symulację awarii: zgłosić przykładowe P1, sprawdzić listę kontaktów, dostęp do narzędzia ticketowego, raport pomiarowy i możliwość eskalacji. Test szybko ujawnia, czy zapis jest wykonalny operacyjnie.
FAQ: umowa SLA w IT
Czy SLA musi być osobną umową?
Nie. SLA najczęściej stanowi załącznik do umowy utrzymaniowej, outsourcingowej, wdrożeniowej albo SaaS. Ważne, aby hierarchia dokumentów była jednoznaczna i wskazywała, które postanowienie ma pierwszeństwo w razie sprzeczności.
Czy dostępność 99,9% jest wystarczająca?
Zależy od skutków przestoju i sposobu pomiaru. Poziom 99,9% pozwala na około 43 minuty i 12 sekund niedostępności w miesiącu 30-dniowym. Dla systemu pomocniczego może być odpowiedni, a dla usługi krytycznej zdecydowanie zbyt niski.
Czym service credit różni się od kary umownej?
Service credit jest kontraktowym obniżeniem opłaty lub kredytem na kolejną fakturę. Kara umowna jest instytucją Kodeksu cywilnego zabezpieczającą wykonanie zobowiązania niepieniężnego. Umowa powinna określić wzajemną relację obu mechanizmów i wpływ na możliwość dochodzenia odszkodowania.
Czy dostawca może zatrzymać zegar SLA, gdy czeka na klienta?
Może to zostać uzgodnione, ale przesłanki powinny być konkretne. Zatrzymanie jest zasadne, gdy brak określonej informacji, decyzji lub dostępu rzeczywiście uniemożliwia dalsze działania. Nie powinno następować automatycznie po każdym pytaniu dostawcy.
Czy umowa powierzenia danych zastępuje klauzule cyberbezpieczeństwa?
Nie. Umowa zgodna z art. 28 RODO dotyczy przetwarzania danych osobowych. SLA powinno dodatkowo regulować bezpieczeństwo całej usługi, ciągłość, dostęp serwisowy, podatności, logi, reakcję na incydent oraz ochronę innych informacji i systemów.
Czy kary umowne wyłączają możliwość dochodzenia większej szkody?
Co do zasady żądanie odszkodowania przewyższającego karę nie jest dopuszczalne, chyba że strony postanowią inaczej. Jeżeli zamawiający chce zachować takie prawo, powinno ono zostać wyraźnie wpisane do umowy.
Sprawdź SLA, zanim pierwsza awaria sprawdzi je za Ciebie
Podczas bezpłatnej konsultacji możesz omówić projekt umowy, krytyczność utrzymywanego systemu, czasy reakcji i przywrócenia, odpowiedzialność dostawcy oraz wymagania cyberbezpieczeństwa. Kolejnym krokiem może być audyt obecnego SLA, przygotowanie listy zmian negocjacyjnych albo opracowanie kompletnej umowy utrzymaniowej.