Wersja: 1.1
Data publikacji: 29.10.2025

Podmiot: Astrabit Krzysztof Kowalski | NIP: 679 302 80 24
Adres: Astrabit, ul. Podłęska 1/3, 30-865 Kraków
Kontakt (privacy / dane osobowe): biuro@astrabit.com
Kontakt (bezpieczeństwo): k.kowalski@astrabit.com

 

Kluczowe zasady (skrót):
• Nie agregujemy danych między sprzedawcami ani nie tworzymy benchmarków między sprzedawcami.
• Nie udostępniamy, nie sprzedajemy i nie publikujemy danych ani insightów pochodzących z platform marketplace (np. Amazon) innym podmiotom.
• Aplikacja działa w modelu „zero‑transfer” – w środowisku Klienta; Astrabit nie przechowuje danych operacyjnych Klienta u siebie.
• Wszelkie integracje odbywają się wyłącznie za autoryzacją Klienta i wyłącznie na jego rzecz.

 

1) Polityka prywatności (Privacy Policy)

1.1. Kto jest administratorem danych?

Administratorem danych osobowych w związku z naszą stroną internetową, relacjami B2B, rekrutacją oraz innymi własnymi celami jest Astrabit Krzysztof Kowalski (dalej: „Astrabit”), ul. Podłęska 1/3, 30-865 Kraków. Kontakt: biuro@astrabit.com.

Uwaga: Dane operacyjne przetwarzane w środowiskach Klientów (np. dane zamówień z platform marketplace) pozostają pod kontrolą danego Klienta – patrz sekcje 1.7, 2.6 i Załącznik A/E.

1.2. Zakres danych i źródła

Przetwarzamy dane w związku z:

  • korzystaniem z naszych aplikacji i usług,
  • realizacją zamówień oraz obsługą posprzedażową (w środowiskach Klientów),
  • obsługą zapytań, umów i rozliczeń,
  • integracją z zewnętrznymi platformami na podstawie autoryzacji Klienta (np. platformy marketplace – zob. Załącznik A),
  • bezpieczeństwem i utrzymaniem systemów (logi techniczne bez PII, o ile przepisy nie stanowią inaczej).

Model wdrożenia (zero‑transfer): Aplikacja Astrabit działa w infrastrukturze Klienta (on‑prem / VPC Klienta). Dane operacyjne (w tym dane z platform marketplace) nie są przesyłane ani przechowywane na serwerach Astrabit. Wyjątki mogą wystąpić wyłącznie w trybie wsparcia serwisowego na wyraźne, udokumentowane polecenie Klienta (patrz §2.6 oraz Załącznik D).

1.3. Cele i podstawy prawne (RODO)

  • Realizacja umowy (art. 6 ust. 1 lit. b RODO): obsługa relacji B2B, umów, zamówień – w zakresie naszych własnych celów.
  • Obowiązek prawny (art. 6 ust. 1 lit. c): rachunkowość, podatki, reklamacje.
  • Prawnie uzasadniony interes (art. 6 ust. 1 lit. f): bezpieczeństwo usług, dochodzenie roszczeń, zapobieganie nadużyciom, statystyki oparte o dane zanonimizowane/zagregowane bez PII i bez danych operacyjnych Klienta.
  • Zgoda (art. 6 ust. 1 lit. a): tam, gdzie wymagana (np. newsletter, cookie nieniezbędne).

1.4. Odbiorcy danych

Co do zasady nie ujawniamy danych operacyjnych żadnym podmiotom poza Klientem – aplikacja działa w środowisku Klienta, a dane pozostają pod jego kontrolą. Nie przekazujemy danych przewoźnikom ani innym odbiorcom „po naszej stronie”. Możliwe ujawnienia po stronie Astrabit ograniczają się do: (i) danych kontaktowych/rozliczeniowych w relacji B2B z Klientem; (ii) informacji nieosobowych/technicznych (np. telemetria bez PII) – wyłącznie po konfiguracji i zgodnie z niniejszą Polityką.

