W praktyce audyt umowy SaaS zaczyna się często za późno: wtedy, gdy dostawca podnosi cenę, występuje incydent bezpieczeństwa albo spółka chce przenieść dane do innego systemu. Umowa zaakceptowana w pośpiechu przez kliknięcie regulaminu może przez lata określać zasady przetwarzania danych klientów, dostęp do kluczowych procesów biznesowych oraz realny zakres odpowiedzialności dostawcy. W modelu chmurowym nie kupuje się programu jako rzeczy. Uzyskuje się czasowy dostęp do usługi, której parametry i otoczenie technologiczne mogą się zmieniać.
To sprawia, że ocena dokumentacji SaaS nie powinna ograniczać się do sprawdzenia ceny i okresu subskrypcji. Przedmiotem analizy jest cały układ kontraktowy: formularz zamówienia, regulamin, umowa powierzenia przetwarzania danych, polityka prywatności, załącznik SLA, dokumentacja bezpieczeństwa oraz polityki dotyczące podwykonawców. Nierzadko właśnie w dokumentach odsyłanych lub udostępnianych na stronie internetowej znajdują się postanowienia najistotniejsze dla ryzyka prawnego.
Audyt umowy SaaS to analiza modelu zależności
SaaS jest wygodny, ponieważ skraca drogę do wdrożenia. Ta wygoda ma jednak cenę w postaci zależności od dostawcy. Przedsiębiorca powierza mu nie tylko utrzymanie aplikacji, ale często również przechowywanie danych, zarządzanie dostępami użytkowników, wykonywanie kopii zapasowych i rozwój funkcjonalności. W przypadku systemów CRM, ERP, księgowych, HR, marketing automation lub narzędzi wykorzystujących generatywną AI konsekwencje błędnego wyboru warunków są szczególnie dotkliwe.
Dobry audyt nie polega na mechanicznym wyszukiwaniu niekorzystnych klauzul. Najpierw należy ustalić, do czego usługa będzie używana, jakie informacje do niej trafią i czy brak dostępu przez kilka godzin, dni lub tygodni zatrzyma istotny proces. Inny poziom zabezpieczeń jest racjonalny dla narzędzia do zarządzania kalendarzem, a inny dla platformy obsługującej transakcje finansowe, dokumentację medyczną, dane pracownicze lub tajemnice przedsiębiorstwa.
Punktem wyjścia powinno być również określenie roli przedsiębiorcy. Czy będzie jedynym klientem dostawcy, czy platforma ma służyć także jego własnym klientom? Czy użytkownicy końcowi będą mogli przesyłać do systemu pliki, treści chronione prawem autorskim albo dane osobowe? Odpowiedzi wpływają na potrzebę uregulowania praw własności intelektualnej, odpowiedzialności za treści oraz relacji wynikających z RODO i przepisów konsumenckich.
Co powinien obejmować audyt umowy SaaS
Zakres usługi i prawo dostawcy do zmian
Opis funkcjonalności bywa ogólny: dostawca zapewnia dostęp do platformy, aktualizacji i wsparcia technicznego. Taka formuła nie odpowiada jeszcze na pytanie, co dokładnie klient otrzyma. W audycie należy porównać opis umowny z materiałami sprzedażowymi, specyfikacją wdrożenia oraz funkcjami uznanymi przez biznes za krytyczne.
Szczególnej uwagi wymagają klauzule pozwalające jednostronnie zmieniać regulamin, funkcjonalności, limity użycia lub polityki bezpieczeństwa. Sama możliwość aktualizowania usługi jest naturalna dla SaaS i często korzystna. Problem powstaje, gdy dostawca może usunąć istotną funkcję, ograniczyć integrację albo wprowadzić nowy model rozliczeń bez realnego prawa klienta do sprzeciwu lub rozwiązania umowy.
Warto więc sprawdzić, czy zmiana istotnie pogarszająca sytuację klienta jest odpowiednio komunikowana, czy przewidziano okres przejściowy i czy klient może zakończyć współpracę bez sankcji. Przy rozwiązaniach kluczowych dla działalności zasadne jest umowne wskazanie funkcji podstawowych oraz procedury zarządzania zmianą.
SLA, wsparcie i konsekwencje niedostępności
Deklaracja dostępności na poziomie 99,9 proc. może brzmieć dobrze, ale nie przesądza o jakości ochrony. Należy ustalić okres pomiaru, wyłączenia z kalkulacji, planowane prace serwisowe, sposób raportowania oraz to, czy dostępność dotyczy całej usługi, czy tylko wybranych komponentów. Różnica między miesięcznym a rocznym sposobem liczenia dostępności może mieć praktyczne znaczenie.
Istotne są też czasy reakcji i usunięcia błędów, kanały zgłoszeń oraz klasyfikacja incydentów. W wielu standardowych kontraktach jedynym świadczeniem za naruszenie SLA jest service credit, czyli przyszły rabat na abonament. Nie zawsze jest to rozwiązanie nieakceptowalne. Dla usługi o niskiej krytyczności może być proporcjonalne, ale nie powinno zastępować odpowiedzialności za szkody wynikłe z rażącego naruszenia obowiązków, naruszenia poufności lub bezprawnego wykorzystania danych.
Dane osobowe, tajemnica przedsiębiorstwa i lokalizacja danych
Jeżeli w systemie przetwarzane są dane osobowe, umowa powierzenia nie może być traktowana jako formalny załącznik bez znaczenia operacyjnego. Trzeba zweryfikować kategorię danych, zakres operacji, instrukcje administratora, środki techniczne i organizacyjne, zasady korzystania z podprocesorów oraz procedurę obsługi naruszeń ochrony danych.
Należy rozróżnić sytuację, w której dostawca rzeczywiście działa jako procesor, od przypadków, w których wykorzystuje dane także dla własnych celów, na przykład do analityki produktowej, bezpieczeństwa lub trenowania modeli. Zwłaszcza przy narzędziach AI sformułowania o ulepszaniu usług wymagają precyzyjnej oceny. Dane wprowadzane przez użytkowników nie powinny automatycznie stawać się materiałem wykorzystywanym do rozwoju produktu, jeżeli nie wynika to jasno z uzgodnionych zasad i nie zostało ocenione pod kątem podstaw prawnych oraz poufności.
Audyt powinien objąć lokalizację centrów danych i transfery poza Europejski Obszar Gospodarczy. Informacja, że dostawca jest globalny, nie stanowi odpowiedzi na pytanie o mechanizm legalizujący transfer, zakres dostępu personelu z państw trzecich ani środki dodatkowe. W sektorach regulowanych potrzebna może być dalej idąca analiza wymogów outsourcingu, cyberbezpieczeństwa, tajemnicy zawodowej lub zasad nadzorczych.
Własność intelektualna i dane wprowadzane do systemu
W modelu SaaS licencja na korzystanie z oprogramowania jest zwykle ograniczona, niewyłączna i nieprzenoszalna. To standard, ale jej zakres musi odpowiadać rzeczywistemu użyciu. Wątpliwości mogą dotyczyć korzystania przez spółki z grupy, kontraktorów, klientów klienta, administratorów zewnętrznych albo dostępu przez API.
Równie istotne jest ustalenie, komu przysługują prawa do danych, raportów, konfiguracji, szablonów i rezultatów wygenerowanych w systemie. Dostawca powinien mieć tylko takie uprawnienia do materiałów klienta, jakie są konieczne do wykonania usługi. Klauzula udzielająca szerokiej, nieodpłatnej i nieodwołalnej licencji na wszelkie treści klienta może być nie do pogodzenia z ochroną tajemnicy przedsiębiorstwa, obowiązkami wobec klientów lub zasadami licencjonowania cudzych materiałów.
Warto także ustalić, czy usługodawca zapewnia ochronę przed roszczeniami osób trzecich z tytułu naruszenia praw własności intelektualnej. Wyłączenie takiej odpowiedzialności może być szczególnie ryzykowne, gdy SaaS udostępnia biblioteki treści, komponenty programistyczne lub funkcje generowania materiałów marketingowych.
Limit odpowiedzialności nie może być analizowany w oderwaniu od ryzyka
Najczęściej spotykane ograniczenie odpowiedzialności dostawcy to wielokrotność opłat zapłaconych w określonym okresie, niekiedy z wyłączeniem utraconych korzyści, szkód pośrednich i wszelkich roszczeń związanych z utratą danych. Dla klienta płacącego niski abonament limit może być symboliczny wobec skali potencjalnej szkody.
Nie oznacza to, że każda umowa powinna przewidywać nieograniczoną odpowiedzialność dostawcy. Takie żądanie może być nieproporcjonalne i nierealistyczne w relacji z dużym globalnym podmiotem. Potrzebne jest natomiast świadome rozdzielenie ryzyk. Wyższy albo odrębny limit warto rozważyć dla naruszenia poufności, obowiązków związanych z danymi osobowymi, umyślnego działania, rażącego niedbalstwa oraz roszczeń dotyczących praw własności intelektualnej.
Trzeba przy tym pamiętać, że ograniczenie odpowiedzialności w relacji B2B podlega ocenie według prawa właściwego dla umowy. W kontraktach międzynarodowych wybór prawa obcego i sądu zagranicznego ma znaczenie nie tylko procesowe. Może również wpływać na skuteczność określonych wyłączeń oraz koszt dochodzenia roszczeń.
Wyjście z usługi jest testem jakości kontraktu
Najbardziej pomijanym elementem dokumentacji SaaS jest exit plan. Tymczasem pytanie nie brzmi wyłącznie, czy można wypowiedzieć umowę, lecz czy po jej zakończeniu przedsiębiorca odzyska dane w formacie użytecznym biznesowo i technicznie. Eksport pliku PDF albo niepełnego arkusza kalkulacyjnego nie zawsze pozwoli przenieść historię transakcji, załączniki, metadane, uprawnienia i konfigurację do nowego dostawcy.
Umowa powinna określać okres dostępu do danych po zakończeniu współpracy, format eksportu, ewentualne opłaty, wsparcie migracyjne i termin trwałego usunięcia danych. W przypadku rozwiązań krytycznych warto testować procedurę eksportu jeszcze przed pełnym wdrożeniem. To działanie techniczne, lecz jego sens jest również prawny: pozwala sprawdzić, czy deklarowana przenoszalność danych ma rzeczywistą wartość.
Audyt powinien wykrywać nie tylko wady tekstu, lecz także rozdźwięk między kontraktem a modelem operacyjnym przedsiębiorstwa. Najlepsza umowa nie zastąpi właściwego zarządzania dostępami, klasyfikacji informacji czy procedury reagowania na incydenty. Może jednak zapewnić, że gdy dostawca zmieni warunki, usługa przestanie działać albo dane trzeba będzie odzyskać, firma nie będzie dopiero wtedy odkrywać, jaką cenę ma pozornie prosty abonament.