Klauzule bezpieczeństwa w umowach B2B, o których większość firm zapomina

Dlaczego klauzule bezpieczeństwa w B2B są kluczowe, choć często pomijane

Relacje B2B są dziś znacznie bardziej złożone niż jeszcze kilka lat temu. Współpraca obejmuje nie tylko proste dostawy towaru czy świadczenie usług, lecz często również dostęp do systemów informatycznych, danych klientów, know-how, procedur operacyjnych, a nawet do całych procesów biznesowych. Bez dobrze przemyślanych klauzul bezpieczeństwa w umowach B2B ryzyko prawne, finansowe i operacyjne rośnie wykładniczo.

Jak zmieniło się ryzyko w relacjach B2B

Cyfryzacja, outsourcing i praca zdalna sprawiły, że praktycznie każda umowa B2B zawiera elementy, które jeszcze niedawno były typowe tylko dla branży IT lub sektora finansowego. Dziś nawet niewielka agencja marketingowa, software house czy firma logistyczna:

• ma dostęp do systemów klienta (CRM, ERP, systemy magazynowe),
• przetwarza dane klientów końcowych (dane osobowe, dane transakcyjne),
• korzysta z podwykonawców i freelancerów w różnych krajach,
• posługuje się narzędziami chmurowymi, na które klient nie ma bezpośredniego wpływu,
• łączy się z infrastrukturą klienta zdalnie, często z prywatnych urządzeń.

Każdy taki element generuje konkretne ryzyka: wyciek danych, utrata ciągłości działania, blokada dostępu do systemów, roszczenia osób trzecich czy spór o prawa do wytworzonych rozwiązań. Jeżeli umowa B2B jest zbudowana wyłącznie wokół opisania świadczeń i wynagrodzenia, bez mocnych klauzul bezpieczeństwa, to faktycznie nie zabezpiecza interesów stron.

Typowy „szkielet” umowy B2B a realne potrzeby bezpieczeństwa

Standardowa umowa B2B, często wyciągnięta z szuflady albo pobrana z Internetu, zawiera zwykle kilka powtarzalnych elementów:

• strony umowy i definicje,
• przedmiot umowy i zakres usług,
• zasady rozliczeń i fakturowania,
• czas trwania umowy i warunki rozwiązania,
• ogólne postanowienia o poufności,
• kilka zdań o odpowiedzialności i karach umownych.

Na pierwszy rzut oka wygląda to przyzwoicie. Problem zaczyna się, gdy dochodzi do incydentu. Wtedy okazuje się, że:

• nie zdefiniowano, jakie dane są przekazywane i w jaki sposób,
• nie wskazano, kto dokładnie odpowiada za konfigurację i bezpieczeństwo kont użytkowników,
• brakuje precyzyjnego limitu odpowiedzialności albo jest on skopiowany z zupełnie innego modelu współpracy,
• nie ustalono procedury na wypadek incydentu bezpieczeństwa,
• brak jakiegokolwiek „exit planu” na wypadek rozwiązania umowy.

Umowa B2B, która ma działać jak system bezpieczeństwa, musi wyjść poza ogólne formułki. Powinna krok po kroku regulować sposób dostępu do danych i systemów, sposób raportowania problemów, zakres odpowiedzialności, warunki współpracy z podwykonawcami oraz sposób zakończenia współpracy bez paraliżu biznesu.

Skąd biorą się luki w klauzulach bezpieczeństwa

Źródła luk w umowach B2B są stosunkowo powtarzalne. Zwykle pojawia się kombinacja kilku czynników:

• Kopiowanie wzorów – dokumenty są przepisywane z poprzednich kontraktów lub anglojęzycznych szablonów, bez refleksji, czy konkretne klauzule pasują do aktualnego modelu współpracy i polskich przepisów.
• Brak współpracy działów – kontrakt przygotowuje tylko prawnik albo tylko menedżer biznesowy; brakuje konsultacji z IT, bezpieczeństwem, operacjami, co powoduje, że klauzule są oderwane od rzeczywistości technologicznej i procesowej.
• Pośpiech przy podpisywaniu – nacisk na „jak najszybsze startowanie projektu” prowadzi do sytuacji, w której szczegóły bezpieczeństwa odkłada się na później. Tyle że „później” często znaczy „nigdy”.
• Przekonanie, że „przecież się dogadamy” – gdy relacja zaczyna się w dobrej atmosferze, strony często bagatelizują ryzyko sporu i nie chcą „psuć klimatu” twardymi zapisami.

W praktyce to właśnie dobra relacja jest najlepszym momentem, aby na spokojnie poukładać tematy bezpieczeństwa. Po wystąpieniu incydentu trudno już działać racjonalnie, a wszelkie niedookreślone kwestie działają na niekorzyść tej strony, która realnie poniosła szkodę.

Krótki przykład sporu o dane i dostęp do systemu

Przykład z praktyki: firma zleciła zewnętrznemu wykonawcy wdrożenie i dalszy rozwój systemu sprzedażowego. Dostawca utrzymywał system w swojej infrastrukturze, zapewniał hosting, backupy i wsparcie. Umowa przewidywała ogólną klauzulę poufności i kilka zapisów o odpowiedzialności, ale nie zawierała:

• procedury przekazania pełnej kopii danych po zakończeniu umowy,
• konkretnego harmonogramu i formatu eksportu danych,
• prawa zamawiającego do samodzielnego odczytu danych z bazy,
• klauzul o przejęciu kodu źródłowego lub dokumentacji przy określonych zdarzeniach.

Po kilku latach współpracy strony pokłóciły się o ceny dalszego utrzymania. Klient chciał przenieść system do innego dostawcy, ale okazało się, że nie ma technicznej i prawnej ścieżki szybkiego odzyskania danych w użytecznym formacie. Dostawca wykorzystywał ten fakt w negocjacjach, a każda ze stron powoływała się na ogólne postanowienia umowy, które nie przystawały do realiów technicznych. Spór sądowy ciągnął się tyle, że realnie zaszkodził obu biznesom.

Ten scenariusz można było w dużej mierze zneutralizować, stosując kilka prostych klauzul bezpieczeństwa: opis formatu eksportu danych, terminy przekazania, odpowiedzialność za prawidłowość backupów, prawo do audytu sposobu przechowywania danych i jasny „exit plan” na wypadek rozwiązania umowy.

Podstawy prawne bezpieczeństwa w relacjach B2B – ramy, w których porusza się umowa

Przed dopisaniem do umowy B2B kolejnych klauzul bezpieczeństwa trzeba zrozumieć, w jakich ramach prawnych porusza się taka regulacja. Część spraw można uregulować dowolnie, inne są ograniczone przepisami bezwzględnie obowiązującymi. Zdarzają się też obszary, w których zbyt śmiałe kopiowanie anglojęzycznych wzorów może przynieść efekt odwrotny do zamierzonego.

Swoboda umów i jej granice

Polskie prawo cywilne opiera się na zasadzie swobody umów (art. 353¹ kodeksu cywilnego). Co do zasady strony mogą kształtować stosunek prawny według własnego uznania, byleby jego treść lub cel:

• nie sprzeciwiały się właściwości (naturze) stosunku,
• nie były sprzeczne z ustawą,
• nie naruszały zasad współżycia społecznego.

W praktyce daje to dość szerokie pole do regulowania klauzul bezpieczeństwa w umowach B2B. Można m.in.:

• ograniczać lub rozszerzać odpowiedzialność kontraktową w granicach wyznaczonych przez prawo,
• proceduralizować kwestie dostępu do systemów, reakcji na incydenty, audytów, przekazywania danych,
• wprowadzać szczególne mechanizmy kontroli podwykonawców i łańcucha dostaw,
• ustalać szczegółowe zasady poufności wykraczające poza standardową ochronę tajemnicy przedsiębiorstwa.

Są jednak granice. Nie można np. skutecznie wyłączyć odpowiedzialności za szkodę wyrządzoną umyślnie, a próby skrajnego ograniczania odpowiedzialności za rażące niedbalstwo bywały w orzecznictwie oceniane krytycznie. Nie można też klauzulą umowną „zastąpić” obowiązków wynikających z RODO czy przepisów o zwalczaniu nieuczciwej konkurencji.

Odpowiedzialność kontraktowa i deliktowa – praktyczne konsekwencje

Dla konstrukcji klauzul bezpieczeństwa znaczenie ma różnica między odpowiedzialnością:

• kontraktową – za niewykonanie lub nienależyte wykonanie zobowiązania wynikającego z umowy,
• deliktową – za czyn niedozwolony, np. naruszenie dóbr osobistych, szkoda wyrządzona osobie trzeciej niezależnie od istnienia umowy.

Ograniczenia odpowiedzialności i kary umowne co do zasady odnoszą się do odpowiedzialności kontraktowej między stronami. Nie zawsze obejmują szkody wyrządzone osobom trzecim (np. klientom końcowym), za które jedna ze stron zostanie obciążona na podstawie innych przepisów. Stąd w umowach B2B trzeba świadomie zdecydować, czy:

• limit odpowiedzialności dotyczy wyłącznie roszczeń między stronami,
• obejmuje również regres lub zwrot kosztów roszczeń osób trzecich,
• wprowadza się mechanizmy zwolnienia z odpowiedzialności (tzw. indemnity) za określone kategorie roszczeń.