1.5. Przekazywanie poza EOG

Jeśli dochodzi do transferów poza EOG (np. gdy Klient korzysta z dostawców spoza EOG), stosowane są zabezpieczenia wymagane przez RODO, w szczególności SCC oraz – jeśli to konieczne – dodatkowe środki techniczne i organizacyjne.

1.6. Okres przechowywania

Co do zasady przechowujemy dane tak długo, jak to konieczne do realizacji celu, a następnie przez okresy wymagane przepisami. Dane operacyjne Klienta (w tym PII pochodzące z platform marketplace) przechowywane są w systemach Klienta zgodnie z jego konfiguracją; domyślnie ≤ 30 dni po dostawie przesyłki, chyba że przepisy prawa wymagają dłuższego okresu (szczegóły w §3).

1.7. Prawa osób, których dane dotyczą

Masz prawo do: dostępu, sprostowania, usunięcia, ograniczenia, przenoszenia danych oraz sprzeciwu.

Gdzie złożyć wniosek (DSAR):

  • Dane operacyjne Klienta (np. zamówienia/Marketplace): administratorem jest Klient – wniosek złóż bezpośrednio u Klienta (sprzedawcy), u którego złożyłeś(-aś) zamówienie. Jeśli nie wiesz, do kogo się zwrócić, napisz do nas – podaj minimum: platformę/sprzedawcę oraz identyfikator lub datę zamówienia. Za Twoją wyraźną zgodą możemy przekazać wniosek właściwemu administratorowi.
  • Dane Astrabit (np. formularze na stronie, korespondencja B2B, rekrutacja, logi wsparcia): administratorem jest Astrabit – wniosek złóż do nas.

Kanały kontaktu DSAR:

  • e‑mail: biuro@astrabit.com
  • listownie: Astrabit, ul. Podłęska 1/3, 30-865 Kraków, z dopiskiem „IOD/DSAR”

Masz też prawo wnieść skargę do Prezesa UODO (ul. Stawki 2, 00‑193 Warszawa).

1.8. Pliki cookie i podobne technologie

Używamy plików cookie niezbędnych do działania serwisu oraz – za Twoją zgodą – analitycznych/marketingowych. Szczegóły, w tym lista dostawców i cele, znajdują się w Polityce cookie oraz w banerze zgody.

1.9. Zmiany polityki

Polityka jest okresowo przeglądana. Aktualna wersja i historia zmian publikowane są na tej stronie.

2) Polityka zarządzania i klasyfikacji danych

2.1. Zakres i cel

Polityka określa zasady klasyfikacji, gromadzenia, przetwarzania, przechowywania, udostępniania i usuwania informacji – w tym danych pochodzących z platform marketplace – w całym cyklu życia.

2.2. Role i odpowiedzialności

  • Właściciel polityki: Krzysztof Kowalski
  • Właściciel danych: Krzysztof Kowalski
  • Zespół bezpieczeństwa/IT: Mirosław Kapałka

2.3. Klasyfikacja

  • PUBLIC – informacje publicznie dostępne.
  • INTERNAL – informacje wewnętrzne, bez danych osobowych.
  • CONFIDENTIAL – informacje wrażliwe biznesowo lub PII.
  • MARKETPLACE CONFIDENTIAL/PII – dane pochodzące z platform marketplace objęte restrykcjami właściwych polityk dostępu do danych (np. Amazon DPP).

Etykiety klasyfikacji utrzymywane są w systemach źródłowych i repozytoriach.

2.4. Zasady przetwarzania

  • Minimalizacja zakresu, least privilege i „need‑to‑know”.
  • Bezpieczne interfejsy (TLS 1.2+), szyfrowanie w tranzycie i w spoczynku (AES‑256 / KMS lub równoważne).
  • Zakaz użycia danych pochodzących z platform marketplace do marketingu/analityki niezwiązanej z realizacją zamówienia na rzecz danego Klienta.
  • Rejestr czynności przetwarzania (ROPA) – utrzymywany wewnętrznie; udostępniamy na żądanie uprawnionym podmiotom.

