Umowa SLA krok po kroku. Jak napisać kontrakt, który ochroni Twój biznes, gdy system padnie.

Black Friday, godzina 10:00. System płatności w Twoim e-commerce pada. Dzwonisz do dostawcy — cisza. Sprawdzasz umowę. Nie ma w niej SLA. Albo jest, ale jedyne co mówi, to „czas reakcji: do 24 godzin”. Przez najbliższe osiem godzin Twój sklep nie sprzedaje. Ile właśnie straciłeś?

Jeśli prowadzisz firmę technologiczną, e-commerce albo SaaS — i korzystasz z zewnętrznych usług IT — umowa SLA (Service Level Agreement, czyli umowa o gwarantowanym poziomie usług) decyduje o tym, czy w momencie kryzysu masz narzędzie do działania, czy zostaje Ci tylko telefon i nadzieja. Źle skonstruowane SLA oznacza chaos, gdy system przestaje działać. Dobrze napisane — porządkuje odpowiedzialność, daje Ci kontrolę nad czasem reakcji dostawcy i chroni przed stratami, które mogą wielokrotnie przekroczyć koszt samej usługi.

W tym artykule pokażę, jak krok po kroku przygotować umowę SLA, która zabezpieczy Twój biznes. Omówię parametry, kary, procedury zgłoszeniowe, bezpieczeństwo danych, prawa do IP i mechanizmy wyjścia z umowy — na konkretnych scenariuszach i w oparciu o orzecznictwo polskich sądów.

Najważniejsze pojęcia, zanim zaczniesz negocjować SLA

Zanim przejdziemy do konkretów, uporządkujmy terminologię. Wiele sporów o SLA wynika z tego, że strony inaczej rozumieją te same słowa.

Rozróżnienie między czasem reakcji a czasem naprawy to jedno z najczęstszych źródeł nieporozumień. Klienci zakładają, że „czas reakcji 2 godziny” oznacza naprawę w 2 godziny. Dostawcy rozumieją to jako: „odpowiemy w 2 godziny”. Jeśli nie zdefiniujesz obu parametrów osobno, dowiesz się o różnicy dopiero w trakcie awarii.

Zakres usług i wyłączenia — co dokładnie kupujesz

Pierwsza i najważniejsza sekcja SLA to precyzyjny opis tego, co dostawca ma robić — i czego nie ma robić.

Brak jasnego zakresu prowadzi do klasycznego sporu: klient mówi „konsulting był w cenie”, dostawca odpowiada „nie był”. Takie konflikty eskalują szybko i kończą się albo w sądzie, albo zerwaniem relacji.

Co powinno znaleźć się w opisie zakresu

1. Lista usług objętych SLA — hosting, monitoring, wsparcie helpdesk, utrzymanie aplikacji, backup, aktualizacje bezpieczeństwa.
2. Wyłączenia — co nie jest objęte umową (np. rozwój nowych funkcjonalności, szkolenia użytkowników, integracje z systemami trzecimi).
3. Godziny wsparcia — czy dostawca odpowiada 24/7, czy tylko w godzinach roboczych (8:00–18:00, dni robocze).
4. Warunki brzegowe — np. maksymalna liczba użytkowników, wolumen danych, liczba zgłoszeń miesięcznie.
5. Procedura zarządzania zmianą — zasady modyfikacji zakresu usług w trakcie trwania umowy, chroniące przed zjawiskiem scope creep (niekontrolowanym rozszerzaniem zakresu).

Dostawca nie ponosi odpowiedzialności za obszary, które nie zostały mu umownie powierzone. Dlatego każda usługa, której oczekujesz, musi mieć swoje odzwierciedlenie w treści SLA. Jeśli czegoś tam nie ma — nie masz podstaw do roszczeń.

Skontaktuj się — przejrzymy Twoje umowy z dostawcami IT i wskażemy, gdzie brakuje zapisów.

Parametry SLA, które naprawdę mają znaczenie

99,5% uptime brzmi świetnie — dopóki nie policzysz, że to prawie 44 godziny niedostępności rocznie. Czy Twój e-commerce przeżyje 44 godziny bez sprzedaży?

Jak czytać wskaźnik dostępności

Na polskim rynku hostingu dolna granica oferty to dostępność powyżej 99% rocznie. Dla usług biznesowych standardem jest 99,9% i wyżej. Centra danych i infrastruktura sieciowa konkurują na poziomie 99,95–99,99%.

