Umowa utrzymania aplikacji: SLA, kopie i aktualizacje

W umowie utrzymania aplikacji zapisz zakres prac i czasy reakcji oraz naprawy dla każdego priorytetu zgłoszeń. Opisz też kopie zapasowe z testem odtwarzania, aktualizacje bezpieczeństwa i monitoring. Do tego dochodzą pula godzin na rozwój, dostęp do kodu i zasady przekazania aplikacji po zakończeniu współpracy. Jeśli wykonawca ma w ramach utrzymania dostęp do danych osobowych, np. w bazie, kopiach lub logach, potrzebna jest również umowa powierzenia przetwarzania danych.

Po wdrożeniu utrzymujemy m.in. system rejestracji na badania MR, Offer Exchange i INVENTA Licenses. Każdy z tych punktów pojawia się w rozmowach o umowie. Poniżej opisujemy, jak je sformułować, żeby za każdy obszar odpowiadała konkretna strona. Zakres naszej usługi znajdziesz na stronie o utrzymaniu i rozwoju aplikacji.

Zakres umowy utrzymania: co dokładnie obejmuje

Zacznij od listy elementów, za które odpowiada wykonawca. Zwykle są to kod aplikacji, baza danych, serwer lub środowisko w chmurze, domena i certyfikat SSL. Jeśli jakiś element zostaje po Twojej stronie, zapisz to wprost.

Najczęściej myli się dwie warstwy: aplikację i serwer. Administrator serwera zadba o system operacyjny i zaporę, ale nie zaktualizuje bibliotek w kodzie. W Conetso obiema warstwami zajmują się nasze zespoły, więc aplikacja i serwer mogą być w jednej umowie.

SLA: czas reakcji i czas naprawy

Umowa SLA określa, jak szybko wykonawca zajmie się zgłoszeniem. Czas reakcji to czas od zgłoszenia do podjęcia pracy. Czas naprawy to czas do przywrócenia działania, czasem przez rozwiązanie tymczasowe. Zapisz oba, bo sama szybka odpowiedź nie usuwa awarii.

Czasy warto powiązać z priorytetami zgłoszeń:

Priorytet	Przykład	Co zapisać
Krytyczny	aplikacja nie działa albo blokuje pracę wszystkich użytkowników	najkrótszy czas reakcji i naprawy, kanał zgłoszenia awaryjnego
Wysoki	ważna funkcja nie działa, ale da się pracować dalej	czas reakcji i termin rozwiązania tymczasowego
Normalny	błąd w pojedynczym widoku lub raporcie	czas reakcji, naprawa w najbliższym wydaniu
Zmiana	nowe pole, filtr, zmiana w raporcie	wycena i termin z puli godzin

Zapisz też, w jakich godzinach liczą się te czasy. U nas standardem są dni robocze 8:00–17:00, a czas reakcji w standardowej umowie wynosi 2 godziny w tych godzinach. Szybszą reakcję i pracę poza tymi godzinami ustalamy w umowie SLA. Dopisz sposób zgłaszania: portal helpdesk, e-mail, telefon przy awarii.

Kopie zapasowe i test odtwarzania

Umowa powinna określać, co jest kopiowane, jak często, gdzie są przechowywane kopie i jak długo. Kopie trzymaj poza serwerem aplikacji. Ważny jest też test odtwarzania na osobnym środowisku, wykonywany okresowo i z pomiarem czasu.

Test odpowiada na pytanie, które padnie przy awarii: za ile godzin system wróci i z danymi z którego dnia. Te dwie wartości mają swoje nazwy. RPO to maksymalny okres, z którego możesz stracić dane. RTO to maksymalny czas przywracania systemu.

Kopie i środowisko do testu odtwarzania zawierają te same dane osobowe co produkcja. Zabezpiecz je tak samo i wskaż w umowie powierzenia, gdzie są przechowywane.

Aktualizacje bezpieczeństwa

Aplikacja webowa w dużej części składa się z cudzego kodu: frameworka, bibliotek, środowiska uruchomieniowego i bazy danych. Każdy z tych elementów dostaje poprawki bezpieczeństwa i ma określony okres wsparcia. Aplikacja bez aktualizacji przez dwa lata wymaga już migracji, a to kosztuje więcej niż bieżące utrzymanie.

W umowie zapisz:

• co jest aktualizowane: biblioteki, framework, system serwera, baza danych,
• jak szybko wdrażane są poprawki bezpieczeństwa, a jak zwykłe aktualizacje,
• że każda zmiana przechodzi najpierw przez wersję testową,
• że przed wdrożeniem na serwer produkcyjny powstaje kopia bazy,
• kto płaci za aktualizację, która wymaga zmian w kodzie.

Monitoring aplikacji

Monitoring ma wykryć problem, zanim zgłosi go użytkownik. Zapisz, co jest sprawdzane: dostępność aplikacji, błędy w logach, miejsce na dysku, ważność certyfikatów. Ustal też, kto dostaje alert i jak alert przekłada się na priorytet zgłoszenia.

Pula godzin na rozwój

Utrzymanie rozliczamy w abonamencie miesięcznym z pulą godzin na rozwój. Pula przydaje się, gdy aplikacja jest używana na co dzień i stale pojawiają się drobne prośby. W umowie zapisz wielkość puli. Określ też stawkę za pracę ponad pulę, bo większe zmiany i pilne prace poza abonamentem rozliczamy godzinowo.