2.5. Przeglądy i audyty

Coroczne przeglądy zarządcze; testy i audyty wg potrzeb biznesowych/umownych (w tym na żądanie partnerów).

2.6. Role i transfery – model Zero‑Transfer

  • Rola Klienta: Klient jest administratorem danych operacyjnych (w tym danych pochodzących z platform marketplace). Dane przetwarzane i przechowywane są wyłącznie w jego środowisku.
  • Rola Astrabit: w typowym działaniu systemu nie uzyskujemy dostępu do danych operacyjnych Klienta i ich nie przetwarzamy poza jego środowiskiem.
  • Wsparcie serwisowe (opcjonalnie): na wyraźne, udokumentowane polecenie Klienta możemy uzyskać tymczasowy, kontrolowany dostęp (np. sesja zdalna nadzorowana/udostępnienie ekranu albo dostęp do zanonimizowanego zrzutu). Wtedy działamy jako podmiot przetwarzający wyłącznie w zakresie i czasie niezbędnym do wykonania zadania; stosujemy DPA, rejestrujemy dostęp, a wszelkie artefakty są bezpiecznie usuwane natychmiast po zakończeniu (0–7 dni).
  • DSAR: wnioski dotyczące danych operacyjnych realizuje Klient jako administrator; Astrabit wspiera Klienta jedynie, gdy uzyskał tymczasowy dostęp w trybie wsparcia.

2.7. Podział odpowiedzialności (Shared Responsibility)

  • Astrabit odpowiada za: bezpieczny SDLC, domyślne konfiguracje zgodne z zasadami właściwych polityk dostępu do danych marketplace (np. retencja ≤ 30 dni, NIST 800‑88, szyfrowanie, brak PII w logach), dokumentację i wytyczne konfiguracji w środowisku Klienta, bezpieczeństwo incydentalnego dostępu (DPA, logowanie), aktualizacje i łatki aplikacji.
  • Klient odpowiada za: środowisko uruchomieniowe (serwery, sieć, SIEM, backupy), konfigurację i egzekwowanie retencji/usuwania w aplikacji oraz integracje z przewoźnikami, obowiązki informacyjne i własną politykę prywatności, reakcję na incydenty w swoim środowisku.

3) Polityka retencji i usuwania danych (Retention & Disposal)

3.1. Zasady ogólne

  • Dane przechowujemy tylko tak długo, jak to konieczne i zgodnie z prawem.
  • PII w systemach Klienta (np. dane odbiorców zamówień): domyślnie ≤ 30 dni po dostawie, chyba że przepisy wymagają dłużej.
  • Logi bezpieczeństwa: min. 90 dni online do celów dochodzeniowych/incydentowych (po stronie Klienta).
  • Kopie zapasowe: wg harmonogramu Klienta; po upływie retencji – bezpieczne usunięcie.

3.2. Usuwanie i sanitizacja

Bezpieczne usunięcie zgodnie z NIST 800‑88 (nadpisywanie, secure erase, niszczenie nośników); utrzymujemy dowody wykonania (raporty). W przypadku otrzymania żądania usunięcia od właściwej platformy lub organu, zapewniamy wsparcie Klientowi w trwałym usunięciu danych w terminie ≤ 30 dni, a wszystkie instancje „live” (online/dostępne w sieci) są usuwane w terminie ≤ 90 dni. Na żądanie przekazujemy potwierdzenie usunięcia.

3.3. Zamrożenie prawne (legal hold)

W przypadku sporu/regulacji wstrzymujemy usuwanie do czasu zniesienia hold (po stronie Klienta dla danych operacyjnych).

4) Polityka dostępu i tożsamości (Access Management)

Unikalne konta, zakaz kont współdzielonych, MFA dla kont uprzywilejowanych, zasada least privilege, przeglądy uprawnień kwartalnie, offboarding ≤ 24 h; hasła min. 12 znaków, klucze API w sejfach tajemnic (brak hardcodowania).