Ale sam wskaźnik uptime to za mało. Sprawdź, jak dostawca mierzy dostępność. Jeśli mierzone są tylko „godziny biznesowe” (8:00–18:00), nocne awarie — gdy działają procesy batchowe, synchronizacje czy importy danych — nie wliczają się do statystyk. Definicja „uptime” musi być jednoznaczna.

Priorytety błędów i czasy reakcji/naprawy

Nie każda awaria jest taka sama. SLA powinno definiować kilka poziomów priorytetów z różnymi czasami reakcji i naprawy.

Wartości w tabeli to przykłady — Twoje parametry powinny wynikać z analizy tego, jakie systemy są dla Twojej firmy krytyczne i ile kosztuje ich przestój. Inna jest skala ryzyka przy awarii systemu płatności w e-commerce w Black Friday, a inna przy awarii wewnętrznego narzędzia do raportowania.

Z orzecznictwa polskich sądów wynika, że w dużych kontraktach serwisowych stosuje się czasy reakcji rzędu 4 godzin dla awarii krytycznych, z czasem naprawy 24 godzin dla awarii krytycznych i 48 godzin dla niekrytycznych (sprawa I ACa 1219/15, SA w Krakowie — kontrakt serwisowy o wartości 208.594 USD).

Procedura zgłaszania problemów — gdzie zaczyna się liczyć czas

Nawet najlepsze parametry SLA są bezwartościowe, jeśli nie wiesz, od kiedy liczy się czas reakcji.

Czy czas biegnie od momentu wysłania maila? Od potwierdzenia przyjęcia zgłoszenia? Od otwarcia ticketa w systemie? Jeśli tego nie ustalisz, w momencie kryzysu dojdzie do sporu o każdą minutę.

Co musi regulować procedura zgłoszeniowa

1. Kanały zgłoszeń — jakie formy kontaktu są dopuszczalne (system ticketowy, e-mail, telefon, komunikator). Ustal, który kanał jest wiążący — jeśli zgłoszenie mailem nie otwiera ticketa automatycznie, czas reakcji może nie ruszyć.
2. Format zgłoszenia — jakie informacje musi zawierać zgłoszenie (opis problemu, priorytet, środowisko, zrzuty ekranu, logi).
3. Moment rozpoczęcia liczenia czasu — np. od potwierdzenia przyjęcia ticketa przez system, nie od wysłania maila przez klienta.
4. Godziny wsparcia — czy czas reakcji liczy się w godzinach roboczych czy kalendarzowych. Zgłoszenie wysłane w piątek o 17:00 przy wsparciu 8/5 zacznie „tykać” dopiero w poniedziałek o 8:00.
5. Eskalacja — kto po stronie klienta i dostawcy odpowiada za kontakt, jakie są linie wsparcia, zasady zastępstwa, domniemania kompetencji.

Macierz odpowiedzialności powinna obejmować: zgłoszenie błędu, nadanie kategorii, akceptację naprawy, a także przypisanie ról projektowych i linii wsparcia z jasnym podziałem kompetencji. Uzupełnienie tych zapisów o skutki niewykonania (np. automatyczne podwyższenie priorytetu po upływie czasu) tworzy kompletną procedurę operacyjną.

Kary umowne i service credits — jak motywować dostawcę bez blokowania negocjacji

To sekcja, która generuje najwięcej napięć w negocjacjach. Dostawca nie chce podpisywać SLA z karami. Klient nie chce SLA bez kar. Jak znaleźć równowagę?

Model 1: klasyczne kary umowne (art. 483–484 k.c.)

Kary umowne w SLA najczęściej określa się jako procent wynagrodzenia dostawcy za każdą rozpoczętą godzinę lub dzień trwania stanu nieusunięcia wady. Kara za wady wyższej kategorii jest zazwyczaj wyższa.

Z orzecznictwa polskich sądów wynikają konkretne przedziały:

Czego unikać:

1. Kary za zobowiązania pieniężne — art. 483 § 1 k.c. dopuszcza kary wyłącznie za zobowiązania niepieniężne. Sprawa XIII GC 1553/15: postanowienie przewidujące zachowanie prawa do wynagrodzenia mimo zawieszenia usług po opóźnieniu w zapłacie uznano za niedopuszczalną karę za zobowiązanie pieniężne.
2. Kumulacja kar za zwłokę i za odstąpienie — sprawa XIV C 1579/21: sąd stwierdził, że po odstąpieniu od umowy wierzyciel może dochodzić wyłącznie kary za odstąpienie, nie łącznie z karą za zwłokę dotyczącą tego samego zobowiązania.
3. Brak precyzji — sprawa VIII Ga 92/19: kara uznana za nieskuteczną, bo z umowy nie wynikało, za jakie konkretne naruszenia jest należna.

