Polityka bezpieczeństwa informacji i cyberbezpieczeństwa Zentra

Wersja: 1.0

Data wejścia w życie: 23.07.2026

Właściciel dokumentu:

Moja Zentra Spółka z Ograniczoną Odpowiedzialnością

ul. MICHAŁA KAJKI 10/12 Olsztyn 10-547

NIP: 7394037430

REGON: 54531042500000

Numer KRS: 0001255899

ROZDZIAŁ I

POSTANOWIENIA OGÓLNE

§1. Cel dokumentu

1. Niniejsza Polityka Bezpieczeństwa Informacji i Cyberbezpieczeństwa Zentry („Polityka”) określa zasady ochrony informacji, danych oraz zasobów wykorzystywanych podczas świadczenia usług w ramach Aplikacji Zentra.

2. Celem Polityki jest w szczególności:

a. zapewnienie odpowiedniego poziomu bezpieczeństwa informacji;

b. ograniczenie ryzyka wystąpienia incydentów bezpieczeństwa;

c. ochrona danych przed utratą, zniszczeniem, modyfikacją lub nieuprawnionym ujawnieniem;

d. określenie odpowiedzialności osób korzystających z Aplikacji;

e. ustanowienie zasad reagowania na incydenty bezpieczeństwa;

f. wspieranie ciągłości świadczenia usług;

g. budowanie zaufania użytkowników do usług świadczonych przez Zentrę.

§2. Zakres obowiązywania

1. Polityka obowiązuje:

a. Usługodawcę;

b. osoby współpracujące z Usługodawcą, w zakresie wykonywanych obowiązków;

c. Administratorów Organizacji;

d. Użytkowników korzystających z Aplikacji;

e. osoby, którym nadano dostęp do Organizacji;

f. podwykonawców, jeżeli wynika to z zawartych umów.

2. Postanowienia Polityki stosuje się do wszystkich informacji przetwarzanych przez Aplikację, niezależnie od ich formy, miejsca przechowywania lub sposobu przetwarzania.

§3. Cele bezpieczeństwa

1. Zentra dąży do zapewnienia ochrony informacji zgodnie z następującymi zasadami:

a. poufności – poprzez ograniczenie dostępu do informacji wyłącznie do osób uprawnionych;

b. integralności – poprzez podejmowanie działań ograniczających ryzyko nieuprawnionej modyfikacji danych;

c. dostępności – poprzez dążenie do zapewnienia ciągłości działania usług i możliwości korzystania z danych przez uprawnionych użytkowników;

d. rozliczalności – poprzez prowadzenie działań umożliwiających identyfikację operacji wykonywanych w systemie w zakresie uzasadnionym bezpieczeństwem i obowiązującymi przepisami prawa;

e. minimalizacji danych – poprzez przetwarzanie wyłącznie danych niezbędnych do realizacji określonych celów;

f. minimalnych uprawnień – poprzez przyznawanie użytkownikom wyłącznie takich uprawnień, jakie są niezbędne do wykonywania ich obowiązków.

§4. Zakres ochrony

1. Ochroną objęte są w szczególności:

<!-- -->

1. dane przedsiębiorców;

2. dane kontrahentów;

3. dane pracowników;

4. dane finansowe;

5. dokumenty;

6. faktury;

7. informacje księgowe;

8. dane dotyczące organizacji;

9. pliki przesłane do Aplikacji;

10. logi systemowe;

11. konfiguracja Aplikacji;

12. elementy infrastruktury technicznej;

13. informacje dotyczące bezpieczeństwa;

14. dane uwierzytelniające;

15. klucze oraz tokeny dostępu;

16. inne informacje przetwarzane w związku ze świadczeniem Usług.

§5. Model bezpieczeństwa

1. Bezpieczeństwo informacji w Zentrze opiera się na zasadzie zarządzania ryzykiem.

2. Środki organizacyjne i techniczne dobierane są odpowiednio do:

a. charakteru przetwarzanych informacji;

b. poziomu ryzyka;

c. aktualnego stanu wiedzy technicznej;

d. możliwości organizacyjnych i technicznych;

e. obowiązujących przepisów prawa.

3. Polityka ma charakter dokumentu nadrzędnego względem wewnętrznych procedur bezpieczeństwa dotyczących świadczenia usług przez Zentrę.

§6. Odpowiedzialność

1. Każda osoba korzystająca z Aplikacji zobowiązana jest do działania w sposób ograniczający ryzyko naruszenia bezpieczeństwa.

2. Administrator Organizacji odpowiada za właściwe zarządzanie dostępami użytkowników w ramach swojej Organizacji.

3. Użytkownicy są zobowiązani do niezwłocznego zgłaszania zauważonych zagrożeń bezpieczeństwa, naruszeń lub podejrzeń naruszeń.

4. Usługodawca podejmuje działania zmierzające do utrzymania odpowiedniego poziomu bezpieczeństwa, z uwzględnieniem charakteru świadczonych usług oraz dostępnych środków organizacyjnych i technicznych.

§7. Aktualizacja Polityki

1. Polityka podlega okresowym przeglądom oraz może być aktualizowana w przypadku:

a. zmian przepisów prawa;

b. zmian technologicznych;

c. wprowadzenia nowych funkcjonalności;

d. wystąpienia istotnych incydentów bezpieczeństwa;

e. zmian organizacyjnych;

f. wyników analiz ryzyka;

g. innych okoliczności mających wpływ na bezpieczeństwo informacji.

2. Każda nowa wersja Polityki otrzymuje numer wersji oraz datę obowiązywania.

3. Zmiany Polityki nie ograniczają praw użytkowników wynikających z obowiązujących przepisów prawa ani z zawartych umów.

ROZDZIAŁ II

ZARZĄDZANIE TOŻSAMOŚCIĄ, KONTAMI ORAZ DOSTĘPEM

§8. Zasady ogólne

1. Dostęp do Aplikacji przyznawany jest wyłącznie osobom uprawnionym.

2. Każdy Użytkownik korzysta z indywidualnego Konta przypisanego do jednej osoby.

3. Zabrania się współdzielenia jednego Konta pomiędzy kilkoma osobami, chyba że charakter udostępnionej funkcjonalności wyraźnie na to pozwala.

4. Każda operacja wykonana po prawidłowym uwierzytelnieniu jest przypisywana do Konta, z którego została wykonana.

5. Dostęp do danych powinien być ograniczony do zakresu niezbędnego do wykonywania obowiązków przez danego Użytkownika.

§9. Tworzenie Kont

1. Konto tworzone jest zgodnie z procedurą rejestracji obowiązującą w Aplikacji.

2. Konto może zostać utworzone:

a. przez Przedsiębiorcę;

b. przez Administratora Organizacji;

c. na zaproszenie Administratora Organizacji;

d. w inny sposób udostępniony przez Usługodawcę.

3. Każde Konto powinno być przypisane do konkretnej osoby fizycznej korzystającej z Aplikacji.

4. Zabrania się tworzenia fikcyjnych Kont, chyba że służą one celom testowym i zostały utworzone zgodnie z zasadami określonymi przez Usługodawcę.

§10. Administrator Organizacji

1. Administrator Organizacji odpowiada za zarządzanie dostępami w ramach swojej Organizacji.

2. Do obowiązków Administratora należy w szczególności:

a. zapraszanie nowych Użytkowników;

b. nadawanie odpowiednich ról;

c. odbieranie dostępu osobom, które utraciły uprawnienia;

d. okresowa weryfikacja przyznanych uprawnień;

e. zapewnienie, aby dostęp posiadały wyłącznie osoby upoważnione.

3. Administrator powinien niezwłocznie usunąć lub zablokować dostęp osoby, która zakończyła współpracę z Organizacją albo utraciła uprawnienie do korzystania z Aplikacji.

§11. Role i uprawnienia

1. Aplikacja umożliwia przypisywanie Użytkownikom różnych poziomów uprawnień.

2. Zakres uprawnień zależy od roli przypisanej przez Administratora Organizacji.

3. Uprawnienia powinny być nadawane zgodnie z zasadą najmniejszych uprawnień (Least Privilege), tj. wyłącznie w zakresie niezbędnym do wykonywania powierzonych obowiązków.

4. Usługodawca nie odpowiada za skutki nadania przez Administratora Organizacji zbyt szerokich lub niewłaściwych uprawnień użytkownikom.

5. Administrator Organizacji ponosi odpowiedzialność za prawidłowe zarządzanie rolami oraz dostępem do danych w ramach swojej Organizacji.

§12. Dane uwierzytelniające

1. Dane uwierzytelniające mają charakter poufny.

2. Użytkownik jest zobowiązany chronić swoje dane logowania przed ujawnieniem osobom nieuprawnionym.

3. Zabrania się:

a. przekazywania hasła innym osobom;

b. zapisywania hasła w sposób narażający je na ujawnienie;

c. udostępniania danych logowania osobom trzecim.

4. W przypadku podejrzenia ujawnienia danych logowania Użytkownik powinien niezwłocznie zmienić hasło oraz poinformować Administratora Organizacji lub Usługodawcę, jeżeli wymaga tego charakter zdarzenia.

§13. Hasła

1. Hasło powinno zapewniać odpowiedni poziom bezpieczeństwa.

2. Użytkownik powinien stosować hasła:

a. unikalne;

b. trudne do odgadnięcia;

c. niewykorzystywane w innych serwisach, o ile jest to możliwe.

3. Usługodawca może określić minimalne wymagania dotyczące haseł oraz odmówić przyjęcia hasła niespełniającego tych wymagań.

4. Usługodawca może wymagać zmiany hasła w przypadku uzasadnionego podejrzenia naruszenia bezpieczeństwa.

§14. Wieloskładnikowe uwierzytelnianie

1. Usługodawca może udostępnić możliwość korzystania z wieloskładnikowego uwierzytelniania (MFA).

2. W przypadku udostępnienia takiej funkcjonalności Administrator Organizacji może wymagać stosowania MFA przez użytkowników Organizacji.