5) Polityka szyfrowania (Encryption)

  • W tranzycie: TLS 1.2+
  • W spoczynku: szyfrowanie na poziomie nośnika/bazy (AES‑256 / RSA ≥ 2048), klucze w KMS/HSM Klienta
  • Dodatkowe szyfrowanie komunikatów, gdy TLS kończy się na sprzęcie nieufnym.

6) Polityka logowania i monitorowania

Logowanie i monitoring odbywa się w środowisku Klienta. Aplikacja udostępnia: logi API, autoryzacji, paneli, systemów, baz i storage; integrację z SIEM Klienta; logi bez PII (maskowanie/tokenizacja); retencję ≥ 90 dni; zestaw reguł (brute‑force, anomalie eksportów, dostępy do canary records, nadużycia uprawnień). Przeglądy zdarzeń w czasie rzeczywistym (SIEM) lub nie rzadziej niż co 14 dni.

7) Plan reagowania na incydenty (IRP)

Zdefiniowane role, playbooki (wyciek danych, kompromitacja klucza API, DoS), procedura: wykrycie → triage → containment → eradication → recovery → post‑mortem; jeśli incydent dotyczy danych pochodzących z platform marketplace – zgłoszenie do właściwego zespołu bezpieczeństwa platformy (np. security@amazon.com dla Amazon) w ciągu 24 h; zachowanie łańcucha dowodowego.

8) Polityka plików cookie

Cookie niezbędne oraz – za zgodą – analityczne/marketingowe; zarządzanie zgodami przez baner i ustawienia przeglądarki. Szczegóły – w odrębnej Polityce cookie.

9) Procedura obsługi praw osób (DSAR)

Kanały kontaktu jak w §1.7; wnioski dot. danych operacyjnych kierować do Klienta‑administratora; Astrabit wspiera Klienta w realizacji DSAR, jeśli uzyskaliśmy dostęp w trybie wsparcia.

10) Rejestr czynności przetwarzania (ROPA) – informacja

ROPA utrzymujemy wewnętrznie i udostępniamy na żądanie uprawnionym podmiotom w zakresie niezbędnym do weryfikacji zgodności.

11) Wykaz podmiotów przetwarzających (kategorie)

Hosting/strona www, systemy ticketowe/komunikacja, księgowość/ERP, SOC/SIEM (jeśli dotyczy wsparcia) – lista aktualna w Załączniku C. Nie obejmuje przewoźników Klienta.

12) Oświadczenie o wykorzystaniu danych z platform marketplace

  • Dane pochodzące z platform marketplace nie są zbierane ani przechowywane przez Astrabit – przetwarzane są wyłącznie w środowisku Klienta.
  • Komunikacja z platformami odbywa się z sieci Klienta poprzez bezpieczne API; klucze/API keys przechowywane są w narzędziach Klienta (np. KMS/Secrets Vault). Astrabit nie posiada kopii kluczy.
  • Aplikacja egzekwuje: klasyfikację, szyfrowanie w tranzycie i w spoczynku (zasoby Klienta), retencję ≤ 30 dni po dostawie oraz bezpieczne usuwanie zgodnie z NIST 800‑88.
  • Brak agregacji danych między sprzedawcami oraz brak tworzenia „insightów o biznesie platformy” – działamy wyłącznie na rzecz autoryzującego Klienta.

13) Informacja o mapowaniu do wymagań polityk dostępu do danych platform (np. Amazon DPP)

Na żądanie udostępniamy mapowanie kontroli do wymagań właściwych polityk (np. Amazon DPP).

14) Zarządzanie podatnościami i jakością wytwarzania

Rozdzielenie środowisk DEV/TEST/PROD, code review, SAST/DAST przed wydaniem, skany podatności ≥ co 180 dni, testy penetracyjne ≥ raz/rok; zarządzanie zmianą (segregacja obowiązków); DR/BCP.

15) Sieć i ochrona punktów końcowych