Miarkowanie przez sąd: zgodnie z art. 484 § 2 k.c. sąd może obniżyć karę, jeżeli zobowiązanie zostało w znacznej części wykonane lub kara jest rażąco wygórowana. Kary przekraczające wartość wynagrodzenia dostawcy są w orzecznictwie uznawane za rażąco wygórowane. Sąd nie może jednak całkowicie znieść kary — może ją tylko zmniejszyć.

Model 2: service credits (obniżanie wynagrodzenia)

Alternatywa dla klasycznych kar — konstrukcja, w której dostawca obniża wynagrodzenie za dany okres rozliczeniowy proporcjonalnie do niedostępności systemu. Ten model stosują globalni dostawcy chmury (AWS, Azure, GCP).

Rekomendacja: rozważ model hybrydowy — service credits za typowe naruszenia parametrów (np. uptime poniżej progu) oraz kary umowne za poważne naruszenia (np. utrata danych, naruszenie poufności, brak reakcji na incydent bezpieczeństwa).

Po osiągnięciu określonego limitu wartościowego kar (np. 30% rocznego wynagrodzenia) klient powinien mieć prawo wypowiedzenia umowy — kumulacja problemów na takim poziomie oznacza, że dostawca nie jest w stanie realizować zobowiązań.

Bezpieczeństwo danych i RODO w SLA — co musi być, a czego nie powielać

Relacja SLA do umowy powierzenia danych (DPA)

Art. 28 RODO wymaga zawarcia odrębnej umowy powierzenia przetwarzania danych z każdym dostawcą IT, który przetwarza dane osobowe w Twoim imieniu. Pytanie: czy SLA musi powielać zapisy DPA?

Nie. RODO nie wymaga powielania treści DPA w SLA. Powielanie postanowień jest wręcz niekorzystne — zwiększa ryzyko sprzeczności, utrudnia zarządzanie zmianami i może prowadzić do rozbieżności interpretacyjnych.

Rekomendowany model:

1. Umowa główna — ogólne warunki współpracy.
2. DPA — odrębny załącznik z pełnym katalogiem elementów z art. 28 ust. 3 RODO.
3. SLA — odrębny załącznik techniczny, który operacjonalizuje wymogi bezpieczeństwa z DPA.
4. Klauzula pierwszeństwa — w razie sprzeczności między DPA a SLA w zakresie ochrony danych, pierwszeństwo mają postanowienia DPA.

Co SLA powinno rozwijać w kontekście bezpieczeństwa

1. Parametry RPO i RTO — ile danych możesz stracić i jak szybko usługa musi wrócić po awarii.
2. Procedura powiadamiania o incydencie — dostawca musi poinformować Cię o naruszeniu bezpieczeństwa w ciągu 24 godzin od wykrycia. Dlaczego? Bo art. 33 RODO daje Ci jako administratorowi 72 godziny na zgłoszenie naruszenia do UODO. Jeśli dostawca informuje Cię po 5 dniach — nie zdążysz.
3. Standardy kryptograficzne — wymagania dotyczące szyfrowania danych w spoczynku i w tranzycie.
4. Częstotliwość testów bezpieczeństwa — np. testy penetracyjne raz na kwartał, testy odtworzeniowe backupów raz na miesiąc.
5. Obowiązek współpracy przy dochodzeniu — dostawca musi udostępnić logi, dane diagnostyczne i wsparcie techniczne w razie incydentu.

Decyzja UODO ws. Sułkowickiego Ośrodka Kultury pokazuje, że nawet kara 2.500 zł może być nałożona za powierzenie przetwarzania danych bez pisemnej umowy powierzenia i bez weryfikacji gwarancji procesora. UODO podkreśla też, że administrator ma obowiązek weryfikacji procesora nie tylko przed zawarciem umowy, ale w trakcie całej współpracy — co oznacza, że SLA powinno przewidywać prawo do audytu.

Wpływ NIS2 i AI Act na wymagania wobec SLA

