Odbiorcy danych Palladin
Projekt przed premierą. Wymaga przeglądu wykwalifikowanego prawnika przed publikacją; nie wszedł w życie. Wiążąca jest wersja polska, z zachowaniem obowiązkowych praw konsumenta.
Wykaz rozdziela potwierdzony kod i wybór dostawcy od niezweryfikowanych umów i wdrożeń. Nie stanowi dowodu zawarcia DPA, wyboru regionu lub zgodności transferu. Przed produkcją należy wskazać dokładne podmioty umowne, lokalizacje i zabezpieczenia. Kontakt: patryk.roguszewski@palladin.io.
1. Integracje istniejące w kodzie
| Dostawca i usługa | Rola i dane | Lokalizacja i stan weryfikacji |
|---|---|---|
| AWS — infrastruktura, magazyn i Amazon SES | przewidziany procesor danych aplikacji: zaszyfrowane Sejfy, konto, logi, publiczne katalogi; SES: e-mail i treść wiadomości oraz zdarzenia doręczeń, w tym link potwierdzenia i alerty bezpieczeństwa | AWS wybrany przez właściciela; podmiot kontraktowy, rzeczywisty region, retencja i DPA niepotwierdzone. Nie przyjmujemy automatycznie eu-west-1 ani braku dostępu spoza EOG |
| Google/Firebase — FCM | procesor doręczania powiadomień: token, platforma, generyczny komunikat i nieprzezroczyste identyfikatory; bez nazw Sejfów/Wpisów i sekretów | Firebase wybrany; dokładne podmioty, przepływy międzynarodowe i warunki do potwierdzenia |
| Apple — APNs | doręczenie push na urządzenia Apple przez FCM; token i ograniczony payload jak wyżej; rolę określają właściwe warunki | infrastruktura Apple; podmiot, warunki i zabezpieczenia przepływu do potwierdzenia |
| PostHog | przewidziany procesor wybranych zdarzeń: pseudonimowe ID konta/waitlist albo losowe ID strony, zdarzenie i ograniczone dane techniczne. Bez sekretów, replay, autocapture i profili osób | transport klienta ograniczony do EU; samo to nie dowodzi regionu przechowywania/logów ani wyłączenia dostępu spoza EOG. DPA, retencja, sprzeciw backendowy i warunki uruchomienia nadal do zamknięcia |
| Netlify — landing/CDN i proxy waitlist | przewidziany procesor powierzonych danych: IP i żądanie; formularz przekazuje e-mail i język do API. Kod proxy nie zapisuje ani nie loguje e-maila | integracja w kodzie; dokładny region funkcji, logi, podmiot i DPA niezweryfikowane |
| Google — logowanie | dostawca tożsamości; identyfikator, e-mail i profil potrzebny do logowania. Własne cele Google określa jego polityka; nie jest automatycznie procesorem Palladin | jedyny zarejestrowany OAuth w obecnym backendzie; właściwe warunki i transfery do weryfikacji |
| Google Fonts | odbiorca bezpośredniego żądania fontu z panelu aplikacji, w tym IP i danych przeglądarki; nie otrzymuje przez to treści Sejfu. Strona informacyjna i strony prawne używają fontów z własnego hostingu, bez połączenia z Google Fonts | połączenie zewnętrzne pozostaje w panelu; podstawa, warunki i konieczność do zatwierdzenia lub usunięcie tego połączenia przed premierą |
| Have I Been Pwned / Pwned Passwords | niezależny odbiorca kontroli hasła: pięcioznakowy prefiks SHA-1 i dane połączenia, w tym IP; nie pełne hasło ani pełny skrót. Nie kwalifikujemy go automatycznie jako procesora | bezpośrednie połączenie klienta z API; warunki i lokalizacja przepływu do weryfikacji |
Treść i prezentacja Wpisów trafiają do infrastruktury jako szyfrogram. Odrębne funkcje ujawniają hostname publicznej ikony oraz domenę, adres logowania i definicję mapy formularza bez wartości sekretów. Lokalny eksport i świadomie upoważniony Agent lub strona mogą otrzymać dane jawne; ich odbiorcy nie są przez sam wybór użytkownika podprocesorami Palladin.
2. Wybrane przyszłe płatności i niepotwierdzone usługi
Apple App Store, Google Play i Paddle zostały wybrane do pierwszego płatnego wydania, lecz integracje rozliczeniowe nie są jeszcze gotowe. Właściwy sprzedawca/platforma i niezależny administrator będą identyfikowani przed zakupem. Zakres obejmie identyfikatory konta i transakcji, Plan, uprawnienia, okres oraz wymagane dane płatnicze/fakturowe, nigdy klucze Sejfu. Nie oznacza to zatwierdzenia Palladin przez operatora ani zawarcia wszystkich umów.
RevenueCat nie jest potwierdzoną integracją. Discord nie jest obecnym kanałem wsparcia ani potwierdzonym podprocesorem. Ich ewentualne uruchomienie wymaga ponownego określenia roli, danych i warunków. Nie znaleziono wdrożonego zewnętrznego crash-reportingu ani sieci reklamowej; ten opis nie zastępuje kontroli faktycznej konfiguracji premiery.
3. Transfery i zmiany
Przed przekazaniem danych poza EOG należy ustalić podstawę właściwą dla konkretnego odbiorcy i przepływu. Adekwatność działa tylko w swoim zakresie; DPF wymaga objętej nim certyfikowanej organizacji i danych, a adekwatność Kanady obejmuje właściwe przetwarzanie podlegające PIPEDA. W innych przypadkach potrzebne są SCC lub inny mechanizm rozdziału V RODO, ocena transferu i stosowne zabezpieczenia. Hosting w UE nie wyklucza zagranicznego dostępu.
Kopię rzeczywiście stosowanych zabezpieczeń i informacje o lokalizacjach można uzyskać przez powyższy kontakt, z niezbędną ochroną cudzych danych i bezpieczeństwa. Zmiany podprocesorów wymagają aktualizacji listy i zawiadomienia Klientów B2B zgodnie z DPA; odbiorca będący niezależnym administratorem nie podlega automatycznie procedurze autoryzacji podprocesora.