Umowa SLA

SLA (Service Level Agreement) określa uzgodnione poziomy świadczenia usług, sposób ich pomiaru oraz konsekwencje niedotrzymania parametrów. Może być odrębną umową, częścią kontraktu lub załącznikiem do umowy serwisowej, chmurowej czy outsourcingowej. Nie zastępuje całej umowy utrzymaniowej — uzupełnia ją o konkretne wymagania dotyczące jakości i dostępności usług.

Z mojego doświadczenia wynika, że zbyt ogólne SLA naraża zamawiającego na przestoje i nieprzewidywalne koszty, a dostawcę na spory o zakres odpowiedzialności i gotowość zespołu. Dobrze wynegocjowany dokument ma działać operacyjnie: określać parametry obsługi, porządkować zgłoszenia i pozwalać obu stronom sprawdzić, czy usługa jest wykonywana zgodnie z ustaleniami.

Service Level Agreement

Czym zajmuję się w ramach obsługi umów SLA?

W praktyce widzę, że większość sporów na etapie utrzymania oprogramowania (maintenance) wynika z braku precyzji w definiowaniu pojęć technicznych na gruncie prawnym. Dlatego gdy na stół trafia nowa umowa SLA, definicja jej przedmiotu nie może ograniczać się do ogólników. Buduję kontrakty tak, aby parametry dostępności (np. mityczne 99,9%) i czasy reakcji były nie tylko ładnie wyglądającymi liczbami, ale realnym, wykonalnym planem zarządzania kryzysem, gdy system napotka problemy.

Punktem wyjścia jest znaczenie systemu dla biznesu i dopuszczalny czas przerwy w jego działaniu. Sklep internetowy prowadzący sprzedaż całodobowo może potrzebować obsługi incydentów krytycznych przez całą dobę. Wewnętrzny CRM może wymagać podobnej gotowości, jeżeli wspiera kluczowe procesy lub zespoły pracujące w różnych strefach czasowych. Godziny wsparcia, priorytety i konsekwencje niedotrzymania parametrów dobieram do tych potrzeb, a nie do samej nazwy systemu.

„Znajomość specyfiki branży IT, zrozumienie jej problemów i doświadczenie przy prawnej obsłudze firm działających w obszarze IT umożliwiają mi świadczenie specjalistycznych i kompleksowych usług z korzyścią dla moich Klientów.”

Radca Prawny Piotr Stawowski

Co powinny zawierać

UMOWA SLA W PRAKTYCE IT

W umowach serwisowych SLA nie chodzi o to, by obciążyć dostawcę odpowiedzialnością za każdą nieprzewidzianą usterkę, ani o to, by zamawiający musiał czekać tygodniami na usunięcie błędu krytycznego, który blokuje jego sprzedaż. Jeżeli zastanawiasz się, co powinna zawierać umowa SLA, aby była użytecznym narzędziem zarządzania ryzykiem, musisz skupić się na precyzyjnych procedurach obsługi incydentów. Na stronach branżowych często podkreśla się znaczenie kategoryzacji błędów i wskaźników dostępności, jako elementów, które realnie porządkują współpracę na etapie utrzymania systemu. Poniżej elementy, które uwzględniam przy przygotowaniu SLA, dopasowując ich zakres do usługi i ustalonego podziału odpowiedzialności:

Precyzyjna kategoryzacja incydentów: Definiuję w umowie jasny podział na błędy krytyczne, poważne (istotne) oraz zwykłe usterki, opisując przy tym rzeczywisty wpływ danego problemu na użyteczność lub wydajność systemu IT.
Wskaźniki, poziomy usług i raportowanie: rozdzielam mierzoną wartość (SLI), wymagany poziom tej wartości (SLO) oraz konsekwencje przewidziane w SLA. Przy dostępności określam sposób obliczeń, okres pomiaru, źródło danych i katalog wyłączeń. Ustalam też, jak traktować częściową niedostępność oraz kiedy dostawca przekazuje raporty.
Procedury i kanały zgłoszeń: Opisuję, w jaki sposób incydenty mają być zgłaszane (np. poprzez dedykowany system klasy ITSM, e-mail czy kanał telefoniczny), aby liczenie czasu reakcji było transparentne dla obu stron.