Dwie nowe regulacje UE zmieniają funkcję SLA — z dokumentu techniczno-operacyjnego w instrument realizacji obowiązków publicznoprawnych.

NIS2 — bezpieczeństwo łańcucha dostaw

Dyrektywa NIS2 (2022/2555), implementowana w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa (KSC), obejmuje podmioty z sektorów takich jak energia, transport, bankowość, zdrowie, infrastruktura cyfrowa i dostawcy usług cyfrowych. Co do zasady dotyczy średnich i dużych przedsiębiorstw (≥50 pracowników, roczny obrót >10 mln euro).

NIS2 wprost wymaga, aby środki zarządzania ryzykiem obejmowały bezpieczeństwo łańcucha dostaw — w tym stosunki z dostawcami usług ICT. Dla SLA oznacza to konieczność dodania:

1. Zobowiązania dostawcy do utrzymywania określonego poziomu bezpieczeństwa — z odwołaniem do norm ISO/IEC 27001 lub wymogów KSC.
2. Obowiązku niezwłocznego informowania o incydentach — kompatybilnego z reżimem raportowania 24/72 godzin (24h na wstępne ostrzeżenie do CSIRT, 72h na pełny raport).
3. Zasad korzystania z podwykonawców — obowiązek uzyskania zgody klienta na podwykonawców i rozszerzenia wymogów bezpieczeństwa na cały łańcuch.
4. Prawa klienta do audytu bezpieczeństwa u dostawcy.
5. Parametrów RPO, RTO, testów odtworzeniowych i retencji logów.
6. Mechanizmów zakończenia współpracy w razie poważnych naruszeń bezpieczeństwa.

Odpowiedzialność za raportowanie incydentów spoczywa na podmiocie objętym NIS2 — niezależnie od tego, czy incydent dotyczy infrastruktury własnej czy zarządzanej przez zewnętrznego dostawcę. Nowelizacja KSC wprowadza też bezpośrednią odpowiedzialność osobistą kierownika podmiotu za wykonanie obowiązków z zakresu cyberbezpieczeństwa.

AI Act — obowiązki wobec systemów wysokiego ryzyka

Jeśli korzystasz z systemu AI w rekrutacji, ocenie pracy, planowaniu czasu pracy czy monitoringu pracowników — ten system jest wprost zaliczony do kategorii wysokiego ryzyka (załącznik III do AI Act). SLA z dostawcą takiego systemu musi uwzględniać:

1. Obowiązek dostarczenia pełnej dokumentacji technicznej i instrukcji użytkowania.
2. Informowanie o aktualizacjach mogących wpływać na zgodność z regulacją.
3. Udostępnienie informacji niezbędnych do przeprowadzenia DPIA (oceny skutków dla ochrony danych).
4. Parametry dotyczące nadzoru człowieka nad decyzjami systemu.

Kary za naruszenia AI Act sięgają do 35 mln euro lub 7% rocznego obrotu za zakazane praktyki i do 15 mln euro lub 3% obrotu za naruszenia wymogów dla systemów wysokiego ryzyka.

Prawa własności intelektualnej w SLA — kto jest właścicielem kodu

Programista dostawcy w ramach wsparcia pisze customowy skrypt rozwiązujący Twój problem. Po rozwiązaniu umowy dostawca mówi: „ten kod jest nasz”. Zostajesz z dziurą w systemie.

Brak klauzuli IP w SLA to ryzyko utraty dostępu do aktywów technologicznych, które powstały przy Twoim udziale i na Twoje zamówienie.

Co ustalić w SLA dotyczącym praw IP

1. Przeniesienie praw autorskich czy licencja — zdecyduj, czy chcesz pełne przeniesienie majątkowych praw autorskich do kodu, dokumentacji i konfiguracji powstałych w ramach SLA, czy wystarczy Ci licencja. Przeniesienie daje pełną kontrolę. Licencja jest tańsza, ale ogranicza Twoje możliwości.
2. Pola eksploatacji — jeśli licencja, to na jakich polach: użytkowanie, modyfikacja, sublicencjonowanie, rozpowszechnianie.
3. Moment przeniesienia — czy prawa przechodzą z chwilą powstania utworu, z chwilą zapłaty, czy z chwilą odbioru.
4. Kod źródłowy — czy dostawca udostępnia kod źródłowy, czy tylko skompilowaną wersję. Bez kodu źródłowego nie będziesz w stanie samodzielnie utrzymywać ani rozwijać rozwiązania po zakończeniu współpracy.
5. Materiały wcześniej istniejące — dostawca wnosi do projektu swoje biblioteki, frameworki, narzędzia. Ustal, co pozostaje własnością dostawcy (i na jakich warunkach możesz tego używać), a co staje się Twoją własnością.