Dodatkowo w praktyce pojawia się kwestia szkód pośrednich (utracone korzyści, downtime, utrata reputacji). Jeżeli umowa nic o nich nie mówi, obowiązują zasady ogólne, które mogą być dla jednej ze stron nieakceptowalne. Dlatego klauzule bezpieczeństwa powinny możliwie precyzyjnie opisywać, jakie szkody są wliczone do limitu, a jakie są z niego wyłączone lub dodatkowo ograniczone.

Relacja pomiędzy umową główną, załącznikami, SLA i umową powierzenia

Bezpieczeństwo w relacjach B2B rzadko da się opisać w jednym, krótkim dokumencie. Często pojawia się układ wielowarstwowy:

• umowa główna – określa ogólne zasady współpracy, odpowiedzialność, mechanizmy rozwiązywania sporów,
• SLA (Service Level Agreement) – doprecyzowuje poziomy usług, czasy reakcji, dostępność systemów,
• umowa powierzenia przetwarzania danych (DPA) – reguluje kwestie RODO,
• załączniki techniczne – opisują architekturę systemu, interfejsy, procesy backupowe,
• polityki bezpieczeństwa i regulaminy – wewnętrzne dokumenty usługodawcy, do których odwołuje się umowa.

Kluczowe jest spójne powiązanie tych dokumentów. W praktyce warto zadbać o to, aby:

• wyraźnie wskazać hierarchię dokumentów (co ma pierwszeństwo w razie sprzeczności),
• zadbać, aby zmiany w politykach bezpieczeństwa czy SLA nie były wprowadzane jednostronnie bez prawa do sprzeciwu lub rozwiązania umowy,
• zachować spójność pojęciową – te same terminy (np. „Dane Klienta”, „System”, „Incydent”) powinny mieć tę samą definicję we wszystkich dokumentach lub wyraźne odwołania.

Niespójność między umową główną a załącznikami bywa częstym źródłem sporów. Przykład: umowa główna przewiduje kary za niedotrzymanie dostępności na poziomie 99,9%, a w SLA zapisano inną wartość lub inny sposób jej liczenia. Przy braku jasnej hierarchii dokumentów spór interpretacyjny jest niemal pewny.

Znaczenie przepisów szczególnych: RODO, nieuczciwa konkurencja, prawo pracy

Niektóre zagadnienia bezpieczeństwa nie mogą być regulowane całkowicie dowolnie, bo podlegają ustawom szczególnym. W relacjach B2B najczęściej pojawiają się:

• RODO i krajowe przepisy o ochronie danych osobowych – definiują role (administrator, procesor), minimalny zakres umowy powierzenia, obowiązek dokumentowania naruszeń, obowiązki wobec osób, których dane dotyczą.
• Ustawa o zwalczaniu nieuczciwej konkurencji – reguluje ochronę tajemnicy przedsiębiorstwa, zakaz rozpowszechniania cudzych tajemnic, zasady konkurencji; wpływa na zakres dopuszczalnych klauzul lojalnościowych i antykonkurencyjnych.
• Prawo pracy – przy umowach B2B z osobami fizycznymi (tzw. quasi-etaty) zbyt sztywne ukształtowanie stosunku może prowadzić do zarzutów obejścia przepisów prawa pracy (np. gdy kontraktor jest w praktyce podporządkowany jak pracownik).

Klauzule bezpieczeństwa muszą więc uwzględniać te regulacje. Przykład: nie wystarczy napisać, że „procesor nie ponosi żadnej odpowiedzialności za naruszenia danych osobowych”, ponieważ przepisy RODO przewidują określoną odpowiedzialność zarówno po stronie administratora, jak i procesora. Podobnie całkowite wyłączenie odpowiedzialności za naruszenie tajemnicy przedsiębiorstwa kontrahenta byłoby sprzeczne z ustawą.

Pułapki kopiowania anglojęzycznych wzorów

Wiele polskich firm korzysta z anglojęzycznych wzorów NDA, umów o świadczenie usług czy ogólnych warunków, w których pojawiają się rozbudowane konstrukcje typu indemnity, hold harmless, liquidated damages, gross negligence. Problem w tym, że:

w polskim porządku prawnym nie mają one prostych odpowiedników albo ich sens jest inny niż w systemach common law. Bezrefleksyjne „wklejenie” takich postanowień, a następnie dosztukowanie polskich przepisów często kończy się wewnętrzną sprzecznością dokumentu. W razie sporu sąd będzie szukał znaczenia przede wszystkim w prawie krajowym, a nie w tym, co strony „miała na myśli” przy kopiowaniu zagranicznego wzorca.

Przykładowo, szeroka klauzula indemnity z wzorca amerykańskiego, przewidująca przejęcie „wszelkiej odpowiedzialności” za roszczenia osób trzecich, może w praktyce zostać odczytana jako zobowiązanie do zwrotu kosztów określonego rodzaju szkód, ale już nie jako „wyłączenie” odpowiedzialności tej strony wobec poszkodowanych. Z kolei pojęcie gross negligence nie jest wprost zdefiniowane w polskim prawie; sądy posługują się kategorią „rażącego niedbalstwa”, ale zakres i skutki takiego zastrzeżenia bywają inne niż w systemie anglosaskim. Stąd każde takie pojęcie trzeba przełożyć na język polskiego prawa i opisać, co dokładnie strony chcą nim objąć.

Podobnie jest z klauzulami liquidated damages (zryczałtowane odszkodowanie). W Polsce ich odpowiednikiem są zwykle kary umowne, które rządzą się własnymi zasadami: co do zasady przysługują tylko za niewykonanie lub nienależyte wykonanie zobowiązania niepieniężnego, mogą być miarkowane przez sąd, a całkowite wyłączenie odpowiedzialności ponad karę umowną wymaga precyzyjnych zapisów. Kopiowanie obcych konstrukcji bez dostosowania do tych reguł prowadzi do rozczarowań po pierwszym poważnym incydencie bezpieczeństwa, kiedy strony odkrywają, że ich „twarde” postanowienia nie działają tak, jak zakładały.

Bezpieczniejsze podejście polega na tym, aby zamiast egzotycznych klauzul wprowadzać możliwie proste, opisowe mechanizmy, oparte na znanych instytucjach prawa polskiego: jasno określone limity odpowiedzialności, precyzyjnie zdefiniowane kary umowne, zastrzeżenia co do szkód pośrednich czy regresu, a w razie potrzeby – odwołania do konkretnych przepisów. Jeżeli strony decydują się mimo wszystko na użycie pojęć zapożyczonych z prawa obcego, dobrze jest uzupełnić je definicjami i doprecyzować, jak mają być rozumiane w świetle prawa polskiego.

Starannie zaprojektowane klauzule bezpieczeństwa nie są „ozdobą” umowy, lecz narzędziem zarządzania ryzykiem po obu stronach. Im większa transparentność co do tego, kto, za co i w jakim zakresie odpowiada, tym mniejsze szanse na kosztowny spór po wystąpieniu incydentu. W praktyce najwięcej zyskują ci, którzy łączą rozsądne standardy techniczne z dobrze napisaną, osadzoną w polskim prawie częścią kontraktową – bez ślepego kopiowania obcych wzorców i bez iluzji, że sam paragraf zastąpi faktyczne bezpieczeństwo procesów i systemów.

Bezpieczeństwo w łańcuchu podwykonawców i dostawców

Ryzyko rzadko kończy się na bezpośredniej relacji dwóch firm. Usługodawca niemal zawsze korzysta z podwykonawców: dostawców chmury, centrów danych, usług monitoringu, utrzymania aplikacji, a czasem freelancerów. Jeżeli umowa nie reguluje tego poziomu, pojawia się klasyczny problem „najsłabszego ogniwa”.

Przy projektowaniu klauzul bezpieczeństwa dobrze jest zadać sobie kilka podstawowych pytań i przełożyć je na konkretne postanowienia:

• czy i w jakim zakresie usługodawca może korzystać z podwykonawców,
• czy korzystanie z kluczowych podwykonawców wymaga zgody lub choćby poinformowania kontrahenta,
• jakie minimalne standardy bezpieczeństwa muszą spełniać podwykonawcy (np. lokalizacja danych, certyfikacje, mechanizmy szyfrowania),
• kto odpowiada za szkody wyrządzone przez podwykonawców – czy w pełni usługodawca, czy w jakimś zakresie odpowiedzialność jest dzielona lub ograniczana,
• jak wygląda transfer danych do podmiotów zewnętrznych, w tym poza EOG.

Z punktu widzenia klienta kluczowy jest prosty efekt: chce mieć jednego odpowiedzialnego partnera, a nie tłumaczeń, że „to wina data center” albo „to problem chmury publicznej”. Klauzula może więc wprost przewidywać, że usługodawca ponosi odpowiedzialność za działania i zaniechania podwykonawców jak za własne, z zastrzeżeniem określonych wyjątków (np. awaria globalnego dostawcy chmury o charakterze siły wyższej, o ile została prawidłowo zakomunikowana i obsłużona).

