RODO Art. 28 — Umowa Powierzenia Przetwarzania Danych Osobowych (DPA)
Strony:
/legal/imprint.Ostatnia aktualizacja: 2026-10-14
Jest to jedna, wspólna Umowa Powierzenia dla wszystkich marek platformy (Exceptao, paraKSCol, CyberZgodność EDU); jej publikowane egzemplarze różnią się wyłącznie nazwą marki, adresami kontaktowymi Operatora i opisem serwera. Niniejsza umowa stanowi integralną część Regulaminu Usługi („Regulamin") dostępnego pod adresem /legal/terms-of-service i zostaje zawarta automatycznie z chwilą akceptacji Regulaminu przez Dzierżawcę. Oddzielny podpis nie jest wymagany, chyba że strony postanowią inaczej w formie pisemnej.
W przypadku gdy Dzierżawca sam działa jako podmiot przetwarzający na rzecz własnych klientów (np. JST zarządzająca danymi szkół), Operator działa jako podwykonawca w tym łańcuchu. Obowiązki określone w niniejszej umowie mają zastosowanie w obu konfiguracjach.
1.1 Przedmiot. Podmiot przetwarzający przetwarza dane osobowe w imieniu Administratora w celu świadczenia platformy zgodności CyberZgodność EDU i jej aktywnych Modułów (Wyjątki, Rejestr Ryzyka, Incydenty, NIS2 Szkoły i przyszłe Moduły) zgodnie z Regulaminem.
1.2 Czas trwania. Niniejsza umowa obowiązuje przez czas trwania umowy subskrypcji między stronami. Po wygaśnięciu lub rozwiązaniu subskrypcji zastosowanie mają obowiązki Podmiotu przetwarzającego dotyczące zwrotu i usunięcia danych, określone w §9.
1.3 Hierarchia. W przypadku sprzeczności między niniejszą umową a Regulaminem w zakresie ochrony danych osobowych, niniejsza umowa ma pierwszeństwo.
Podmiot przetwarzający przetwarza dane osobowe wyłącznie w celu:
(a) Eksploatacji, utrzymania i wspierania Usługi w imieniu Administratora, w tym hostingu, zarządzania bazą danych, uwierzytelniania i zarządzania sesją;
(b) Uwierzytelniania i autoryzacji Użytkowników w ramach konta dzierżawcy Administratora;
(c) Prowadzenia wykrywającego manipulacje, append-only dziennika audytowego per dzierżawca, rejestrującego działania Użytkowników podejmowane w przestrzeni roboczej Administratora;
(d) Wysyłania powiadomień e-mail w imieniu zdarzeń przepływu pracy Administratora (zatwierdzenia wyjątków, przypomnienia o terminach incydentów, zaległe zadania, powiadomienia bezpieczeństwa), z wykorzystaniem infrastruktury poczty wychodzącej Operatora;
(e) Generowania raportów, paczek audytowych i eksportów danych na polecenie Administratora lub na żądanie Użytkownika w ramach konta dzierżawcy Administratora;
(f) Przechowywania plików dowodowych i załączników przesłanych przez Użytkowników Administratora, w Cloudflare R2. Obiekty są szyfrowane w spoczynku przez dostawcę; szyfrowanie po stronie klienta wrażliwych plików jest zaplanowane i jeszcze nie wdrożone (zob. Załącznik II §C);
(g) Tworzenia automatycznych kopii zapasowych i operacji odtwarzania po awarii w imieniu Administratora;
(h) Monitorowania Usługi pod kątem zagrożeń bezpieczeństwa, nadużyć i problemów z wydajnością mogących wpłynąć na dane Administratora.
Podmiot przetwarzający nie przetwarza danych osobowych na własne niezależne cele komercyjne (takie jak profilowanie, reklama lub sprzedaż stronom trzecim). Przetwarzanie odbywa się wyłącznie zgodnie z udokumentowanymi instrukcjami Administratora (za pośrednictwem interfejsu Usługi lub pisemnej instrukcji), chyba że jest wymagane przez obowiązujące prawo UE lub państwa członkowskiego.
Dane osobowe przetwarzane w ramach niniejszej umowy mogą obejmować następujące kategorie, w zależności od sposobu korzystania z Usługi przez Administratora:
| Kategoria | Przykłady |
|---|---|
| Identyfikatory | Imię i nazwisko, adres e-mail, identyfikator użytkownika, nazwa wyświetlana |
| Dane uwierzytelniające | Skróty haseł (Argon2id), sekrety TOTP (zaszyfrowane AES), kody odzyskiwania MFA (przechowywane wyłącznie w postaci jednokierunkowej: skrót SHA-256 i kluczowany HMAC, nigdy jako czytelne kody), identyfikatory i klucze publiczne poświadczeń WebAuthn |
| Dane sieciowe | Adresy IP, ciągi user-agent (zdarzenia logowania, rekordy ograniczania prób logowania i wpisy dziennika audytu) |
| Dane zdarzeń audytowych | Kody działań, typ i identyfikator obiektu docelowego, podsumowania stanu przed i po, znaczniki czasu, skróty kryptograficzne |
| Treści biznesowe przesłane przez Administratora | Opisy i uzasadnienia wyjątków, pliki dowodowe, wpisy rejestru ryzyka, raporty incydentów, rekordy zadań kontrolnych — które mogą zawierać dane osobowe osób trzecich według uznania Administratora |
| Dane sesji | Tokeny sesji (po stronie serwera), znaczniki czasu sesji |
| Dane komunikacyjne | Adresy e-mail i imiona używane do dostarczania powiadomień |
| Wyznaczenia ról | W module NIS2 Szkoły: Użytkownik wyznaczony jako inspektor bezpieczeństwa placówki (ITSO/IBTI) |
Usługa nie służy do pozyskiwania szczególnych kategorii danych osobowych (art. 9 RODO) ani danych dotyczących wyroków skazujących i czynów zabronionych (art. 10 RODO). O tym, czy takie dane zostaną wprowadzone do pól tekstowych lub plików dowodowych, decyduje Administrator.
Kategorie podmiotów danych, których dane osobowe mogą być przetwarzane w ramach niniejszej umowy, obejmują:
Podmiot przetwarzający zobowiązuje się:
5.1 Przetwarzać wyłącznie zgodnie z instrukcjami. Przetwarzać dane osobowe wyłącznie zgodnie z udokumentowanymi instrukcjami Administratora, chyba że jest do tego zobowiązany przez prawo UE lub prawo państwa członkowskiego. W takim przypadku Podmiot przetwarzający poinformuje Administratora przed przetwarzaniem, chyba że prawo tego zakazuje ze względu na ważny interes publiczny.
5.2 Poufność personelu. Zapewnić, że wszystkie osoby upoważnione do przetwarzania danych osobowych Administratora zobowiązały się do zachowania poufności lub podlegają ustawowemu obowiązkowi zachowania tajemnicy.
5.3 Wdrożyć techniczne i organizacyjne środki bezpieczeństwa. Wdrożyć i utrzymywać techniczne i organizacyjne środki bezpieczeństwa opisane w Załączniku II niniejszej umowy i w Białej Księdze Bezpieczeństwa dostępnej pod adresem /legal/security. Podmiot przetwarzający nie będzie istotnie redukować tych środków w trakcie obowiązywania niniejszej umowy bez uprzedniego pisemnego powiadomienia Administratora z co najmniej 30-dniowym wyprzedzeniem.
5.4 Angażować podwykonawców wyłącznie zgodnie z §6. Przestrzegać warunków angażowania podwykonawców określonych w §6 niniejszej umowy.
5.5 Wspierać realizację praw podmiotów danych. Pomagać Administratorowi w wypełnianiu obowiązku odpowiadania na wnioski podmiotów danych korzystających z praw przysługujących im na mocy Rozdziału III RODO (art. 15–22), w zakresie technicznie możliwym biorąc pod uwagę rolę Administratora i architekturę Usługi. Podmiot przetwarzający będzie przekazywał Administratorowi bez zbędnej zwłoki wszelkie wnioski podmiotów danych otrzymane bezpośrednio.
5.6 Wspierać przestrzeganie obowiązków. Pomagać Administratorowi w zapewnieniu zgodności z art. 32–36 RODO (środki bezpieczeństwa, powiadamianie o naruszeniach, ocena skutków dla ochrony danych, uprzednie konsultacje z organem nadzorczym), uwzględniając charakter przetwarzania i informacje dostępne Podmiotowi przetwarzającemu.
5.7 Zwrot lub usunięcie danych. Według wyboru Administratora: (a) usunąć wszystkie dane osobowe przetwarzane w imieniu Administratora lub (b) zwrócić wszystkie dane osobowe w ustrukturyzowanym, nadającym się do odczytu maszynowego formacie, po zakończeniu umowy o świadczenie usług. Podmiot przetwarzający usunie istniejące kopie, chyba że prawo UE lub prawo państwa członkowskiego wymaga dalszego przechowywania (zob. §9).
5.8 Udostępnianie informacji i audyt. Udostępnić Administratorowi wszelkie informacje racjonalnie niezbędne do wykazania zgodności z art. 28 RODO oraz umożliwić i wspierać audyty i inspekcje, zgodnie z §10.
5.9 Powiadamianie o niezgodnych z prawem instrukcjach. Niezwłocznie poinformować Administratora, jeżeli w opinii Podmiotu przetwarzającego instrukcja wydana przez Administratora narusza RODO lub inne stosowne przepisy UE lub państwa członkowskiego dotyczące ochrony danych.
6.1 Ogólna zgoda. Administrator udziela Podmiotowi przetwarzającemu ogólnej zgody na angażowanie podwykonawców wymienionych w Załączniku I niniejszej umowy i pod adresem /legal/subprocessors. Aktualna lista jest prowadzona pod adresem /legal/subprocessors i zawiera cel, kategorie danych, region, poziom bezpieczeństwa i status DPA każdego podwykonawcy.
6.2 Powiadamianie o zmianach. Podmiot przetwarzający powiadomi Administratora co najmniej 30 dni kalendarzowych przed planowanym dodaniem lub zastąpieniem podwykonawcy, aktualizując listę pod adresem /legal/subprocessors i wysyłając powiadomienie e-mail na adres zarejestrowanego Administratora Dzierżawcy. Powiadomienie będzie zawierać: nazwę i cel nowego lub zastępczego podwykonawcy, kategorie danych i region.
6.3 Prawo do sprzeciwu. Administrator może wnieść sprzeciw wobec planowanej zmiany w 30-dniowym okresie powiadomienia, wysyłając e-mail na adres legal@parakscol.pl ze wskazaniem konkretnych podstaw sprzeciwu. Jeżeli Administrator wniesie sprzeciw, a Podmiot przetwarzający nie może go uwzględnić, Administrator może rozwiązać subskrypcję bez kary, ze skutkiem od daty wejścia zmiany w życie, z proporcjonalnym zwrotem opłat z góry.
6.4 Obowiązki podwykonawców. Podmiot przetwarzający nakłada na wszystkich podwykonawców obowiązki ochrony danych równoważne tym określonym w niniejszej umowie, w drodze umowy. W przypadku gdy podwykonawca nie wypełni swoich obowiązków ochrony danych, Podmiot przetwarzający pozostaje w pełni odpowiedzialny wobec Administratora za realizację tych obowiązków.
6.5 Brak dalszego podpowierzania. Podwykonawcy nie mogą angażować dalszych podwykonawców do przetwarzania danych osobowych Administratora bez uprzedniej pisemnej zgody Podmiotu przetwarzającego i powiadomienia Administratora zgodnie z §6.2.
7.1 Lokalizacja danych. Dane osobowe są przechowywane w regionie zapisanym dla Dzierżawcy przy jego utworzeniu; regionu nie można później zmienić. Jedynym działającym regionem jest region EU i należą do niego wszyscy Dzierżawcy: dane są przechowywane w UE, produkcja działa w Polsce, a kwartalny test odtworzenia odbywa się w Austrii (UE) (Załącznik I). Dane Dzierżawców marek paraKSCol i CyberZgodność EDU są przetwarzane na jednym serwerze wspólnym dla tych dwóch marek, w centrum danych OVHcloud w Warszawie (WAW2), Polska; marka Exceptao działa na odrębnym serwerze w tej samej lokalizacji.
7.2 Brak transferu danych biznesowych między regionami. Dane biznesowe klientów nie przekraczają granic regionów. Metadane płaszczyzny kontrolnej (routing dzierżawcy, rekordy subskrypcji) są przechowywane w regionie EU i nie zawierają danych biznesowych klientów.
7.3 Transfery do podwykonawców. W przypadku gdy podwykonawcy są zlokalizowani poza UE/EOG lub gdy ich podmioty nadrzędne mają siedzibę w krajach bez decyzji UE o odpowiednim poziomie ochrony, Podmiot przetwarzający zapewnia odpowiednie zabezpieczenia na podstawie Rozdziału V RODO, w szczególności:
Szczegóły dotyczące zabezpieczeń transferu dla każdego podwykonawcy są udokumentowane pod adresem /legal/subprocessors.
8.1 Termin powiadomienia. Podmiot przetwarzający powiadomi Administratora bez zbędnej zwłoki, nie później niż w ciągu 72 godzin od stwierdzenia naruszenia ochrony danych osobowych dotyczącego danych Administratora. Termin ten jest spójny z art. 33 RODO (powiadamianie organu nadzorczego) i art. 23 NIS2 (zgłaszanie incydentów) — 72-godzinne powiadomienie Podmiotu przetwarzającego do Administratora umożliwia Administratorowi dotrzymanie własnych terminów regulacyjnych.
8.2 Treść powiadomienia. Powiadomienie o naruszeniu będzie zawierać, w zakresie znanych na dany moment informacji (uzupełnianych w miarę ich dostępności):
8.3 Współpraca. Podmiot przetwarzający będzie współpracować przy zarządzaniu naruszeniami przez Administratora, udzielać uzasadnionej pomocy przy powiadamianiu organów nadzorczych i podmiotów danych przez Administratora oraz wdrażać środki naprawcze bez zbędnej zwłoki.
8.4 Wstępne częściowe powiadomienie. Jeżeli w ciągu 72 godzin nie można przekazać wszystkich informacji wymienionych w §8.2, Podmiot przetwarzający przekaże wstępne częściowe powiadomienie w ciągu 72 godzin i uzupełni je o dostępne informacje bez zbędnej zwłoki.
9.1 Okno eksportu. W trakcie obowiązywania subskrypcji oraz przez 30 dni po jej wygaśnięciu lub rozwiązaniu („Okres Retencji Danych"), Administrator może eksportować dane za pomocą funkcji eksportu Usługi (eksport CSV dziennika audytu, eksport raportów, eksport rejestru czynności przetwarzania oraz, w module NIS2 Szkoły, paczka audytowa). Nie istnieje jedna funkcja eksportująca wszystkie Dane Usługi. Podmiot przetwarzający dostarczy również pełny eksport danych w ustrukturyzowanym, nadającym się do odczytu maszynowego formacie (JSON i/lub CSV) w ciągu 30 dni od pisemnego wniosku Administratora.
9.2 Usunięcie. Po Okresie Retencji Danych wszystkie dane osobowe przetwarzane w imieniu Administratora zostaną bezpiecznie i nieodwracalnie usunięte z aktywnych systemów Podmiotu przetwarzającego, w tym baz danych, magazynów plików, pamięci podręcznych i kolejek e-mail. Usunięcie z nośników kopii zapasowych nastąpi w normalnym cyklu wygaśnięcia kopii zapasowych, z zastrzeżeniem okresów retencji określonych w §9.3. Zob. Załącznik II §C w zakresie mechanizmów realizacji usunięcia i ich ograniczeń, w tym okna kopii rezydualnych oraz kryptograficznego usuwania („crypto-shredding") poświadczeń Dzierżawcy.
9.3 Zastrzeżenia dotyczące retencji prawnej. Następujące dane mogą być przechowywane po Okresie Retencji Danych w zakresie wymaganym przez obowiązujące prawo:
9.4 Potwierdzenie usunięcia. Na pisemny wniosek Podmiot przetwarzający dostarczy Administratorowi potwierdzenie usunięcia w ciągu 30 dni od potwierdzenia usunięcia wszystkich aktywnych danych.
9.5 Brak retencji na własne cele. Podmiot przetwarzający nie będzie przechowywał żadnych danych osobowych przetwarzanych w ramach niniejszej umowy na własne cele komercyjne po rozwiązaniu umowy.
10.1 Udostępnianie informacji. Podmiot przetwarzający udostępni Administratorowi wszelkie informacje racjonalnie niezbędne do wykazania zgodności z obowiązkami określonymi w art. 28 RODO, w tym przez wypełnianie standardowych kwestionariuszy bezpieczeństwa i dostarczanie stosownych certyfikatów.
10.2 Audyty na miejscu. Administrator (lub jego upoważniony audytor zewnętrzny) może przeprowadzić audyt działań i obiektów przetwarzania danych Podmiotu przetwarzającego, pod następującymi warunkami:
10.3 Zapewnienie oparte na certyfikatach. Podmiot przetwarzający może częściowo lub w całości wypełnić obowiązek audytowy przez dostarczenie stosownych certyfikatów (np. certyfikatu ISO 27001, raportu SOC 2 Type II — gdy zostanie uzyskany), odpowiedzi na kwestionariusze bezpieczeństwa lub raportów audytowych zewnętrznych, gdy obejmują one zakres żądanego audytu.
11.1 Usunięcie danych pseudonimizuje rekord użytkownika podmiotu danych: adres e-mail zostaje zastąpiony stabilnym, nieodwracalnym znacznikiem (deleted-<uuid>@tombstone.invalid), imię i nazwisko zostaje usunięte, nazwy nadane przez użytkownika jego kluczom dostępu (passkey) zastąpione neutralną wartością (nazwa zapisana także w wierszach audytu z dodania lub unieważnienia klucza pozostaje w tych wierszach, które są tylko do dopisywania), a konto dezaktywowane. Jednocześnie usuwane są rekordy ograniczania prób logowania zapisane pod adresem e-mail konta (identyfikator, adres IP i user-agent jego logowań i nieudanych prób logowania); rekordy konta usuniętego wcześniej są usuwane, gdy mają 30 dni. Obecnie Usługa wykonuje to wyłącznie na żądanie samego użytkownika, w ustawieniach jego konta, po potwierdzeniu hasłem. W aplikacji nie ma funkcji, za pomocą której Administrator lub Podmiot przetwarzający mógłby zastosować to wobec innego użytkownika. Administrator Dzierżawcy może natychmiast zawiesić lub usunąć członkostwo użytkownika w Dzierżawcy. Jeżeli Administrator poleci usunięcie, którego użytkownik nie może wykonać sam, Podmiot przetwarzający rozpatruje polecenie indywidualnie; narzędzia do tego jeszcze nie ma.
11.2 Żaden wiersz dziennika audytowego nie jest zmieniany. Wiersze audytu odwołują się do podmiotu danych wyłącznie przez wewnętrzny identyfikator, nigdy przez adres e-mail, dlatego każdy widok audytu od momentu pseudonimizacji rekordu użytkownika pokazuje znacznik. Dziennik audytowy działa w trybie tylko-do-dopisu na poziomie bazy danych — wyzwalacz odrzuca każdą operację UPDATE — więc kryptograficzny łańcuch skrótów jest zachowany z samej konstrukcji, a nie przeliczany, i pozostaje nienaruszony i weryfikowalny.
11.3 Sam rekord zdarzenia audytowego (działanie, znacznik czasu, obiekt docelowy, skrót) jest przechowywany, ponieważ usunięcie lub zmiana rekordu zniszczyłyby integralność łańcucha wszystkich kolejnych wierszy, co podważyłoby podstawowy cel bezpieczeństwa i zgodności dziennika audytowego.
11.4 Adres IP i user agent aktora nie są pseudonimizowane. Wiersze audytu rejestrują również adres IP i user agent sesji wykonującej działanie. Ponieważ dziennika audytowego nie można zmienić po zapisie (§11.2), pola te nie są zmieniane przy usuwaniu danych i są przechowywane przez cały okres istnienia konta Dzierżawcy. Podstawą prawną jest uzasadniony interes w zakresie integralności audytu (art. 6 ust. 1 lit. f RODO). Podmiot przetwarzający ujawnia ten fakt, zamiast gwarantować możliwość, na którą architektura nie pozwala. Wiersze dziennika audytu zapisane przed wdrożeniem produkcyjnym z 2026-10-12 mogą ponadto zawierać w samym wierszu adresy e-mail: przy czynnościach wymienionych według kodów czynności w dokumencie Bezpieczeństwo pod adresem /legal/security (logowanie, blokada konta i reset hasła; zakładanie kont przez SSO; nadawanie uprawnień administratora platformy; zakładanie, zawieszanie i przywracanie Dzierżawców; dostęp wsparcia Operatora i wyszukiwanie w dzienniku przez Operatora; deklaracje nieciągłości łańcucha i raporty z ćwiczeń odtwarzania; delegowanie zadań przez JST; powiadomienia i przypomnienia; ocena dostawców; profil organizacji; podłączenie poczty Microsoft 365; kontrola ścieżki e-mail) — użytkownika wykonującego lub objętego czynnością, odbiorcy powiadomienia lub osoby kontaktowej Dzierżawcy albo identyfikator wpisany w formularzu logowania lub resetu hasła — a przy dowolnej czynności w tekście swobodnym, np. w komunikacie błędu lub w tekście wpisanym przez użytkownika. Pozostają one przez cały okres istnienia konta Dzierżawcy (w łańcuchu warstwy sterującej platformy — przez cały okres istnienia platformy), na tej samej podstawie prawnej co adres IP aktora: uzasadniony interes w zakresie integralności audytu (art. 6 ust. 1 lit. f RODO). Od wdrożenia produkcyjnego z 2026-10-12 w treści ani w polu obiektu docelowego wiersza audytu nie jest zapisywany żaden tekst w postaci adresu e-mail: użytkownicy są identyfikowani wewnętrznym identyfikatorem, a każdy inny adres — także w tekście swobodnym — skrótem kluczowanym (HMAC), z którego adresu nie da się odczytać. Do poprawki z 2026-10-13 obowiązywał jeden wyjątek: gdy adresy lub domeny były połączone znakiem @ bez niczego pomiędzy (x@a.com@b.org), w wierszu zostawał skrót, po nim @ i nazwa domeny — nigdy cały adres. Wiersze zapisane od wdrożenia produkcyjnego z 2026-10-12 do wdrożenia tej poprawki mogą zawierać taki fragment; są przechowywane na tej samej podstawie i ujawniane, a nie usuwane. Drugą lukę usunęła poprawka z 2026-10-14: adres zawierający łączące znaki diakrytyczne — literę z akcentem zapisaną jako litera podstawowa i osobny znak (Unicode NFD, powstający w niektórych systemach i przy kopiowaniu z niektórych dokumentów) albo pismo, w którym samogłoski zapisuje się takimi znakami, np. dewanagari lub tajskie, albo niewidoczny łącznik (ZWNJ/ZWJ) używany w nazwach perskich i indyjskich — nie był rozpoznawany i był zapisywany tak, jak go wpisano, w całości lub w części. Wiersze zapisane przed wdrożeniem tej poprawki mogą zawierać taki adres jawnym tekstem; są przechowywane na tej samej podstawie i ujawniane, a nie usuwane. Taki skrót jest pseudonimem i pozostaje daną osobową: każdy, kto może spowodować zapisanie przez platformę wybranego adresu, albo kto posiada klucz, może potwierdzić odgadnięty adres. Inne dane osobowe wpisane w pola tekstowe, np. imię i nazwisko lub numer telefonu, są zapisywane tak, jak je wpisano. Nie obejmuje to ciągu user-agent sesji wykonującej czynność: jest on zapisywany tak, jak go przesłał klient, a niektórzy klienci, zwłaszcza roboty indeksujące, umieszczają w nim adres kontaktowy.
11.5 Kopie rezydualne. Kopia zapasowa lub artefakt odtworzenia do punktu w czasie utworzony przed zastosowaniem pseudonimizacji nadal zawiera tożsamość sprzed tombstone'a i pozostaje odtwarzalny tak długo, jak ten artefakt jest przechowywany (Załącznik II §C, §F). Pseudonimizacja stosowana jest do danych aktywnych w chwili żądania; nie obejmuje artefaktów już zapisanych. Podmiot przetwarzający odtwarza takie artefakty wyłącznie w celu odtworzenia po awarii oraz na potrzeby zaplanowanych testów przywracania opisanych w Załączniku II §F. Automatyczne ponowne zastosowanie zaległych żądań usunięcia po odtworzeniu nie jest obecnie wdrożone; po każdym odtworzeniu Podmiot przetwarzający ponownie stosuje zaległe instrukcje usunięcia jako udokumentowany krok manualny.
11.6 Podstawą prawną przechowywania pseudonimizowanego rekordu zdarzenia audytowego jest uzasadniony interes w zakresie integralności audytu (art. 6 ust. 1 lit. f RODO). Administrator, zawierając niniejszą umowę, przyjmuje do wiadomości i akceptuje takie traktowanie jako technicznie i prawnie właściwą odpowiedź na żądanie usunięcia dotyczące wierszy dziennika audytowego. Podmiot przetwarzający dokumentuje ocenę podstawy prawnej per żądanie usunięcia i udostępnia ją Administratorowi na wniosek.
12.1 W przypadku gdy Administrator stwierdzi, że na mocy art. 35 RODO wymagane jest przeprowadzenie Oceny Skutków dla Ochrony Danych (DPIA) w odniesieniu do jakiejkolwiek czynności przetwarzania obejmującej Usługę, Podmiot przetwarzający udzieli uzasadnionej pomocy przy sporządzaniu DPIA, w tym przez udostępnienie niniejszej umowy, Białej Księgi Bezpieczeństwa, Rejestru Czynności Przetwarzania pod adresem /legal/ropa i odpowiadanie na uzasadnione zapytania informacyjne.
12.2 Podmiot przetwarzający powiadomi Administratora, jeżeli uzasadnianie będzie uważał, że przetwarzanie prowadzone na mocy niniejszej umowy jest rodzajem przetwarzania, które może powodować wysokie ryzyko dla praw podmiotów danych, tak aby Administrator mógł ocenić, czy DPIA jest wymagana.
Niniejsza umowa podlega prawu polskiemu. Wszelkie spory wynikające z niniejszej umowy lub z nią związane podlegają jurysdykcji sądów polskich, zgodnie z §17 Regulaminu.
Aktualna lista podwykonawców jest prowadzona pod adresem /legal/subprocessors. W chwili publikacji niniejszej umowy aktywni podwykonawcy to:
| Podwykonawca | Siedziba | Cel | Kategorie danych | Podstawa transferu |
|---|---|---|---|---|
| Cloudflare, Inc. | San Francisco, CA, USA (przetwarzanie w EU) | CDN, WAF, Tunnel, magazyn obiektów R2 | Adresy IP, metadane żądań (CDN/WAF); zaszyfrowane pliki dowodowe i kopie zapasowe (R2) | SCK (Moduł 2); jurysdykcja R2: EU |
| Backblaze, Inc. | San Mateo, CA, USA (przetwarzanie w EU) | Zapasowy zaszyfrowany magazyn kopii zapasowych | Wyłącznie archiwa zaszyfrowane kopertowo (RSA-4096 + AES-256-GCM) | SCK (Moduł 2); region przechowywania EU |
| Microsoft Corporation | Redmond, WA, USA (przetwarzanie w EU) | Wychodząca transakcyjna poczta e-mail przez Graph API | Adres e-mail odbiorcy, imię, treść powiadomienia | SCK (Moduł 2); dzierżawa M365 EU |
| Microsoft Corporation (Azure Key Vault) | Redmond, WA, USA (sejf w regionie UE) | Powiernictwo kluczy: odpakowanie archiwów logicznych, automatyczne otwarcie Vault, pgbackrest-cipher-pass | Brak danych osobowych — wyłącznie materiał klucza | SCK (Moduł 2); sejf w regionie EU |
| OVH Sp. z o.o. | Wrocław, Polska (centrum danych Warszawa, WAW2) | Hosting obu serwerów produkcyjnych (aplikacja, baza danych, Vault, procesy kopii zapasowych) | Wszystkie kategorie, jako host infrastruktury | Brak — UE/EOG; to, czy z dostawcą zawarto umowę z art. 28 ust. 3 RODO, jest potwierdzane |
| netcup GmbH | Karlsruhe, Niemcy (serwer w Wiedniu, Austria) | Samodzielnie zarządzany runner CI, na którym kwartalny test odtworzenia odtwarza, weryfikuje i usuwa kopię produkcyjnej bazy danych | Wszystkie kategorie z produkcyjnej bazy danych, przejściowo, na czas testu | Brak — UE/EOG; to, czy z dostawcą zawarto umowę z art. 28 ust. 3 RODO, jest potwierdzane |
| GitHub, Inc. | San Francisco, CA, USA | Hosting kodu i obrazów kontenerów; orkiestracja testu odtworzenia i federacja OpenID Connect do Azure Key Vault | Żadne dane biznesowe Dzierżawców — logi przebiegów (UUID łańcuchów Dzierżawców; log PostgreSQL przy niepowodzeniu) | Ujęte zachowawczo; status wg art. 28 w przeglądzie prawnym |
HashiCorp Vault jest hostowany samodzielnie na własnym VPS Podmiotu przetwarzającego w EU i nie jest podwykonawcą w rozumieniu art. 28 RODO.
Poniższe techniczne i organizacyjne środki bezpieczeństwa („TOMs") są wdrożone i utrzymywane przez Podmiot przetwarzający, z wyjątkiem środków wyraźnie oznaczonych poniżej jako zaplanowane lub jeszcze nie wdrożone. Pełny opis techniczny zawiera Biała Księga Bezpieczeństwa dostępna pod adresem /legal/security.
app (CRUD, brak DDL), audit_writer (INSERT i SELECT na audit_log — wyzwalacz łańcucha odczytuje bieżącą głowę; brak UPDATE i DELETE), superadmin (BYPASSRLS, używany wyłącznie do wielodzierżawczego panelu Operatora — wszystkie działania rejestrowane w audycie), platform_writer (ograniczone zapisy dla działań konsoli operatora), iam_definer (BYPASSRLS, NOLOGIN; nigdy nie jest przyjmowana przez sesję — jest wyłącznie właścicielem pięciu funkcji wyszukiwania między Dzierżawcami, które po wywołaniu działają z jej uprawnieniami). DDL wykonywane jest przez rolę bootstrap superuser, a nie przez dedykowaną rolę migracyjną; osobna rola DDL jest śledzona jako zadanie hardeningowe.ui = false); żaden interfejs monitoringu nie jest wdrożony.current_setting('app.current_tenant_id') względem kolumny tenant_id wiersza. Nawet właściciel tabeli nie może ominąć FORCE RLS.(app.current_tenant_id, app.current_org_unit_id) jest ustawiana w bloku SET LOCAL na początku transakcji każdego żądania i wygasa z końcem transakcji. Przed Postgresem nie ma żadnego poolera połączeń, a CONN_MAX_AGE = 0, więc każde żądanie korzysta z własnego połączenia i żadna wartość GUC nie może przetrwać poza swoją transakcją.org_unit_id) ogranicza dostęp dla ról powiązanych z placówkami we wdrożeniach wieloinstytucjonalnych (np. dzierżawcy JST z zagnieżdżonymi jednostkami szkolnymi).unwrapKey, więc przejęcie serwera daje dostęp do archiwów, których nie da się odczytać.transit/keys/platform-iam) i odpakowywanego przez aplikację przy pierwszym użyciu. Zob. /legal/security §13.1. Aplikacja nie odczytuje już z Vault KV żadnego klucza szyfrowania pól; wycofany klucz Fernet dla TOTP nie jest używany; usunięto go z Vault 2026-10-11 i pozostaje jedynie w zaszyfrowanych migawkach Vault do czasu ich wygaśnięcia, około 2026-11-10.BACKUP_RETENTION_DAYS, domyślnie 30) oraz około 8 dni dla repozytorium odtworzenia do punktu w czasie (§F przechowuje 8 nocnych kopii pełnych wraz z WAL potrzebnym, by je osiągnąć). Rotacja lub unieważnienie poświadczenia chroni zatem jego przyszłe użycie; nie powoduje wstecznie nieczytelności kopii przechowywanych w oknie retencji. Podmiot posiadający uprawnienia zapisu do bazy danych mógłby przywrócić taki wcześniejszy tekst zaszyfrowany w miejsce jego następcy. Klucz ogólnoplatformowy, który chronił wcześniejsze kopie poświadczeń (IAM_OIDC_KEY, wycofany 2026-10-11), oraz dawny klucz sekretów TOTP (IAM_TOTP_KEY, wycofany 2026-10-11) zostały 2026-10-11 usunięte z Vault Podmiotu przetwarzającego wraz ze wszystkimi starszymi wersjami jego magazynu klucz-wartość, które nadal je przechowywały, a Podmiot przetwarzający usunął swoje kopie depozytowe obu kluczy. Przetrwały wyłącznie w zaszyfrowanych migawkach Vault wykonanych przed tą datą, przechowywanych przez najwyżej 30 dni (do około 2026-11-10). Żaden tekst zaszyfrowany poświadczeń pod kluczem IAM_OIDC_KEY nie istnieje, więc jego kopie niczego nie odszyfrowują; sekrety TOTP w kopiach zapasowych bazy danych wykonanych przed migracją klucza TOTP z 2026-10-11 są zaszyfrowane kluczem IAM_TOTP_KEY i byłyby odczytywalne przy użyciu odtworzonej migawki, dopóki te kopie zapasowe nie wygasną./legal/security §13.1. Uzupełnia ono, a nie zastępuje, usuwanie realizowane zgodnie z §9 niniejszej Umowy, w granicach cyklu wygasania kopii zapasowych. To, czy i w jakiej formie harmonogram ten jest oferowany jako zobowiązanie umowne (np. poziom usług lub zaświadczenie o usunięciu), jest przedmiotem analizy prawnej.Strict-Transport-Security: max-age=31536000; includeSubDomains; bez dyrektywy preload).row_hash_n = sha256(prev_hash_n-1 || canonical(row_n)), gdzie canonical to dwanaście pól składowych, zserializowanych przez Postgres do tekstu i połączonych znakiem \x1f (ASCII unit separator); dwunastym z nich jest wersja listy pól contract_version. Skrót wyliczany jest przez wyzwalacz Postgres SECURITY DEFINER, nie przez aplikację.audit_writer): INSERT i SELECT na audit_log; brak UPDATE, DELETE i TRUNCATE. Test regresyjny CI sprawdza dokładny zestaw uprawnień przy każdym pull requeście — jest to bramka scalania, a nie kontrola w chwili wdrożenia.row_hash per dzierżawca w tabeli audit_chain_anchor, razem z tokenem znacznika czasu RFC 3161 z zewnętrznego urzędu znaczników czasu (domyślnie freetsa.org, który otrzymuje wyłącznie skrót); token każdej nowej kotwicy jest weryfikowany przy najbliższym codziennym uruchomieniu względem przypiętego certyfikatu głównego TSA, a wcześniejsze kotwice są sprawdzane ponownie na żądanie. Pełne przejście łańcucha odbywa się codziennie.verify_chains), które rejestruje przerwanie w dzienniku audytu i wysyła e-mail do administratorów Dzierżawcy oraz do Operatora; jednorazowa weryfikacja każdej nowej kotwicy, a wszystkich kotwic na żądanie; ręczne deklarowanie przez Operatora znanej nieciągłości, np. pozostawionej przez odtworzenie z kopii. Przy uruchomieniu aplikacji łańcuch nie jest sprawdzany.GET /api/audit/verify przechodzi przez pełny łańcuch dla żądającego dzierżawcy i zwraca wynik w formacie nadającym się do odczytu maszynowego: czy łańcuch jest nienaruszony, łączną liczbę wierszy oraz, jeżeli jest przerwany, pozycję i przyczynę przerwania.unwrapKey, a jego poświadczenie celowo nie znajduje się na maszynie. Wykonany raz na markę, oba 2026-09-02.security@parakscol.pl; .well-known/security.txt opublikowany na każdej domenie marki.unattended-upgrades) celowo nie jest stosowana, ponieważ aktualizacja środowiska kontenerów restartuje wszystkie kontenery, a serwer z szyfrowanym dyskiem nie może restartować się bez nadzoru. Codzienna kontrola, alarmująca, gdy którakolwiek aktualizacja bezpieczeństwa czeka dłużej niż 7 dni (termin dla podatności wysokich), jest zbudowana; nie jest jeszcze zainstalowana na żadnym z serwerów produkcyjnych. Termin 24 godzin dla podatności krytycznych nie jest zautomatyzowany: jego dotrzymanie zależy od reakcji Operatora na biuletyny bezpieczeństwa Ubuntu.pip-audit, npm audit i skanowanie obrazów narzędziem Trivy są uruchamiane przy każdym pull requeście, przy każdej zmianie gałęzi głównej i co tydzień.