Klauzule exit i transition — jak bezpiecznie zmienić dostawcę

SLA podpisane 3 lata temu na 50 użytkowników. Firma urosła do 500. Parametry są takie same. Dostawca nie nadąża, ale formalnie spełnia zapisy. Chcesz zmienić dostawcę — ale nie wiesz, jak przeprowadzić migrację bez utraty ciągłości.

Elementy klauzuli exit, które musisz mieć w SLA

Regulacje sektorowe wymuszają te zapisy coraz silniej. DORA (Digital Operational Resilience Act) dla sektora finansowego wymaga, aby umowy z dostawcami ICT zawierały szczegółowe klauzule exit (art. 28–30, stosowanie od 17 stycznia 2025 r.). Data Act (art. 25) wprowadza zakaz pobierania opłat za migrację danych po 12 stycznia 2027 r.

Nawet jeśli Twoja firma nie podlega DORA ani Data Act — te regulacje wyznaczają kierunek rynkowy. Dostawcy, którzy blokują migrację, tracą klientów.

Checklista przed podpisaniem umowy SLA

Zanim podpiszesz SLA, zweryfikuj te punkty:

Perspektywa klienta:

1. Zakres usług pokrywa się z wymaganiami biznesowymi — nic nie zostało pominięte.
2. Parametry SLA (uptime, czasy reakcji, czasy naprawy) są mierzalne i weryfikowalne.
3. Procedura zgłoszeniowa jest jasna — wiesz, od kiedy liczy się czas reakcji.
4. Kary umowne lub service credits są skalibrowane — motywują dostawcę, ale nie blokują negocjacji.
5. Limity odpowiedzialności są adekwatne do ryzyka — nie za niskie (nie chronią), nie za wysokie (dostawca nie podpisze).
6. Prawa IP do kodu i dokumentacji są uregulowane — wiesz, co jest Twoje po zakończeniu współpracy.
7. DPA jest odrębnym dokumentem, spójnym z SLA, z klauzulą pierwszeństwa.
8. Procedura powiadamiania o incydencie bezpieczeństwa jest kompatybilna z 72-godzinnym terminem RODO.
9. Klauzula exit przewiduje okres przejściowy, obowiązek współpracy i eksport danych w otwartych formatach.
10. Klauzula przeglądowa zapewnia weryfikację parametrów co 6–12 miesięcy.

Perspektywa dostawcy:

1. Zakres zobowiązań odpowiada realnym możliwościom — nie obiecujesz więcej, niż możesz dostarczyć.
2. Ryzyko finansowe jest policzalne — kary nie przekraczają wartości wynagrodzenia.
3. Harmonogram i budżet są spójne z zakresem usług.
4. Wyłączenia odpowiedzialności obejmują siłę wyższą, podatności zero-day i brak współdziałania klienta.

Możemy Ci w tym pomóc

Przygotowanie SLA, które faktycznie chroni Twój biznes, wymaga połączenia wiedzy prawnej z rozumieniem modelu działania firmy technologicznej. Nie wystarczy skopiować wzoru z internetu — każde SLA musi odzwierciedlać specyfikę Twojej usługi, skalę operacji i profil ryzyka.

W kancelarii Sawaryn & Partnerzy łączymy prawo umów z kontekstem IT, AI i ochrony danych. Pracujemy z founderami, CTO i liderami produktowymi — rozumiemy, jak działają zespoły technologiczne i co oznacza przestój systemu o 10:00 w Black Friday.

Nasze wsparcie obejmuje:

1. Audyt istniejących umów z dostawcami IT — identyfikacja luk w SLA, brakujących parametrów, nieskutecznych klauzul karnych.
2. Przygotowanie lub renegocjacja SLA — od definicji zakresu usług, przez parametry i kary, po klauzule bezpieczeństwa, IP i exit.
3. Spójność SLA z DPA i regulacjami — weryfikacja zgodności z RODO, NIS2, AI Act i regulacjami sektorowymi.
4. Wsparcie w negocjacjach z dostawcami — dostarczamy gotowe warianty negocjacyjne zamiast teoretycznych analiz.

Kiedy SLA decyduje o przetrwaniu firmy