Od drugiej strony, dostawca usług potrzebuje elastyczności. Zbyt sztywny zakaz korzystania z podwykonawców lub obowiązek każdorazowej zgody kontrahenta może sparaliżować możliwość skalowania usługi. Zwykle sprawdza się kompromis: swoboda korzystania z „typowych” podwykonawców (np. infrastruktura chmurowa) przy jednoczesnym obowiązku informowania o zmianach listy tzw. istotnych subprocesorów i prawie klienta do sprzeciwu w sytuacjach o wyższym ryzyku.

Przykładowa konstrukcja, często pomijana, to obowiązek zapewnienia przez usługodawcę, aby jego podwykonawcy byli związani umowami co najmniej tak restrykcyjnymi jak umowa główna w zakresie bezpieczeństwa informacji i ochrony danych. Bez takiego „przeniesienia” wymogów do łańcucha dostaw powstaje luka: na poziomie głównej umowy wymagania są wysokie, ale dalej w dół łańcucha nie mają odzwierciedlenia w kontraktach.

Klauzule dotyczące audytów, testów penetracyjnych i prawa do kontroli

Bezpieczeństwo to nie tylko deklaracje w umowie, ale też możliwość ich weryfikacji. Z tego powodu w relacjach B2B coraz częściej pojawiają się klauzule dotyczące audytów, testów penetracyjnych, przeglądów bezpieczeństwa.

Takie postanowienia bywają jednak formułowane skrajnie: od całkowitego braku prawa do kontroli po bardzo rozbudowane uprawnienia audytowe, które w praktyce są niemożliwe do wykonania. Rozsądne podejście zakłada zbalansowanie interesów stron poprzez:

• określenie, kto ma prawo przeprowadzać audyt (sam kontrahent, podmiot trzeci, audytor zewnętrzny),
• wskazanie minimalnego zakresu audytu (np. zgodność z określonym standardem, wybrane systemy, procesy backupu i przywracania),
• ustalenie częstotliwości i zasad zapowiedzi audytu (np. z wyprzedzeniem kilkunastu dni, z wyjątkiem sytuacji po incydencie bezpieczeństwa),
• opisanie sposobu dostępu do informacji, tak aby nie naruszać tajemnicy przedsiębiorstwa usługodawcy ani prywatności innych klientów,
• uporządkowanie kwestii kosztów – kto i w jakich sytuacjach je ponosi.

W obszarze testów penetracyjnych pojawia się jeszcze jedna praktyczna kwestia: oddziaływanie testów na infrastrukturę produkcyjną. Jeżeli klient ma prawo samodzielnie zlecać testy na systemie produkcyjnym usługodawcy, a umowa nie reguluje harmonogramu i parametrów takich testów, łatwo o niezamierzone skutki (spadek wydajności, fałszywe alarmy, a nawet incydenty bezpieczeństwa).

Z tego powodu klauzule dotyczące testów i audytów powinny:

• rozróżniać audyty dokumentacyjne (przegląd procedur, polityk, logów) od technicznych testów penetracyjnych,
• zawierać wymóg uzgodnienia scenariusza testów, okien czasowych oraz ograniczeń technicznych (np. zakaz ataków typu DoS na środowisko produkcyjne),
• regulować status raportów z audytów – kto je otrzymuje, w jakim zakresie, w jakim stopniu mogą być udostępniane dalej (np. regulatorom).

Często rozsądnym kompromisem jest zapewnienie klientowi dostępu do cyklicznych, zewnętrznych audytów usługodawcy (np. raporty z audytów ISO, SOC) oraz możliwość przeprowadzenia własnego audytu tylko przy zaistnieniu istotnego powodu (poważny incydent, istotna zmiana zakresu przetwarzania danych, wymóg regulatora).

Zmiana poziomu ryzyka w trakcie trwania umowy – klauzule rewizyjne

Umowy B2B, szczególnie IT i outsourcingowe, trwają często kilka lat. Ryzyko bezpieczeństwa nie pozostaje w tym czasie stałe: zmieniają się technologie, modele ataków, otoczenie regulacyjne (np. nowe wytyczne organów nadzorczych). Jeżeli umowa jest „sztywna” i nie przewiduje mechanizmów dostosowania, po pewnym czasie przestaje odpowiadać realiom.

W praktyce przydają się klauzule rewizyjne, które umożliwiają:

• aktualizację standardów bezpieczeństwa (np. odwołanie do aktualnych wersji norm, możliwość zaostrzenia wymogów w razie nowych regulacji),
• modyfikację procedur obsługi incydentów, gdy okazują się niewystarczające lub zbyt kosztowne organizacyjnie,
• przegląd limitów odpowiedzialności i kar umownych przy istotnej zmianie skali współpracy (np. znaczący wzrost wolumenu danych lub obrotu).

Tego typu postanowienia powinny zawierać zarówno mechanizm inicjowania przeglądu (np. raz do roku lub po określonym wydarzeniu), jak i konsekwencje braku porozumienia. Spotykanym rozwiązaniem jest wprowadzenie progu tolerancji: do pewnego poziomu zaostrzenia wymogów bezpieczeństwa strony przyjmują je automatycznie, ponad ten limit zmiana wymaga aneksu, a w razie braku zgody – przewidziana jest możliwość zakończenia współpracy z zachowaniem określonego okresu wypowiedzenia.

Bez klauzul rewizyjnych strony często „utykają” w umowie niedostosowanej do nowego poziomu ryzyka. Dostawca obawia się podnosić temat, bo każda zmiana wymaga pełnej renegocjacji kontraktu, a klient nie ma formalnego narzędzia, aby domagać się podniesienia standardów, mimo że skala i wrażliwość danych dawno się zmieniły.

Bezpieczeństwo a zakończenie współpracy – klauzule „exitowe”

Moment zakończenia współpracy jest jednym z najbardziej newralgicznych etapów z punktu widzenia bezpieczeństwa. Dane są migrowane, dostęp do systemów musi zostać odebrany, część infrastruktury jest wygaszana. Jeżeli w umowie brakuje szczegółowych postanowień na ten temat, pojawia się pole do sporów i niepewności.

Klauzule „exitowe” związane z bezpieczeństwem powinny w szczególności obejmować:

• procedurę przekazania danych – w jakim formacie, w jakich terminach, w jaki sposób zabezpieczony jest transfer, kto ponosi koszty migracji,
• termin i sposób usunięcia lub zanonimizowania danych po zakończeniu umowy, łącznie z obowiązkiem udokumentowania tego procesu (np. protokół usunięcia, raport z nadpisania nośników),
• zasady wygaszania dostępów (kont użytkowników, kluczy API, dostępów administracyjnych) oraz maksymalne terminy na ich dezaktywację,
• obsługę logów i kopii zapasowych – jak długo są przechowywane po zakończeniu umowy i na jakich zasadach mogą być udostępniane byłemu klientowi (np. na potrzeby obrony przed roszczeniami),
• możliwość krótkotrwałego „podtrzymania” usług w trybie przejściowym, gdy migracja do nowego dostawcy wymaga więcej czasu niż pierwotnie założono.

W praktyce kontrowersje budzi zwykle zakres i koszt wsparcia migracyjnego. Dostawca nie chce brać na siebie pełnej odpowiedzialności za przejście systemów do podmiotu trzeciego, klient natomiast oczekuje sprawnego i bezpiecznego transferu danych. Rozwiązaniem może być wprowadzenie ramowego obowiązku współpracy przy migracji, z oddzielnie wynagradzanym zakresem prac, przy jednoczesnym zachowaniu minimalnych standardów bezpieczeństwa (np. szyfrowanie kanałów, ograniczenie dostępu do danych migracyjnych do wąskiego grona osób).

Często pomijanym elementem jest utrzymanie poufności i zakaz wykorzystywania danych także po wygaśnięciu umowy. Jeżeli klauzule poufności są ograniczone wyłącznie do okresu obowiązywania kontraktu, po jego zakończeniu powstaje ryzyko niewystarczającej ochrony informacji – szczególnie gdy mowa o dokumentacji technicznej, kodzie źródłowym czy know-how przekazanym usługodawcy.

Bezpieczeństwo informacji a własność intelektualna i know-how

Ochrona poufności często skupia się na danych osobowych lub tajemnicy przedsiębiorstwa w sensie biznesowym. Tymczasem w wielu relacjach B2B równie istotne są kwestie własności intelektualnej i know-how: kod źródłowy, dokumentacja systemów, konfiguracje, modele uczenia maszynowego, bazy reguł, skrypty automatyzujące procesy.

Jeżeli w umowie nie zgra się ze sobą części dotyczącej praw własności intelektualnej i klauzul bezpieczeństwa, może dojść do niezamierzonych efektów. Przykład z praktyki: dostawca oprogramowania, chcąc zabezpieczyć swój kod, wprowadza bardzo ograniczone uprawnienia audytowe i zakazy dekompilacji. Klient z kolei, mając obowiązki regulacyjne, domaga się pełnego wglądu w kod w razie incydentu bezpieczeństwa lub podejrzenia backdoora. Brak jasnych reguł na ten temat kończy się konfliktem przy pierwszym poważnym problemie.

Rozsądne klauzule bezpieczeństwa powinny zatem odwoływać się do ustaleń w zakresie własności intelektualnej i wyraźnie wskazywać:

