Umowa o przetwarzanie danych

„Administrator” oznacza osobę fizyczną, która tworzy i posiada dane w swoim sejfie Clavitor. Zawsze jesteś Administratorem swoich poświadczeń i danych osobowych.

„Procesor” oznacza Clavitor.ai, podmiot świadczący usługi hostingowe, orkiestrację szyfrowania i przechowywanie danych w imieniu Administratora.

„Osoba, której dane dotyczą” oznacza osobę fizyczną, której dane osobowe są przetwarzane – może to być Pan/Pani (Administrator) lub inne osoby, których dane przechowuje Pan/Pani w swoim sejfie (członkowie rodziny, pracownicy, klienci).

„Dane osobowe” oznaczają wszelkie informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej przechowywane w Pana/Pani sejfie, w tym między innymi: poświadczenia, hasła, klucze API, dane kart płatniczych, dokumenty tożsamości i informacje kontaktowe.

„Przetwarzanie” oznacza wszelkie operacje wykonywane na danych osobowych, w tym ich zbieranie, przechowywanie, szyfrowanie, przesyłanie, tworzenie kopii zapasowych i usuwanie.

3.1 Przetwarzaj wyłącznie na udokumentowanych poleceniach. Clavitor przetwarza dane osobowe wyłącznie w celu świadczenia usługi sejfu, zgodnie z naszymi Warunkami świadczenia usług. Nie wykorzystujemy danych do własnych celów, nie trenujemy modeli AI, nie wyciągamy wniosków ani nie monetyzujemy ich poza opłatami abonamentowymi.

3.2 Zapewnij poufność. Wszyscy pracownicy Clavitor z potencjalnym dostępem do infrastruktury są związani umowami o poufności. Dostęp jest przyznawany na zasadzie minimalnych uprawnień i jest rejestrowany.

3.3 Wdróż środki bezpieczeństwa. Wdrażamy:

• Szyfrowanie end-to-end: Dane szyfrowane w spoczynku i w tranzycie
• Szyfrowanie warstwowe (L2/L3): Pola tożsamości szyfrowane kluczami pochodzącymi z urządzenia użytkownika (WebAuthn PRF) – nieodczytywalne przez nas
• Architektura zerowej wiedzy: Nie możemy odszyfrować zawartości sejfu; czytelne są tylko metadane (identyfikatory wpisów, typy, znaczniki czasu)
• Uwierzytelnianie oparte na urządzeniu (WebAuthn): Brak haseł przechowywanych po stronie serwera
• Dystrybucja geograficzna: 21 Punktów Obecności (POP) z zaszyfrowaną replikacją
• Reagowanie na incydenty: Monitorowanie 24/7, automatyczne alerty, udokumentowane procedury naruszenia bezpieczeństwa

3.4 Przejrzystość podprocesorów. Korzystamy wyłącznie z podprocesorów wymienionych w naszej Liście podprocesorów. Powiadamiamy subskrybentów 30 dni przed dodaniem nowego podprocesora.

3.5 Pomoc w zakresie praw osób, których dane dotyczą. Na Pana/Pani żądanie pomożemy w odpowiedzi na żądania osób, których dane dotyczą, dotyczące realizacji praw wynikających z RODO/UODO (dostęp, sprostowanie, usunięcie, przenoszenie, ograniczenie, sprzeciw). Uwaga: Ze względu na architekturę szyfrowania nie mamy dostępu ani możliwości modyfikacji zaszyfrowanej zawartości sejfu; pomoc ogranicza się do operacji na poziomie konta.

3.6 Pomoc w zakresie obowiązków bezpieczeństwa. Dostarczamy dokumentację bezpieczeństwa, podsumowania testów penetracyjnych (do szczegółów wymagana NDA) oraz dzienniki audytu na żądanie.

3.7 Usuń lub zwróć dane. Po zakończeniu subskrypcji Pana/Pani sejfy stają się dostępne tylko do odczytu przez 30 dni. Po 30 dniach dane z sejfu są trwale usuwane. Kopie zapasowe zgodności są niszczone 30 dni po usunięciu. W przypadku kont zawieszonych z powodu braku płatności dane są usuwane po 30 dniach od zawieszenia, a kopie zapasowe są rotowane 60 dni później. Natychmiastowe usunięcie jest dostępne na żądanie w dowolnym momencie. Dane nie mogą zostać zwrócone w formie odszyfrowanej (nie posiadamy kluczy). Pełne szczegóły w naszych Warunkach świadczenia usług.

3.8 Audyt i inspekcja. Po 30 dniach pisemnego powiadomienia może Pan/Pani przeprowadzić audyt naszej zgodności z niniejszą Umową. Audyty są przeprowadzane w naszej siedzibie głównej w Zurychu lub wirtualnie. Dostarczamy odpowiednią dokumentację; bezpośredni dostęp do infrastruktury wymaga poświadczeń bezpieczeństwa.