Dobrze napisane SLA to nie dokument „do szuflady”. To narzędzie, które uruchamiasz w momencie kryzysu — gdy system pada, dane wyciekają albo dostawca przestaje odbierać telefon. Każdy element SLA — od definicji uptime, przez procedurę zgłoszeniową, po klauzulę exit — odpowiada na jedno pytanie: co robisz, gdy coś pójdzie nie tak.

Jeśli Twoje obecne umowy z dostawcami IT nie zawierają mierzalnych parametrów, jasnych kar i procedur na wypadek awarii — teraz jest moment, żeby to zmienić. Koszt przygotowania dobrego SLA to ułamek strat, które generuje jeden poważny przestój.

Potrzebujesz wsparcia w audycie umów IT, przygotowaniu SLA lub negocjacjach z dostawcami? Napisz do nas.

Najczęściej zadawane pytania

Czym różni się SLA od umowy głównej — czy to osobny dokument?
SLA może być zarówno odrębnym dokumentem, jak i załącznikiem do umowy głównej. Rekomendowany model to trzy odrębne dokumenty: umowa główna (ogólne warunki współpracy), DPA (umowa powierzenia danych) i SLA (parametry techniczne usługi). Taka struktura ułatwia zarządzanie zmianami — możesz zaktualizować parametry SLA bez renegocjowania całej umowy.

Jak ustalić realistyczne kary umowne, żeby motywowały dostawcę, ale nie blokowały negocjacji?
Z orzecznictwa polskich sądów wynika, że kary w przedziale 0,1–0,5% wynagrodzenia za każdy dzień opóźnienia są akceptowane. Kary przekraczające wartość wynagrodzenia dostawcy mogą zostać zmiarkowane przez sąd jako rażąco wygórowane (art. 484 § 2 k.c.). Rozważ model hybrydowy: service credits za typowe naruszenia parametrów i kary umowne za poważne naruszenia (utrata danych, naruszenie poufności). Ustal też limit kumulacji kar — po jego przekroczeniu masz prawo wypowiedzenia umowy.

Co zrobić, gdy dostawca mówi „nie podpiszemy SLA z karami”?
Zaproponuj model service credits zamiast klasycznych kar umownych. W tym modelu dostawca obniża wynagrodzenie za okres niedostępności — to nie jest kara umowna w rozumieniu art. 483 k.c., więc nie podlega miarkowania przez sąd. Dostawcy akceptują ten model łatwiej, bo ryzyko finansowe jest ograniczone do wartości abonamentu. Jeśli dostawca odmawia jakiejkolwiek formy odpowiedzialności za parametry usługi — rozważ zmianę dostawcy.

Czy SLA musi regulować RODO, skoro mam osobną umowę powierzenia (DPA)?
SLA nie powinno powielać zapisów DPA — to zwiększa ryzyko sprzeczności. SLA powinno natomiast operacjonalizować wymogi bezpieczeństwa z DPA: definiować parametry RPO i RTO, procedurę powiadamiania o incydencie (maks. 24h od wykrycia, żebyś zdążył ze zgłoszeniem do UODO w 72h), standardy szyfrowania i częstotliwość testów bezpieczeństwa. W razie sprzeczności między SLA a DPA — postanowienia DPA mają pierwszeństwo.

Jak zmierzyć, czy dostawca naprawdę spełnia SLA — czy powinienem mieć własny monitoring?
Tak — poleganie wyłącznie na raportach dostawcy to ryzyko. Wdróż niezależny monitoring dostępności i wydajności usług. Comiesięczny raport SLA powinien automatycznie porównywać dane dostawcy z Twoimi pomiarami i flagować rozbieżności. Powiąż raport SLA z procesem płatności — jeśli parametry nie są spełnione, uruchamia się procedura service credits lub eskalacji.

Czy mogę jednostronnie rozwiązać SLA, gdy dostawca ciągle nie spełnia parametrów?
To zależy od zapisów umowy. Rekomendacja: wprowadź klauzulę, która daje Ci prawo wypowiedzenia po osiągnięciu określonego limitu kumulacji kar lub po określonej liczbie naruszeń parametrów w danym okresie (np. 3 naruszenia P1 w kwartale). Bez takiej klauzuli musisz polegać na ogólnych przepisach k.c. o wypowiedzeniu umowy zlecenia lub o rozwiązaniu za porozumieniem stron — co jest wolniejsze i mniej przewidywalne.