Czas reakcji (Response Time): określam, czy reakcja oznacza potwierdzenie zgłoszenia, jego kwalifikację, czy rozpoczęcie prac przez specjalistę. Ustalam zdarzenie rozpoczynające pomiar — np. skuteczne zgłoszenie lub wykrycie przez monitoring — a także godziny wsparcia, zasady zmiany priorytetu i dopuszczalne przerwy w biegu czasu.
Przywrócenie działania, obejście i trwała naprawa: rozdzielam termin przywrócenia uzgodnionej funkcjonalności od terminu trwałego usunięcia błędu. Ustalam, kiedy dopuszczalne jest obejście (workaround), jakie wymagania musi spełniać i jak wpływa na dalszy bieg terminów. Obowiązek zapewnienia rozwiązania zastępczego dopasowuję do możliwości technicznych i znaczenia danej usługi.
Okna serwisowe (Maintenance Windows): ustalam, czy i pod jakimi warunkami planowane przerwy są wyłączone z pomiaru dostępności. Określam sposób i termin ich zapowiadania, dopuszczalne godziny, maksymalny czas oraz skutki przekroczenia uzgodnionego okna. Samo nazwanie przerwy pracami serwisowymi nie powinno wystarczać do zastosowania wyłączenia.

Service credits i kary umowne: określam mechanizm rozliczenia niedotrzymanych parametrów, np. obniżenie opłaty lub karę umowną. Doprecyzowuję sposób naliczania, limity, procedurę zgłoszenia roszczenia oraz relację do odszkodowania i prawa zakończenia umowy. Sama nazwa service credits nie rozstrzyga o charakterze prawnym świadczenia — decyduje jego konstrukcja.
Katalog wyłączeń (Exclusions): osobno ustalam wyłączenia z pomiaru SLA i ograniczenia odpowiedzialności. Atak DDoS, awaria zewnętrznego API czy infrastruktury nie zwalniają dostawcy automatycznie — znaczenie mają jego obowiązki dotyczące zabezpieczeń, integracji i współpracy z innymi podmiotami. Wyłączenia nie powinny pozbawiać klienta ochrony właśnie w tych obszarach, za które dostawca zobowiązał się odpowiadać.

Przy infrastrukturze zewnętrznej i usługach chmurowych sprawdzam, czy umowa główna, SLA i pozostałe załączniki spójnie określają odpowiedzialność za dostępność, bezpieczeństwo oraz kopie zapasowe. Nie zawsze potrzebna jest dodatkowa umowa — kluczowe jest jasne przypisanie obowiązków dostawcy, klientowi i pozostałym podmiotom uczestniczącym w obsłudze środowiska.

Jeżeli w dalszym ciągu masz wątpliwości, skontaktuj się ze mną.

Gwarancja, Utrzymanie czy Rozwój?

Umowa SLA a modele współpracy

W projektach IT rozdzielam odpowiedzialność za wady wdrożenia, zobowiązania gwarancyjne, płatne utrzymanie i dalszy rozwój systemu. Gwarancja nie powstaje automatycznie przy każdym wykonaniu kodu, a stosowanie rękojmi zależy od kwalifikacji umowy i jej postanowień. SLA określa poziomy usług — samo w sobie nie przesądza, które naprawy są dodatkowo płatne.

Umowa powinna wyjaśniać, jak obsługiwane jest zgłoszenie objęte jednocześnie odpowiedzialnością za wadę i usługą utrzymania. Ustalam, jakie terminy obowiązują i co obejmuje abonament, aby strony nie spierały się o podwójne rozliczenie tej samej pracy. Poniżej opisuję dwa częste modele współpracy: utrzymanie aplikacji przez jej twórców oraz outsourcing infrastruktury i usług chmurowych.

Utrzymanie autorskie i rozwój systemu (Maintenance & Development)

Jeżeli po wdrożeniu ten sam software house odpowiada za utrzymanie i rozwój, ustalam, które obowiązki obejmuje abonament, a które wymagają osobnego zamówienia. Parametry SLA przypisuję do konkretnych usług utrzymaniowych. Rozwój może być rozliczany w tej samej umowie, ale nie powinien powodować niejasności co do pierwszeństwa obsługi incydentów.

Jednym z możliwych rozwiązań jest miesięczny ryczałt za gotowość i określone usługi utrzymaniowe, połączony z rozliczeniem Time & Material za rozwój. Zakres każdej opłaty wymaga jednak precyzyjnego opisu. Ustalam też priorytety, dostępność zespołu i zasady wdrażania zmian, ponieważ sam model rozliczeń nie gwarantuje dotrzymania parametrów SLA.

Umowa SLA – outsourcing infrastruktury i usług chmurowych

Kiedy utrzymanie systemu nie spoczywa na barkach twórców kodu, lecz zewnętrznego operatora IT (np. administratorów serwerów czy dostawców usług chmurowych), zasady gry całkowicie się zmieniają. Gdy przedmiotem negocjacji jest umowa SLA outsourcing wymaga szczególnego podejścia do bezpieczeństwa, ponieważ zewnętrzny podmiot uzyskuje dostęp do środowisk produkcyjnych i wrażliwych danych.