Co miesiąc warto dostawać raport z wykonanych prac i wykorzystanych godzin. Na tej podstawie łatwiej zaplanować kolejne zmiany.

Dostęp do kodu i repozytorium

Jako właściciel aplikacji powinieneś mieć dostęp do kodu, dokumentacji technicznej i danych administracyjnych. Zapisz, gdzie jest repozytorium kodu i kto ma do niego dostęp. Prawa do kodu ustalamy już w umowie na budowę aplikacji. Opisujemy to we wpisie o tym, jak powstaje oprogramowanie na zamówienie. W umowie utrzymania dopisz, że te same zasady obejmują zmiany wprowadzone w ramach utrzymania.

Przekazanie aplikacji przy końcu umowy

Ten punkt najczęściej pomija się przy podpisywaniu umowy. Zapisz okres wypowiedzenia i listę tego, co dostajesz przy zakończeniu współpracy:

• aktualny kod z historią zmian w repozytorium,
• kopię bazy danych w uzgodnionym formacie,
• dokumentację techniczną i opis wdrożenia,
• hasła i dostęp do serwera, domeny i usług zewnętrznych,
• czas na pytania nowego wykonawcy po przekazaniu.

Dopisz też, kiedy wykonawca usuwa dane ze swoich systemów, łącznie z kopiami zapasowymi.

Przejmujemy także utrzymanie aplikacji napisanych przez inną firmę. Taką współpracę wyceniamy indywidualnie. Lista powyżej pokazuje, co warto wtedy dostać od poprzedniego wykonawcy.

RODO: umowa powierzenia przetwarzania danych

Wykonawca utrzymania zwykle ma dostęp do danych osobowych w bazie, kopiach i logach. Przetwarza je wtedy w Twoim imieniu jako podmiot przetwarzający, a obowiązki stron opisuje umowa powierzenia z art. 28 RODO. Jeśli Twoja aplikacja przetwarza dane Twoich klientów w ich imieniu, np. w modelu SaaS, wykonawca jest dalszym podmiotem przetwarzającym. Na jego udział potrzebujesz wtedy zgody swoich klientów jako administratorów danych.

Art. 28 ust. 3 RODO określa, co musi znaleźć się w umowie powierzenia. Są to m.in.:

• przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych oraz kategorie osób, których dane dotyczą,
• przetwarzanie danych wyłącznie na Twoje udokumentowane polecenie, także co do przekazywania ich poza Europejski Obszar Gospodarczy,
• zobowiązanie do poufności osób, które mają dostęp do danych,
• środki bezpieczeństwa wymagane przez art. 32 RODO,
• warunki korzystania z dalszych podmiotów przetwarzających,
• pomoc wykonawcy w realizacji praw osób, których dane dotyczą, w obsłudze naruszeń i w ocenie skutków dla ochrony danych,
• zwrot albo usunięcie danych po zakończeniu usług, zależnie od Twojej decyzji, razem z kopiami, chyba że przepisy nakazują ich przechowywanie,
• udostępnianie Ci informacji potrzebnych do wykazania zgodności i umożliwienie audytów.

Jeśli wykonawca sam zamawia hosting albo bramkę SMS, ci dostawcy są dalszymi podmiotami przetwarzającymi. Wykonawca może z nich korzystać tylko za Twoją uprzednią pisemną zgodą, szczegółową albo ogólną (art. 28 ust. 2 RODO). Przy zgodzie ogólnej informuje Cię o planowanych zmianach, a Ty możesz się im sprzeciwić.

Na dalszy podmiot wykonawca nakłada w umowie te same obowiązki i odpowiada za niego wobec Ciebie jak za siebie (art. 28 ust. 4 RODO). Jeśli umowę z hostingiem zawierasz bezpośrednio Ty, hosting jest Twoim podmiotem przetwarzającym i potrzebuje osobnej umowy powierzenia. Sprawdź też, czy dane trafiają poza Europejski Obszar Gospodarczy. Takie przekazanie musi przewidywać umowa, a jego podstawa musi spełniać warunki z rozdziału V RODO.

RODO wymaga, żeby wykonawca zgłosił Ci naruszenie ochrony danych bez zbędnej zwłoki (art. 33 ust. 2). Ty zgłaszasz je Prezesowi UODO w miarę możliwości w ciągu 72 godzin od jego stwierdzenia (art. 33 ust. 1). Zgłoszenie nie jest wymagane, jeśli naruszenie raczej nie powoduje ryzyka dla osób, których dane dotyczą.

Przy wysokim ryzyku zawiadamiasz też te osoby (art. 34 RODO). Dlatego w umowie zapisz konkretny czas na powiadomienie Cię przez wykonawcę i zakres informacji, które ma przekazać.

Jeśli Twoja aplikacja pobiera opłaty przez bramkę płatności, dopisz do umowy też kontrolę webhooków i wersji API. Piszemy o nich we wpisie o płatnościach w aplikacji SaaS.

Wpis opisuje praktykę wykonawcy i nie jest poradą prawną. Jeśli chcesz ustalić zakres utrzymania swojej aplikacji, napisz do nas. Opisz, na czym aplikacja działa i jakiego czasu reakcji potrzebujesz.