Umowa SLA – czym jest Service Level Agreement i co powinna zawierać

Wdrożenie systemu IT nie kończy współpracy z dostawcą. System może przestać działać, jego wydajność może spaść, a użytkownicy mogą potrzebować pomocy technicznej. W takich sytuacjach dla klienta nabywającego oprogramowanie kluczowe staje się nie tylko to, czy dostawca usunie awarię, ale również jak szybko powinien zareagować i przywrócić prawidłowe działanie systemu. Brak takich ustaleń często prowadzi do sporu z dostawcą. Dla klienta „pilna awaria” może oznaczać konieczność przywrócenia działania systemu w ciągu godziny, podczas gdy dostawca może uważać, że wystarczająca będzie reakcja następnego dnia roboczego. Właśnie takim problemom ma zapobiegać SLA.

Umowa SLA – co to jest?

SLA (Service Level Agreement) to umowa o gwarantowanym poziomie świadczenia usług, zawierana między dostawcą usług a ich odbiorcą. Najczęściej dotyczy usług IT świadczonych po wdrożeniu systemu, choć SLA występuje również m.in. przy usługach chmurowych, hostingowych, telekomunikacyjnych czy outsourcingowych.

Głównym celem umowy SLA jest uregulowanie, w możliwie mierzalny sposób, wymaganego poziomu należytej staranności świadczenia usług związanych z korzystaniem z oprogramowania (określenie, jakie parametry usługi muszą być spełnione, w jakim czasie i z jaką jakością). Dobrze przygotowana umowa SLA pozwala z góry ustalić m.in. dostępność systemu, zasady monitoringu systemu, kategoryzację błędów i sposób ich zgłaszania, czas reakcji i naprawy oraz konsekwencje niedotrzymania tych parametrów.

SLA najczęściej nie jest odrębną umową, lecz stanowi element składowy innej umowy, np. wdrożeniowej, serwisowej, umowy dotyczącej korzystania z oprogramowania w chmurze obliczeniowej, czy to w formie bezpośrednich postanowień zawartych w umowie czy w formie załącznika do niej.

Warto zwrócić uwagę, że w przestrzeni – także prawnej – często nakładają się, a nawet bywają używane zamiennie pojęcia SLA oraz umowa serwisowa / utrzymaniowa. Tymczasem mimo tego, że te pojęcia są ze sobą mocno związane, to jednak nie są to synonimy, umowa SLA to nie jest to samo, co umowa utrzymaniowa. Umowa SLA może być częścią umowy serwisowej, jednak umowa serwisowa jest pojęciem szerszym. Umowa serwisowa określa ogólny zakres usług serwisowych, takich jak naprawy, aktualizacje oprogramowania, helpdesk i wsparcie użytkowników, wykonywanie kopii zapasowych, konsultacje techniczne, podczas gdy umowa SLA precyzuje konkretne parametry jakości świadczonych usług – czas reakcji, czas naprawy, dostępność systemu, jego wydajność. 

Charakter prawny umowy SLA w polskim prawie

Kodeks cywilny nie przewiduje odrębnego typu umowy określanego jako „umowa SLA”. Co do zasady jest to więc umowa nienazwana, której treść strony mogą ukształtować w ramach zasady swobody umów wynikającej z art. 353¹ KC. Przepis ten pozwala przedsiębiorcom samodzielnie określić treść łączącego ich stosunku prawnego, o ile nie sprzeciwia się ona właściwości stosunku, ustawie ani zasadom współżycia społecznego.

Nie oznacza to jednak, że do SLA nie stosuje się przepisów KC. W zależności od zakresu współpracy umowa może zawierać elementy charakterystyczne dla różnych typów umów uregulowanych w KC.

Jeżeli podstawowym obowiązkiem dostawcy jest stałe utrzymywanie systemu, monitoring, helpdesk czy reagowanie na zgłoszenia, mamy zazwyczaj do czynienia przede wszystkim ze świadczeniem usług. Zgodnie z art. 750 KC do umów o świadczenie usług, które nie są uregulowane innymi przepisami, stosuje się odpowiednio przepisy o zleceniu.

Nie przesądzając, że każda umowa SLA będzie mieć charakter umowy o świadczenie usług, należy podkreślić, że odpowiednia kwalifikacja prawna umowy może mieć znaczenie m.in. dla zasad wypowiedzenia umowy, odpowiedzialności stron czy terminów przedawnienia poszczególnych roszczeń. Zawsze należy więc patrzeć na umowę jako całość, a nie kierować się wyłącznie jej nazwą. 

Prawa autorskie do rezultatów prac serwisowych