Przy utrzymaniu infrastruktury ustalam przede wszystkim wymagany poziom dostępności, zakres zabezpieczeń oraz zasady odtwarzania środowiska i danych. Rozdzielam docelowy czas przywrócenia działania (RTO) od dopuszczalnego zakresu utraty najnowszych danych, wyrażanego w czasie (RPO). Jeżeli usługa obejmuje ochronę przed DDoS, określam jej zakres i ograniczenia. Doprecyzowuję również zasady współpracy z software house’em, aby incydent dotyczący aplikacji i infrastruktury miał ustalonego koordynatora i jasną ścieżkę eskalacji.

Na co zwracam uwagę?

WŁASNOŚĆ INTELEKTUALNA A UMOWA SLA

W projektach IT utrzymanie systemu i prawa autorskie to naczynia połączone. W praktyce najwięcej problemów w fazie maintenance pojawia się wtedy, gdy zamawiający płaci za usunięcie błędu krytycznego lub stworzenie obejścia awarii, a po zakończeniu prac okazuje się, że nie posiada praw do nowo napisanego kodu. Dlatego dbam o to, by SLA umowa precyzyjnie regulowała kwestie własności intelektualnej do wszelkich łatek (bugfixów), skryptów naprawczych czy aktualizacji wdrażanych w ramach prac serwisowych.

Przeniesienie autorskich praw majątkowych oraz udzielenie licencji wyłącznej wymagają formy pisemnej pod rygorem nieważności. Elektronicznie można zachować równoważną formę przy użyciu kwalifikowanych podpisów elektronicznych. Zwykły e-mail lub wymiana skanów nie wystarczają do spełnienia tego wymogu.

W umowie obejmującej prace utrzymaniowe porządkuję prawa do powstających w ich ramach utworów oraz zasady korzystania z pozostałych rezultatów. Zakres przeniesienia praw lub licencji dopasowuję do planowanego używania i rozwoju systemu, z uwzględnieniem komponentów zewnętrznych. Jeśli utrzymanie ma móc przejąć inny wykonawca, sprawdzam możliwość udostępnienia mu kodu i zlecenia modyfikacji. W zależności od konstrukcji prawnej może to wymagać zgody na działanie na rzecz klienta, sublicencji lub innych odpowiednich uprawnień.

Zwracam również szczególną uwagę na powiązanie dostępu do kodu źródłowego z procedurami eskalacji. Uregulowanie zasad przekazywania repozytorium czy mechanizmów escrow staje się dla klienta swoistym „wyjściem awaryjnym”. Gdy dostawca rażąco narusza gwarantowane wskaźniki dostępności, nie usuwa na czas błędów krytycznych lub grozi mu utrata płynności finansowej, odpowiednio skonstruowana umowa SLA pozwala zamawiającemu przejąć kontrolę nad procesem naprawczym bez ryzyka roszczeń o naruszenie majątkowych praw autorskich.

Nasz zespół

Nasz zespół to prawnicy z doświadczeniem w pracy z firmami z sektora IT, gamedev i startupami. Współpracowaliśmy m.in. z Imnite, Nice Guys, InviNets i innymi wiodącymi firmami działającymi w obszarze IP/IT.

Piotr Stawowski

Właściciel

Radca prawny

Natalia Rogalewska

of Counsel

Radca prawny

Michał Ciepłucha

of Counsel

Radca prawny

Rekomendacje

Opinie moich klientów

Współpraca z panem Piotrem przebiegła bardzo pozytywnie w każdym aspekcie – rzetelności, terminów, komunikacji i umiejętności wytłumaczenia wszystkich zagadnień w przystępnej formie. Z czystym sumieniem mogę polecić tę Kancelarię.

Marta RoszkowkaWłaścicielka serwisu doginclusive.com

Z przyjemnością polecamy współpracę z Kancelarią Pana Piotra Stawowskiego. Od kilku miesięcy korzystamy z usług Kancelarii, a nasze doświadczenia są niezwykle pozytywne. Pan Piotr, jako ekspert w dziedzinie prawa IT oraz obsługi korporacyjnej, cechuje się nie tylko doskonałą wiedzą, ale również profesjonalizmem oraz terminowością w realizacji powierzonych mu zadań. Jego Kancelaria nie tylko spełnia, ale również przewyższa nasze oczekiwania, dostarczając kompleksowe wsparcie prawne. Współpraca z Panem Piotrem to dla nas gwarancja solidności, partnerskiego podejścia oraz skuteczności.

Konrad OsiakPrezes Zarządu Imnite sp. z o.o.

Kancelaria mecenasa Piotra Stawowskiego obsługiwała moją firmę pod kątem prawnym (przygotowanie umów, protokołów, consulting dotyczący ofert, dostosowywanie ofert dla nas i klienta pod kątem wymagań). Nasza firma korzystała z wielu kancelarii, ale Pan Piotr jako jedyny podszedł do naszych zapotrzebowań w sposób spersonalizowany. Często udzielał nam porad od strony praktycznej, które wdrożyliśmy i które przyniosły pozytywny efekt. Serdecznie polecamy jego usługi.