3. Usługodawca może uzależnić dostęp do wybranych funkcjonalności od stosowania dodatkowych metod uwierzytelniania, jeżeli jest to uzasadnione względami bezpieczeństwa.

§15. Sesje użytkownika

1. Po skutecznym uwierzytelnieniu tworzona jest sesja użytkownika.

2. Sesja może zostać zakończona automatycznie po okresie bezczynności lub z innych przyczyn związanych z bezpieczeństwem.

3. Usługodawca może unieważnić aktywne sesje w przypadku:

a. wykrycia zagrożenia bezpieczeństwa;

b. zmiany hasła;

c. podejrzenia przejęcia Konta;

d. naruszenia Regulaminu;

e. działań wymagających ochrony infrastruktury.

4. Użytkownik powinien wylogować się po zakończeniu korzystania z Aplikacji, zwłaszcza gdy korzysta z urządzenia współdzielonego lub publicznie dostępnego.

§16. Blokada Konta

1. Konto może zostać czasowo zablokowane w przypadku:

a. wykrycia prób nieuprawnionego dostępu;

b. podejrzenia przejęcia Konta;

c. naruszenia zasad bezpieczeństwa;

d. działań mogących zagrażać bezpieczeństwu Aplikacji;

e. innych okoliczności uzasadniających zastosowanie środków ochronnych.

2. Blokada Konta może mieć charakter automatyczny lub zostać zastosowana przez Usługodawcę po przeprowadzeniu analizy zgłoszenia lub wykrytego zdarzenia.

3. Jeżeli okoliczności na to pozwalają, Użytkownik zostanie poinformowany o blokadzie Konta oraz, w miarę możliwości, o sposobie przywrócenia dostępu.

§17. Okresowa weryfikacja dostępu

1. Administrator Organizacji powinien okresowo weryfikować listę użytkowników oraz zakres przyznanych im uprawnień.

2. Dostęp osób, które nie powinny już korzystać z Aplikacji, powinien zostać niezwłocznie odebrany.

3. Usługodawca może udostępniać narzędzia wspierające zarządzanie dostępami, jednak odpowiedzialność za prawidłowe zarządzanie użytkownikami Organizacji spoczywa na Administratorze Organizacji.

ROZDZIAŁ III

OCHRONA INFORMACJI ORAZ DANYCH

§18. Zasady ochrony informacji

1. Zentra dąży do zapewnienia odpowiedniego poziomu ochrony informacji przetwarzanych w ramach świadczonych Usług.

2. Środki ochrony dobierane są z uwzględnieniem:

a. charakteru przetwarzanych danych;

b. poziomu ryzyka;

c. dostępnych rozwiązań technicznych;

d. kosztów wdrożenia środków bezpieczeństwa;

e. obowiązujących przepisów prawa.

3. Ochrona informacji obejmuje zarówno środki organizacyjne, jak i techniczne.

§19. Klasyfikacja informacji

1. Informacje przetwarzane przez Aplikację mogą być klasyfikowane według poziomu ich wrażliwości.

2. W szczególności wyróżnia się:

<!-- -->

1. informacje publiczne;

2. informacje wewnętrzne;

3. informacje poufne;

4. informacje o podwyższonym znaczeniu dla bezpieczeństwa.

<!-- -->

3. Rodzaj zastosowanych środków bezpieczeństwa może być uzależniony od klasy informacji.

§20. Zasada minimalizacji danych

1. Zentra dąży do przetwarzania wyłącznie takich danych, które są niezbędne do świadczenia Usług.

2. Zakres przetwarzanych danych powinien odpowiadać celowi, dla którego zostały zgromadzone.

3. Dane nieprzydatne dla realizacji danego celu mogą zostać usunięte, zanonimizowane lub poddane innym procesom ograniczającym możliwość ich identyfikacji, zgodnie z obowiązującymi przepisami prawa.

§21. Dostęp do informacji

1. Dostęp do informacji powinien być ograniczony do osób, które potrzebują go do wykonywania swoich obowiązków.

2. Usługodawca stosuje zasadę najmniejszych uprawnień oraz, w miarę możliwości, zasadę potrzeby wiedzy (Need to Know).

3. Każde rozszerzenie zakresu dostępu powinno być uzasadnione charakterem wykonywanych czynności.

§22. Poufność

1. Osoby posiadające dostęp do informacji zobowiązane są do zachowania ich poufności.

2. Informacje nie mogą być ujawniane osobom nieuprawnionym.

3. Obowiązek zachowania poufności obowiązuje również po ustaniu współpracy lub zakończeniu korzystania z Aplikacji, jeżeli wynika to z przepisów prawa, umowy lub charakteru informacji.

§23. Integralność danych

1. Zentra podejmuje działania mające na celu ograniczenie ryzyka nieuprawnionej modyfikacji danych.

2. W przypadku wykrycia naruszenia integralności danych Usługodawca podejmie działania zmierzające do ustalenia przyczyn zdarzenia oraz ograniczenia jego skutków.

3. Użytkownik powinien niezwłocznie zgłaszać zauważone nieprawidłowości dotyczące danych.

§24. Dostępność danych

1. Zentra podejmuje uzasadnione działania mające na celu zapewnienie dostępności danych dla osób uprawnionych.

2. Dostępność danych może zostać czasowo ograniczona w szczególności z powodu:

a. prac serwisowych;

b. aktualizacji;

c. awarii;

d. działań mających na celu ochronę bezpieczeństwa;

e. działania siły wyższej.

3. Ograniczenie dostępności danych nie stanowi naruszenia niniejszej Polityki, jeżeli jest uzasadnione ochroną bezpieczeństwa lub wynika z okoliczności niezależnych od Usługodawcy.

§25. Przechowywanie informacji

1. Informacje przechowywane są przez okres niezbędny do realizacji celu ich przetwarzania lub przez okres wymagany przepisami prawa.

2. Po upływie okresu przechowywania informacje mogą zostać:

a. usunięte;

b. zanonimizowane;

c. zarchiwizowane, jeżeli wymagają tego przepisy prawa lub uzasadnione potrzeby organizacyjne.

§26. Usuwanie informacji

1. Usunięcie informacji powinno odbywać się w sposób ograniczający możliwość ich nieuprawnionego odzyskania, z uwzględnieniem charakteru wykorzystywanych technologii.

2. Dane mogą pozostawać w kopiach zapasowych przez okres wynikający z procedur bezpieczeństwa oraz polityki retencji.

3. Po upływie okresów retencji dane w kopiach zapasowych podlegają usunięciu lub nadpisaniu zgodnie z przyjętymi procedurami.

§27. Przekazywanie informacji

1. Przekazywanie informacji pomiędzy Aplikacją a użytkownikiem powinno odbywać się z wykorzystaniem odpowiednich środków ochrony transmisji, stosownie do charakteru świadczonych Usług.

2. Informacje mogą być przekazywane podmiotom trzecim wyłącznie:

a. na podstawie przepisów prawa;

b. na podstawie zawartej umowy;

c. za zgodą osoby lub podmiotu uprawnionego;

d. w zakresie niezbędnym do świadczenia Usług.

§28. Dane szczególnie istotne

1. Szczególnej ochronie podlegają w szczególności:

a. dane uwierzytelniające;

b. dane finansowe;

c. dokumenty księgowe;

d. dane dotyczące pracowników;

e. dane kontrahentów;

f. dane przesyłane do systemów administracji publicznej;

g. tokeny dostępu;

h. klucze kryptograficzne, jeżeli są wykorzystywane w ramach świadczonych Usług.

2. Dostęp do danych, o których mowa w ust. 1, powinien być ograniczony do minimum niezbędnego do realizacji celu ich przetwarzania.

§29. Ciągłe doskonalenie bezpieczeństwa

1. Zentra dąży do systematycznego podnoszenia poziomu bezpieczeństwa informacji poprzez analizę ryzyka, rozwój stosowanych rozwiązań oraz uwzględnianie nowych zagrożeń.

2. Środki bezpieczeństwa mogą być modyfikowane wraz z rozwojem technologii, zmianami przepisów prawa lub pojawieniem się nowych zagrożeń.

3. Postanowienia niniejszej Polityki podlegają okresowym przeglądom w celu zapewnienia ich aktualności oraz skuteczności.

ROZDZIAŁ IV

OCHRONA INFRASTRUKTURY ORAZ SYSTEMÓW TELEINFORMATYCZNYCH

§30. Cele ochrony infrastruktury

1. Zentra dąży do utrzymania infrastruktury teleinformatycznej w sposób zapewniający odpowiedni poziom bezpieczeństwa, dostępności oraz odporności na zagrożenia.

2. Środki bezpieczeństwa są dobierane z uwzględnieniem:

a. charakteru świadczonych usług;

b. aktualnej wiedzy technicznej;

c. poziomu ryzyka;

d. możliwości organizacyjnych i technicznych;

e. obowiązujących przepisów prawa.

§31. Ochrona środowiska produkcyjnego

1. Środowisko produkcyjne powinno być chronione przed nieuprawnionym dostępem.

2. Dostęp do środowiska produkcyjnego może zostać przyznany wyłącznie osobom, dla których jest to niezbędne do wykonywania obowiązków.

3. Uprawnienia administracyjne powinny być okresowo weryfikowane.

4. Nieużywane konta administracyjne powinny zostać usunięte lub zablokowane.

§32. Zarządzanie konfiguracją

1. Konfiguracja systemów powinna być prowadzona w sposób umożliwiający zachowanie stabilności i bezpieczeństwa usług.

2. Zmiany konfiguracji powinny być wykonywane z zachowaniem należytej staranności.

3. W przypadku zmian mogących wpływać na bezpieczeństwo Usługodawca może przeprowadzić testy przed ich wdrożeniem.

§33. Aktualizacje oprogramowania

1. Zentra dąży do utrzymywania wykorzystywanego oprogramowania w aktualnym stanie.

2. Aktualizacje mogą obejmować:

a. poprawki bezpieczeństwa;

b. poprawki błędów;

c. aktualizacje komponentów;

d. aktualizacje bibliotek;

e. zmiany wynikające z nowych zagrożeń.

3. Wdrożenie aktualizacji może wiązać się z czasową niedostępnością części funkcjonalności.

§34. Zarządzanie podatnościami

1. Usługodawca może prowadzić działania mające na celu identyfikowanie podatności bezpieczeństwa.

2. W przypadku wykrycia podatności podejmowane są działania odpowiednie do poziomu ryzyka.

3. Kolejność usuwania podatności może zależeć od ich wpływu na bezpieczeństwo Aplikacji.

§35. Segmentacja środowisk

1. W miarę możliwości środowiska wykorzystywane do projektowania, testowania oraz świadczenia usług powinny być od siebie oddzielone.

2. Dane produkcyjne nie powinny być wykorzystywane w środowiskach testowych, chyba że zastosowano odpowiednie środki ochrony.

§36. Zarządzanie komponentami

1. Zentra może korzystać z komponentów, bibliotek oraz usług dostarczanych przez podmioty trzecie.

2. Dobór komponentów powinien uwzględniać:

a. bezpieczeństwo;

b. stabilność;

c. wsparcie producenta;

d. dostępność aktualizacji.

3. Komponenty, które mogą stwarzać istotne zagrożenie bezpieczeństwa, mogą zostać wycofane z użycia.

§37. Monitoring infrastruktury

1. Usługodawca może prowadzić monitoring infrastruktury w zakresie niezbędnym do zapewnienia bezpieczeństwa i ciągłości działania.

2. Monitoring może obejmować między innymi:

a. dostępność usług;

b. wydajność systemów;

c. wykorzystanie zasobów;

d. błędy aplikacyjne;

e. zdarzenia bezpieczeństwa;

f. próby nieautoryzowanego dostępu.

3. Monitoring prowadzony jest wyłącznie w zakresie uzasadnionym ochroną usług oraz infrastruktury.

§38. Ograniczanie ryzyka

1. Zentra podejmuje działania mające na celu ograniczenie ryzyka:

a. awarii;

b. utraty danych;

c. nieuprawnionego dostępu;

d. naruszenia integralności danych;

e. zakłócenia ciągłości działania.

2. Rodzaj zastosowanych środków zależy od charakteru zagrożenia oraz poziomu ryzyka.

§39. Ochrona przed nieautoryzowanym dostępem

1. Podejmowane są działania mające na celu ograniczenie możliwości uzyskania dostępu przez osoby nieuprawnione.

2. W szczególności mogą być stosowane środki organizacyjne i techniczne mające na celu:

a. kontrolę dostępu;

b. ograniczenie uprawnień;

c. identyfikację prób naruszenia bezpieczeństwa;

d. ochronę danych uwierzytelniających;

e. zabezpieczenie komunikacji pomiędzy komponentami systemu.

§40. Ochrona przed automatycznymi zagrożeniami

1. Usługodawca może stosować mechanizmy mające na celu ograniczenie negatywnego wpływu automatycznego ruchu na działanie Aplikacji.

2. Mechanizmy, o których mowa w ust. 1, mogą obejmować w szczególności:

a. ograniczanie liczby żądań;

b. wykrywanie nietypowej aktywności;

c. czasowe blokowanie źródeł ruchu;

d. dodatkową weryfikację użytkownika;

e. inne środki adekwatne do poziomu zagrożenia.

§41. Ciągłość działania

1. Zentra podejmuje działania zmierzające do utrzymania ciągłości świadczenia usług.

2. W przypadku awarii lub incydentu bezpieczeństwa Usługodawca podejmuje działania mające na celu możliwie szybkie przywrócenie prawidłowego funkcjonowania usług.

3. Ze względu na charakter zagrożenia nie jest możliwe zagwarantowanie całkowitej nieprzerwanej dostępności Aplikacji.

4. Działania podejmowane przez Usługodawcę mają na celu ograniczenie skutków awarii oraz skrócenie czasu niedostępności usług.

ROZDZIAŁ V

OCHRONA PRZED CYBERZAGROŻENIAMI

§42. Cel ochrony

1. Celem niniejszego rozdziału jest określenie zasad przeciwdziałania zagrożeniom mogącym naruszyć bezpieczeństwo Aplikacji, danych lub infrastruktury wykorzystywanej przez Zentrę.

2. Usługodawca podejmuje działania mające na celu wykrywanie, analizowanie oraz ograniczanie skutków cyberzagrożeń odpowiednio do poziomu ryzyka oraz charakteru świadczonych Usług.

3. Ze względu na dynamiczny rozwój metod prowadzenia cyberataków nie jest możliwe całkowite wyeliminowanie ryzyka ich wystąpienia.

§43. Zakaz podejmowania działań naruszających bezpieczeństwo

1. Zabrania się podejmowania jakichkolwiek działań mogących naruszyć bezpieczeństwo Aplikacji lub infrastruktury Usługodawcy.

2. W szczególności zabronione jest:

a. obchodzenie mechanizmów bezpieczeństwa;

b. uzyskiwanie dostępu do danych bez uprawnienia;

c. podejmowanie prób eskalacji uprawnień;

d. wykorzystywanie błędów aplikacji do osiągnięcia nieuprawnionych korzyści;

e. zakłócanie działania usług;

f. podejmowanie prób przejęcia kont innych użytkowników;

g. wykorzystywanie zautomatyzowanych narzędzi w celu naruszenia bezpieczeństwa.

§44. Próby nieautoryzowanego dostępu

1. Podejmowanie prób uzyskania dostępu do zasobów, do których Użytkownik nie posiada uprawnień, jest zabronione.

2. Dotyczy to również prób uzyskania dostępu do:

a. paneli administracyjnych;

b. środowisk testowych;

c. interfejsów programistycznych;

d. zasobów innych Organizacji;

e. danych innych użytkowników.

3. W przypadku wykrycia takich działań Usługodawca może podjąć środki ochronne przewidziane w Regulaminie oraz niniejszej Polityce.

§45. Automatyczne próby logowania

1. Zabrania się prowadzenia zautomatyzowanych prób logowania do Aplikacji.

2. W szczególności zakazane są:

a. ataki typu Brute Force;

b. Credential Stuffing;

c. Password Spraying;

d. inne działania mające na celu odgadnięcie danych uwierzytelniających.

3. W przypadku wykrycia takich działań Usługodawca może zastosować odpowiednie środki ochronne, w tym czasowe ograniczenie dostępu, blokadę konta lub blokadę źródła ruchu.

§46. Ataki na aplikację

1. Zabrania się podejmowania prób wykorzystania podatności aplikacyjnych.

2. Zakaz obejmuje w szczególności próby wykorzystania podatności określanych powszechnie jako:

a. SQL Injection;

b. Cross-Site Scripting (XSS);

c. Cross-Site Request Forgery (CSRF);

d. Server-Side Request Forgery (SSRF);

e. Remote Code Execution (RCE);

f. Directory Traversal;

g. Path Traversal;

h. XML External Entity (XXE);

i. deserializacja niezaufanych danych;

j. inne podatności mogące naruszyć bezpieczeństwo Aplikacji.

§47. Ataki na interfejsy programistyczne

1. Zabrania się podejmowania prób zakłócania działania interfejsów API udostępnianych przez Zentrę.

2. W szczególności zabronione jest:

a. obchodzenie limitów;

b. manipulowanie żądaniami;

c. wykorzystywanie nieudokumentowanych funkcjonalności;

d. próby uzyskania danych spoza przyznanych uprawnień;

e. generowanie nadmiernego ruchu.

§48. Złośliwe oprogramowanie

1. Zabrania się przesyłania do Aplikacji materiałów zawierających złośliwe oprogramowanie.

2. Zakaz obejmuje między innymi:

a. wirusy;

b. trojany;

c. ransomware;

d. spyware;

e. keyloggery;

f. robaki komputerowe;

g. skrypty służące naruszeniu bezpieczeństwa;

h. inne programy mogące zakłócić działanie usług.

3. Usługodawca może odmówić przyjęcia danych lub plików, które mogą stwarzać zagrożenie dla bezpieczeństwa.

§49. Ataki socjotechniczne

1. Zabrania się podejmowania działań polegających na wyłudzaniu informacji dotyczących bezpieczeństwa Aplikacji.

2. Zakaz obejmuje w szczególności:

a. phishing;

b. spear phishing;

c. podszywanie się pod pracowników Usługodawcy;

d. podszywanie się pod użytkowników;

e. wyłudzanie danych logowania;

f. wyłudzanie kodów uwierzytelniających.

§50. Testowanie bezpieczeństwa

1. Przeprowadzanie testów bezpieczeństwa infrastruktury, aplikacji lub interfejsów API wymaga uprzedniej pisemnej zgody Usługodawcy.

2. Bez uzyskania zgody zabrania się:

a. skanowania podatności;

b. testów penetracyjnych;

c. fuzzingu;

d. automatycznego wykrywania podatności;

e. innych działań mogących wpłynąć na bezpieczeństwo lub dostępność usług.

3. Postanowienia niniejszego paragrafu nie wyłączają możliwości odpowiedzialnego zgłaszania podatności zgodnie z zasadami określonymi w niniejszej Polityce.

§51. Reakcja na zagrożenia

1. W przypadku wykrycia działań mogących zagrażać bezpieczeństwu Aplikacji Usługodawca może niezwłocznie zastosować środki ochronne adekwatne do poziomu zagrożenia.

2. Środki te mogą obejmować w szczególności:

a. ograniczenie funkcjonalności;

b. czasową blokadę konta;

c. czasową blokadę adresów sieciowych;

d. unieważnienie aktywnych sesji;

e. czasowe ograniczenie ruchu;

f. odrzucanie podejrzanych żądań;

g. inne działania niezbędne do zapewnienia bezpieczeństwa.