• w jakim zakresie klient może analizować i testować oprogramowanie usługodawcy (w tym poprzez testy bezpieczeństwa),
• czy dopuszczalny jest dostęp do kodu źródłowego, a jeśli tak – na jakich zasadach (np. escrow, dostęp wyłącznie w ściśle określonych sytuacjach),
• jakie ograniczenia obowiązują przy przetwarzaniu danych treningowych, modeli i wyników uczenia maszynowego, jeśli są oparte na danych przekazanych przez klienta,
• w jaki sposób chronione są materiały szkoleniowe, procedury i inne elementy know-how obu stron.

Bez takich postanowień dochodzi niekiedy do paradoksu: aby skutecznie zbadać przyczynę incydentu bezpieczeństwa, klient musi naruszyć zapisy licencyjne dostawcy (np. zakaz reverse engineering), albo odwrotnie – dostawca, chcąc udowodnić brak swojej winy, musi ujawnić więcej szczegółów technicznych, niż przewidywała pierwotna umowa. Jasne zasady współpracy w tym obszarze zmniejszają ryzyko, że bezpieczeństwo i własność intelektualna będą ciągnąć w przeciwne strony.

Bezpieczeństwo a ubezpieczenia odpowiedzialności cywilnej i cyber

Coraz częściej elementem kontraktowego „ekosystemu bezpieczeństwa” są ubezpieczenia – zarówno klasyczne polisy OC prowadzonej działalności, jak i wyspecjalizowane ubezpieczenia cyber. Umowy B2B często jednak ograniczają się do lakonicznego stwierdzenia, że „strony posiadają stosowne ubezpieczenie”, bez doprecyzowania czegokolwiek więcej.

Tymczasem dobrze opisane w umowie relacje między odpowiedzialnością kontraktową a ubezpieczeniem potrafią istotnie zmniejszyć ryzyko finansowe i ułatwić likwidację szkody. Warto rozważyć m.in.:

• czy posiadanie określonego rodzaju polisy (np. cyber) jest obowiązkiem stron, czy tylko rekomendacją,
• minimalne sumy gwarancyjne i zakres ochrony (np. czy obejmuje koszty reagowania na incydent, powiadomień, obsługi prawnej, roszczeń osób trzecich),
• obowiązek utrzymania polisy przez cały okres umowy oraz przez określony czas po jej zakończeniu (tzw. okres zgłaszania roszczeń),
• obowiązek przedstawienia potwierdzenia ubezpieczenia i informowania o jego zmianach lub wygaśnięciu,
• koordynację zgłaszania szkód do ubezpieczyciela z obowiązkami umownymi (np. terminy raportowania incydentów).

Bez takich ustaleń klient może z zaskoczeniem odkryć, że dostawca, odpowiedzialny za poważny incydent bezpieczeństwa, w ogóle nie ma ubezpieczenia lub jego polisa nie obejmuje większości poniesionych szkód. Z drugiej strony zbyt rygorystyczne i oderwane od realiów wymogi ubezpieczeniowe (wysokie sumy gwarancyjne, bardzo szeroki zakres) mogą wykluczyć z rynku mniejsze, ale kompetentne podmioty, które po prostu nie są w stanie spełnić tak wygórowanych oczekiwań.

Bezpieczeństwo a przepływ informacji wewnątrz organizacji

Nawet najlepiej napisane klauzule bezpieczeństwa nie zadziałają, jeśli wiedza o nich nie „zejdzie” do osób, które faktycznie realizują umowę. W praktyce dość często spotyka się sytuację, w której dział prawny wynegocjował rozbudowane postanowienia, ale zespół IT lub operacyjny nie został o nich poinformowany albo rozumie je inaczej.

Umowa może częściowo adresować ten problem poprzez:

• nałożenie obowiązku przekazania istotnych postanowień umownych (np. wymogów bezpieczeństwa, procedur reagowania na incydenty, zasad dostępu do danych) wszystkim osobom zaangażowanym w realizację kontraktu po stronie każdej ze stron,
• wskazanie po jednej osobie kontaktowej ds. bezpieczeństwa po każdej stronie, odpowiedzialnej zarówno za komunikację przy incydentach, jak i za bieżące wyjaśnianie wątpliwości dotyczących stosowania umowy,
• zobowiązanie stron do okresowych szkoleń wewnętrznych z wymogów bezpieczeństwa wynikających z kontraktu (np. przed startem projektu i przy istotnej zmianie zakresu współpracy),
• uregulowanie zasad korzystania z podwykonawców i dostawców technologicznych – tak, aby kluczowe wymogi bezpieczeństwa były im formalnie przekazywane i odpowiednio „flow-downowane” w umowach niższego rzędu.

W relacjach, w których bezpieczeństwo ma krytyczne znaczenie (np. usługi chmurowe, outsourcing IT, przetwarzanie danych wrażliwych), przydaje się też mechanizm cyklicznych spotkań roboczych. Umowa może przewidywać np. kwartalne przeglądy bezpieczeństwa z udziałem przedstawicieli IT, bezpieczeństwa i biznesu. Ich celem jest nie tylko omówienie incydentów, ale również zmian po stronie infrastruktury, nowych integracji, planowanych wdrożeń czy modyfikacji procesu, które mogą wpływać na poziom ryzyka.

Osobnym zagadnieniem jest sposób dokumentowania komunikacji dotyczącej bezpieczeństwa. Uporządkowane procedury (np. obowiązek potwierdzania ustaleń mailowo, prowadzenie rejestru incydentów i istotnych zmian) ograniczają spory co do tego, co faktycznie zostało uzgodnione, kto o czym wiedział i kiedy. W praktyce dobrze działa powiązanie tych wymogów z istniejącymi narzędziami (system ticketowy, narzędzie do zarządzania zmianą, dedykowana skrzynka e-mail), zamiast tworzenia „równoległego świata” tylko na potrzeby jednej umowy.

Przy bardziej złożonych projektach sensowne bywa także powiązanie klauzul bezpieczeństwa z systemem motywacyjnym i wskaźnikami jakościowymi (KPI). Jeżeli określone wymagania bezpieczeństwa są powiązane z premiami, karami umownymi lub warunkami przedłużenia kontraktu, rośnie szansa, że nie pozostaną jedynie „prawniczym załącznikiem”, ale będą faktycznie uwzględniane przy codziennych decyzjach.

Dobrze skonstruowane klauzule bezpieczeństwa w umowach B2B nie zastąpią dojrzałego podejścia do ryzyka w organizacji, ale potrafią uporządkować oczekiwania, wyznaczyć minimalny standard i ułatwić działanie wtedy, gdy dzieje się coś nieprzewidzianego. Im wcześniej bezpieczeństwo zostanie włączone do rozmowy kontraktowej – obok ceny, zakresu i terminów – tym mniejsze prawdopodobieństwo, że przy pierwszym poważnym incydencie obie strony zorientują się, że ich wyobrażenia były zupełnie odmienne.

Bezpieczeństwo danych i systemów – klauzule wykraczające poza standardowy RODO-DPA

RODO i DPA to dopiero punkt wyjścia

Standardowy załącznik powierzeniowy (DPA) reguluje przetwarzanie danych osobowych. W relacjach B2B często jest traktowany jako „główna” klauzula bezpieczeństwa, chociaż w istocie dotyka tylko części problemu. Większość krytycznych zagadnień – integralność systemów, dostęp uprzywilejowany, logowanie, backupy, bezpieczeństwo środowisk testowych, odporność na awarie – wymyka się poza klasyczne ramy RODO.

Jeżeli w umowie nie pojawią się postanowienia dotyczące bezpieczeństwa całości środowiska technologicznego, powstaje luka: dane osobowe są formalnie chronione, ale aplikacja biznesowa, na której opiera się działalność klienta, może być utrzymywana w sposób odbiegający od branżowego minimum. Regulacje sektorowe (np. finansowe, telekomunikacyjne, medyczne) częściowo tę lukę wypełniają, jednak w wielu sektorach jedynym realnym „bezpiecznikiem” pozostaje umowa.

Standardy, normy i dobre praktyki jako punkt odniesienia

Jednym z częściej pomijanych wątków jest wskazanie wprost, do jakich standardów i dobrych praktyk bezpieczeństwa ma odwoływać się dostawca. W praktyce zamiast ogólnego hasła „zapewni standardy bezpieczeństwa zgodne z najlepszą praktyką rynkową” lepiej działa odniesienie do konkretnych ram, na przykład:

• ISO/IEC 27001 wraz z odpowiednimi normami uzupełniającymi (np. 27017, 27018) – jako odniesienie do zarządzania bezpieczeństwem informacji,
• NIST Cybersecurity Framework – jako zbiór funkcji i kategorii, do których można przypisać wymagania umowne,
• branżowe wytyczne regulatorów (np. EBA w sektorze finansowym, krajowe zalecenia dla podmiotów świadczących usługi kluczowe).

Nie zawsze chodzi o formalną certyfikację. Częściej o zobowiązanie, że rozwiązania techniczne i organizacyjne będą zaprojektowane co najmniej na poziomie odpowiadającym wskazanemu standardowi. Umowa może przewidywać także obowiązek przedstawienia przez dostawcę polityk, procedur lub raportów z audytów wewnętrznych, które potwierdzają, że nie są to jedynie deklaracje marketingowe.