W trakcie świadczenia usług SLA może dojść do modyfikacji  kodu źródłowego oprogramowania, a rezultat takiego działania może stanowić utwór chroniony przepisami ustawy o prawie autorskim i prawach pokrewnych.

Należy pamiętać, że sama zapłata wynagrodzenia należnego dostawcy  za wykonanie usług wchodzących w zakres SLA nie powoduje automatycznego przejścia autorskich praw majątkowych na klienta. Jeżeli klient ma uzyskać prawa do nowopowstałego rozwiązania, umowa powinna odpowiednio regulować ich przeniesienie albo udzielenie licencji.

W przypadku przeniesienia autorskich praw majątkowych konieczne jest wskazanie pól eksploatacji, których przeniesienie dotyczy. Jeżeli strony wybierają model licencyjny, warto ustalić m.in. zakres licencji, pola eksploatacji, na których dozwolone będzie korzystanie z powstałego utworu, możliwość dokonywania modyfikacji oraz korzystania z rozwiązania przez inne podmioty.

Brak odpowiednich postanowień na temat praw autorskich w umowie SLA może prowadzić do sytuacji, w której przedsiębiorca finansuje utrzymanie swojego systemu, ale nie dysponuje prawami pozwalającymi mu swobodnie korzystać z rezultatów tych usług.

Rodzaje umów SLA

SLA może być skonstruowana na kilka sposobów. Wybór modelu powinien zależeć przede wszystkim od potrzeb klienta, a także charakteru świadczonych usług i stopnia ich standaryzacji.

Customer-based SLA jest przygotowywana dla konkretnego klienta i obejmuje wszystkie lub wybrane usługi świadczone właśnie na jego rzecz. Takie rozwiązanie pozwala dostosować parametry do znaczenia systemu dla działalności konkretnego przedsiębiorstwa.

Service-based SLA odnosi się do określonej usługi świadczonej na takich samych lub bardzo podobnych zasadach na rzecz wielu klientów. Model ten jest często stosowany przy usługach standaryzowanych.

Multilevel SLA, czyli SLA wielopoziomowa, dzieli wymagania SLA na kilka poziomów, dopasowując je do konkretnych grup klientów, działów w firmie lub różnych rodzajów usług. Najczęściej umowa taka dzieli się na poziom korporacyjny, poziom klienta i poziom usługi. Przykładowo w obrębie jednej firmy poziom korporacyjny może zawierać zasady wspólne dla całej organizacji, poziom usługi – wymagania dotyczące parametrów określonej usługi, a poziom klienta– indywidualne parametry usługi dopasowane do grupy odbiorców w firmie, np. konkretnego działu firmy.

Uogólniając można powiedzieć, że im bardziej krytyczny oraz indywidualnie dostosowany do potrzeb konkretnej organizacji system IT, tym większe znaczenie w umowie SLA ma odejście od standardowych warunków SLA oferowanych przez dostawcę na rzecz SLA odpowiadającej rzeczywistym potrzebom przedsiębiorcy.

Co powinna zawierać umowa SLA?

Dobrze skonstruowana umowa SLA powinna przede wszystkim odpowiadać na proste pytanie: co dokładnie wydarzy się od chwili wystąpienia problemu aż do jego rozwiązania?

Umowa powinna regulować co najmniej:

• przedmiot i zakres usług;
• godziny i dni świadczenia wsparcia;
• sposób zgłaszania błędów;
• kategorie błędów;
• czas reakcji;
• czas naprawy albo obejścia problemu;
• wymagany poziom dostępności systemu;
• zasady monitorowania parametrów systemu;
• procedurę eskalacji;
• zasady korzystania z podwykonawców;
• obowiązki klienta niezbędne do wykonania usług;
• raportowanie realizacji SLA;
• wynagrodzenie;
• odpowiedzialność stron i kary umowne;
• zasady wykonywania backupów, jeżeli wchodzą w zakres usług;
• okres obowiązywania i zasady zakończenia współpracy;
• wskazanie sytuacji, w których  SLA nie obowiązuje.

Ostatni punkt ma duże znaczenie praktyczne. Należy jasno określić sytuacje, w których czas reakcji lub naprawy zostaje wstrzymany albo dana niedostępność nie jest uwzględniana przy obliczaniu parametrów SLA. Może to dotyczyć np. wcześniej uzgodnionego okna serwisowego, awarii infrastruktury pozostającej po stronie klienta czy działania siły wyższej.

Wyłączenia nie powinny jednak być sformułowane tak szeroko, aby dostawca mógł powoływać się na nie przy niemal każdej awarii. W takim przypadku gwarantowany poziom usług pozostawałby jedynie deklaracją.

Kategorie błędów, czas reakcji i czas naprawy