3. Jeżeli będzie to możliwe i nie wpłynie negatywnie na bezpieczeństwo Aplikacji, Użytkownik zostanie poinformowany o zastosowanych środkach.

§52. Współpraca użytkowników

1. Użytkownicy są zachęcani do niezwłocznego zgłaszania zauważonych podatności, błędów bezpieczeństwa lub innych zagrożeń.

2. Zgłoszenie powinno zostać dokonane w sposób odpowiedzialny i z zachowaniem poufności.

3. Osoba zgłaszająca podatność nie powinna wykorzystywać jej w celu uzyskania nieuprawnionych korzyści ani ujawniać informacji o niej publicznie przed umożliwieniem Usługodawcy podjęcia odpowiednich działań.

4. Usługodawca może opublikować zasady odpowiedzialnego zgłaszania podatności (Responsible Disclosure Policy) jako odrębny dokument.

ROZDZIAŁ VI

ZARZĄDZANIE INCYDENTAMI BEZPIECZEŃSTWA

§53. Cel zarządzania incydentami

1. Celem zarządzania incydentami bezpieczeństwa jest możliwie szybkie wykrywanie, analizowanie, ograniczanie skutków oraz usuwanie zdarzeń mogących wpływać na bezpieczeństwo informacji, Aplikacji lub świadczonych Usług.

2. Procedury zarządzania incydentami mają na celu:

a. ograniczenie skutków naruszeń;

b. przywrócenie prawidłowego działania Usług;

c. zabezpieczenie materiału dowodowego;

d. zapobieganie podobnym zdarzeniom w przyszłości;

e. spełnienie obowiązków wynikających z przepisów prawa.

§54. Definicja incydentu bezpieczeństwa

1. Za incydent bezpieczeństwa uznaje się każde zdarzenie, które może prowadzić lub doprowadziło do naruszenia:

a. poufności informacji;

b. integralności danych;

c. dostępności Usług;

d. autentyczności danych;

e. rozliczalności działań użytkowników;

f. bezpieczeństwa infrastruktury.

2. Incydentem bezpieczeństwa może być również uzasadnione podejrzenie wystąpienia takiego zdarzenia.

§55. Przykładowe incydenty

Do incydentów bezpieczeństwa mogą należeć między innymi:

1. przejęcie Konta;

2. ujawnienie danych logowania;

3. nieuprawniony dostęp do danych;

4. utrata urządzenia wykorzystywanego do logowania;

5. wykrycie złośliwego oprogramowania;

6. próby włamania;

7. ataki typu DDoS;

8. wykrycie podatności mogącej prowadzić do naruszenia bezpieczeństwa;

9. przypadkowe ujawnienie informacji;

10. błędna konfiguracja uprawnień;

11. nieautoryzowany eksport danych;

12. naruszenie bezpieczeństwa integracji z usługami zewnętrznymi.

§56. Zgłaszanie incydentów

1. Każdy Użytkownik powinien niezwłocznie zgłosić zauważony incydent bezpieczeństwa lub uzasadnione podejrzenie jego wystąpienia.

2. Zgłoszenie powinno zawierać, o ile jest to możliwe:

a. opis zdarzenia;

b. datę i godzinę zauważenia;

c. okoliczności zdarzenia;

d. informacje mogące pomóc w analizie.

3. Brak pełnych informacji nie stanowi przeszkody do zgłoszenia incydentu.

§57. Reakcja na incydent

1. Po otrzymaniu zgłoszenia lub wykryciu incydentu Usługodawca może podjąć działania odpowiednie do charakteru zagrożenia.

2. Działania mogą obejmować w szczególności:

a. analizę zdarzenia;

b. ograniczenie skutków incydentu;

c. czasowe ograniczenie funkcjonalności;

d. zablokowanie Kont;

e. unieważnienie aktywnych sesji;

f. zabezpieczenie logów;

g. zabezpieczenie materiału dowodowego;

h. przywracanie prawidłowego działania Usług.

§58. Współpraca z Użytkownikiem

1. W przypadku incydentu bezpieczeństwa Użytkownik powinien współpracować z Usługodawcą w zakresie niezbędnym do wyjaśnienia okoliczności zdarzenia.

2. W szczególności Użytkownik może zostać poproszony o:

a. przekazanie dodatkowych informacji;

b. zmianę hasła;

c. potwierdzenie wykonanych działań;

d. weryfikację tożsamości;

e. wykonanie czynności ograniczających skutki incydentu.

§59. Środki nadzwyczajne

1. W sytuacjach wymagających natychmiastowej reakcji Usługodawca może podjąć działania bez uprzedniego informowania Użytkownika, jeżeli jest to niezbędne do:

a. ochrony danych;

b. ochrony infrastruktury;

c. ochrony innych Użytkowników;

d. ograniczenia skutków incydentu;

e. wykonania obowiązków wynikających z przepisów prawa.

2. Jeżeli okoliczności na to pozwalają, Użytkownik zostanie poinformowany o podjętych działaniach po ustaniu bezpośredniego zagrożenia.

§60. Dokumentowanie incydentów

1. Usługodawca może dokumentować incydenty bezpieczeństwa w zakresie niezbędnym do:

a. analizy zdarzeń;

b. poprawy bezpieczeństwa;

c. realizacji obowiązków prawnych;

d. dochodzenia roszczeń;

e. ochrony praw Usługodawcy oraz Użytkowników.

2. Dokumentacja incydentów może obejmować informacje techniczne, logi systemowe oraz inne dane niezbędne do wyjaśnienia przebiegu zdarzenia.

§61. Naruszenie ochrony danych osobowych

1. Jeżeli incydent stanowi naruszenie ochrony danych osobowych, Usługodawca podejmie działania wymagane obowiązującymi przepisami prawa, w szczególności przepisami RODO.

2. W przypadkach przewidzianych przepisami prawa odpowiednie organy oraz osoby, których dane dotyczą, mogą zostać poinformowane o naruszeniu.

§62. Działania po zakończeniu incydentu

1. Po zakończeniu obsługi incydentu Usługodawca może przeprowadzić analizę jego przyczyn.

2. Analiza może prowadzić do:

a. zmian procedur bezpieczeństwa;

b. zmian organizacyjnych;

c. wdrożenia nowych zabezpieczeń;

d. aktualizacji dokumentacji;

e. działań mających zapobiegać podobnym zdarzeniom w przyszłości.

3. Wnioski wynikające z analizy mogą zostać wykorzystane do dalszego doskonalenia systemu bezpieczeństwa Zentry.

ROZDZIAŁ VII

REJESTROWANIE ZDARZEŃ, MONITORING ORAZ AUDYT BEZPIECZEŃSTWA

§63. Cele monitorowania

1. Zentra może prowadzić monitoring działania Aplikacji oraz infrastruktury w zakresie niezbędnym do:

a. zapewnienia bezpieczeństwa świadczonych Usług;

b. wykrywania incydentów bezpieczeństwa;

c. przeciwdziałania nadużyciom;

d. zapewnienia ciągłości działania;

e. diagnozowania problemów technicznych;

f. spełnienia obowiązków wynikających z przepisów prawa.

2. Monitoring prowadzony jest z poszanowaniem prywatności Użytkowników oraz zgodnie z obowiązującymi przepisami prawa.

§64. Rejestrowanie zdarzeń

1. W celu zapewnienia bezpieczeństwa Aplikacji Usługodawca może rejestrować zdarzenia związane z korzystaniem z Usług.

2. Rejestrowanie zdarzeń odbywa się wyłącznie w zakresie niezbędnym do realizacji celów określonych w niniejszej Polityce.

3. Dane zgromadzone w logach nie są wykorzystywane do monitorowania działalności gospodarczej Użytkownika ani do analizy jego decyzji biznesowych, z wyjątkiem przypadków wynikających z przepisów prawa lub niezbędnych do realizacji Umowy.

§65. Rodzaje rejestrowanych zdarzeń

W zależności od dostępnych funkcjonalności oraz potrzeb bezpieczeństwa Usługodawca może rejestrować między innymi:

1. logowania;

2. nieudane próby logowania;

3. wylogowania;

4. zmianę hasła;

5. zmianę danych Konta;

6. zmianę uprawnień;

7. utworzenie lub usunięcie Konta;

8. utworzenie Organizacji;

9. dodanie lub usunięcie Użytkownika;

10. eksport danych;

11. import danych;

12. przesyłanie dokumentów;

13. usuwanie dokumentów;

14. korzystanie z wybranych funkcjonalności wymagających podwyższonego poziomu bezpieczeństwa;

15. zdarzenia związane z bezpieczeństwem infrastruktury.

§66. Dane techniczne

1. W zakresie niezbędnym do zapewnienia bezpieczeństwa Usługodawca może przetwarzać dane techniczne dotyczące korzystania z Aplikacji.

2. Dane techniczne mogą obejmować w szczególności:

a. datę i godzinę zdarzenia;

b. identyfikator sesji;

c. identyfikator użytkownika;

d. informacje o rodzaju wykonanej operacji;

e. informacje o błędach technicznych;

f. informacje o wykrytych zagrożeniach.

3. Zakres gromadzonych danych technicznych może ulegać zmianie wraz z rozwojem Aplikacji oraz zmianą zagrożeń bezpieczeństwa.

§67. Wykorzystanie logów

1. Logi mogą być wykorzystywane wyłącznie do celów związanych z:

a. bezpieczeństwem;

b. analizą incydentów;

c. diagnozowaniem błędów;

d. przywracaniem działania Usług;

e. wykrywaniem nadużyć;

f. dochodzeniem lub obroną roszczeń;

g. realizacją obowiązków prawnych.

2. Logi nie są wykorzystywane do profilowania działalności gospodarczej Użytkowników, chyba że wynika to z odrębnej zgody lub obowiązujących przepisów prawa.

§68. Ochrona logów

1. Logi bezpieczeństwa podlegają ochronie przed nieuprawnionym dostępem, modyfikacją oraz usunięciem.

2. Dostęp do logów posiadają wyłącznie osoby upoważnione.