Poziom usług bezpieczeństwa (Security SLA)

SLA zwykle obejmuje dostępność usługi, rzadziej natomiast precyzuje parametry bezpieczeństwa. Tymczasem w wielu współpracach kluczowe są nie tylko procenty uptime, ale też czas reakcji na incydent czy sposób eskalacji zgłoszeń. W tym obszarze przydają się postanowienia określające m.in.:

• czas reakcji na zgłoszenie potencjalnego incydentu bezpieczeństwa (np. pierwsza reakcja w ciągu 1–2 godzin),
• czas na podjęcie działań ograniczających skutki incydentu (containment),
• poziomy krytyczności zgłoszeń i odpowiadające im ścieżki eskalacji,
• format i częstotliwość raportów z obsługi incydentu (np. raport wstępny, raport końcowy z przyczyną źródłową i planem działań korygujących).

W relacjach o podwyższonym ryzyku można także określić wymagania dotyczące ciągłego monitoringu, np. obowiązek stosowania systemów wykrywania włamań (IDS/IPS), korelacji logów (SIEM) czy alertów w razie nietypowych zdarzeń. Takie postanowienia lepiej sytuować w aneksach technicznych, ale ich istnienie powinno wynikać już z samej umowy głównej.

Bezpieczeństwo środowisk testowych i developerskich

W praktyce zawodzą nie tyle systemy produkcyjne, co „poboczne” środowiska testowe, deweloperskie, UAT. Często są słabiej zabezpieczone, a jednocześnie zawierają zanonimizowane jedynie częściowo lub w ogóle nieprzetworzone dane rzeczywiste. W umowie można wprost przesądzić kilka punktów, o których wiele organizacji zapomina:

• zakaz używania danych produkcyjnych w środowiskach testowych bez uprzedniej anonimizacji lub pseudonimizacji,
• wymóg stosowania takich samych lub zbliżonych standardów bezpieczeństwa (uwierzytelnianie, kontrola dostępu, logowanie) jak na produkcji,
• obowiązek usuwania lub bezpiecznego nadpisywania danych testowych po zakończeniu określonych prac,
• szczególne ograniczenia w dostępie do środowisk testowych dla podwykonawców lub personelu zewnętrznego.

Brak takich regulacji sprzyja „tymczasowym” wyjątkom, które w praktyce stają się standardem – do momentu, gdy wyciek danych z niepozornego środowiska testowego okaże się równie dotkliwy jak atak na produkcję.

Zarządzanie tożsamością i dostępem (IAM)

Większość incydentów ma związek z dostępami nadmiernymi albo nieaktualnymi. Umowa powinna w co najmniej podstawowym zakresie regulować zasady zarządzania tożsamością i uprawnieniami. W szczególności przydaje się doprecyzowanie, że:

• wszystkie dostępy użytkowników (w tym administratorów) są tworzone imiennie, a nie jako „kont wspólnych”,
• stosowany jest mechanizm silnego uwierzytelniania (np. MFA) tam, gdzie ryzyko tego wymaga,
• istnieje i jest realizowany proces regularnego przeglądu uprawnień (np. kwartalne lub półroczne recertyfikacje),
• odejścia pracowników oraz zmiany ról po stronie dostawcy i klienta skutkują niezwłoczną aktualizacją dostępów,
• uprawnienia administracyjne są oddzielone od zwykłych kont użytkowników i używane wyłącznie do zadań administracyjnych.

W umowach z podmiotami odpowiedzialnymi za utrzymanie infrastruktury lub usługę chmurową przydatne jest też wskazanie, w jaki sposób strona klienta może zweryfikować, jakie konta i uprawnienia istnieją po stronie dostawcy, oraz jak wygląda proces ich nadawania i odbierania.

Logowanie, audyt i retencja danych technicznych

Bez odpowiednich logów i ścieżek audytu ustalenie przyczyn incydentu bywa niemożliwe. Umowy B2B często poprzestają na ogólnym zapewnieniu, że „dostawca prowadzi dzienniki zdarzeń”, bez wskazania parametrów tego obowiązku. W bardziej świadomym podejściu kontraktowym strony uzgadniają m.in.:

• jakie kategorie zdarzeń muszą być logowane (np. logowania, zmiany uprawnień, operacje na danych, działania administracyjne),
• minimalny okres przechowywania logów oraz sposób ich zabezpieczenia przed modyfikacją,
• dostęp klienta do logów dotyczących jego środowiska – czy w czasie rzeczywistym, czy na wniosek, w jakim terminie i formacie,
• zasady udostępniania logów osobom trzecim (np. organom ścigania, regulatorom, ubezpieczycielom),
• czy logi mogą zawierać dane osobowe i jak wtedy zabezpieczyć je pod kątem RODO.

W umowach dotyczących systemów o znaczeniu krytycznym można dodać wymóg stosowania narzędzi do centralnego zarządzania logami oraz mechanizmów wykrywania anomalii. Takie postanowienia są często negocjowane, ale w praktyce bardzo ułatwiają późniejszą analizę incydentów i rozstrzyganie sporów o przyczyny.

Backupy, odtworzenie po awarii i testowanie planów ciągłości działania

Backupy są powszechnie wspominane w umowach, ale zazwyczaj w sposób bardzo ogólny. Gdy dochodzi do awarii lub incydentu ransomware, zaczynają mieć znaczenie szczegóły: częstotliwość kopii, rodzaj backupu, miejsce przechowywania, czas odtworzenia (RTO) i akceptowalna utrata danych (RPO). W umowie można zdefiniować choćby w przybliżeniu:

• jak często wykonywane są kopie zapasowe (np. raz na dobę, przy istotnych zmianach danych),
• czy backup jest przechowywany w odseparowanej infrastrukturze (air-gapped, immutable),
• jak długo przechowywane są poszczególne wersje kopii,
• maksymalny czas przywrócenia usługi po awarii (RTO) oraz dopuszczalny poziom utraty danych (RPO),
• obowiązek cyklicznego testowania procedur odtworzeniowych i raportowania wyników tych testów klientowi.

W jednym z projektów outsourcingowych dopiero po poważnej awarii okazało się, że dostawca przechowuje tylko jedną dzienną kopię danych, dodatkowo w tej samej strefie dostępności chmury, w której doszło do problemu. W efekcie kluczowe dane zostały odtworzone z trzydniowym opóźnieniem, mimo że z perspektywy biznesowej klienta dopuszczalna utrata danych wynosiła kilka godzin. Brak precyzyjnych klauzul w tym obszarze przełożył się bezpośrednio na skalę szkody.

Bezpieczeństwo łańcucha dostaw i podwykonawców

Coraz więcej usług jest świadczonych w modelu wielowarstwowym: główny dostawca korzysta z podwykonawców, którzy z kolei opierają się na usługach chmurowych lub innych zewnętrznych narzędziach. Umowy B2B często wspominają o możliwości korzystania z podwykonawców, ale rzadko rozwijają, jak mają do nich „przechodzić” wymagania bezpieczeństwa.

Aby uniknąć sytuacji, w której poziom bezpieczeństwa faktycznie zależy od najsłabszego ogniwa, warto w umowie doprecyzować co najmniej, że:

• dostawca może angażować podwykonawców tylko pod warunkiem nałożenia na nich wymogów bezpieczeństwa co najmniej równoważnych z umową główną,
• klient jest informowany o kluczowych podwykonawcach przetwarzających jego dane lub mających dostęp do jego środowiska,
• istnieje obowiązek uzyskania zgody klienta lub przynajmniej możliwość sprzeciwu wobec określonego podmiotu (np. z przyczyn regulacyjnych),
• dostawca odpowiada wobec klienta za działania podwykonawców jak za działania własne,
• w razie poważnego incydentu po stronie podwykonawcy stosuje się te same zasady raportowania, współpracy i odpowiedzialności, jak w przypadku dostawcy głównego.

Przy korzystaniu z globalnych platform chmurowych katalog podwykonawców może być długi. Umowa może wtedy odwoływać się do publicznej listy subprocesorów publikowanej przez dostawcę chmury, ale dobrze, jeśli przewiduje również mechanizm powiadamiania o istotnych zmianach (np. dodaniu nowego regionu lub kluczowego under-processora).

Transgraniczny przepływ danych i lokalizacja środowisk

Bezpieczeństwo informacji ma także wymiar geograficzny. Dane przetwarzane w centrach danych poza EOG lub przekazywane do państwa o innym reżimie prawnym są narażone na odmienne ryzyka – prawne, regulacyjne i techniczne. Wiele umów ogranicza się do standardowej klauzuli o stosowaniu standardowych klauzul umownych RODO, pomijając pozostałe aspekty.

Klient często potrzebuje wiedzieć nie tylko, czy transfer jest legalny, ale też gdzie fizycznie znajdują się jego dane, kopie zapasowe i systemy pomocnicze (np. monitoring, logowanie). W kontrakcie można ująć w szczególności:

• dozwolone lokalizacje przetwarzania i przechowywania danych (np. wyłącznie EOG lub określone państwa trzecie),
• wymóg uzyskania zgody klienta na zmianę lokalizacji lub dodanie nowego regionu,
• zasady korzystania z zespołów wsparcia zlokalizowanych poza uzgodnionymi regionami (np. dostęp tylko zdalny, w trybie ściśle kontrolowanym),
• obowiązek przeprowadzenia i udostępnienia klientowi oceny skutków transferu (Transfer Impact Assessment) w przypadku przekazywania danych osobowych do państw trzecich.

W praktyce takie klauzule przyspieszają późniejsze uzgodnienia z działami compliance i ryzyka, a przy audytach regulatora pozwalają wykazać, że lokalizacja przetwarzania nie jest „przy okazji”, ale wynika z przemyślanych decyzji kontraktowych.

Bezpieczeństwo rozwiązań opartych na AI i automatyzacji

Coraz więcej usług B2B opiera się na modelach uczenia maszynowego, systemach rekomendacyjnych czy automatyzacji decyzji. Tego typu rozwiązania generują specyficzne ryzyka: od podatności na „zatruwanie” danych treningowych po trudności w wyjaśnieniu decyzji modelu. W umowach nadal rzadko pojawiają się klauzule regulujące bezpieczeństwo takich komponentów.

W zależności od rodzaju usługi można rozważyć postanowienia dotyczące m.in.:

• oddzielenia danych treningowych pochodzących od różnych klientów (np. brak „krzyżowego” uczenia modeli na wrażliwych danych biznesowych),
• przeglądów jakości i bezpieczeństwa modeli (np. walidacja przed produkcyjnym wdrożeniem, testy odporności na typowe wektory ataku),
• zasad wprowadzania automatycznych decyzji wpływających na prawa lub sytuację klientów klienta (np. wymóg nadzoru człowieka, możliwość zakwestionowania decyzji),
• informowania o istotnych zmianach modeli, które mogą wpływać na wyniki (np. zmiana architektury, danych treningowych, parametrów),
• ograniczeń w dalszym wykorzystywaniu danych klienta do własnych celów rozwojowych dostawcy (np. wymóg anonimizacji, doprecyzowanie dozwolonych scenariuszy użycia).

Przy komponentach AI przydaje się także precyzyjne rozdzielenie odpowiedzialności za skutki działania systemu. Inaczej rozkładają się ryzyka, gdy dostawca udostępnia jedynie „silnik” modeli, a inaczej, gdy odpowiada za pełny proces decyzyjny w konkretnej usłudze (np. automatyczna ocena wniosków). Umowa może przewidywać odrębne zasady odpowiedzialności za błędy wynikające z jakości danych wejściowych dostarczanych przez klienta, a inne – za błędy, które są efektem konstrukcji lub wdrożenia modelu po stronie dostawcy. Przy sporach często okazuje się, że taka matryca odpowiedzialności rozstrzyga o tym, kto pokrywa realne straty biznesowe.

Drugim praktycznym elementem jest przejrzystość działania systemu. Nie zawsze da się zapewnić pełną „wyjaśnialność” decyzji modelu na poziomie algorytmicznym, ale zwykle można kontraktowo wymusić minimum: opis logiki działania, wskazanie kluczowych zmiennych wpływających na wynik, a także udostępnianie statystyk skuteczności i błędów. Działy compliance i zarządy oczekują dzisiaj nie tylko zapewnień marketingowych o „sztucznej inteligencji”, lecz materiału, który da się przedstawić wewnętrznemu audytowi lub regulatorowi.

Przy rozwiązaniach, które mogą wpływać na prawa osób fizycznych lub niosą większe ryzyko regulacyjne, przydają się dodatkowe „bezpieczniki kontraktowe”. Chodzi w szczególności o prawo klienta do wyłączenia automatyzacji w określonych scenariuszach (np. wprowadzenie manualnej akceptacji powyżej określonego progu ryzyka), obowiązek przeprowadzenia oceny skutków wdrożenia (np. pod kątem uprzedzeń czy dyskryminacji), a także mechanizmy szybkiego wycofania wadliwej wersji modelu z produkcji. Takie zapisy z pozoru ograniczają elastyczność, ale w sytuacji kryzysowej pozwalają ograniczyć skutki błędnych decyzji systemu do kontrolowalnego obszaru.

Bezpieczeństwo w umowach B2B nie sprowadza się więc do jednego paragrafu o „należytej staranności” i odesłania do RODO. To zestaw szczegółowych, często niewygodnych pytań: o logi, backupy, podwykonawców, lokalizację danych czy sposób działania modeli AI. Im więcej z nich zostanie przepracowanych na etapie negocjacji, tym mniej zaskoczeń przy pierwszym poważnym incydencie – a wtedy klauzule bezpieczeństwa przestają być abstrakcją i stają się bardzo namacalnym narzędziem ochrony interesów obu stron.

Klauzule odpowiedzialności i kar umownych – jak przełożyć ryzyko bezpieczeństwa na konkretne liczby

Bezpieczeństwo informacji w kontraktach B2B często „wygrywa” na poziomie deklaracji, a „przegrywa” na poziomie odpowiedzialności. Z jednej strony mamy rozbudowane załączniki bezpieczeństwa, standardy, procedury, certyfikacje. Z drugiej – bardzo ciasne limity odpowiedzialności, ogólne wyłączenia i brak realnych konsekwencji za naruszenie postanowień bezpieczeństwa. Efekt jest taki, że po incydencie strony dopiero odkrywają, jak niewiele z tych zapisów da się wyegzekwować finansowo.

W umowach B2B da się jednak zbudować bardziej zrównoważony model: taki, w którym bezpieczeństwo jest chronione nie tylko na poziomie organizacyjnym, ale także przez precyzyjne klauzule odpowiedzialności i kar umownych. Trzeba przy tym pamiętać, że „ostre” zapisy nie muszą być wcale oderwane od biznesu dostawcy – kluczowe jest ich dobre uwarunkowanie i powiązanie z realnym wpływem zdarzeń na działalność klienta.

Limit odpowiedzialności a naruszenia bezpieczeństwa

Standardem w relacjach B2B są limity odpowiedzialności – najczęściej powiązane z wartością wynagrodzenia z danego okresu (np. 12 miesięcy). Z perspektywy bezpieczeństwa problemem jest to, że te same limity stosuje się do wszystkich typów naruszeń, w tym do incydentów, które mogą generować szkody o wiele większe niż roczny kontrakt.

Przy projektowaniu klauzul odpowiedzialności za bezpieczeństwo można rozważyć m.in.:

• wyłączenie z limitu odpowiedzialności określonych kategorii szkód, np. szkód spowodowanych rażącym niedbalstwem w zakresie bezpieczeństwa lub świadomym obchodzeniem uzgodnionych zabezpieczeń technicznych,
• podwyższony limit odpowiedzialności dla incydentów bezpieczeństwa spełniających określone kryteria (np. naruszenie poufności danych określonej kategorii, przerwa w dostępności systemu powyżej zdefiniowanego progu),
• limity „warstwowe” – inny limit dla „zwykłych” naruszeń umowy (np. opóźnienia w usługach), a inny, wyższy, dla naruszeń postanowień bezpieczeństwa lub ochrony danych,
• klauzulę minimalnej odpowiedzialności za określone typy zdarzeń (np. co najmniej równowartość wskazanych kosztów notyfikacji naruszenia, obsługi prawnej oraz monitoringu kredytowego dla osób, których dane dotyczą).

W jednym z projektów wdrożeniowych dostawca zastrzegł odpowiedzialność do równowartości miesięcznego wynagrodzenia. Przy większym incydencie cyberbezpieczeństwa – obejmującym wyciek danych klientów i przestój systemu – limit został „wyczerpany” przez same koszty pierwszej reakcji i analizy śledczej. Pozostała szkoda biznesowa nie miała praktycznie szans na pokrycie w ramach umowy, mimo że obie strony na etapie negocjacji długo dyskutowały o standardach bezpieczeństwa technicznego.

Zakres szkody podlegającej naprawieniu

Drugim krytycznym elementem jest określenie, jakie szkody podlegają naprawieniu. Ogólne sformułowania typu „odpowiedzialność za szkodę rzeczywistą” brzmią niewinnie, ale w kontekście incydentów bezpieczeństwa oznaczają zazwyczaj wyłączenie:

• utraconych korzyści (np. utraconych przychodów w okresie przestoju),
• szkód wynikających z utraty reputacji lub zaufania klientów końcowych,
• kar administracyjnych (np. RODO) lub innych sankcji regulacyjnych,
• kosztów postępowań sądowych lub ugód z osobami trzecimi (np. użytkownikami końcowymi systemu).

Jeżeli takie wyłączenia mają pozostać, dobrze jest przynajmniej określić katalog kosztów, które będą uwzględnione. Praktycznym rozwiązaniem bywa osobny paragraf opisujący, że w przypadku naruszenia bezpieczeństwa dostawca odpowiada za konkretne, wymienione kategorie wydatków, w szczególności:

• koszty działań naprawczych (np. odtworzenie danych z kopii, konfiguracja zastępczej infrastruktury),
• koszty powiadomień o incydencie (w tym koszty kampanii informacyjnych, obsługi infolinii, szablonów komunikatów),
• koszty zewnętrznych ekspertów (cyberbezpieczeństwo, PR kryzysowy, kancelarie prawne),
• koszty audytów wymaganych przez regulatora lub kluczowych klientów klienta, jeżeli wynikają bezpośrednio z incydentu po stronie dostawcy.