Jednym z najważniejszych elementów SLA jest klasyfikacja błędów. Nie każda usterka uzasadnia bowiem taką samą reakcję dostawcy.

Najczęściej stosuje się trzy podstawowe kategorie:

Kategoria	Przykładowa sytuacja	Przykładowy czas reakcji	Przykładowy czas naprawy
Błąd krytyczny	system nie działa albo niedostępna jest jego kluczowa funkcja i brak rozwiązania zastępczego (np. w sklepie internetowym nie działa przycisk płatności w koszyku)	30–60 minut	4–8 godzin
Błąd poważny	istotna funkcja działa nieprawidłowo, ale możliwe jest dalsze korzystanie z systemu (np. błędnie wyświetlana grafika produktu w sklepie internetowym)	2–4 godziny	1–2 dni robocze
Usterka	problem wpływa na komfort korzystania z systemu, ale nie ma charakteru błędu (np. strona sklepu wolniej się ładuje)	1 dzień roboczy	3–5 dni roboczych

Są to jedynie przykładowe parametry, a nie wartości wymagane przez przepisy. Właściwe czasy reakcji i czasy naprawy powinny zawsze wynikać ze specyfiki danego oprogramowania i jego znaczenia dla działalności klienta. System obsługujący płatności internetowe może wymagać zupełnie innych parametrów niż wewnętrzne narzędzie wykorzystywane sporadycznie przez kilka osób.

Kluczowe jest również rozróżnienie czasu reakcji od czasu naprawy.

Czas reakcji oznacza okres od prawidłowego zgłoszenia błędu do podjęcia przez dostawcę działań związanych z przystąpieniem przez dostawcę do określonych w umowie działań związanych z usunięciem problemu – np. potwierdzenia zgłoszenia i rozpoczęcia diagnozy problemu.

Czas naprawy oznacza natomiast okres, w którym problem powinien zostać rzeczywiście usunięty albo – jeżeli strony tak ustalą – powinno zostać wdrożone skuteczne rozwiązanie zastępcze.

Umowa SLA, która przewiduje jedynie „czas reakcji: 30 minut” to źle skonstruowana umowa, która może dawać klientowi jedynie pozorne poczucie bezpieczeństwa. W przypadku takiego brzmienia umowy dostawca może zareagować po 20 minutach (np. przyjmując zgłoszenie), ale samą awarię usuwać przez kolejne dwa dni. Należy więc pamiętać, aby oba parametry – czas reakcji i czas naprawy – zostały określone oddzielnie.

Należy również zwrócić uwagę na postanowienia umowy SLA, które wskazują czy czas reakcji jest wliczany do czasu naprawy, czy też nie – bowiem ma to realny wpływ na skrócenie albo wydłużenie terminów wyznaczanych dostawcy.

Ponadto w umowie SLA równie ważne jak właściwe skategoryzowanie błędów jest wyczerpujące opisanie procedury zgłaszania błędów – tzn. tego, kto może zgłaszać błędy, w jaki sposób, co się dzieje, jeśli jeden z kanałów komunikacji zawiedzie, jakie dane należy podać w trakcie zgłoszenia, czy sam klient dokonuje klasyfikacji zgłoszenia, czy klasyfikacja przyjęta przez klienta może zostać zmieniona przez dostawcę po analizie zgłoszenia, zasady zamknięcia zgłoszenia – czyli informacja co do tego, jak rozwiązano problem, tzw. procedury eskalacji, czyli przeniesienia zgłoszenia na wyższy poziom wsparcia, kiedy problem nie zostaje rozwiązany w określonym czasie zgodnym z SLA.

Gwarancja dostępności w SLA

Jednym z najbardziej charakterystycznych parametrów SLA jest tzw. uptime, czyli gwarantowany poziom dostępności systemu.

Dostępność może być określona np. na poziomie 99,9% w skali miesiąca. Sama wartość procentowa jest jednak mało intuicyjna. Dopiero jej przeliczenie pokazuje, na jaki przestój strony faktycznie się godzą.

W przybliżeniu, przy miesiącu liczącym 30,4 dnia:

Gwarantowana dostępność	Dopuszczalna niedostępność miesięcznie
99%	ok. 7,3 godziny
99,9%	ok. 43 minuty
99,99%	ok. 4,3 minuty

Różnica między 99% a 99,99% może wyglądać niepozornie w zapisie umownym, ale biznesowo oznacza przejście od ponad siedmiu godzin dopuszczalnego przestoju do zaledwie kilku minut.

Sama liczba również nie wystarczy. Umowa powinna wskazywać wzór obliczania dostępności oraz okres, dla którego jest ona liczona. Wynik 99,9% w skali miesiąca ma bowiem zupełnie inne znaczenie niż ten sam poziom liczony w skali całego roku.