3. Logi mogą zostać udostępnione wyłącznie:

a. osobom uprawnionym;

b. organom publicznym, jeżeli obowiązek taki wynika z przepisów prawa;

c. podmiotom świadczącym usługi na rzecz Usługodawcy, jeżeli jest to niezbędne do realizacji Umowy oraz odbywa się zgodnie z obowiązującymi przepisami.

§69. Okres przechowywania logów

1. Logi przechowywane są przez okres wynikający z obowiązujących przepisów prawa, uzasadnionych potrzeb bezpieczeństwa lub przyjętych procedur retencji danych.

2. Po upływie okresu przechowywania logi mogą zostać usunięte, zanonimizowane lub zarchiwizowane zgodnie z obowiązującymi procedurami.

§70. Audyt bezpieczeństwa

1. Usługodawca może przeprowadzać okresowe audyty bezpieczeństwa mające na celu ocenę skuteczności stosowanych środków ochrony.

2. Audyty mogą obejmować między innymi:

a. analizę konfiguracji;

b. analizę uprawnień;

c. ocenę procedur bezpieczeństwa;

d. analizę incydentów;

e. ocenę zgodności z obowiązującymi przepisami prawa;

f. ocenę zgodności z niniejszą Polityką.

3. Wyniki audytów mogą stanowić podstawę do wprowadzenia zmian organizacyjnych, technicznych lub proceduralnych.

§71. Poufność informacji audytowych

1. Dokumentacja dotycząca audytów bezpieczeństwa ma charakter poufny.

2. Informacje uzyskane podczas audytów nie podlegają ujawnieniu, z wyjątkiem przypadków wynikających z przepisów prawa lub gdy jest to niezbędne do ochrony praw Usługodawcy.

3. Udostępnienie informacji dotyczących audytu osobom trzecim wymaga odpowiedniej podstawy prawnej lub umownej.

ROZDZIAŁ VIII

BEZPIECZEŃSTWO SZTUCZNEJ INTELIGENCJI ORAZ AUTOMATYCZNEGO PRZETWARZANIA DANYCH

§72. Cel wykorzystania sztucznej inteligencji

1. Zentra może wykorzystywać rozwiązania oparte na sztucznej inteligencji (AI) w celu wspierania Użytkowników w wykonywaniu czynności związanych z prowadzeniem działalności gospodarczej.

2. Funkcje AI mają charakter wspomagający i służą między innymi:

a. analizie danych;

b. generowaniu propozycji działań;

c. automatyzacji wybranych procesów;

d. wspieraniu organizacji pracy;

e. przygotowywaniu zestawień, podsumowań lub sugestii.

3. Zakres funkcjonalności AI może ulegać zmianom wraz z rozwojem Aplikacji.

§73. Charakter odpowiedzi AI

1. Odpowiedzi generowane przez AI mają charakter pomocniczy i nie stanowią decyzji podejmowanej przez Usługodawcę.

2. Wyniki działania AI mogą zawierać błędy, nieścisłości, nieaktualne informacje lub nie uwzględniać wszystkich okoliczności konkretnej sprawy.

3. Użytkownik powinien samodzielnie ocenić zasadność wykorzystania odpowiedzi wygenerowanej przez AI przed podjęciem decyzji biznesowej, finansowej, podatkowej, księgowej lub prawnej.

§74. Ograniczenia odpowiedzialności

1. Usługodawca nie gwarantuje, że odpowiedzi AI będą:

a. kompletne;

b. bezbłędne;

c. aktualne;

d. odpowiednie dla konkretnego przypadku.

2. AI nie zastępuje profesjonalnej porady świadczonej przez:

a. radcę prawnego;

b. adwokata;

c. doradcę podatkowego;

d. biegłego rewidenta;

e. księgowego;

f. innego specjalistę właściwego dla danej dziedziny.

3. Korzystanie z odpowiedzi AI nie zwalnia Użytkownika z obowiązku weryfikacji informacji przed ich wykorzystaniem.

§75. Dane przekazywane do modułów AI

1. Użytkownik powinien przekazywać do funkcji AI wyłącznie dane, których wykorzystanie jest zgodne z obowiązującymi przepisami prawa oraz zasadami korzystania z Aplikacji.

2. Zabrania się wykorzystywania modułów AI do:

a. naruszania praw osób trzecich;

b. przetwarzania danych w sposób niezgodny z prawem;

c. obchodzenia zabezpieczeń Aplikacji;

d. generowania treści bezprawnych;

e. podejmowania działań naruszających bezpieczeństwo systemów informatycznych.

3. Usługodawca może stosować mechanizmy ograniczające wykorzystanie AI w sposób sprzeczny z prawem, Regulaminem lub niniejszą Polityką.

§76. Ochrona informacji wykorzystywanych przez AI

1. Dane przetwarzane przez moduły AI podlegają ochronie zgodnie z obowiązującymi przepisami prawa oraz zasadami określonymi w Polityce Prywatności i niniejszej Polityce.

2. W przypadku korzystania z usług dostawców technologii AI dane mogą być przekazywane wyłącznie w zakresie niezbędnym do realizacji danej funkcjonalności oraz na odpowiedniej podstawie prawnej.

3. Szczegółowe informacje dotyczące przetwarzania danych przez dostawców usług AI są określane w Polityce Prywatności lub odrębnych dokumentach informacyjnych.

§77. Nadużycia związane z AI

1. Usługodawca może ograniczyć lub zablokować dostęp do funkcji AI w przypadku stwierdzenia, że są one wykorzystywane w sposób:

a. niezgodny z prawem;

b. naruszający Regulamin;

c. zagrażający bezpieczeństwu Aplikacji;

d. naruszający prawa osób trzecich;

e. mogący prowadzić do nadużyć lub oszustw.

2. Ograniczenia mogą zostać zastosowane również w celu ochrony infrastruktury technicznej, integralności systemu lub innych Użytkowników.

§78. Rozwój funkcji AI

1. Funkcjonalności AI mogą być rozwijane, modyfikowane, rozszerzane lub wycofywane w zależności od potrzeb organizacyjnych, technologicznych oraz obowiązujących przepisów prawa.

2. Zmiany funkcjonalności AI nie stanowią zmiany niniejszej Polityki, jeżeli nie wpływają na prawa lub obowiązki Użytkowników.

§79. Zasady odpowiedzialnego korzystania z AI

1. Użytkownik zobowiązuje się korzystać z funkcji AI w sposób zgodny z:

a. obowiązującymi przepisami prawa;

b. Regulaminem;

c. niniejszą Polityką;

d. dobrymi obyczajami;

e. zasadami uczciwego obrotu gospodarczego.

2. Użytkownik ponosi odpowiedzialność za sposób wykorzystania informacji uzyskanych przy użyciu funkcji AI oraz za decyzje podjęte na ich podstawie.

3. Usługodawca może prowadzić działania mające na celu zwiększanie bezpieczeństwa funkcji AI, ograniczanie ryzyka nadużyć oraz dostosowywanie sposobu działania systemu do zmian technologicznych i prawnych.

ROZDZIAŁ IX

BEZPIECZEŃSTWO INTEGRACJI Z USŁUGAMI ZEWNĘTRZNYMI

§80. Zasady ogólne

1. W celu świadczenia Usług oraz rozwijania funkcjonalności Aplikacji, Zentra może korzystać z usług, systemów oraz infrastruktury dostarczanej przez podmioty trzecie.

2. Integracje z usługami zewnętrznymi są dobierane z uwzględnieniem ich funkcjonalności, bezpieczeństwa, niezawodności oraz zgodności z obowiązującymi przepisami prawa.

3. Korzystanie z usług podmiotów trzecich nie zwalnia Usługodawcy z obowiązku zapewnienia odpowiedniego poziomu ochrony danych w zakresie wynikającym z obowiązujących przepisów prawa.

§81. Zakres integracji

1. Zentra może integrować się w szczególności z:

a. usługami przechowywania danych;

b. usługami sztucznej inteligencji;

c. systemami księgowymi;

d. systemami administracji publicznej;

e. usługami poczty elektronicznej;

f. usługami wysyłki wiadomości SMS lub powiadomień;

g. operatorami płatności;

h. usługami analitycznymi;

i. innymi usługami niezbędnymi do świadczenia lub rozwoju Usług.

2. Lista wykorzystywanych usług może ulegać zmianom wraz z rozwojem Aplikacji.

§82. Bezpieczeństwo połączeń

1. Integracje z usługami zewnętrznymi powinny wykorzystywać odpowiednie mechanizmy uwierzytelniania oraz ochrony komunikacji, adekwatne do charakteru danej integracji.

2. Dane dostępowe do usług zewnętrznych powinny być chronione przed nieuprawnionym dostępem.

3. Dostęp do kluczy API, tokenów oraz innych danych uwierzytelniających posiadają wyłącznie osoby lub systemy, którym jest to niezbędne do wykonywania powierzonych zadań.

§83. Dane przekazywane usługom zewnętrznym

1. Dane mogą być przekazywane usługom zewnętrznym wyłącznie w zakresie niezbędnym do realizacji określonej funkcjonalności.

2. Zakres przekazywanych danych powinien odpowiadać zasadzie minimalizacji danych.

3. Przekazywanie danych odbywa się zgodnie z obowiązującymi przepisami prawa, zawartymi umowami oraz Polityką Prywatności.

§84. Dostępność usług zewnętrznych

1. Niektóre funkcjonalności Aplikacji mogą być uzależnione od prawidłowego działania usług świadczonych przez podmioty trzecie.

2. Usługodawca nie ponosi odpowiedzialności za przerwy w działaniu, ograniczenia funkcjonalności lub błędy wynikające wyłącznie z awarii, niedostępności albo zmian wprowadzonych przez dostawcę usługi zewnętrznej, chyba że odpowiedzialność taka wynika z bezwzględnie obowiązujących przepisów prawa.

3. W przypadku awarii usługi zewnętrznej Usługodawca podejmie uzasadnione działania w celu ograniczenia wpływu awarii na funkcjonowanie Aplikacji.

