Jak negocjować umowę dotyczącą oprogramowania dostępnego w modelu SaaS, którego architektura i dane będą zlokalizowane poza infrastrukturą IT organizacji?
Liczba zalet tego rodzaju rozwiązania sprawia, że odbiorcy biznesowi akceptują adhezyjny charakter kontraktu, czyli narzucenie warunków przez dostawcę. Nie oznacza to jednak, że nie należy analizować konkretnych postanowień. Na co szczególnie zwrócić uwagę i jak podejść do takich negocjacji.
Standaryzacja procesów, skalowalność, dostępność z każdego miejsca na Ziemi i z każdego urządzenia, możliwość rozbudowania, brak inwestycji we własną infrastrukturę – wymieniać zalety rozwiązań PaaS i SaaS można długo. Jednak to zmienione środowisko pracy tworzy też unikalną listę ryzyk, które wymagają analizy i weryfikacji w kontekście nienegocjowalnych bądź trudno negocjowalnych umów na rozwiązania chmurowe. Ryzyka te są zależne od branży, w jakiej działa organizacja i związanych z tym regulacji prawnych bądź uwarunkowań biznesowych. Prawne aspekty wdrożeń rozwiązań chmurowych trudno nazwać zatem barierą, stanowią jednak zestaw rozproszonych w organizacji wyzwań, które pociągają za sobą istotne zmiany w rzeczywistości prawnej przedsiębiorstw. Jak poradzić sobie z takim wyzwaniem kontraktowym?
Negocjacje kontraktów dotyczące wdrożenia oprogramowania w modelu on-premise oraz rozwiązań chmurowych to diametralnie odmienne światy. W przypadku chmury mamy najczęściej doczynienia z adhezyjnym modelem umowy, który wymusza na odbiorcy usługi konieczność skupienia się na kwestiach podstawowych z punktu widzenia bezpieczeństwa organizacji w aspekcie biznesowym oraz formalno-prawnym. To zupełnie inne podejście do negocjacji i analizy ryzyka prawnego. Wymaga ono interakcji pomiędzy biznesem i prawnikami, ułożenia wspólnego planu i analizy ryzyka. Pozwala to także odejść od często zbyt drobiazgowej weryfikacji i negocjacji warunków, czego przykładem były choćby rosnące przez ostatnie lata klauzule związane z prawami własności intelektualnej i zastanawianie się czy rzeczywiście zabezpieczono klienta w tym zakresie w należyty sposób.
Brak równowagi kontraktowej
Skala działania dostawców wpływa na to, że z założenia operują oni na ustandaryzowanych warunkach umów. W pewnych obszarach ich elastyczność jest więc znacząco mniejsza, w porównaniu z klasycznymi kontraktami outsourcingowymi w obszarze IT. Nie oznacza to, że nie należy próbować takich umów negocjować. Często istnieje bowiem przestrzeń do indywidualnych ustaleń. Należy zatem próbować wszędzie tam, gdzie to możliwe.
Dostawcy rozwiązań chmurowych to globalni gracze, którzy samodzielnie konstruują proponowany klientom kontrakt (ustandaryzowane warunki kontraktowe). Na linii dostawca–konsument brak zgody na warunki umowy oznacza po prostu rezygnację z usług. Niestety w relacjach z przedsiębiorcami jest tutaj podobnie, aczkolwiek w pewnych aspektach pojawia się przestrzeń na profesjonalne negocjacje. Zanim jednak do nich podejdziemy, należy zaakceptować fakt braku równowagi kontraktowej. Przedstawianych przez dostawcę warunków nie można znacząco zmienić, a w wielu przypadkach w ogóle nie można w nie ingerować.
Bardzo często w umowach chmurowych nie da się negocjować poszczególnych klauzul. Nawet jednak w takich przypadkach istnieją narzędzia umożliwiające poszukiwanie porozumienia – należą do nich np. wspólne interpretacje postanowień umowy oraz dodatkowe deklaracje dostawcy. Dzięki takim dodatkom do umowy możliwe staje się omówienie konkretnych przypadków, które są kluczowe z punktu widzenia prowadzenia działalności biznesowej. To bardzo ważne, gdyż w ostatecznym rozrachunku z uwagi na brak możliwości pogodzenia naszych uzasadnionych oczekiwań z warunkami dostawcy koniecznie może okazać się zakończenie negocjacji i wybór innego rozwiązania.
Naturalnie należy mieć na uwadze, że w artykule mowa jest stricte o umowach z dostawcami usługi chmurowej a nie o umowach dotyczących wdrożenia systemu opartego na danym rozwiązaniu chmurowym. W tym drugim przypadku, o ile oczywiście dane rozwiązanie wymaga np. wielomiesięcznego wdrożenia, umowa wdrożeniowa nie będzie aż tak znacząco różnić się od umowy w modelu on-premise. Należy jednak pamiętać o dążeniu dostawców do standaryzacji, co powoduje, że coraz więcej rozwiązań wymaga mniejszych ingerencji w toku implementacji (nawet przy skomplikowanych wdrożeniach systemów ERP).
Lista ryzyk – swoisty dekalog
Analizę zaproponowanej przez dostawcę umowy należy wykonać zwracając szczególną uwagę na kluczowe ryzyka dla organizacji. Wynikiem takiej analizy powinna być pełna lista ryzyk, która pozwoli spojrzeć na kontrakt z pespektywy specyfiki działalności i uregulowań dotyczących danej organizacji. Dzięki temu stanie się jasne, jakie obszary kontraktu warto razem z dostawcą poddać głębszej analizie i w miarę możliwości postarać się o uzupełnienie ich o dodatkowe niezbędne dla nas postanowienia bądź dokonać stosownych interpretacji. Lista ryzyk powinna być aktualizowana także po podpisaniu umowy – zwłaszcza, jeżeli branża, w jakiej porusza się organizacja, podlega ścisłym i zmieniającym się regulacjom prawnym.
Tak jak wspomniano w odniesieniu do umowy chmurowej nie ma możliwości aby wynegocjować kontrakt, który wyeliminuje wszystkie ryzyka. Jest to zadanie niemal niemożliwe do wykonania. Trzeba jednak wiedzieć na co i dlaczego możemy się zgodzić, ewentualnie jakie faktyczne konsekwencje nam grożą i dlaczego możemy sobie pozwolić na ich akceptację. Wyzwaniem pozostaje również mitygacja ryzyk, których nie możemy wynegocjować, w inny sposób niż poprzez postanowienia kontraktowe.
Na co zwracać szczególną uwagę
Przygotowana przez dany podmiot lista ryzyk powiązana będzie z tym czym na co dzień mierzy się dana organizacja. Są jednak pewne standardowe kwestie, na które warto szczególnie zwrócić uwagę przy nabywaniu usługi chmurowych.
- Jeżeli zakup nie jest dokonywany bezpośrednio u dostawcy, to bardzo ważną kwestią jest czy partner u którego nabywamy usługę chmurową daję rękojmię należytego przeprowadzenia tej transakcji, w tym w szczególności odprowadzania opłat do dostawcy (dystrybutora). Niestety, ale zakup dokonamy u podmiotu, który takiej rękojmi nie daje, może spowodować , że przynajmniej za jakiś okres zapłacimy dwa razy i trudno nam będzie odzyskać poniesione koszty. Ryzykiem w takiej sytuacji pozostaje także wstrzymanie usług.
- Możliwość zmiany umowy. Należy przenalizować czy i w jakim zakresie dostawca może jednostronnie zmieniać warunki umowy, w szczególności czy dotyczy to kluczowych parametrów kontraktu. Niestety są na rynku dostawcy, którzy przyznają sobie w tym zakresie bardzo duże uprawnienia.
- Możliwość zmiany zakresu świadczeń. Wszyscy dostawcy aktualizują swoje oprogramowanie, jest to dla klientów pożądane. Jeśli jednak nasza organizacja funkcjonuje w sektorze mocno obwarowanym przepisami prawa , to wprowadzenie takich zmian w oprogramowaniu może okazać się bardzo dużym ryzykiem. Trzeba zatem przenalizować jaki jest okres wprowadzania poprawek, monitowanie takich zmian, a wreszcie czy istnieje możliwość korzystania (przynajmniej przez jakiś okres) z wersji usługi niezawierającej proponowanych przez dostawcę modyfikacji w oprogramowaniu.
- Wstrzymanie usług. Należy zweryfikować czy i w jakich sytuacjach dostawca może wstrzymać świadczenie usług (zablokować dostęp do oprogramowania).
- Jest to jedna z kluczowych kwestii wymagających analizy, gdyż w przypadku krótkich okresów wypowiedzenia i niedookreślonych przesłanek możemy dnia na dzień stracić dostęp do usługi a przede wszystkim do naszych danych.
- Odpowiedzialność kontraktowa. Tu niestety osoby, które będą starały się negocjować umowę czeka duże rozczarowanie. Niemal wszyscy dostawcy zasłonią się kwestiami korporacyjnymi i brakiem możliwości negocjacji tych postanowień. Otwarte mogą pozostać kwestie kar umownych lub upustów.
- Opłaty. Do zweryfikowania czy poza standardowym (zazwyczaj miesięcznym wynagrodzeniem) występują jakieś inne opłaty dodatkowe, które może naliczać dostawca.
- Cena rozwiązania przy zmianach liczby użytkowników. To szczególnie istotne przy analizie scenariusza zmiany i w sytuacji gdy mamy zaplanowany konkretny rozwój w tym zakresie.
- Exit plan. Exit plan powinniśmy mieć gotowy już w momencie zawierania umowy z dostawcą a później należy go monitorować i dostosowywać do zmieniających się realiów. Aby taki plan miał jednak szanse zadziałać, kontrakt z dostawcą nie może zawierać klauzul, które uniemożliwią jego realizację. W szczególności musimy zatem mieć możliwość dostępu do danych, wyodrębnienia ich i eksportu. U niektórych dostawców możliwe jest również wynegocjowanie dodatkowego czasu po zakończeniu umowy na dostęp do naszych zasobów informcyjnych.
- Sektor finansowy. Niestety usługa chmurowa będzie zazwyczaj kwalifikowana jako outsourcing objęty regulacją, co powoduje, że analiza musi obejmować odniesienie postanowień umowy do wymagań prawnych (wynikających np. z ustawy prawo bankowe) oraz regulacyjnych (KNF). Jest to temat, który nadaje się na zupełnie odrębne opracowanie a praktyka pokazuje, że takie podmioty mają często nieco większy wpływ na treść kontraktu. Warto mieć na uwadze, że poszczególni dostawcy dysponują stosownymi opracowaniami dotyczącymi możliwości korzystania z usług chmurowych w sektorze, uwzględniających obowiązujące przepisy jak i regulacje organów nadzorczych.
Dostęp do firmowych danych w chmurze
Niezbędne do ciągłości funkcjonowania firmy są jej dane, a jeżeli znajdują się one w chmurze obliczeniowej, nie dysponujemy nimi w naszej infrastrukturze ze wszystkimi tego konsekwencjami. Ich przechowywaniem a w dużej mierze także ochroną zajmuje się usługodawca. Mimo to, niezbędnym jest zachowanie nad nimi pełnej kontroli i weryfikacji tego aspektu w kontrakcie. Migracje i eksport danych, warunki, w jakich firma ma prawo do korzystania z nich, okres dostępu w przypadku wypowiedzenia, czy szczegółowe deklaracje w tych obszarach pozwolą wyeliminować podstawowe ryzyko, jakim jest utrata części lub całości zasobów informacyjnych. Jeśli to możliwe należy zapewnić organizacji możliwość ograniczonego „sterowania” swoimi zasobami, także po zakończeniu umowy. Taki moment przejścia z przedłużonym dostępem do danych stwarza komfortowe warunki do wymiany systemu pracy. Z pewnością polityka dotycząca danych stanowi kluczowy punkt Exit planu.
Ważna w tym kontekście jest także weryfikacja czy i jaki zakres dostępu do danych ma dostawca. Umowa nie powinna pozwalać na przeniesienia jakichkolwiek praw do przetwarzanych przez nas informacji w chmurze obliczeniowej. Umowa także nie powinna pozwalać na przetwarzanie naszych informacji, poza celami stricte wynikającymi z konieczności zapewniania świadczenia nam usługi. W tym aspekcie powinna zostać także regulowana kwestia warunków i czasu usunięcia danych przez dostawcę.
Dostępność systemu, SLA i klauzule odpowiedzialności
Jest niezwykle ważne, aby system chmurowy zapewniał stabilność funkcjonowania organizacji. Oznacza to dbałość o dostępność usług, która w kontrakcie może być poruszona ogólnie i lakonicznie. Dostawca rzadko kiedy tworzy klauzule dotyczące własnej odpowiedzialności za niedostarczenie usług. Z punktu widzenia dostawców wyłączanie odpowiedzialności to jeden z ważniejszych aspektów umów chmurowych i niestety musimy się z tym co do zasady pogodzić. Dlatego jednak tak ważny jest precyzyjne opisany dokument SLA (Service Level Agreement), który zawiera definicję produktu, szczegółowy katalog usług, a także opis poziomu/jakości usługi (parametrów). Na tej podstawie biznes w organizacji przy wsparciu prawników będą mogli uzyskać konkretne deklaracje dostawcy i ewentualnie uzyskać upusty/kary umowne. Najważniejsze jest określenie parametru dostępności usługi i przyjęcie takich kryteriów aby dla stron było jasne w jaki sposób jest on obliczany. Inaczej egzekwowanie tego parametru i ewentualne wyciąganie konsekwencji za jego niedotrzymania może okazać się niemożliwe.
Na dostępność systemu mogą wpływać także różne naruszenia warunków umowy po stronie usługobiorcy. Dostawca zastrzega sobie prawo do wstrzymania udostępniania usług. Warto przyjrzeć się tej części kontraktu, zwłaszcza, że często zawiera ona kalki z prawa anglosaskiego, np. tzw. “istotne naruszenie umowy”. W polskim prawie nie istnieje „skalowanie” naruszeń, stąd warto uściślić taki zapis i być może uzupełnić go o konkretne przykłady.
W aspekcie konsekwencji niedotrzymania uzgodnionych warunków, umowy mogą zastrzegać albo kary umowne albo upusty dla klienta (tzw. credits). Są to postanowienia, które bardzo często podlegają negocjacjom. Jeśli decydujemy się na mechanizm kar umownych, to ważne jest prawo ich potrącana (jest to jednak trudne do uzyskania). Mechanizm credits jest w tym kontekście bardziej praktyczny biznesowo.
Bezpieczeństwo usług chmurowych
Wyciek danych, zwłaszcza związanych z danymi osobowymi, jest ryzykiem, które zawsze należy brać pod uwagę. Dostawcy usług chmurowych nie mogą iść na kompromisy w kwestii bezpieczeństwa. Wielomiliardowe inwestycje w ten obszar sprawiają, że rozwiązania chmurowe stają się bezpieczniejsze niż jakiekolwiek inne oprogramowanie lokalne (on-premise). W tym kontekście na pewno warto korzystać z usług największych dostawców, którzy dają rękojmię przygotowania własnych rozwiązań zgodnie z obowiązującymi regulacjami i wdrożenia certyfikacji opartych na normach ISO (np. ISO 27001/2). Ich nakłady w tym zakresie są ogromne.
Nie można jednak zapominać, że cały czas najczęstszą przyczyną wycieku danych jest błąd ludzki a nie podatność oprogramowania. Aby jednak przesunąć jak największą odpowiedzialność na dostawcę wymaga to zastosowania modelu SaaS. Model ten z punktu widzenia przenoszenia odpowiedzialności za utrzymanie i bezpieczeństwo jest najbardziej korzystny dla użytkownika. Jeśli mamy dobrze zweryfikowanego dostawcę, to nasza odpowiedzialność skupia się tylko na warstwie aplikacji w kontekście użytkowym (tożsamości/uprawnienia, kwestia danych które przetwarzamy w aplikacji jak i urządzenia klienckie/stacje robocze). Co do zasady w tym modelu serwery, system operacyjny, sieć jak i bezpieczeństwo samej aplikacji jest po stronie dostawcy. Model “shared responsibility”, który domyślnie obowiązuje strony takiej umowy, zakłada, że usługodawca nie odpowiada za błędy po stronie użytkownika, w tym administracyjne, dostępowe i konfiguracyjnie. Według Gartnera do 2025 roku aż 99% problemów z bezpieczeństwem informatycznym będzie skutkiem błędu użytkownika końcowego. Z tego względu należy wdrażać system z pomocą doświadczonych specjalistów, którzy odpowiednio przeprowadzą proces i zabezpieczą dostęp do oprogramowania oraz danych. W przypadku modelu SaaS istotną wartość stanowi zatem przeniesienie na dostawcę odpowiedzialności za zapewnienie ciągłości działania, a także bezpieczeństwa, wydajności oraz skalowalności całej infrastruktury sprzętowej.
Naturalnie wymagana będzie szeroka analiza zgodności z przepisami związanymi z ochroną danych osobowych (RODO), w tym kontekście przykładowo trzeba ustalić, gdzie zlokalizowane jest centrum przetwarzania danych dostawcy. Wbrew obiegowym opiniom RODO wcale nie faworyzuje rozwiązań on-premise. RODO jest neutralne technologicznie i Tak czy inaczej na etapie kontraktowania zdecydowanie warto uzyskać deklaracje dostawcy o zaprojektowaniu systemu zgodnie z wymaganiami bezpieczeństwa kluczowymi dla naszej organizacji (w tym RODO) i w miarę możliwości zweryfikować te zapewnienia.
Przy analizie wszystkich powyższych zagadnień pamiętajmy, że do chmury łatwiej wejść niż z niej wyjść. Dlatego tak ważna jest weryfikacja kluczowych aspektów dla naszej organizacji, w tym aspektów bezpieczeństwa. Nie warto przy tym poświęcać czasu na negocjowanie kwestii, których w praktyce negocjować się nie da a należy skupić się na mitygacji ryzyk i porównaniu warunków, które oferują poszczególni dostawcy, w kontekście zidentyfikowanych przez nas problemów.