Należy też wskazać, które okresy nie są traktowane jako niedostępność. Najczęściej będą to wcześniej zaakceptowane przez klienta okna serwisowe, problemy wynikające z infrastruktury zamawiającego albo przypadki siły wyższej.

Z perspektywy klienta szczególnie ważne jest sprawdzenie, czy katalog wyłączeń nie powoduje, że formalnie wysoki poziom uptime przestaje odpowiadać rzeczywistej dostępności systemu.

Raportowanie i monitorowanie

Bardzo istotną, a w praktyce czasem pomijaną kwestią jest ta, czy w umowie SLA zapisano zasady nt. raportowania i monitorowania systemu przez dostawcę. Warto zatem poszukać w umowie odpowiedzi na następujące pytania: Czy klient otrzymuje raporty SLA? Jak często (np. miesięcznie, kwartalnie)? Czy dostępne są statystyki w czasie rzeczywistym? Czy klient ma dostęp do portalu monitorującego?

Nawet bowiem najbardziej szczegółowe opisanie wskaźników dotyczących poziomu usług nie spełni swojej roli, jeśli zamawiający nie nałoży na dostawcę odpowiednich obowiązków w zakresie monitorowania oraz raportowania spełnienia uzgodnionych poziomów świadczenia usługi. Klient musi wiedzieć, gdzie są problemy, aby móc dokonać analizy sytuacji i wprowadzić procesy optymalizacyjne. Przykładowo, bez raportów SLA zawierających dane o dostępności aplikacji SaaS właściciel sklepu internetowego nie będzie wiedział, że w godzinach szczytu system działa 10x wolniej.

Wskaźniki SLA – SLI, SLO i KPI

W dokumentacji technicznej systemu obok akronimu SLA (który – jak już wskazano wyżej – oznacza umowę o gwarantowanym poziomie usług) często pojawiają się zwroty  SLI, SLO i KPI. Choć są ze sobą powiązane, nie oznaczają tego samego.

SLI (Service Level Indicator) to wskaźnik poziomu usług, czyli konkretny mierzony parametr. Może nim być np. procent dostępności systemu w skali miesiąca albo średni czas odpowiedzi aplikacji.

SLO (Service Level Objective) określa cel dotyczący danego parametru, np. umowne ustalenie pomiędzy stronami, że dostępność systemu będzie  wynosić 99,95% w skali miesiąca.

KPI (Key Performance Indicator) to kluczowy wskaźnik efektywności, czyli wyznaczana przez osoby zarządzające przedsiębiorstwem miara sukcesu biznesowego i operacyjnego organizacji (np. liczba obsłużonych zgłoszeń reklamacyjnych).

SLI, SLO i KPI są przenoszone w umowie SLA na poziom zobowiązania umownego dostawcy wobec klienta, zaś ich niedotrzymanie powinno wiązać się z konkretnymi konsekwencjami. Niezależnie od tego, o jakim parametrze SLA mówimy, podstawową zasadą powinna tutaj być zasada mierzalności: każdy parametr SLA powinien być tak określony, aby był możliwy do obiektywnego zmierzenia. Sformułowania w umowie SLA takie jak „dostawca niezwłocznie podejmie działania” albo „dostawca zapewni wysoką dostępność systemu” brzmią na pierwszy rzut oka korzystnie dla klienta, ale w przypadku zaistnienia problemu trudno będzie jednoznacznie ustalić, czy obowiązek został przez dostawcę wykonany prawidłowo, co często prowadzi do niepotrzebnego i kosztownego sporu klienta z dostawcą, nierzadko sądowego.

Kary umowne i odpowiedzialność w umowie SLA

Właściwe opisanie parametrów SLA, a także określenie towarzyszących im obowiązków dostawcy to połowa sukcesu. Co jednak w przypadku, gdy dostawca nie dotrzyma uzgodnionego poziomu świadczenia usług?

W dobrze skonstruowanej umowie SLA parametry usług  powinny być ściśle powiązane z konsekwencjami ich niedotrzymania. W przeciwnym razie klient może mieć precyzyjnie określony czas reakcji lub dostępność, ale niewiele narzędzi na wypadek ich regularnego naruszania.

Jednym z rozwiązań są tutaj oczywiście kary umowne. Zgodnie z art. 483 § 1 KC można zastrzec karę umowną na wypadek niewykonania lub nienależytego wykonania zobowiązania niepieniężnego. W SLA kara może więc zostać powiązana np. z przekroczeniem uzgodnionego czasu usunięcia awarii albo niezachowaniem określonego poziomu dostępności.