Taki katalog nie rozwiąże wszystkich sporów, ale zawęża pole interpretacji i ułatwia oszacowanie potencjalnej ekspozycji finansowej po obu stronach. Dla działów finansowych dostawcy bywa to argumentem, że wyższy limit odpowiedzialności jest uzasadniony, bo dotyczy z góry określonych typów kosztów, a nie otwartej odpowiedzialności za „wszystko”.

Kary umowne za naruszenia bezpieczeństwa – kiedy mają sens

Kary umowne często funkcjonują w kontraktach B2B jako środek dyscyplinujący za opóźnienia, ale rzadziej jako narzędzie ochrony bezpieczeństwa. W praktyce można je wykorzystać tam, gdzie:

• ustalenie rzeczywistej szkody jest trudne lub wymaga czasu (np. naruszenie poufności danych, incydenty o ograniczonym początkowo zasięgu),
• klient chce mieć pewność minimalnego poziomu rekompensaty niezależnie od późniejszej analizy skutków,
• kluczowy jest element prewencji – kara ma skłaniać do utrzymania określonych standardów bezpieczeństwa.

Typowe sytuacje, w których pojawiają się kary umowne w obszarze bezpieczeństwa, to w szczególności:

• brak zgłoszenia istotnego incydentu w uzgodnionym czasie,
• nieprzeprowadzenie wymaganych testów lub audytów bezpieczeństwa w określonych terminach,
• nieusunięcie stwierdzonych krytycznych podatności w czasie określonym w umowie,
• naruszenie kluczowych zakazów, np. przetwarzania danych poza uzgodnionymi lokalizacjami lub wykorzystania danych klienta do własnych celów.

Projektując kary umowne, opłaca się powiązać je z oceną ryzyka biznesowego, a nie jedynie z „poczuciem sprawiedliwości” strony negocjującej. Dla niektórych naruszeń realny środek nacisku to kara jednorazowa (np. za nieautoryzowany transfer danych poza EOG), dla innych – kara okresowa naliczana za każdy dzień trwania naruszenia (np. brak usunięcia krytycznej podatności, która zagraża produkcyjnej infrastrukturze).

Warto też rozstrzygnąć wprost, czy zapłata kary umownej wyczerpuje odpowiedzialność za dane naruszenie, czy też nie wyłącza dochodzenia odszkodowania przewyższającego jej wysokość. W obszarze bezpieczeństwa częściej stosuje się model „kara + możliwość dochodzenia szkody przewyższającej”, bo pełna skala skutków incydentu ujawnia się z opóźnieniem.

Specjalne klauzule dotyczące naruszenia poufności

Naruszenie poufności danych biznesowych lub technicznych bywa równie dotkliwe jak wyciek danych osobowych. W klasycznych umowach B2B klauzule poufności są dość ogólne i sprowadzają się do standardowego zakazu ujawniania informacji osobom trzecim. W kontekście bezpieczeństwa informacyjnego można jednak iść krok dalej.

W praktyce przydatne są m.in. następujące elementy:

• podział informacji poufnych na kategorie – np. informacje „standardowo poufne” oraz informacje „krytyczne” (tajemnice przedsiębiorstwa, algorytmy, dane produkcyjne) z odrębnym reżimem odpowiedzialności,
• podwyższona odpowiedzialność za naruszenie poufności informacji krytycznych, np. wyższy limit odszkodowawczy lub dedykowana kara umowna,
• precyzja co do dopuszczalnych form ujawnienia: komu, w jakim trybie i przy jakim poziomie zabezpieczeń informacje mogą być przekazywane (np. obowiązek stosowania szyfrowania end-to-end przy przekazywaniu danych produkcyjnych),
• obowiązek dokumentowania dostępu – rejestr osób i ról, które miały dostęp do określonej kategorii poufnych danych, przechowywany przez uzgodniony okres,
• mechanizm „clawbacku” – obowiązek usunięcia lub zwrotu określonych danych poufnych na żądanie klienta w ściśle określonym terminie, wraz z potwierdzeniem zniszczenia.

Przy wycieku kodu źródłowego lub kluczowych parametrów strategii biznesowej szkoda bardzo rzadko daje się precyzyjnie wycenić. Dlatego rozbudowane klauzule poufności z elementami kar umownych częściej stanowią realną dźwignię negocjacyjną niż ogólne odwołania do „szkody, którą strona poniosła”.

Odpowiedzialność za dane osobowe a odpowiedzialność „czysto biznesowa”

W kontraktach, w których pojawiają się dane osobowe, łatwo wpaść w pułapkę utożsamiania bezpieczeństwa wyłącznie z RODO. Tymczasem odpowiedzialność z tytułu przetwarzania danych osobowych to tylko fragment szerszego obrazu – obok niej istnieje pełna odpowiedzialność biznesowa za inne rodzaje informacji oraz dostępność i integralność systemów.

Przy konstruowaniu klauzul odpowiedzialności przydaje się rozróżnienie co najmniej trzech płaszczyzn:

• odpowiedzialność regulacyjna – w szczególności za naruszenie przepisów o ochronie danych osobowych, w tym za kary administracyjne i koszty działań nakazanych przez regulatora,
• odpowiedzialność kontraktowa wobec klienta – za niewykonanie lub nienależyte wykonanie obowiązków bezpieczeństwa określonych w umowie (również tam, gdzie nie ma danych osobowych),
• odpowiedzialność wobec osób trzecich – np. użytkowników końcowych systemu, kontrahentów klienta, partnerów integracyjnych.

Umowa może wprost określać, kto i w jakim zakresie ponosi koszty związane z każdą z tych kategorii. Przykładowo, strony mogą uzgodnić, że:

• kary administracyjne z tytułu RODO pokrywa ta strona, której naruszenie doprowadziło do ich nałożenia, przy czym dostawca partycypuje w karze proporcjonalnie do swojego wkładu w naruszenie,
• roszczenia osób trzecich (np. użytkowników aplikacji) są co do zasady obsługiwane przez klienta, natomiast dostawca zapewnia zwrot uzasadnionych kosztów lub odszkodowań w zakresie, w jakim incydent wynikał z jego nienależytego działania,
• strony będą współdziałać przy obronie przed roszczeniami regulatora lub osób trzecich, a dostawca zobowiązuje się udostępnić niezbędne informacje techniczne i eksperckie.

Taki „podział ról” zmniejsza niepewność w sytuacjach kryzysowych. Zamiast sporów o to, kto ma prowadzić korespondencję z organem nadzorczym i ponosić koszty obsługi prawnej, strony mogą skupić się na samej reakcji na incydent.

Ubezpieczenie odpowiedzialności za incydenty bezpieczeństwa

Coraz częściej elementem negocjacji umownych staje się kwestia ubezpieczenia po stronie dostawcy. Zwykłe polisy OC działalności gospodarczej rzadko pokrywają w wystarczającym stopniu skutki incydentów cyberbezpieczeństwa. Dlatego w poważniejszych projektach pojawiają się wymogi posiadania:

• polisy cyber (cyber insurance) o określonej minimalnej sumie gwarancyjnej,
• rozszerzeń w ramach OC profesjonalnej działalności (Professional Indemnity) obejmujących błędy w zabezpieczeniu systemów,
• ubezpieczenia kosztów reakcji na incydent – w tym usług informatyki śledczej i zarządzania kryzysem PR.

Umowa może wprowadzić obowiązek utrzymywania odpowiednich polis przez cały okres jej trwania oraz przedstawienia dowodu ich obowiązywania (certyfikat, potwierdzenie składki) na żądanie klienta. Strony mogą również określić, jakie ryzyka mają być objęte ubezpieczeniem wprost – np. naruszenia poufności, przestoje systemów, roszczenia osób trzecich związane z incydentem bezpieczeństwa.

Nie chodzi tu o przerzucenie całego ryzyka na ubezpieczyciela, lecz o zwiększenie szans, że dostawca będzie miał środki finansowe na pokrycie skutków poważniejszego incydentu. Z perspektywy klienta to często przesłanka przy ocenie zdolności dostawcy do realizacji projektów o krytycznym znaczeniu.

Współodpowiedzialność stron za bezpieczeństwo – klauzule „shared responsibility”

W nowoczesnych modelach usług – szczególnie chmurowych i platformowych – bezpieczeństwo jest współdzielone. Dostawca odpowiada za infrastrukturę i część mechanizmów, klient za konfigurację, zarządzanie dostępem oraz sposób korzystania z systemu. Umowy B2B nie zawsze odzwierciedlają ten podział odpowiedzialności, przez co po incydencie każda ze stron próbuje dowodzić, że zawiódł „ten drugi”.

Rozwiązaniem jest wprowadzenie do kontraktu wyraźnej sekcji opisującej współodpowiedzialność. Powinna ona obejmować w szczególności:

• podział obowiązków w zakresie konfiguracji bezpieczeństwa systemu (np. kto odpowiada za polityki haseł, konfigurację logowania, zarządzanie rolami użytkowników),
• zakres, w jakim dostawca może ingerować w konfigurację bezpieczeństwa klienta, oraz obowiązek informowania o zmianach,
• obowiązki klienta w zakresie edukacji użytkowników końcowych i wewnętrznych procedur bezpieczeństwa (np. zasady korzystania z kont uprzywilejowanych),
• procedury reagowania na incydenty po stronie klienta i dostawcy – w tym kto inicjuje analizę przyczyn, kto prowadzi komunikację z użytkownikami, a kto przygotowuje raport techniczny,
• granice korzystania z uprawnień administracyjnych dostawcy, np. przy zdalnym wsparciu, serwisie lub aktualizacjach, wraz z zasadami logowania takich działań,
• konsekwencje naruszenia obowiązków po stronie klienta (np. używanie wspólnych kont, ignorowanie ostrzeżeń systemowych) i sposób ustalania, w jakim stopniu miało to wpływ na incydent.

W projektach złożonych technicznie przydaje się dodatkowo załącznik techniczny opisujący model „shared responsibility” w formie tabeli lub macierzy. Dla każdej funkcji bezpieczeństwa (backup, szyfrowanie, monitoring, zarządzanie tożsamością) wskazuje się tam, czy odpowiada za nią dostawca, klient czy obie strony, a także czy dane zadanie jest obowiązkowe, czy opcjonalne. Taki dokument ułatwia zarówno wdrożenie, jak i późniejsze dochodzenie odpowiedzialności.

W praktyce wiele sporów po incydencie wynika z tego, że klient nie wdrożył rekomendowanych ustawień bezpieczeństwa albo zignorował ostrzeżenia. Jeżeli kontrakt przewiduje, że część funkcji bezpieczeństwa jest opcjonalna i aktywowana wyłącznie na wniosek klienta, dobrze jest uregulować również to, co dzieje się, gdy klient rezygnuje z danego mechanizmu. Częstym rozwiązaniem jest wprost wskazanie, że ryzyko związane z niewłączeniem określonych funkcji przechodzi na klienta.

Odpowiednio spisana współodpowiedzialność nie służy temu, by „zdjąć” ciężar z dostawcy, lecz by uniknąć sytuacji, w której żadna ze stron nie czuje się zobowiązana do zadbania o konkretny element bezpieczeństwa. Im bardziej precyzyjny podział, tym większa szansa, że w kluczowym momencie ktoś faktycznie zareaguje.

Klauzule bezpieczeństwa w umowach B2B przestają być dodatkiem na końcu dokumentu, a stają się jednym z głównych narzędzi zarządzania ryzykiem. Dobrze zaprojektowane postanowienia – obejmujące poufność, dane osobowe, odpowiedzialność odszkodowawczą, ubezpieczenia i współdzielone obowiązki – w praktyce przesądzają o tym, czy incydent będzie kontrolowanym kryzysem, czy początkiem długotrwałego sporu. Dla wielu firm to właśnie treść kontraktu przesądza, czy współpraca w obszarze krytycznych systemów biznesowych jest w ogóle opłacalna.

Najczęściej zadawane pytania (FAQ)

Jakie klauzule bezpieczeństwa są absolutnym minimum w umowie B2B?

W większości relacji B2B absolutne minimum obejmuje: precyzyjną klauzulę poufności, regulacje dotyczące dostępu do systemów i danych, zapisy o odpowiedzialności (w tym limity i ewentualne kary umowne), zasady korzystania z podwykonawców oraz procedurę postępowania w razie incydentu bezpieczeństwa.

Nawet prosta umowa powinna wskazywać, jakie dane są przekazywane, kto je chroni, jakie środki bezpieczeństwa są wymagane oraz jak wygląda „exit plan” – czyli w jaki sposób strony zakończą współpracę, przekażą dane i odłączą dostęp do systemów tak, aby nie sparaliżować biznesu.

Jak zabezpieczyć dostęp do systemów i danych w umowie z dostawcą B2B?

Umowa powinna regulować nie tylko „czy” jest dostęp, ale „jak” jest zorganizowany. Zwykle oznacza to opisanie: rodzaju dostępu (VPN, konto w systemie, zdalny pulpit), zasad nadawania i odbierania uprawnień, wymogu stosowania silnych haseł i uwierzytelniania wieloskładnikowego oraz zakazu korzystania z prywatnych urządzeń, jeśli nie spełniają określonych standardów bezpieczeństwa.

Dobrym rozwiązaniem bywa także wskazanie, kto po stronie każdej ze stron odpowiada za konfigurację kont użytkowników, jak często weryfikowana jest lista uprawnień oraz czy i w jakim trybie można przeprowadzić audyt techniczny (np. sprawdzenie logów dostępowych).

Jak zapisać w umowie B2B przekazanie danych po zakończeniu współpracy?

Kluczowe są trzy elementy: format, termin i odpowiedzialność. W umowie powinien znaleźć się zapis, w jakim formacie dane będą przekazane (np. eksport bazy w określonej strukturze), w jakim terminie od rozwiązania umowy nastąpi przekazanie oraz kto ponosi odpowiedzialność za kompletność i poprawność przekazanych danych.

Przy bardziej złożonych projektach przydaje się osobny załącznik „exit plan”, który opisuje kroki przy rozstaniu: przygotowanie backupów, test odczytu danych przez zamawiającego, sposób usunięcia danych z systemów dostawcy oraz zasady współpracy z nowym wykonawcą przez ograniczony czas.

Czy w umowie B2B można ograniczyć odpowiedzialność za wyciek danych?

Co do zasady strony mogą umownie ograniczać odpowiedzialność kontraktową, np. poprzez limity kwotowe czy wyłączenie niektórych rodzajów szkód. Nie można jednak skutecznie wyłączyć odpowiedzialności za szkodę wyrządzoną umyślnie, a zbyt daleko idące ograniczenia przy rażącym niedbalstwie bywają w praktyce kwestionowane.

Trzeba też odróżnić odpowiedzialność między stronami od odpowiedzialności wobec osób trzecich (np. klientów, których dane wyciekły). Klauzule w umowie B2B nie „anulują” obowiązków wynikających z RODO czy przepisów o zwalczaniu nieuczciwej konkurencji – mogą jedynie rozłożyć między stronami ryzyko i koszty ewentualnych roszczeń.

Jak uregulować podwykonawców i freelancerów w kontekście bezpieczeństwa?

Umowa powinna jasno określać, czy i na jakich warunkach strona może korzystać z podwykonawców. Typowo wskazuje się obowiązek uzyskania zgody zamawiającego na kluczowych podwykonawców, nałożenia na nich tożsamych obowiązków poufności i bezpieczeństwa oraz odpowiadania za ich działania jak za własne.

W praktyce sprawdza się lista zatwierdzonych podwykonawców w załączniku oraz obowiązek informowania o zmianach w łańcuchu dostaw. Przy przetwarzaniu danych osobowych zwykle konieczna jest też osobna umowa powierzenia przetwarzania, powiązana z głównym kontraktem B2B.

Jak powinna wyglądać procedura incydentu bezpieczeństwa w umowie B2B?

Dobra procedura opisuje przede wszystkim: jak szybko i jakim kanałem strona musi zgłosić incydent, jakie informacje minimalnie przekazuje (np. rodzaj incydentu, zakres danych, wstępna ocena skutków) oraz kto po obu stronach jest osobą kontaktową. Często określa się też obowiązek podjęcia działań minimalizujących skutki incydentu i współpracy przy analizie przyczyn.

W przypadku przetwarzania danych osobowych umowa powinna uwzględniać także wymogi RODO, np. krótsze terminy zgłoszenia potencjalnego naruszenia ochrony danych, aby administrator zdążył ocenić, czy konieczne jest zawiadomienie organu nadzorczego lub osób, których dane dotyczą.

Czy ogólna klauzula poufności wystarczy do zabezpieczenia współpracy B2B?

Ogólna klauzula poufności zwykle jest zbyt ogólna, by chronić realne interesy przy złożonych projektach. Chroni „informacje poufne”, ale nie reguluje szczegółowo dostępu do systemów, sposobu przechowywania danych, backupów, audytów czy przekazania informacji po zakończeniu umowy.

W praktyce klauzula poufności powinna być jednym z kilku filarów bezpieczeństwa. Obok niej potrzebne są szczegółowe zapisy techniczno-organizacyjne (często w załączniku), regulacje dotyczące odpowiedzialności, podwykonawców, reagowania na incydenty oraz dobrze opisany „exit plan”. Dopiero taki pakiet działa jak faktyczne zabezpieczenie, a nie tylko formalność w kontrakcie.

Źródła informacji

• Kodeks cywilny. Komentarz. Tom III. Zobowiązania – część ogólna (art. 3531 i nast.). C.H.Beck (2022) – Komentarz do zasady swobody umów i granic kształtowania klauzul umownych
• Ogólne rozporządzenie o ochronie danych (RODO). Parlament Europejski i Rada UE (2016) – Podstawy prawne przetwarzania danych, powierzenia, bezpieczeństwa i odpowiedzialności
• Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną. Sejm Rzeczypospolitej Polskiej (2002) – Obowiązki usługodawców online, bezpieczeństwo systemów i danych w relacjach B2B