3.9 Powiadomienie o naruszeniach. Powiadamiamy Pana/Panią w ciągu 24 godzin od wykrycia jakiegokolwiek naruszenia dotyczącego Pana/Pani danych osobowych. Nigdy nie będziemy opóźniać powiadomienia w celu przeprowadzenia dochodzenia lub analizy prawnej.

3.10 Dokumentuj czynności przetwarzania. Prowadzimy rejestry czynności przetwarzania i udostępniamy ich podsumowania na żądanie.

Gwarantuje Pan/Pani, że:

• Posiada Pan/Pani prawną podstawę do przetwarzania danych osobowych w swoim sejfie
• Poinformował/a Pan/Pani osoby, których dane dotyczą, których dane przechowuje, o odpowiednich zasadach ochrony prywatności
• Nie będzie Pan/Pani przechowywać danych z naruszeniem obowiązujących przepisów prawa
• Niezwłocznie powiadomi nas Pan/Pani o wszelkich żądaniach osób, których dane dotyczą, lub zapytaniach regulacyjnych

Dane z Pana/Pani sejfu są przechowywane w szyfrowanej formie w Punkcie Obecności (POP) geograficznie najbliższym Pana/Pani wzorcom dostępu. Podstawowe i zapasowe POP znajdują się w różnych regionach dla zapewnienia odporności. Kompletna lista 21 POP wraz z miastami, dostawcami i certyfikatami zgodności jest utrzymywana w naszej bazie danych POP.

Dostawcy infrastruktury wykorzystywani do POP obejmują: Amazon Web Services (17 POP, główny dostawca dla większości regionów), ISHosting (Stambuł, Ałmaty, Bogota) i HostAfrica (Lagos). Operacje w centrali w Zurychu (rozliczenia, administracja) korzystają z Hostkey.

Wszystkie POP znajdują się albo:

• W jurysdykcjach z decyzjami o odpowiedniości (UE, EOG, Szwajcaria, Wielka Brytania, Kanada itp.)
• Związane standardowymi klauzulami umownymi (SCC), gdzie nie ma decyzji o odpowiedniości

Ze względu na naszą architekturę szyfrowania (zerowa wiedza), nawet dane przechowywane w jurysdykcjach nieposiadających odpowiedniości są technicznie chronione. Nie możemy ich odszyfrować; podobnie jak lokalne władze. Rozwiązanie DNS jest obsługiwane przez Cloudflare; żadne dane z sejfu nigdy nie przechodzą przez ich sieć.

Żadne dane nie są przez nas odszyfrowywane w spoczynku. Plik sejfu jest zaszyfrowany, a klucz szyfrowania nie jest przechowywany na serwerze. Kiedy agent lub użytkownik się łączy, przenosi ze sobą klucz L1 – technicznie możemy go przechwycić w tranzycie (chociaż tego nie robimy, a TLS uniemożliwia to stronom trzecim). Nawet z L1 widoczne są tylko metadane. Pola poświadczeń i tożsamości pozostają zapieczętowane.

• L1 (Szyfrowanie sejfu): Sejf jest szyfrowany w spoczynku za pomocą AES-256-GCM. 8-bajtowy klucz L1 jest przenoszony przez agenta lub użytkownika przy każdym żądaniu – nie jest przechowywany na serwerze. Z L1 widoczne są tytuły wpisów, typy i znaczniki czasu. Jest to minimalny poziom operacyjny wymagany do obsługi żądań.
• L2 (Pola poświadczeń): Hasła, klucze API, dane TOTP, tokeny OAuth – szyfrowane per-pole 16-bajtowym kluczem, który nigdy nie istnieje na serwerze. L2 jest przechowywany wyłącznie w przeglądarce użytkownika i jego zarejestrowanych agentach. Nie możemy odszyfrować pól poświadczeń, a żaden proces po stronie serwera nigdy nie ma dostępu do L2.
• L3 (Pola tożsamości): Karty kredytowe, CVV, numery paszportów, numery PESEL, kody odzyskiwania – szyfrowane 32-bajtowym kluczem o czystej losowej entropii, wygenerowanym podczas tworzenia sejfu. Użytkownik nie zna tego klucza. My go nie posiadamy. L3 nigdy nie istnieje na żadnym serwerze. Jest chroniony przez opakowanie go 32-bajtowym wyjściem PRF klucza sprzętowego użytkownika (odcisk palca, twarz lub klucz bezpieczeństwa przez WebAuthn PRF). Bez fizycznego urządzenia L3 nie można rozpakować. Matematycznie nie możemy odszyfrować pól tożsamości i nie możemy być zmuszeni do dostarczenia klucza, którego nie posiadamy.

W sprawach związanych z DPA:

Inspektor Ochrony Danych (IOD) Clavitor LLC c/o Johan Jongsma

Niniejsza DPA obowiązuje od daty rozpoczęcia Pana/Pani subskrypcji i pozostaje w mocy do jej zakończenia. Zmiany są zgłaszane z 30-dniowym wyprzedzeniem. Dalsze korzystanie oznacza akceptację.

Ostatnia aktualizacja: 25 maja 2026 r. · Wersja 1.1