§85. Zmiany po stronie dostawców

1. Dostawcy usług zewnętrznych mogą zmieniać zakres, sposób działania lub warunki korzystania ze swoich usług.

2. W przypadku zmian mających wpływ na funkcjonowanie Aplikacji Usługodawca może odpowiednio dostosować sposób działania integracji.

3. W razie potrzeby Usługodawca może zastąpić jednego dostawcę innym dostawcą świadczącym podobne usługi.

§86. Weryfikacja dostawców

1. Przy wyborze dostawców usług zewnętrznych Usługodawca dąży do uwzględnienia w szczególności:

a. poziomu bezpieczeństwa;

b. stabilności świadczonych usług;

c. zgodności z obowiązującymi przepisami prawa;

d. reputacji dostawcy;

e. dostępności wsparcia technicznego.

2. Usługodawca może okresowo oceniać współpracę z dostawcami oraz podejmować decyzje o zmianie dostawcy, jeżeli uzna to za uzasadnione.

§87. Zarządzanie dostępami do usług zewnętrznych

1. Dostęp do paneli administracyjnych oraz kont wykorzystywanych do obsługi usług zewnętrznych powinien być ograniczony do osób upoważnionych.

2. Uprawnienia do usług zewnętrznych podlegają okresowej weryfikacji.

3. Po ustaniu potrzeby korzystania z danego dostępu powinien on zostać niezwłocznie odebrany lub ograniczony.

§88. Zakończenie współpracy z dostawcą

1. W przypadku zakończenia współpracy z dostawcą usług zewnętrznych Usługodawca podejmuje działania zmierzające do:

a. odebrania dostępu do danych;

b. zabezpieczenia informacji;

c. migracji danych, jeżeli jest to wymagane;

d. usunięcia lub dezaktywacji nieużywanych danych uwierzytelniających;

e. zapewnienia ciągłości świadczenia Usług w możliwym zakresie.

2. Zakres działań zależy od rodzaju usługi oraz warunków współpracy z danym dostawcą.

§89. Odpowiedzialność za usługi zewnętrzne

1. Usługodawca odpowiada za prawidłową konfigurację integracji pozostających pod jego kontrolą.

2. Usługodawca nie odpowiada za działania lub zaniechania niezależnych dostawców usług zewnętrznych, w szczególności za:

a. awarie ich infrastruktury;

b. błędy ich oprogramowania;

c. zmiany interfejsów API;

d. ograniczenie lub zakończenie świadczenia usług;

e. inne okoliczności pozostające poza kontrolą Usługodawcy.

3. Postanowienia niniejszego paragrafu nie wyłączają odpowiedzialności Usługodawcy w zakresie wynikającym z bezwzględnie obowiązujących przepisów prawa.

ROZDZIAŁ X

BEZPIECZEŃSTWO ORGANIZACYJNE ORAZ ZARZĄDZANIE DOSTĘPEM WEWNĘTRZNYM

§90. Cel

1. Celem niniejszego rozdziału jest określenie zasad organizacyjnych służących ochronie informacji, danych oraz infrastruktury wykorzystywanej przez Zentrę.

2. Środki organizacyjne mają ograniczać ryzyko wynikające z błędów ludzkich, niewłaściwego zarządzania dostępami oraz nieuprawnionego ujawnienia informacji.

§91. Dostęp pracowników i współpracowników

1. Dostęp do systemów wykorzystywanych przez Zentrę może zostać przyznany wyłącznie osobom, którym jest on niezbędny do wykonywania powierzonych obowiązków.

2. Zakres dostępu powinien odpowiadać rzeczywistym potrzebom wynikającym z pełnionej funkcji.

3. Dostępy podlegają okresowej weryfikacji.

4. Po zakończeniu współpracy dostęp powinien zostać niezwłocznie odebrany.

§92. Poufność informacji

1. Osoby posiadające dostęp do informacji związanych z działalnością Zentry są zobowiązane do zachowania ich poufności.

2. Informacje nie mogą być ujawniane osobom nieuprawnionym.

3. Obowiązek zachowania poufności obowiązuje również po zakończeniu współpracy, jeżeli wynika to z przepisów prawa, zawartych umów lub charakteru informacji.

§93. Dane uwierzytelniające

1. Dane umożliwiające dostęp do systemów powinny być przechowywane w sposób ograniczający ryzyko ich ujawnienia.

2. Zabrania się:

a. udostępniania haseł osobom trzecim;

b. przesyłania danych uwierzytelniających w sposób nieodpowiednio zabezpieczony;

c. wykorzystywania wspólnych kont administracyjnych, jeżeli możliwe jest stosowanie kont indywidualnych.

§94. Zarządzanie uprawnieniami

1. Nadawanie, zmiana oraz odebranie uprawnień powinny odbywać się w sposób umożliwiający zachowanie rozliczalności działań.

2. Uprawnienia powinny być przyznawane zgodnie z zasadą najmniejszych uprawnień oraz zasadą potrzeby wiedzy.

3. Uprawnienia administracyjne powinny być ograniczone do niezbędnego minimum.

§95. Korzystanie ze sprzętu

1. Osoby korzystające z urządzeń służbowych lub prywatnych wykorzystywanych do obsługi Zentry powinny podejmować działania ograniczające ryzyko nieuprawnionego dostępu.

2. W szczególności zaleca się:

a. stosowanie blokady ekranu;

b. zabezpieczenie urządzeń hasłem lub inną metodą uwierzytelniania;

c. aktualizowanie oprogramowania;

d. ochronę urządzeń przed dostępem osób nieuprawnionych.

§96. Praca zdalna

1. W przypadku wykonywania obowiązków poza siedzibą Usługodawcy osoby uprawnione powinny zachować szczególną ostrożność podczas korzystania z systemów Zentry.

2. W szczególności należy unikać:

a. pozostawiania urządzeń bez nadzoru;

b. korzystania z niezaufanych urządzeń;

c. ujawniania informacji osobom postronnym;

d. korzystania z publicznych sieci w sposób mogący narazić bezpieczeństwo danych.

§97. Zarządzanie zmianami

1. Zmiany mogące wpływać na bezpieczeństwo Aplikacji powinny być planowane oraz wdrażane z należytą starannością.

2. W uzasadnionych przypadkach przed wdrożeniem zmian mogą zostać przeprowadzone testy funkcjonalne lub bezpieczeństwa.

3. W przypadku wykrycia istotnego ryzyka wdrożenie zmian może zostać odłożone do czasu jego ograniczenia.

§98. Szkolenia i świadomość bezpieczeństwa

1. Usługodawca może prowadzić działania mające na celu podnoszenie świadomości w zakresie bezpieczeństwa informacji.

2. Działania te mogą obejmować:

a. szkolenia;

b. instrukcje;

c. procedury;

d. komunikaty dotyczące nowych zagrożeń;

e. inne działania edukacyjne.

§99. Odpowiedzialność

1. Każda osoba posiadająca dostęp do systemów Zentry jest zobowiązana do korzystania z nich zgodnie z obowiązującymi przepisami prawa, Regulaminem oraz niniejszą Polityką.

2. Naruszenie zasad bezpieczeństwa może skutkować ograniczeniem lub odebraniem dostępu do systemów oraz innymi konsekwencjami przewidzianymi przepisami prawa lub zawartymi umowami.

3. Postanowienia niniejszego rozdziału nie wyłączają odpowiedzialności Administratorów Organizacji za prawidłowe zarządzanie użytkownikami oraz nadawanymi im uprawnieniami.

ROZDZIAŁ XI

CIĄGŁOŚĆ DZIAŁANIA, KOPIE ZAPASOWE ORAZ ODTWARZANIE DANYCH

§100. Cel

1. Celem niniejszego rozdziału jest określenie zasad mających na celu zapewnienie ciągłości świadczenia Usług oraz ograniczenie skutków awarii, incydentów bezpieczeństwa i innych zdarzeń mogących wpływać na funkcjonowanie Aplikacji.

2. Usługodawca dąży do utrzymania dostępności świadczonych Usług przy zastosowaniu środków organizacyjnych i technicznych odpowiednich do charakteru prowadzonej działalności.

§101. Ciągłość działania

1. Zentra podejmuje działania zmierzające do utrzymania ciągłości działania Aplikacji oraz ograniczania skutków zdarzeń mogących powodować przerwy w świadczeniu Usług.

2. Działania, o których mowa w ust. 1, mogą obejmować w szczególności:

a. monitorowanie dostępności usług;

b. analizę ryzyka;

c. planowanie działań naprawczych;

d. stosowanie mechanizmów zwiększających odporność systemu;

e. przygotowanie procedur przywracania działania usług.

3. Ze względu na charakter usług świadczonych drogą elektroniczną nie jest możliwe zagwarantowanie nieprzerwanej dostępności Aplikacji.

§102. Kopie zapasowe

1. W zakresie uzasadnionym potrzebami bezpieczeństwa Usługodawca może wykonywać kopie zapasowe danych przetwarzanych w Aplikacji.

2. Zakres, częstotliwość oraz sposób wykonywania kopii zapasowych zależą od:

a. charakteru danych;

b. poziomu ryzyka;

c. wymagań technicznych;

d. możliwości organizacyjnych;

e. obowiązujących przepisów prawa.

3. Kopie zapasowe mogą obejmować całość lub część danych niezbędnych do zapewnienia ciągłości działania Usług.

§103. Ochrona kopii zapasowych

1. Kopie zapasowe podlegają ochronie przed:

a. nieuprawnionym dostępem;

b. utratą;

c. zniszczeniem;

d. nieuprawnioną modyfikacją;

e. przypadkowym usunięciem.

2. Dostęp do kopii zapasowych posiadają wyłącznie osoby upoważnione.

3. Środki ochrony kopii zapasowych dobierane są odpowiednio do poziomu ryzyka oraz charakteru przechowywanych danych.

§104. Odtwarzanie danych