Należy pamiętać, że w przypadku dochodzenia zastrzeżonych w umowie SLA kar umownych konieczne jest podjęcie czynności bezpośrednio przez zamawiającego / klienta – ich wyliczenie i naliczenie leży właśnie po jego stronie.

Innym rozwiązaniem stosowanym w praktyce umów IT są tzw. service credits, czasem zwane również tokenami. Polegają one na przyznaniu klientowi określonego rabatu odliczanego od wynagrodzenia należnego dostawcy, która uwzględniana jest przez dostawcę automatycznie przy wystawianiu kolejnej faktury. Niekiedy kredyty przybierają formę swego rodzaju „waluty dostawcy”, która jest sukcesywnie naliczana w toku obowiązywania umowy, a po jej zgromadzeniu w danym okresie rozliczeniowym zamawiający ma za jej pośrednictwem możliwość dokupienia dodatkowych określonych usług od dostawcy.

Niezależnie od wybranego rozwiązania trzeba również sprawdzić w warunkach umownych proponowanych przez dostawcę, czy service credits albo kary umowne są jedynym środkiem przysługującym klientowi, czy może on również dochodzić odszkodowania przewyższającego ich wysokość. Ma to znaczenie w świetle art. 484 § 1 KC, zgodnie z którym żądanie odszkodowania ponad zastrzeżoną karę nie jest dopuszczalne, chyba że strony postanowiły inaczej.

Umowy SLA często przewidują również limit odpowiedzialności (liability cap) dostawcy, np. do wysokości wynagrodzenia umownego zapłaconego przez klienta w ostatnich 12 miesiącach, oraz ograniczenie odpowiedzialności za utracone korzyści. Zgodnie z art. 473 § 2 KC niedopuszczalne jest jednak wyłączenie odpowiedzialności za szkodę wyrządzoną umyślnie.

Dlatego klauzula odpowiedzialności dostawcy powinna być analizowana jako cały system: kary umowne, service credits, odszkodowanie, limit odpowiedzialności i przewidziane w umowie wyłączenia muszą być ze sobą spójne.

Umowa SLA a gwarancja i rękojmia

Jeżeli ten sam dostawca najpierw wdraża system, a następnie świadczy usługi jego utrzymania, może powstać praktyczny problem: czy dana wada powinna zostać usunięta w ramach gwarancji lub rękojmi, czy odpłatnego SLA?

Ma to szczególne znaczenie dla klienta. Bez odpowiednich postanowień w umowie może dojść do sytuacji, w której dostawca próbuje zakwalifikować jako odpłatną usługę serwisową usunięcie problemu wynikającego z wadliwego wdrożenia.

Rękojmia jest ustawowym reżimem odpowiedzialności za wady, uregulowanym przede wszystkim w art. 556 i nast. KC w odniesieniu do sprzedaży, przy czym jej zastosowanie do konkretnej umowy IT zależy od konstrukcji prawnej danego kontraktu. Gwarancja jakości jest natomiast odrębnym źródłem uprawnień, którego zakres wynika przede wszystkim z treści oświadczenia gwarancyjnego (art. 577 i nast. KC).

W praktyce relację między tymi mechanizmami a SLA można uregulować m.in. poprzez:

1. zdefiniowanie i rozdzielenie wad zaistniałych w procesie wdrażania oprogramowania od wad usług utrzymaniowych;
2. przypisanie poszczególnych kategorii problemów do gwarancji albo SLA;
3. równoległe funkcjonowanie obu mechanizmów, przy czym SLA zapewnia krótsze terminy reakcji;
4. odpowiednie powiązanie okresów rękojmi / gwarancji i utrzymania systemu.

Najważniejsze jest jednoznaczne określenie, które działania są wykonywane w ramach wynagrodzenia za SLA, a które dostawca ma obowiązek wykonać bez dodatkowych kosztów z uwagi na odpowiedzialność za przeprowadzone wdrożenie.

Umowa SLA a RODO, DORA i NIS2

Umowa SLA nie powinna być analizowana wyłącznie przez pryzmat parametrów określających poziom usług takich jak dostępność systemu czy czas reakcji / czas naprawy. Istotne jest również to, że umowa SLA często dotyczy obszaru związanego z bezpieczeństwem danych, w tym danych osobowych. W obszarze tym bardzo często występują liczne wymogi prawne bądź regulacyjne, a także funkcjonują standardy branżowe. Dobrze skonstruowana umowa SLA powinna wspierać proces osiągnięcia zgodności z przepisami oraz standardami, a w przypadku kontroli czy audytu ze strony uprawnionego organu może stanowić dowód zachowania należytej staranności przez przedsiębiorcę. 

SLA a RODO