Segmentacja sieci, firewalle/WAF, listy ACL, IDS/IPS; kontrole DLP na punktach końcowych i granicach w celu wykrywania nieautoryzowanego ruchu danych; anty‑malware; MDM dla urządzeń służbowych; zakaz przechowywania danych operacyjnych na urządzeniach prywatnych.

16) Informacje kontaktowe i zgłaszanie naruszeń

  • Pytania dot. prywatności: biuro@astrabit.com
  • Zgłoszenia bezpieczeństwa: security@astrabit.com
  • Zgłoszenia dot. danych pochodzących z platform marketplace (np. Amazon): security@amazon.com – w przypadku incydentu dotyczącego danych platformy, w ciągu 24 h od wykrycia.

17) Załączniki

Załącznik A – Integracje z platformami marketplace (skrót)

Zakres danych: identyfikatory zamówień, dane dostawy, statusy – wyłącznie w zakresie niezbędnym do realizacji na rzecz autoryzującego Klienta.
Kanały: wyłącznie bezpieczne API (TLS 1.2+); połączenia wychodzą z sieci Klienta.
Retencja PII: ≤ 30 dni od dostawy (konfigurowana w aplikacji); usunięcie wg NIST 800‑88; logi bez PII (min. 90 dni – po stronie Klienta).
Agregacja: niedozwolona – brak łączenia danych między sprzedawcami; brak benchmarków między kontami.

Załącznik B – Klauzula w umowie z Klientem (Zero‑Transfer)

Zasada Zero‑Transfer. Strony potwierdzają, że Astrabit nie przekazuje danych poza środowisko Klienta. Dane są przetwarzane w systemach Klienta, a Astrabit nie uzyskuje do nich dostępu, chyba że Klient wyraźnie i incydentalnie udzieli takiego dostępu w celu wsparcia serwisowego. W takim wypadku mają zastosowanie postanowienia DPA, a po zakończeniu wsparcia wszelkie dane/artefakty zostają niezwłocznie usunięte.

Załącznik C – Lista podprocesorów Astrabit

Nie angażujemy podprocesorów do przetwarzania danych operacyjnych Klienta.
W odniesieniu do danych Astrabit (www/B2B/rekrutacja) korzystamy z podmiotów przetwarzających – kategorie wskazane są w §11. Szczegółowa lista nazw, lokalizacji i podstaw transferu dostępna na żądanie.

Załącznik D – Oświadczenie braku przepływu danych do Astrabit

  • Aplikacja działa u Klienta; brak stałych połączeń wychodzących do Astrabit dla danych operacyjnych.
  • Brak telemetrii PII do Astrabit (domyślnie wyłączona; możliwa wyłącznie po konfiguracji bez PII).
  • Klucze/API Keys są wyłącznie w posiadaniu Klienta.
  • Wsparcie serwisowe odbywa się bez kopiowania danych (preferencyjnie: screen‑sharing/anonimizacja).

Załącznik E – DSAR „front‑door” – procedura przyjęcia i routingu

  • Klasyfikacja wniosku: dane Astrabit vs. dane operacyjne Klienta.
  • Jeśli Astrabit = administrator: potwierdź odbiór ≤ 7 dni, weryfikacja, realizacja ≤ 1 miesiąc (+2 mies. przy skomplikowanych).
  • Jeśli Klient = administrator: poinformuj wnioskodawcę, że Astrabit nie jest administratorem; wskaż kontakt do Klienta lub – za zgodą wnioskodawcy – przekaż wniosek. Wymagane minimum: platforma/sprzedawca, ID lub data zamówienia.
  • Minimalizacja: nie kopiuj danych; przechowuj metadane obsługi DSAR (daty, klasyfikacja, nr sprawy).
  • Wzory odpowiedzi – dostępne na żądanie.

Stopka prawna

Niniejszy dokument ma charakter informacyjny i operacyjny. W zakresie, w jakim jest wymagane prawem lokalnym, może stanowić regulamin/politykę ochrony danych. W razie sprzeczności z obowiązującymi przepisami pierwszeństwo mają przepisy prawa.