1. W przypadku awarii, utraty danych lub innego zdarzenia wpływającego na dostępność informacji Usługodawca może podjąć działania zmierzające do odtworzenia danych z dostępnych kopii zapasowych.

2. Odtwarzanie danych odbywa się z uwzględnieniem możliwości technicznych, charakteru incydentu oraz dostępności materiału umożliwiającego odtworzenie danych.

3. Usługodawca podejmuje uzasadnione działania w celu ograniczenia ryzyka utraty danych, jednak nie gwarantuje możliwości odzyskania wszystkich danych w każdym przypadku.

§105. Awarie infrastruktury

1. W przypadku awarii infrastruktury technicznej Usługodawca podejmuje działania mające na celu możliwie szybkie przywrócenie prawidłowego funkcjonowania Usług.

2. Zakres działań naprawczych zależy od:

a. rodzaju awarii;

b. skali zdarzenia;

c. dostępności zasobów;

d. możliwości technicznych;

e. wpływu zdarzenia na Użytkowników.

§106. Zdarzenia nadzwyczajne

1. Zdarzenia nadzwyczajne mogą obejmować między innymi:

a. poważne awarie techniczne;

b. rozległe incydenty cyberbezpieczeństwa;

c. awarie infrastruktury dostawców usług;

d. przerwy w dostawie energii;

e. katastrofy naturalne;

f. działania organów publicznych wpływające na świadczenie Usług;

g. inne zdarzenia pozostające poza kontrolą Usługodawcy.

2. W takich przypadkach Usługodawca podejmuje działania adekwatne do charakteru i skali zdarzenia.

§107. Testowanie procedur

1. Usługodawca może okresowo weryfikować skuteczność procedur związanych z ciągłością działania oraz odtwarzaniem danych.

2. Weryfikacja może obejmować:

a. testy procedur;

b. analizę skuteczności zastosowanych rozwiązań;

c. ocenę możliwości odtworzenia danych;

d. ocenę czasu przywracania usług.

3. Wyniki weryfikacji mogą stanowić podstawę do aktualizacji procedur bezpieczeństwa.

§108. Komunikacja z Użytkownikami

1. W przypadku istotnych awarii lub zdarzeń wpływających na świadczenie Usług Usługodawca może przekazywać Użytkownikom informacje dotyczące:

a. charakteru zdarzenia;

b. przewidywanego czasu usunięcia problemu;

c. dostępnych sposobów ograniczenia skutków awarii;

d. zakończenia działań naprawczych.

2. Zakres przekazywanych informacji może zostać ograniczony, jeżeli ich ujawnienie mogłoby negatywnie wpłynąć na bezpieczeństwo Aplikacji lub utrudnić usunięcie skutków zdarzenia.

§109. Doskonalenie odporności

1. Zentra dąży do systematycznego zwiększania odporności swoich usług na awarie oraz zagrożenia bezpieczeństwa.

2. W tym celu Usługodawca może rozwijać rozwiązania organizacyjne i techniczne służące poprawie ciągłości działania, ochrony danych oraz bezpieczeństwa infrastruktury.

3. Rozwiązania stosowane przez Usługodawcę mogą być modyfikowane wraz z rozwojem technologii, zmianami przepisów prawa oraz pojawianiem się nowych zagrożeń.

ROZDZIAŁ XII

ZARZĄDZANIE RYZYKIEM BEZPIECZEŃSTWA INFORMACJI

§110. Cel zarządzania ryzykiem

1. Celem zarządzania ryzykiem jest identyfikowanie, analiza, ocena oraz ograniczanie ryzyk mogących wpływać na bezpieczeństwo informacji, ciągłość działania oraz prawidłowe świadczenie Usług.

2. Zarządzanie ryzykiem stanowi proces ciągły i jest elementem systemu zarządzania bezpieczeństwem informacji Zentry.

§111. Identyfikacja ryzyka

1. Usługodawca może okresowo identyfikować zagrożenia mogące wpływać na:

a. poufność informacji;

b. integralność danych;

c. dostępność usług;

d. zgodność z przepisami prawa;

e. bezpieczeństwo infrastruktury;

f. bezpieczeństwo użytkowników;

g. bezpieczeństwo integracji z usługami zewnętrznymi.

2. Identyfikacja ryzyka może uwzględniać zarówno zagrożenia techniczne, jak i organizacyjne.

§112. Ocena ryzyka

1. Po zidentyfikowaniu ryzyka Usługodawca może dokonać jego oceny z uwzględnieniem w szczególności:

a. prawdopodobieństwa wystąpienia;

b. możliwych skutków;

c. wpływu na użytkowników;

d. wpływu na działalność Usługodawcy;

e. możliwości ograniczenia ryzyka.

2. Ocena ryzyka może być aktualizowana w przypadku zmian technologicznych, organizacyjnych lub prawnych.

§113. Postępowanie z ryzykiem

1. W zależności od charakteru ryzyka Usługodawca może:

a. ograniczyć ryzyko poprzez wdrożenie odpowiednich środków bezpieczeństwa;

b. zaakceptować ryzyko, jeżeli jego poziom jest uzasadniony;

c. przenieść ryzyko na inny podmiot, jeżeli dopuszczają to przepisy prawa oraz zawarte umowy;

d. zrezygnować z działań powodujących niedopuszczalne ryzyko.

2. Dobór sposobu postępowania z ryzykiem zależy od jego charakteru, wpływu na bezpieczeństwo oraz możliwości organizacyjnych i technicznych.

§114. Monitorowanie ryzyka

1. Ryzyka bezpieczeństwa mogą podlegać okresowemu monitorowaniu.

2. Monitoring może obejmować:

a. analizę incydentów;

b. analizę podatności;

c. wyniki audytów;

d. zmiany przepisów prawa;

e. nowe zagrożenia technologiczne;

f. informacje pochodzące od dostawców usług.

3. Wyniki monitorowania mogą stanowić podstawę do aktualizacji procedur bezpieczeństwa.

§115. Akceptowalny poziom ryzyka

1. Nie wszystkie ryzyka mogą zostać całkowicie wyeliminowane.

2. Usługodawca dąży do utrzymywania ryzyka na poziomie uznanym za akceptowalny z punktu widzenia charakteru świadczonych Usług oraz dostępnych środków organizacyjnych i technicznych.

3. Podejmowane działania mają na celu zmniejszanie prawdopodobieństwa wystąpienia incydentów oraz ograniczanie ich potencjalnych skutków.

§116. Aktualizacja procesu zarządzania ryzykiem

1. Proces zarządzania ryzykiem podlega okresowej ocenie.

2. Aktualizacja może nastąpić w szczególności w przypadku:

a. wystąpienia istotnego incydentu bezpieczeństwa;

b. wdrożenia nowych funkcjonalności;

c. zmiany architektury systemu;

d. zmiany dostawców kluczowych usług;

e. zmian przepisów prawa;

f. pojawienia się nowych kategorii zagrożeń.

3. Zmiany procesu zarządzania ryzykiem mogą prowadzić do aktualizacji niniejszej Polityki lub procedur wewnętrznych.

ROZDZIAŁ XIII

BEZPIECZEŃSTWO INTERFEJSÓW PROGRAMISTYCZNYCH (API)

§117. Cel

1. Niniejszy rozdział określa zasady bezpieczeństwa dotyczące korzystania z interfejsów programistycznych (API) udostępnianych przez Zentrę.

2. Postanowienia niniejszego rozdziału stosuje się w przypadku udostępnienia przez Usługodawcę interfejsów API umożliwiających integrację z Aplikacją.

§118. Dostęp do API

1. Dostęp do API może wymagać uprzedniej autoryzacji oraz spełnienia warunków określonych przez Usługodawcę.

2. Usługodawca może uzależnić dostęp do API od:

a. posiadania aktywnego Konta;

b. weryfikacji Organizacji;

c. zaakceptowania dodatkowych warunków korzystania z API;

d. stosowania odpowiednich mechanizmów uwierzytelniania.

3. Usługodawca może odmówić przyznania dostępu do API, jeżeli jest to uzasadnione względami bezpieczeństwa lub obowiązującymi przepisami prawa.

§119. Klucze API

1. Klucze API, tokeny dostępu oraz inne dane uwierzytelniające mają charakter poufny.

2. Użytkownik jest zobowiązany do ich odpowiedniego zabezpieczenia oraz nieudostępniania osobom nieuprawnionym.

3. Użytkownik ponosi odpowiedzialność za działania wykonane z wykorzystaniem jego kluczy API, chyba że wykaże, iż doszło do ich wykorzystania pomimo zachowania należytej staranności lub z przyczyn od niego niezależnych.

4. W przypadku podejrzenia ujawnienia klucza API Użytkownik powinien niezwłocznie:

a. unieważnić klucz, jeżeli jest to możliwe;

b. wygenerować nowy klucz;

c. poinformować Usługodawcę o incydencie, jeżeli może on mieć wpływ na bezpieczeństwo Aplikacji lub danych.

§120. Zasady korzystania z API

1. Korzystanie z API powinno odbywać się zgodnie z dokumentacją techniczną oraz niniejszą Polityką.

2. Zabrania się:

a. obchodzenia mechanizmów autoryzacji;

b. wykorzystywania API do działań niezgodnych z prawem;

c. generowania nadmiernego ruchu mogącego wpływać na dostępność Usług;

d. podejmowania prób uzyskania dostępu do danych, do których Użytkownik nie posiada uprawnień;

e. wykorzystywania API w sposób naruszający bezpieczeństwo innych Użytkowników lub infrastruktury Zentry.

§121. Ograniczenia techniczne

1. W celu zapewnienia bezpieczeństwa i stabilności działania Aplikacji Usługodawca może stosować środki techniczne dotyczące korzystania z API, w szczególności:

a. limity liczby zapytań;

b. ograniczenia przepustowości;

c. ograniczenia liczby jednoczesnych połączeń;

d. mechanizmy wykrywania nadużyć;

e. czasowe blokady dostępu.