Jeżeli w ramach świadczenia usług dostawca uzyskuje w imieniu klienta dostęp do danych osobowych i dochodzi do powierzenia dostawcy ich przetwarzania, konieczne jest odpowiednie uregulowanie tego procesu zgodnie z przepisami RODO.

W myśl art. 28 ust. 3 RODO przetwarzanie danych osobowych przez podmiot przetwarzający powinno być uregulowane umową lub innym instrumentem prawnym, który określa m.in. przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych osobowych oraz obowiązki i prawa administratora.

W praktyce często załącznikiem do umowy SLA, lub głównej umowy IT – np. umowy wdrożeniowej, jest umowa powierzenia przetwarzania danych osobowych (DPA) . Warto zaznaczyć, że umowa taka powinna regulować także korzystanie przez dostawcę z dalszych podmiotów przetwarzających. Zgodnie bowiem z art. 28 ust. 2 RODO konieczne jest uzyskanie uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora na korzystanie z innego podmiotu przetwarzającego.

SLA a DORA

Dodatkowe wymagania w stosunku do treści SLA pojawiają się w przypadku podmiotów sektora finansowego objętych rozporządzeniem DORA – Digital Operational Resilience Act (rozporządzenie (UE) 2022/2554).

DORA szczegółowo reguluje zasady zarządzania przez podmioty objęte rozporządzeniem ryzykiem związanym z zewnętrznymi dostawcami usług ICT. Zgodnie z art. 28 DORA podmioty finansowe mają obowiązek zarządzać takim ryzykiem jako integralną częścią swojego systemu zarządzania ryzykiem ICT.

Szczególnie istotny jest tu art. 30 DORA. Wymaga on, aby prawa i obowiązki podmiotu finansowego oraz zewnętrznego dostawcy ICT zostały jasno określone na piśmie, a całość ustaleń umownych obejmowała klauzule dotyczące gwarantowanego poziomu usług. Przepis wskazuje także katalog elementów, które powinny znaleźć się w umowach dotyczących usług ICT.

Oznacza to, że dla przedsiębiorców działających w sektorze finansowym SLA może stanowić nie tylko narzędzie biznesowe, ale również element szerszego systemu zgodności regulacyjnej.

SLA a NIS2

Znaczenie umów z dostawcami IT zwiększa również dyrektywa NIS2 (dyrektywa (UE) 2022/2555).

Art. 21 ust. 2 lit. d dyrektywy wskazuje na konieczność zachowania przez zdefiniowane w dyrektywie podmioty kluczowe i ważne bezpieczeństwa łańcucha dostaw, co stanowić ma jeden ze środków zarządzania ryzykiem w cyberbezpieczeństwie.

W motywie 85 dyrektywy NIS2 podkreślono ponadto znaczenie oceny przez podmioty kluczowe i ważne jakości i odporności produktów oraz usług dostawców tych produktów i usług, a także stosowanych przez nich środków w zakresie cyberbezpieczeństwa.

W praktyce oznacza to, że przy negocjowaniu umowy z dostawcą IT warto uwzględnić nie tylko wskaźniki określające poziom usług, ale również m.in. wymagania bezpieczeństwa, zasady obsługi incydentów, korzystania z podwykonawców oraz stosowne obowiązki informacyjne.

Najczęstsze błędy w umowach SLA

Największym problemem SLA nie jest zazwyczaj brak rozbudowanych postanowień, lecz ich pozorna precyzja.

Do najczęstszych błędów należą:

• stosowanie określeń „niezwłocznie”, „możliwie szybko” albo „w rozsądnym terminie” zamiast konkretnych parametrów;
• brak jasnej klasyfikacji błędów;
• pozostawienie dostawcy pełnej swobody w klasyfikowaniu zgłoszeń;
• określenie czasu reakcji bez czasu naprawy;
• brak wskazania, czy terminy liczone są w godzinach zegarowych czy roboczych;
• wsparcie „24/7” bez określenia kanału umożliwiającego faktyczne zgłoszenie awarii poza godzinami pracy;
• brak procedury eskalacji;
• brak konsekwencji niedotrzymania SLA;
• brak obowiązku raportowania;
• zbyt szerokie wyłączenia odpowiedzialności dostawcy;
• brak określenia sposobu pomiaru dostępności;
• brak precyzyjnej formy rekompensaty i procedury ubiegania się o nią w przypadku zaistnienia problemów z usługą;
• brak jasności w zakresie odpowiedzialności stron (brak podziału odpowiedzialności za np. infrastrukturę klienta, błędy użytkownika, konfigurację);
• brak wyłączeń i ograniczeń;
• brak uregulowania relacji SLA z gwarancją i umową wdrożeniową.