Adam WysockiWiceprezes Zarządu Nice Guys sp. z o.o.

Mecenas Piotr Stawowski świadczy usługi dla naszej spółki. Pomaga nam w codziennej działalności oraz rozwiązuje aktualne problemy prawne. Opracowuje umowy, zapewniając ich zgodność z RODO. Jego wsparcie jest dla nas nieocenione.

Kamilla TomczakPrezes Zarządu My Wspieramy sp. z o.o.

Bez zastanowienia możemy polecić kancelarię prawną Pana Piotra Stawowskiego każdemu właścicielowi e-commerce szukającemu wsparcia w zakresie tworzenia regulaminu sklepu. Pan Piotr dokładnie przeanalizował nasze potrzeby, a także wskazał obszary, o których sami wcześniej nie pomyśleliśmy. Komunikacja była bardzo sprawna, a w dodatku wszystkie zlecone prace były dostarczane szybko i terminowo.

Zespół BasenShop.pl

Kancelaria Prawna IT Piotr Stawowski wspierała moją firmę w procesie tworzenia i negocjowania warunków umów dotyczących wdrażania rozwiązań IT w chmurze internetowej. Pan Piotr wykazał się najwyższym poziomem profesjonalizmu oraz pełnym zaangażowaniem we współpracy. Dzięki jego skrupulatności, dbałości o szczegóły i szybkości działania proces finalizacji umów przebiegał zawsze sprawnie i bezproblemowo. Kancelaria zapewniła nam kompleksowe doradztwo, które pozwoliło zawrzeć umowy na wyjątkowo korzystnych warunkach. Z pełnym przekonaniem polecam Kancelarię Prawną IT Piotr Stawowski każdemu, kto poszukuje rzetelnej, szybkiej i efektywnej pomocy prawnej.

Adam OpońCSO & Co-founder Invinets Sp. z o.o.

Mecenas Stawowski wspierał Spółkę już na etapie jej zakładania – kompleksowo przeprowadził nas przez formalności i przygotował wzory umów, które zabezpieczają nasz biznes.

Doceniamy nie tylko wysoką jakość obsługi, ale też praktyczne podejście, szybkość działania i słuchanie naszych potrzeb. Dzięki wsparciu kancelarii mogliśmy skupić się na rozwijaniu firmy, wiedząc, że kwestie prawne są w dobrych rękach.

Z pełnym przekonaniem polecamy kancelarię Piotra Stawowskiego

Mateusz TerkaPrezes Zarządu Football Financial Group

Wsparcie prawnika

NEGOCJOWANIE I OPINIOWANIE UMÓW SLA

W negocjacjach kontraktów serwisowych nie interesuje mnie mnożenie ryzyk czy wpisywanie nierealnych kar finansowych, które zniszczą relacje biznesowe – zależy mi na tym, żeby system miał zagwarantowaną ciągłość działania, a obydwie strony jasne reguły rozliczeń. Dlatego pracuję tak, by każda umowa SLA (od prostego wsparcia po złożone utrzymanie 24/7) była dokumentem mierzalnym technicznie i zrozumiałym dla zarządu, prawnika oraz zespołu wsparcia (helpdesk).

Najczęściej pomagam w jednym z poniższych wariantów:

Audyt umowy od dostawcy: Wskazuję słabe punkty w zaproponowanych wskaźnikach (np. ukryte wyłączenia z czasu niedostępności) i proponuję konkretne, negocjowalne poprawki, które realnie zwiększą bezpieczeństwo.
Przygotowanie SLA od zera: Dobieram odpowiedni model kontraktu serwisowego, ustalam precyzyjne tabele priorytetów (kategoryzację błędów), czasy reakcji i naprawy oraz mechanizmy service credits (rekompensat).
Wsparcie w negocjacjach: Biorę udział w rozmowach, tłumacząc zawiłości prawne na język technologii i biznesu; dbam o wypracowanie kompromisu, który pozwala bezpiecznie rozpocząć fazę utrzymania.
Wsparcie w trakcie trwania umowy: Gdy pojawia się spór dotyczący tego, czy dane zgłoszenie to błąd objęty gwarancją czy nowa funkcjonalność (change request), pomagam rozstrzygnąć problem i uregulować zasady płatności.

Jeżeli na Twoim biurku leży do podpisu nowa umowa SLA, podeślij mi dokument. Przeanalizuję proponowane poziomy świadczenia usług i podpowiem, które zapisy należy doprecyzować, by chroniły Twój budżet i spokój.