2. Zakres oraz sposób stosowania środków, o których mowa w ust. 1, może ulegać zmianie wraz z rozwojem Aplikacji.

§122. Zawieszenie lub cofnięcie dostępu

1. Usługodawca może czasowo ograniczyć lub cofnąć dostęp do API w przypadku:

a. naruszenia niniejszej Polityki;

b. naruszenia Regulaminu;

c. wykrycia zagrożenia bezpieczeństwa;

d. konieczności wykonania prac serwisowych;

e. obowiązku wynikającego z przepisów prawa.

2. O ile nie uniemożliwiają tego względy bezpieczeństwa lub przepisy prawa, Usługodawca dołoży starań, aby poinformować Użytkownika o przyczynach ograniczenia dostępu.

§123. Zmiany API

1. Usługodawca może rozwijać, zmieniać lub wycofywać funkcjonalności API.

2. W miarę możliwości Usługodawca będzie dążył do zapewnienia odpowiedniego okresu przejściowego dla zmian mogących wpływać na integracje Użytkowników.

3. Zmiany wynikające z wymogów bezpieczeństwa mogą zostać wprowadzone ze skutkiem natychmiastowym, jeżeli jest to niezbędne do ochrony Aplikacji, danych lub Użytkowników.

§124. Odpowiedzialność

1. Użytkownik odpowiada za bezpieczeństwo własnych systemów wykorzystujących API Zentry.

2. Usługodawca nie ponosi odpowiedzialności za szkody wynikające z:

a. nieprawidłowej implementacji API przez Użytkownika;

b. niewłaściwego zabezpieczenia kluczy API;

c. błędów systemów zewnętrznych pozostających poza kontrolą Usługodawcy;

d. wykorzystania API w sposób niezgodny z dokumentacją lub przeznaczeniem.

3. Postanowienia niniejszego paragrafu nie wyłączają odpowiedzialności Usługodawcy wynikającej z bezwzględnie obowiązujących przepisów prawa.

ROZDZIAŁ XIV

ZARZĄDZANIE PODATNOŚCIAMI ORAZ ODPOWIEDZIALNE ZGŁASZANIE LUK BEZPIECZEŃSTWA

§125. Cel

1. Celem niniejszego rozdziału jest określenie zasad identyfikowania, oceny, zgłaszania oraz usuwania podatności mogących wpływać na bezpieczeństwo Aplikacji, danych oraz infrastruktury Zentry.

2. Usługodawca dąży do możliwie szybkiego ograniczania ryzyka wynikającego z wykrytych podatności z uwzględnieniem ich charakteru, wpływu oraz dostępnych środków organizacyjnych i technicznych.

§126. Identyfikowanie podatności

1. Podatności mogą być identyfikowane między innymi poprzez:

a. wewnętrzne analizy bezpieczeństwa;

b. testy bezpieczeństwa;

c. audyty;

d. monitoring infrastruktury;

e. zgłoszenia Użytkowników;

f. zgłoszenia niezależnych badaczy bezpieczeństwa;

g. informacje przekazywane przez dostawców usług;

h. informacje pochodzące z publicznie dostępnych źródeł.

2. Wykrycie podatności nie oznacza automatycznie wystąpienia incydentu bezpieczeństwa.

§127. Zgłaszanie podatności

1. Każda osoba, która w dobrej wierze wykryje potencjalną podatność bezpieczeństwa dotyczącą Zentry, może zgłosić ją Usługodawcy.

2. Zgłoszenie powinno zawierać, w miarę możliwości:

a. opis podatności;

b. sposób jej odtworzenia;

c. informacje umożliwiające ocenę wpływu podatności;

d. dane kontaktowe zgłaszającego, jeżeli chce otrzymać odpowiedź.

3. Usługodawca może opublikować dedykowany adres e-mail lub formularz przeznaczony do zgłaszania podatności.

§128. Zasady odpowiedzialnego zgłaszania

1. Osoba zgłaszająca podatność powinna działać w dobrej wierze oraz z poszanowaniem prawa.

2. W szczególności osoba zgłaszająca nie powinna:

a. wykorzystywać podatności do osiągnięcia korzyści;

b. modyfikować danych innych Użytkowników;

c. usuwać danych;

d. ujawniać podatności publicznie przed umożliwieniem Usługodawcy podjęcia działań naprawczych;

e. zakłócać działania Aplikacji.

3. Zgłoszenie dokonane zgodnie z niniejszym paragrafem nie stanowi zgody Usługodawcy na prowadzenie testów bezpieczeństwa wykraczających poza niezbędny zakres potwierdzenia podatności.

§129. Analiza zgłoszeń

1. Każde zgłoszenie może zostać poddane analizie pod kątem:

a. rzeczywistego istnienia podatności;

b. wpływu na bezpieczeństwo;

c. możliwości wykorzystania podatności;

d. potencjalnych skutków dla Użytkowników;

e. priorytetu usunięcia.

2. Usługodawca może kontaktować się ze zgłaszającym w celu uzyskania dodatkowych informacji.

§130. Usuwanie podatności

1. Po potwierdzeniu podatności Usługodawca podejmie działania zmierzające do ograniczenia ryzyka oraz usunięcia podatności w czasie odpowiednim do jej charakteru i poziomu ryzyka.

2. Kolejność usuwania podatności zależy w szczególności od:

a. poziomu zagrożenia;

b. wpływu na bezpieczeństwo danych;

c. wpływu na dostępność Usług;

d. możliwości technicznych wdrożenia poprawek.

§131. Poufność zgłoszeń

1. Informacje dotyczące wykrytych podatności mają charakter poufny do czasu ich usunięcia lub ograniczenia ryzyka z nimi związanego.

2. Usługodawca może odmówić ujawnienia szczegółów technicznych podatności, jeżeli mogłoby to zwiększyć ryzyko wykorzystania ich przez osoby nieuprawnione.

§132. Program nagród

1. Usługodawca może w przyszłości wprowadzić program nagród (Bug Bounty Program) dla osób zgłaszających podatności bezpieczeństwa.

2. Zasady programu, jeżeli zostanie uruchomiony, zostaną określone w odrębnym dokumencie.

ROZDZIAŁ XV

PRZEGLĄD, AKTUALIZACJA ORAZ NADZÓR NAD POLITYKĄ

§133. Przegląd Polityki

1. Niniejsza Polityka podlega okresowym przeglądom w celu zapewnienia jej aktualności, skuteczności oraz zgodności z obowiązującymi przepisami prawa.

2. Przegląd może zostać przeprowadzony również w przypadku:

a. istotnych zmian organizacyjnych;

b. wdrożenia nowych funkcjonalności;

c. zmian architektury systemu;

d. wystąpienia poważnego incydentu bezpieczeństwa;

e. zmian przepisów prawa;

f. zmian dotyczących usług wykorzystywanych przez Zentrę.

§134. Aktualizacja Polityki

1. Usługodawca może aktualizować niniejszą Politykę w zakresie niezbędnym do:

a. poprawy bezpieczeństwa;

b. dostosowania do zmian technologicznych;

c. dostosowania do zmian organizacyjnych;

d. dostosowania do zmian przepisów prawa;

e. usunięcia nieścisłości lub oczywistych omyłek.

2. Aktualizacje Polityki nie mogą naruszać praw Użytkowników wynikających z bezwzględnie obowiązujących przepisów prawa.

§135. Interpretacja

1. Niniejszą Politykę należy interpretować z uwzględnieniem:

a. obowiązujących przepisów prawa;

b. Regulaminu;

c. Polityki Prywatności;

d. innych dokumentów regulujących zasady korzystania z Usług.

2. W przypadku rozbieżności pomiędzy dokumentami pierwszeństwo mają bezwzględnie obowiązujące przepisy prawa.

§136. Wejście w życie zmian

1. Zmieniona wersja Polityki obowiązuje od dnia wskazanego przez Usługodawcę.

2. Jeżeli wymagają tego obowiązujące przepisy prawa lub charakter zmian, Użytkownicy zostaną poinformowani o zmianach z odpowiednim wyprzedzeniem.

3. Aktualna wersja Polityki jest publikowana w sposób umożliwiający zapoznanie się z jej treścią.

ROZDZIAŁ XVI

POSTANOWIENIA KOŃCOWE

§137. Charakter Polityki

1. Niniejsza Polityka stanowi dokument określający zasady bezpieczeństwa informacji i cyberbezpieczeństwa obowiązujące w Zentrze.

2. Polityka ma charakter organizacyjny oraz informacyjny i uzupełnia postanowienia Regulaminu, Polityki Prywatności oraz pozostałych dokumentów obowiązujących w Zentrze.

§138. Ograniczenie odpowiedzialności

1. Żadne środki bezpieczeństwa nie zapewniają całkowitej ochrony przed wszystkimi zagrożeniami.

2. Usługodawca stosuje środki organizacyjne i techniczne odpowiednie do charakteru świadczonych Usług oraz poziomu ryzyka, jednak nie gwarantuje całkowitego wyeliminowania możliwości wystąpienia incydentów bezpieczeństwa.

3. Postanowienia niniejszej Polityki nie wyłączają ani nie ograniczają odpowiedzialności Usługodawcy w zakresie, w jakim odpowiedzialność ta wynika z bezwzględnie obowiązujących przepisów prawa.

§139. Kontakt

1. Pytania dotyczące bezpieczeństwa informacji, cyberbezpieczeństwa lub niniejszej Polityki mogą być kierowane do Usługodawcy za pośrednictwem danych kontaktowych opublikowanych na stronie internetowej Zentry lub w Regulaminie.

2. Usługodawca może wyznaczyć dedykowany adres e-mail do kontaktu w sprawach bezpieczeństwa.

§140. Wejście w życie

1. Niniejsza Polityka wchodzi w życie z dniem wskazanym przez Usługodawcę.

2. Polityka obowiązuje do czasu jej zmiany lub uchylenia przez Usługodawcę zgodnie z obowiązującymi przepisami prawa.