Przykładowo zapis „dostawca usunie awarię niezwłocznie” może wyglądać prawidłowo, dopóki strony nie zaczną spierać się, czy „niezwłocznie” oznacza dwie godziny, jeden dzień czy kilka dni.

Znacznie bezpieczniej określić, że np. dla błędu krytycznego dostawca rozpoczyna działania w ciągu 30 minut od prawidłowego zgłoszenia i przywraca działanie systemu w ciągu czterech godzin.

Jak negocjować umowę SLA i czy korzystać z gotowych wzorów?

SLA najlepiej negocjować równolegle z umową wdrożeniową, a nie dopiero po uruchomieniu systemu.

Już na etapie negocjacji wdrożenia wiadomo bowiem, które funkcjonalności są krytyczne dla działalności przedsiębiorcy i jak poważne konsekwencje może spowodować ich niedostępność. Jednocześnie można określić moment rozpoczęcia świadczenia usług SLA, np. od formalnego odbioru produkcyjnego systemu.

Przy bardziej złożonych projektach warto, aby w negocjacjach uczestniczyły zarówno osoby odpowiedzialne za kwestie prawne, jak i techniczne. Prawnik może ocenić konsekwencje postanowień umowy, ale to CTO, administrator systemu lub inna osoba techniczna najlepiej oceni, czy określony czas reakcji, sposób eskalacji lub poziom dostępności odpowiada rzeczywistym potrzebom przedsiębiorstwa.

Gotowy wzór umowy SLA może być pomocny jako punkt wyjścia, ale rzadko powinien być podpisywany bez dostosowania.

SLA dla sklepu internetowego obsługującego tysiące transakcji dziennie powinno wyglądać inaczej niż SLA dotyczące wewnętrznego systemu wykorzystywanego przez kilkunastu pracowników. Inne będą dopuszczalne przestoje, tryb awaryjny, potrzeba wsparcia 24/7 czy konsekwencje niewykonania usługi.

Dlatego parametry SLA powinny wynikać przede wszystkim z odpowiedzi na pytanie: co dla działalności przedsiębiorstwa oznacza godzina, cztery godziny albo jeden dzień niedostępności danego systemu?

Poniżej najważniejsze zasady dotyczące negocjowania SLA mające na celu zbudowanie dobrej współpracy z dostawcą:

• Zdefiniuj kluczowe procesy biznesowe i określ, które systemy wymagają najwyższego poziomu SLA – prawdopodobnie nie wszystko musi działać w systemie 24/7;
• Segmentuj SLA – wprowadź różne poziomy SLA dla różnych typów usług lub systemów (np. „złoty”, „srebrny”, „brązowy”);
• Zaudytuj dostawcę – poproś o dane historyczne SLA, referencje i audyty jakości usług;
• Zadbaj o mierzalność wskaźników poziomu usług, ale i o marginesy tolerancji – nie wymagaj od dostawcy 100% perfekcji, np. zapisz w umowie, że dopuszczalne jest niewielkie (np. 0,1%) przekroczenie czasu reakcji bez kary umownej;
• Zadbaj o postanowienia w umowie nt. okresowych przeglądów i renegocjacji SLA (np. co 6 czy 12 miesięcy);
• Zadbaj o to, aby przewidziane w umowie kary umowne za niedotrzymanie parametrów SLA były proporcjonalne, ale nie drakońskie;
• Negocjuj „z głową” – np. jeśli oczekujesz dostępności systemu na poziomie 99,99%, ale dostawca może zagwarantować tylko 99,9%, natomiast w zamian oferuje krótszy czas reakcji na awarie krytyczne, dedykowaną osobę kontaktową i priorytetowe wsparcie w godzinach szczytu zastanów się, które rozwiązanie bardziej zabezpieczy Twoje rzeczywiste potrzeby biznesowe.

FAQ – najczęściej zadawane pytania

Co to jest SLA i co oznacza ten skrót?

SLA (Service Level Agreement) oznacza umowę o gwarantowanym poziomie świadczenia usług. W praktyce umów IT reguluje ona m.in. dostępność systemu, czas reakcji na awarie, czas ich usunięcia, sposób zgłaszania problemów i odpowiedzialność dostawcy.

Czym różni się SLA od SLO i SLI?

SLI to mierzony parametr, np. rzeczywista dostępność systemu. SLO określa zakładany poziom tego parametru, np. dostępność na poziomie 99,95%. SLA jest natomiast umownym zobowiązaniem dostawcy wobec klienta i może określać konsekwencje niezachowania uzgodnionego poziomu.

Ile powinna wynosić gwarantowana dostępność w umowie SLA?

Nie istnieje jeden właściwy poziom dla wszystkich systemów. Na rynku spotyka się wartości od 99% do 99,99% i wyższe. Wybór powinien zależeć od znaczenia systemu dla działalności przedsiębiorstwa. 99% oznacza około 7,3 godziny dopuszczalnego przestoju miesięcznie, 99,9% – około 43 minut, a 99,99% – około 4,3 minuty.

Czym różni się czas reakcji od czasu naprawy?

Czas reakcji określa, jak szybko dostawca powinien podjąć działania po otrzymaniu zgłoszenia. Czas naprawy wskazuje natomiast, ile czasu ma na rzeczywiste usunięcie problemu albo wdrożenie uzgodnionego rozwiązania zastępczego. W SLA warto określić oba parametry.

Czy umowa SLA jest obowiązkowa?

Przepisy nie nakładają na przedsiębiorców obowiązku zawierania odrębnej umowy SLA. Konieczność jej zawarcia może jednak wynikać z wymogów regulacyjnych dotyczących określonych podmiotów lub usług. Przykładowo rozporządzenie DORA przewiduje szczegółowe wymagania dotyczące ustaleń umownych podmiotów finansowych z dostawcami usług ICT, w tym klauzul dotyczących gwarantowanego poziomu usług.

Czy można korzystać z gotowego wzoru umowy SLA?

Tak, ale wzór umowy proponowany przez dostawcę powinien być traktowany raczej jako punkt wyjścia. Parametry SLA muszą bowiem odpowiadać Twojemu systemowi, modelowi świadczenia usług, architekturze technicznej i skutkom ewentualnej awarii dla przedsiębiorstwa.

Co grozi dostawcy za niedotrzymanie warunków SLA?

Konsekwencje zależą przede wszystkim od treści umowy. SLA może przewidywać kary umowne, service credits, obowiązek naprawienia szkody, a w przypadku powtarzających się lub poważnych naruszeń także prawo wypowiedzenia lub rozwiązania umowy.

Czy umowa SLA wymaga umowy powierzenia danych osobowych?

Nie zawsze. Jeżeli jednak w ramach świadczenia usług dostawca przetwarza dane osobowe, których administratorem jest klient – co może mieć miejsce np. przy dostępie serwisowym do bazy danych – relacja taka powinna zostać uregulowana zgodnie z art. 28 RODO, tj. najczęściej poprzez zawarcie umowy powierzenia przetwarzania danych osobowych zgodną z warunkami określonymi w art. 28 ust. 3 RODO.

Kiedy podpisać umowę SLA – przed czy po wdrożeniu systemu?

Najbezpieczniej uzgodnić jej warunki już podczas negocjowania umowy wdrożeniowej, nawet jeżeli samo SLA zacznie obowiązywać dopiero po odbiorze systemu. Pozwala to jeszcze przed rozpoczęciem projektu ustalić, kto i na jakich zasadach będzie odpowiadał za system po jego wdrożeniu.

Umowa SLA – dlaczego warto zadbać o jej treść?

Dobra umowa SLA nie musi być długa. Musi być przede wszystkim mierzalna, jednoznaczna i dostosowana do rzeczywistego znaczenia systemu dla przedsiębiorstwa.

Z perspektywy klienta najważniejsze jest ustalenie, jakiego poziomu dostępności rzeczywiście potrzebuje, ile czasu może czekać na reakcję i usunięcie awarii oraz jakie konsekwencje powinno powodować niedotrzymanie tych parametrów. Z perspektywy dostawcy równie istotne jest precyzyjne określenie zakresu jego odpowiedzialności, obowiązków klienta i sytuacji, za które dostawca nie powinien odpowiadać.

Im bardziej krytyczny dla działalności firmy jest system, tym większe znaczenie ma prawidłowe skonstruowanie SLA. Ogólna deklaracja „zapewnienia ciągłości działania” nie zastąpi konkretnych parametrów, procedury eskalacji i zasad odpowiedzialności.

Kancelaria Rubicon wspiera przedsiębiorców w negocjowaniu i przygotowywaniu umów IT, w tym umów wdrożeniowych, utrzymaniowych i SLA, a także w zakresie ochrony danych osobowych oraz wymogów regulacyjnych związanych z korzystaniem z usług ICT. Pomagamy zarówno na etapie tworzenia modelu współpracy z dostawcą, jak i przy analizie przedstawionego przez kontrahenta wzoru umowy.

Jeżeli planujesz wdrożenie systemu IT, negocjujesz umowę SLA albo chcesz zweryfikować, czy obowiązujące warunki rzeczywiście zabezpieczają Twoją firmę, zapraszamy do kontaktu z naszym zespołem.