UMOWA POWIERZENIA PRZETWARZANIA DANYCH OSOBOWYCH

Data Processing Agreement (DPA)

KSeF Import — Oprogramowanie do automatycznego pobierania faktur z Krajowego Systemu e-Faktur i eksportu do platform wybranych przez Klienta

STRONY UMOWY

PROCESOR: - ANTENA Sp. z o.o. - Siedziba: Gdynia 81-208, Polska - NIP: 9581754603 - REGON: 541828792 - KRS: 0001174534 - Email: kontakt@ksefimport.pl - Inspektor Ochrony Danych (IOD): kontakt@ksefimport.pl

ADMINISTRATOR: - Podmiot podpisujący Umowę Świadczenia Usług (Umowę Ogólną) z ANTENA Sp. z o.o. - Dane ADMINISTRATORA wymienione w Umowie Głównej

§ 1. DEFINICJE

1.1. RODO — Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych.

1.2. Dane osobowe — wszelkie informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej.

1.3. Przetwarzanie — operacja wykonywana na danych osobowych, taka jak zbieranie, utrwalanie, organizowanie, porządkowanie, przechowywanie, adaptowanie, modyfikowanie, pobieranie, przeglądanie, wykorzystywanie, ujawnianie, przesyłanie, rozpowszechnianie lub w inny sposób udostępnianie, porównywanie lub łączenie, ograniczanie, usuwanie lub niszczenie.

1.4. Administrator — podmiot, który samodzielnie lub wspólnie z innymi określa cele i sposoby przetwarzania danych osobowych (zgodnie z RODO art. 4 ust. 7). W kontekście niniejszej Umowy — klient korzystający z usług KSeF Import.

1.5. Procesor — ANTENA Sp. z o.o., która przetwarza dane osobowe w imieniu ADMINISTRATORA.

1.6. Podprzetwarzający (Sub-processor) — osoba lub podmiot, która przetwarza dane osobowe w imieniu Procesora (na podstawie polecenia Procesora).

1.7. Naruszenie ochrony danych — naruszenie bezpieczeństwa prowadzące do przypadkowego lub niezamierzonego zniszczenia, utraty, zmodyfikowania, nieautoryzowanego ujawnienia lub dostępu do danych osobowych przesyłanych, przechowywanych lub przetwarzanych w inny sposób.

1.8. Usługi KSeF Import — platforma SaaS umożliwiająca automatyczne pobieranie faktur z Krajowego Systemu e-Faktur (KSeF) oraz eksport tych danych do platform wybranych przez ADMINISTRATORA (m.in. Google Sheets, Excel, CSV, Airtable, Notion).

1.9. Instrukcja — każde polecenie ADMINISTRATORA skierowane do Procesora w celu przetwarzania danych osobowych, wydane w formie pisemnej lub poprzez interfejs usługi.

1.10. Certyfikat KSeF — plik (.p12) zawierający klucz prywatny i certyfikat do autentykacji wobec API Krajowego Systemu e-Faktur, powierzony Procesorowi przez ADMINISTRATORA w celu realizacji usług.

§ 2. PRZEDMIOT UMOWY

2.1. Niniejsza Umowa Powierzenia Przetwarzania Danych Osobowych (dalej: „Umowa") jest integralnym aneksem do Umowy Świadczenia Usług zawartej pomiędzy Stronami (dalej: „Umowa Główna") i określa warunki, na których Procesor przetwarza dane osobowe na rzecz ADMINISTRATORA.

2.2. Procesor zobowiązuje się do przetwarzania danych osobowych wyłącznie na polecenie ADMINISTRATORA, w zakresie i na warunkach określonych w niniejszej Umowie oraz w zgodzie z obowiązującymi przepisami prawa, w szczególności z RODO.

2.3. Niniejsza Umowa stanowi umowę powierzenia przetwarzania danych osobowych w rozumieniu art. 28 RODO.

§ 3. ZAKRES I CEL PRZETWARZANIA

3.1. Cel przetwarzania: Procesor przetwarza dane osobowe wyłącznie w celu świadczenia Usług KSeF Import, a konkretnie: - (a) pobrania faktur z Krajowego Systemu e-Faktur (KSeF) za pomocą API KSeF na podstawie danych uwierzytelniających (Certyfikatu KSeF) powierzonego przez ADMINISTRATORA; - (b) przetworzenia, przeanalizowania i eksportu danych z faktur do platform wybranych przez ADMINISTRATORA; - (c) przechowywania kopii faktur w bazie danych Procesora w celu umożliwienia wielokrotnego eksportu, wyszukiwania i przeglądania historii; - (d) realizacji obowiązków księgowych, podatkowych i rozliczeniowych Procesora (VAT, podatek dochodowy, statystyki użycia usługi); - (e) realizacji obowiązków wynikających z przepisów prawa i decyzji organów publicznych.

3.2. Brak automatycznego podejmowania decyzji: Procesor nie podejmuje żadnych automatycznych decyzji skutkujących dla danych osobowych (art. 22 RODO) w ramach świadczenia Usług. Wszystkie operacje na danych mają charakter automatyzacji technicznej bez podejmowania decyzji w rozumieniu RODO.

3.3. Instrukcje ADMINISTRATORA: Procesor przetwarza dane osobowe wyłącznie na instrukcje ADMINISTRATORA. Instrukcjami są w szczególności: - działania ADMINISTRATORA w interfejsie użytkownika (login, konfiguracja eksportu, wybór platform eksportu); - polecenia przesłane drogą elektroniczną (email, formularz kontaktowy); - konfiguracja harmonogramów synchronizacji (działania podjęte w panelu użytkownika); - zapauzowanie lub wznowienie usługi.

3.4. Procesor nie przetwarza danych osobowych do żadnych innych celów niż wymienione w pkt. 3.1 bez uprzedniej pisemnej zgody ADMINISTRATORA.

§ 4. RODZAJ DANYCH I KATEGORIE OSÓB

4.1. Kategorie przetwarzanych danych osobowych (szczegółowy opis w Załączniku 1):

Dane z faktur pobieranych z KSeF: - (a) Dane identyfikacyjne kontrahentów: imiona i nazwiska, nazwy firm, imiona i nazwiska pełnomocników; - (b) Adresy: siedziby, adresy zamieszkania, adresy do korespondencji; - (c) Numery NIP (Numer Identyfikacyjny Podatnika); - (d) Numery REGON (Numer Rejestracji Gospodarczej); - (e) Numery identyfikacyjne za granicą (VATIN); - (f) Dane transakcyjne: kwoty, daty, opisy towarów/usług, numery dokumentów; - (g) Numery referencyjne faktur KSeF; - (h) Dane kontaktowe: adresy e-mail, numery telefonów (jeśli zawarte w fakturze).

Dane użytkownika systemu: - (a) Adres e-mail ADMINISTRATORA; - (b) Dane logowania (login, hash hasła); - (c) Historia logowania (daty, godziny, adresy IP); - (d) Dane o działalności w systemie (logi operacji).

Certyfikat KSeF: - (a) Plik certyfikatu (.p12) zawierający klucz prywatny i certyfikat autentykacyjny — przechowywany w postaci zaszyfrowanej.

4.2. Kategorie osób, których dotyczą dane: - (a) Kontrahenci (dostawcy, odbiorcy) ADMINISTRATORA widoczni na fakturach; - (b) Osoby fizyczne prowadzące działalność gospodarczą (jednoosobowe działalności gospodarcze, osoby fizyczne jako przedsiębiorcy); - (c) Osoby zatrudnione w firmach ADMINISTRATORA (jeśli na fakturach widnieją ich imiona jako osoby kontaktowe); - (d) Pracownicy ADMINISTRATORA mający dostęp do danych (użytkownicy systemu KSeF Import).

4.3. Szczególne kategorie danych: Procesor nie przetwarza specjalnych kategorii danych osobowych w rozumieniu art. 9 RODO. Jeśli dane zawarte w fakturach KSeF przypadkowo zawierają dane dotyczące zdrowia, życia seksualnego lub przekonań, ADMINISTRATOR odpowiada za zapewnienie prawidłowej podstawy prawnej do przetwarzania takich danych.

§ 5. CZAS TRWANIA PRZETWARZANIA

5.1. Okres przetwarzania: Procesor przetwarza dane osobowe przez cały okres trwania Umowy Głównej oraz w okresie po jej wygaśnięciu lub rozwiązaniu (patrz § 14).

5.2. Okres przetwarzania technicznego: Wymienione fakty mogą wymagać przetwarzania danych bez Instrukcji ADMINISTRATORA: - (a) operacje techniczne wymagane dla utrzymania infrastruktury (np. tworzenie kopii zapasowych, migracja serwerów); - (b) operacje wymuszające działalność w oparciu o przepisy prawa (patrz § 3.1 pkt. (e)); - (c) operacje wymagane do bezpieczeństwa systemu (analiza logów w ramach monitorowania bezpieczeństwa, detekcja ataków); - (d) operacje wymagane dla badania i zapobiegania oszustwom.

5.3. Postanowienia dotyczące przechowywania danych po wygaśnięciu Umowy określono w § 14.

§ 6. OBOWIĄZKI PROCESORA

6.1. Ogólne obowiązki procesora:

6.1.1. Procesor przetwarza dane osobowe wyłącznie na Instrukcje ADMINISTRATORA, chyba że przetwarzanie wynika z obowiązków narzuconych przez prawo Unii Europejskiej lub prawo polskie.

6.1.2. Procesor zapewnia, aby osoby uprawnione do przetwarzania danych osobowych (pracownicy, podwykonawcy) zobowiązały się do zachowania poufności lub podlegały odpowiedniemu obowiązkowi poufności.

6.1.3. Procesor wdraża i utrzymuje odpowiednie środki techniczne i organizacyjne w celu zapewnienia poziomu bezpieczeństwa dostosowanego do ryzyka (szczegółowo opisane w Załączniku 3 oraz w § 10).

6.1.4. Procesor nie łączy danych osobowych przetwarzanych na instrukcje jednego ADMINISTRATORA z danymi przetwarzanymi dla innych klientów, z wyjątkiem łączenia niezbędnego dla realizacji Instrukcji ADMINISTRATORA (np. podczas eksportu).

6.2. Bezpieczeństwo i szyfrowanie:

6.2.1. Certyfikaty KSeF powierzone przez ADMINISTRATORA są szyfrowane algorytmem AES-256-GCM przy użyciu klucza pochodnego (HKDF) wygenerowanego dla każdego ADMINISTRATORA osobno. Klucz główny (master encryption key) jest przechowywany osobno, poza bazą danych zawierającą zaszyfrowane certyfikaty.

6.2.2. Hasła użytkowników są haszowane algorytmem bcrypt z współczynnikiem kosztu wynoszącym minimum 12.

6.2.3. Przesyłanie danych odbywa się z wykorzystaniem TLS w wersji 1.3 lub wyższej.

6.2.4. Baza danych Procesora chroniona jest poprzez implementację Row-Level Security (RLS) w PostgreSQL, która technicznie zapewnia, że każdy użytkownik może uzyskać dostęp wyłącznie do swoich danych.

6.2.5. Wszystkie sesje użytkownika chronione są za pomocą ciasteczek z atrybutami: httponly (niedostępne dla JavaScript), secure (tylko HTTPS), samesite=Lax.

6.2.6. Wszystkie formularze i żądania POST chronione są tokenami CSRF (Cross-Site Request Forgery).

6.3. Rate limiting i ochrona przed atakami:

6.3.1. Procesor implementuje ograniczenia szybkości żądań: maksymalnie 100 żądań na minutę dla każdego użytkownika, maksymalnie 10 żądań na minutę na endpoint logowania.

6.3.2. Infrastruktura chroni przed atakami typu DDoS poprzez sieć dostarczającą zawartość (CDN) i firewall aplikacyjny (WAF).

6.4. Nagłówki bezpieczeństwa:

6.4.1. Procesor wysyła następujące nagłówki bezpieczeństwa w każdej odpowiedzi HTTP: - Content-Security-Policy (CSP) ograniczająca źródła skryptów i zasobów; - X-Frame-Options: DENY (ochrona przed clickjackingiem); - X-Content-Type-Options: nosniff (ochrona przed MIME sniffingiem); - Referrer-Policy (ograniczenie ujawniania informacji o pochodzeniu żądań); - Strict-Transport-Security (wymuszenie HTTPS).

6.5. Audytowanie i logowanie:

6.5.1. Procesor prowadzi logi (audit logs) wszystkich operacji wrażliwych, w tym: - (a) Upload i usunięcie certyfikatu KSeF; - (b) Zmiana konfiguracji eksportu; - (c) Logowanie i wylogowanie użytkownika; - (d) Zmiana hasła użytkownika; - (e) Dostęp do funkcji administratora; - (f) Zmiana ustawień bezpieczeństwa.

6.5.2. Logi przechowywane są przez minimum 90 dni i są niedostępne dla użytkownika końcowego (przechowywane w bezpiecznym systemie logów).

6.5.3. Logi zawierają co najmniej: timestamp, identyfikator użytkownika/ADMINISTRATORA, typ operacji, wynik operacji, adres IP, user agent.

6.6. Kopie zapasowe:

6.6.1. Procesor tworzy regularnie (minimum raz dziennie) kopie zapasowe bazy danych zawierające dane osobowe.

6.6.2. Kopie zapasowe szyfrowane są algorytmem GPG 2048-bit lub wyższym.

6.6.3. Kopie zapasowe przechowywane są geograficznie rozdzielone (minimum 2 lokalizacje w Unii Europejskiej).

6.6.4. Procesor testuje procedury odzyskiwania (restore) kopii zapasowych minimum raz na rok.

6.7. Monitoring bezpieczeństwa:

6.7.1. Procesor monitoruje bezpieczeństwo infrastruktury poprzez: - (a) monitorowanie sieci — detekcja anomalii w ruchu sieciowym; - (b) monitorowanie logów aplikacji — detekcja błędów, wyjątków, podejrzanych operacji; - (c) monitorowanie integracji — alerty o niedostępności serwisów, błędach synchronizacji; - (d) skanowanie podatności — regularne testy penetracyjne i skanowanie kodu.

6.7.2. Wyniki monitorowania przechowywane są w systemie monitorowania błędów (Sentry lub podobnym).

6.8. Dostęp pracowników Procesora:

6.8.1. Dostęp pracowników Procesora do bazy danych zawierającej dane osobowe ograniczony jest do minimum niezbędnego dla realizacji funkcji zawodowej (principle of least privilege).

6.8.2. Dostęp do danych w produkcji wymaga autoryzacji i jest logowany.

6.8.3. Dostęp do danych w środowisku testowym możliwy jest wyłącznie do zanonimizowanych kopii danych (bez czułych informacji).

6.8.4. Pracownicy Procesora podpisują umowy o poufności zawierające zobowiązania dotyczące ochrony danych osobowych.

6.9. Zakazy dla Procesora:

6.9.1. Procesor nie łączy danych osobowych z danymi pozyskiwanymi z innych źródeł w celu profilowania lub analizy ADMINISTRATORA lub jego kontrahentów, bez uprzedniej pisemnej zgody.

6.9.2. Procesor nie udostępnia danych osobowych Instytucjom Finansowym, biurom informacji o kredytowych lub innym trzecim podmiotom, z wyjątkiem podprzetwarzających wymienionych w Załączniku 2 i na podstawie wydanych Instrukcji.

6.9.3. Procesor nie magazynuje ani nie archiwizuje danych osobowych dłużej niż jest to konieczne dla celów przetwarzania określonych w § 3.1, z wyjątkiem przechowywania wymaganego przez prawo (patrz § 3.1 pkt. (e) i § 14).

6.10. Pomoc techniczna:

6.10.1. Procesor świadczy pomoc techniczną dostępną przez email kontakt@ksefimport.pl w godzinach 9:00-17:00 (czasu środkowoeuropejskiego) od poniedziałku do piątku (z wyjątkiem świąt).

6.10.2. Czas odpowiedzi na zgłoszenia: do 24 godzin roboczych dla reportów o średnim priorytecie, do 4 godzin roboczych dla incydentów bezpieczeństwa.

§ 7. OBOWIĄZKI ADMINISTRATORA

7.1. Ogólne obowiązki:

7.1.1. ADMINISTRATOR jest odpowiedzialny za: - (a) określenie celów i sposobów przetwarzania danych osobowych (role Administratora w rozumieniu RODO art. 4 ust. 7); - (b) posiadanie prawidłowej podstawy prawnej do przetwarzania danych osobowych (art. 6 RODO) przed powierzeniem Procesorowi; - (c) udokumentowanie podstawy prawnej przetwarzania w rejestrze przetwarzania danych (RODO art. 30); - (d) dokonanie oceny skutków przetwarzania danych dla ochrony osób fizycznych (DPIA - Data Protection Impact Assessment) jeśli dotyczy (RODO art. 35); - (e) powiadomienie Inspektora Ochrony Danych (jeśli wymagane) przed wdrożeniem usługi.

7.1.2. ADMINISTRATOR jest odpowiedzialny za dokładność, kompletność i zgodność z prawem danych osobowych przesyłanych Procesorowi. Procesor nie weryfikuje poprawności danych.

7.2. Certyfikat KSeF:

7.2.1. ADMINISTRATOR zobowiązuje się do powierzenia Procesorowi Certyfikatu KSeF w formacie .p12 wymaganego do autentykacji wobec API Krajowego Systemu e-Faktur.

7.2.2. ADMINISTRATOR potwierdza, że: - (a) jest uprawniony do korzystania z Certyfikatu KSeF; - (b) Certyfikat KSeF pochodzi z legalnego źródła i został wydany przez uprawniony podmiot (Ministerstwo Finansów, certyfikowana pracownia kryptografii); - (c) będzie chronić hasło dostępu do Certyfikatu zgodnie ze standardami bezpieczeństwa; - (d) powiadomi Procesora niezwłocznie w przypadku podejrzenia kompromitacji Certyfikatu.

7.2.3. ADMINISTRATOR w każdej chwili może usunąć Certyfikat KSeF z systemu Procesora. Usunięcie Certyfikatu automatycznie zatrzyma pobieranie nowych faktur.

7.3. Instrukcje przetwarzania:

7.3.1. ADMINISTRATOR zobowiązuje się do wydawania Instrukcji przetwarzania danych osobowych wyłącznie na podstawie prawidłowej podstawy prawnej oraz prawidłowego określenia celów.

7.3.2. Instrukcje muszą być wydane w jasny i zrozumiały sposób (poprzez interfejs systemu, email, formularz).

7.3.3. ADMINISTRATOR ponosi odpowiedzialność za wykonanie Instrukcji — Procesor wykonuje Instrukcję zgodnie z jej treścią.

7.4. Zarządzanie dostępem:

7.4.1. ADMINISTRATOR jest odpowiedzialny za zarządzanie dostępem użytkowników do systemu KSeF Import (przyznawanie, udzielanie uprawnień, usuwanie dostępu).

7.4.2. ADMINISTRATOR zobowiązuje się do niezwłocznego usunięcia dostępu byłych pracowników i współpracowników z systemu.

7.4.3. ADMINISTRATOR upoważnia Procesora do żądania potwierdzenia, że przyznane uprawnienia są aktualne, i do zablokowania dostępu użytkownika, jeśli nie będzie możliwości weryfikacji uprawnień.

7.5. Odpowiedzialność za eksport i dalsze wykorzystanie danych:

7.5.1. ADMINISTRATOR jest odpowiedzialny za to, co robi z danymi osobowymi po wyeksportowaniu ich z systemu Procesora do wybranych platform (Google Sheets, Excel, Airtable, Notion itp.).

7.5.2. Procesor nie ma kontroli nad danymi, które ADMINISTRATOR wyeksportuje, ani nad tym, jak ADMINISTRATOR je przechowuje lub udostępnia.

7.5.3. ADMINISTRATOR zobowiązuje się do zgodności z RODO przy dalszym przetwarzaniu wyeksportowanych danych.

7.6. Powiadomienia o zmianach:

7.6.1. ADMINISTRATOR zobowiązuje się do niezwłocznego powiadomienia Procesora o zmianach, które mogą wpłynąć na przetwarzanie danych, w szczególności: - (a) zmiana celu przetwarzania; - (b) zmiana kategorii danych osobowych; - (c) zmiana kategorii osób fizycznych; - (d) zmiana siedziby lub adresu ADMINISTRATORA (jeśli ma wpływ na dane w systemie); - (e) zmiana Inspektora Ochrony Danych.

7.7. Praktyka bezpieczeństwa:

7.7.1. ADMINISTRATOR zobowiązuje się do stosowania bezpiecznych praktyk w wykorzystywaniu systemu: - (a) nie udostępniania hasła innym osobom (dotyczy hasła głównego konta); - (b) korzystania z silnych haseł; - (c) wylogowywania się z systemu po zakończeniu sesji (szczególnie na komputerach wspólnych); - (d) niezwłocznego powiadomienia Procesora o podejrzeniu nieautoryzowanego dostępu.

7.8. Brak obligacji Procesora wobec KSeF:

7.8.1. ADMINISTRATOR potwierdza, że odpowiada za utrzymywanie prawidłowej relacji z Krajowym Systemem e-Faktur (KSeF) i za zgodność z wymogami KSeF.

7.8.2. Procesor nie jest odpowiedzialny za: - (a) dokładność i kompletność danych pobieranych z KSeF; - (b) dostępność API KSeF (awarie, utrzymanie, limity); - (c) decyzje KSeF dotyczące ograniczenia dostępu do API, zmianę sposobu udostępniania danych, itp.; - (d) podatność Certyfikatu KSeF na kompromitację w KSeF lub innym systemie; - (e) prawidłowość wystawienia faktur przez kontrahentów ADMINISTRATORA.

§ 8. DALSZE POWIERZENIE (PODPRZETWARZAJĄCY)

8.1. Ogólne zasady:

8.1.1. ADMINISTRATOR upoważnia Procesora do powierzania przetwarzania danych osobowych podprzetwarzającym (Sub-processors) na zasadach określonych w pkt. 8.2.

8.1.2. Procesor pozostaje w pełni odpowiedzialny wobec ADMINISTRATORA za wykonywanie obowiązków przez podprzetwarzających (art. 28 ust. 4 RODO), jednakże odpowiedzialność Procesora ograniczona jest jak określono w § 15.

8.2. Zatwierdzeni podprzetwarzający:

8.2.1. Lista zatwierdzonych podprzetwarzających zawarta jest w Załączniku 2.

8.2.2. Podprzetwarzającymi są następujące kategorie dostawców: - (a) Dostawcy infrastruktury hostingowej (serwery, bazy danych, backup); - (b) Dostawcy usług sieciowych (CDN, DNS, firewall); - (c) Dostawcy usług analityki i monitorowania błędów; - (d) Dostawcy usług komunikacji (email, SMS); - (e) Dostawcy usług płatności (Stripe); - (f) Dostawcy usług związane z eksportem (API platform eksportu, jeśli ADMINISTRATOR wybrze eksport do tych platform).

8.3. Procedura zawiadomienia o zmianach podprzetwarzających:

8.3.1. Procesor powiadomi ADMINISTRATORA na piśmie (email na adres powiązany z kontem) o każdej zaplanowanej zmianie dotyczącej dodania lub usunięcia podprzetwarzającego co najmniej 14 dni przed wprowadzeniem zmiany.

8.3.2. Powiadomienie zawierać będzie informacje o: - (a) nazwie podprzetwarzającego; - (b) rodzaju przetwarzanych danych; - (c) lokalizacji przetwarzania; - (d) rodzaju gwarancji bezpieczeństwa.

8.3.3. ADMINISTRATOR ma prawo sprzeciwić się dodaniu nowego podprzetwarzającego na podstawie poważnych obaw dotyczących bezpieczeństwa przetwarzania lub zgodności z prawem.

8.3.4. Sprzeciw musi być wyrażony na piśmie w ciągu 14 dni od otrzymania powiadomienia.

8.3.5. Jeśli ADMINISTRATOR zgłosi sprzeciw: - (a) Procesor podejmie wysiłki w celu rozwiązania obaw ADMINISTRATORA; - (b) jeśli nie będzie możliwe rozwiązanie obaw, ADMINISTRATOR ma prawo rozwiązać Umowę bez naliczania kar; - (c) Procesor nie ponosi kary za rozwiązanie Umowy w wyniku sprzeciwu ADMINISTRATORA wobec podprzetwarzającego.

8.4. Umowy z podprzetwarzającymi:

8.4.1. Procesor zawiera umowy z podprzetwarzającymi na warunkach zapewniających takie same lub zbliżone poziom ochrony danych osobowych jak określony w niniejszej Umowie.

8.4.2. Procesor może na żądanie ADMINISTRATORA dostarczyć kopie umów z podprzetwarzającymi (z redakcją danych handlowych będących tajemnicą handlową) w celu weryfikacji zgodności z RODO.

8.5. Odpowiedzialność za podprzetwarzających:

8.5.1. Procesor ponosi odpowiedzialność za podprzetwarzających (art. 28 ust. 4 RODO), jednakże odpowiedzialność Procesora jest ograniczona do odpowiedzialności PROCESORA za całość przetwarzania, zgodnie z § 15 (Ograniczenie odpowiedzialności).

§ 9. PRZEKAZYWANIE DANYCH DO PAŃSTW TRZECICH

9.1. Zakaz bez gwarancji:

9.1.1. Procesor nie przekazuje danych osobowych do państw trzecich (poza Unią Europejską i Europejskim Obszarem Gospodarczym) bez wcześniejszej pisemnej zgody ADMINISTRATORA.

9.1.2. Wyjątek stanowią transfer do USA na podstawie rozwiązań prawnych zaakceptowanych przez Europejską Komisję Ochrony Danych, w szczególności: - (a) Standardowe Klauzule Umowne (Standard Contractual Clauses - SCC); - (b) Mechanizmy bezpieczeństwa zastosowane przez podprzetwarzających (np. szyfrowanie end-to-end).

9.2. Transfery techniczne (niezbędne dla świadczenia usługi):

9.2.1. Procesor informuje, że niektóre podprzetwarzające mogą być zlokalizowani w USA: - (a) Stripe — płatności (USA, ale podlegają SCC i Privacy Shield / Decipher); - (b) Sentry — monitorowanie błędów (USA, ale podlegają SCC); - (c) Resend / Mailgun — email (USA, ale podlegają SCC i GDPR DPA).

9.2.2. ADMINISTRATOR, akceptując Umowę, wyrażą zgodę na przekazanie danych niezbędnych dla realizacji tych usług na warunkach określonych w podpisanych Standardowych Klauzulach Umownych (SCC) między podprzetwarzającymi a Procesorem.

9.2.3. ADMINISTRATOR ma prawo do żądania informacji o konkretnych gwarancjach bezpieczeństwa zastosowanych w przypadku transferu do USA.

9.3. Brak transferu poza powyższe:

9.3.1. Procesor nie transferuje danych do żadnych innych państw trzecich poza wymienionymi powyżej bez uprzedniej pisemnej zgody ADMINISTRATORA.

9.3.2. Procesor informuje ADMINISTRATORA o każdym zaplanowanym transferze i gwarancjach zastosowanych, zgodnie z § 8.3 (procedura zawiadomienia).

§ 10. ŚRODKI TECHNICZNE I ORGANIZACYJNE

10.1. Zakres środków:

Szczegółowy opis wszystkich środków technicznych i organizacyjnych wdrożonych przez Procesora zawarto w Załączniku 3 (Środki techniczne i organizacyjne - TOMs).

10.2. Główne obszary:

10.2.1. Infrastruktura: - Hosting na Hetzner Online GmbH (Niemcy, ISO 27001); - Szyfrowanie danych w spoczynku (AES-256); - Szyfrowanie przesyłu (TLS 1.3); - Fizyczna ochrona infrastruktury (dostęp kontrolowany, monitoring CCTV).

10.2.2. Kontrola dostępu: - Uwierzytelnianie wielopoziomowe (MFA) dla pracowników; - Zarządzanie uprawnień (RBAC - Role-Based Access Control); - Least Privilege Principle (dostęp do minimum niezbędnych danych); - Audyt logów dostępu.

10.2.3. Integralność i dostępność: - Kopie zapasowe (daily + offsite); - Plan odzyskiwania po katastrofie (RTO < 4 godziny); - Redundancja systemu (failover, load balancing); - Testy regularności kopii zapasowych (minimum co 6 miesięcy).

10.2.4. Monitorowanie i logowanie: - Centralne logowanie zdarzeń (SIEM); - Alerty w czasie rzeczywistym (anomalia w dostępie, błędy bezpieczeństwa); - Przechowywanie logów minimum 90 dni.

10.2.5. Zarządzanie vulnerabilościami: - Regularne skanowanie podatności (weekly); - Testy penetracyjne (annually); - Patch management (críticas within 48h, normalne within 30d); - Inventory oprogramowania (SBOM - Software Bill of Materials).

10.2.6. Zarządzanie incydentami: - Plan zarządzania incydentami bezpieczeństwa; - Zespół reagowania na incydenty (Incident Response Team); - Procedury eskalacji i komunikacji (patrz § 11).

10.2.7. Szkolenia i świadomość: - Szkolenia bezpieczeństwa dla pracowników (minimum co rok); - Szkolenia dotyczące RODO i ochrony danych (minimum co rok); - Procedury sprawdzania bezpieczeństwa (background check) dla nowych pracowników.

10.2.8. Zarządzanie dostawcami: - Umowy DPA z podprzetwarzającymi; - Audyty dostawców (security assessment); - SLA dotyczące czasu pracy (uptime, RTO, RPO).

10.3. Dostęp do opisu TOMs:

Pełny, szczegółowy opis TOMs dostępny jest w Załączniku 3 i w dokumentach technicznych dostępnych na żądanie Procesora.

10.4. Zmiany w TOMs:

10.4.1. Procesor może wdrażać zmiany w TOMs na bieżąco (np. nowe narzędzia bezpieczeństwa, patches, aktualizacje) bez uprzedniej zgody ADMINISTRATORA.

10.4.2. Jeśli zmiana w TOMs wiąże się ze zmniejszeniem poziomu bezpieczeństwa, Procesor powiadomi ADMINISTRATORA z wyprzedzeniem 30 dni.

10.4.3. Proces zaktualizowanego opisu TOMs (np. poprzez Załącznik 3) będzie dostępny na żądanie.

§ 11. ZGŁASZANIE NARUSZEŃ OCHRONY DANYCH

11.1. Definicja naruszenia:

Naruszenie ochrony danych — naruszenie bezpieczeństwa, które powoduje przypadkowe lub niezamierzone zniszczenie, utraty, modyfikację, nieautoryzowane ujawnienie lub dostęp do danych osobowych przechowywanych, przesyłanych lub w inny sposób przetwarzanych (art. 33 RODO).

11.2. Obowiązek zawiadomienia:

11.2.1. Procesor zawiadomi ADMINISTRATORA niezwłocznie, ale nie później niż 48 godzin po stwierdzeniu naruszenia ochrony danych, chyba że naruszenie nie stwarza ryzyka dla praw i wolności osób fizycznych.

11.2.2. Definicja "48 godzin" w kontekście tej Umowy oznacza 48 godzin od momentu, kiedy Procesor uzyskał wiedzę o naruszeniu. Procesor nie pozostaje pod presją dostarczenia pełnego raportu w ciągu 48 godzin — informacje będą dostarczane w trakcie śledztwa.

11.2.3. Powiadomienie będzie przesłane na email powiązany z kontem ADMINISTRATORA oraz do osoby wyznaczonej jako kontakt do spraw bezpieczeństwa (jeśli wskazana).

11.3. Zawartość powiadomienia (faza 1 - wstępne):

Wstępne powiadomienie (w ciągu 48 godzin) będzie zawierać: - (a) fakt naruszenia (co się stało - ogólny opis); - (b) kategorie danych, których dotyczy naruszenie; - (c) liczba osób fizycznych, której mogą dotyczyć (jeśli znana); - (d) możliwe skutki naruszenia; - (e) działania podjęte przez Procesora (zawezwanie, zabezpieczanie); - (f) kontakt osoby do kontaktu w razie pytań.

11.4. Zawartość raportu (faza 2 - pełna):

W miarę postępu śledztwa, Procesor dostarczy pełny raport zawierający: - (a) dokładny opis naruszenia (jak doszło, kiedy, skąd wiadomo); - (b) root cause analysis (przyczyna pierwotna); - (c) szczegółową listę osób, których danych dotyczy (imiona, nazwiska, kategorie danych); - (d) działania zaradcze zastosowane (zamknięcie luki, resetowanie haseł, itp.); - (e) działania zapobiegawcze na przyszłość; - (f) opinie eksperta bezpieczeństwa (jeśli przeprowadzono audyt); - (g) zalecenia dla ADMINISTRATORA.

11.5. Brak odpowiedzialności Procesora w określonych sytuacjach:

11.5.1. Procesor nie ponosi odpowiedzialności za naruszenia spowodowane: - (a) działaniami ADMINISTRATORA (np. udostępnieniem hasła innej osobie); - (b) działaniami pracownika ADMINISTRATORA (np. włamaniem się pracownika do konta); - (c) brakiem zgodności ADMINISTRATORA z instrukcjami bezpieczeństwa Procesora; - (d) brakiem wdrożenia przez ADMINISTRATORA zaleceń Procesora (np. włączenie MFA); - (e) atakami (ataki brute force, phishing, social engineering) jeśli ADMINISTRATOR nie zastosował zaleceń Procesora; - (f) atakami dokonywanymi przez podprzetwarzających, jeśli Procesor wybrał podprzetwarzającego w dobrej wierze i zawrze z nim umowę DPA.

11.6. Współpraca w zakresie notyfikacji:

11.6.1. ADMINISTRATOR jest odpowiedzialny za notyfikację naruszenia do Inspektora Ochrony Danych i osób, których danych dotyczy, w terminie wymaganym przez RODO (art. 33-34).

11.6.2. Procesor udzieli ADMINISTRATOROWI wszelkiej niezbędnej pomocy w przygotowaniu zawiadomienia, w tym poprzez dostarczenie szczegółowych informacji o naruszeniu.

11.6.3. Procesor może żądać, aby ADMINISTRATOR wcześniej uzgodnił wersję publicznego powiadomienia, jeśli naruszenie ma być publiczne (media, komunikat prasowy), aby zapewnić dokładność faktów opisywanych.

11.7. Tajemnica śledztwa:

11.7.1. Zawartość raportu o naruszeniu jest poufna i stanowi tajemnicę handlową Procesora.

11.7.2. ADMINISTRATOR nie będzie ujawniać szczegółów technicznych naruszenia, przyczyn, czy informacji o bezpieczeństwa Procesora w publicznych komunikatach bez zgody Procesora.

11.7.3. ADMINISTRATOR może ujawnić fakty naruszenia w komunikatach prawnych i do urzędów, ale powinien ograniczyć ujawnianie szczegółów technicznych.

§ 12. POMOC ADMINISTRATOROWI

12.1. Obowiąż pomocnicze Procesora:

Procesor udzieli ADMINISTRATOROWI niezbędnej pomocy technicznej i organizacyjnej w:

12.1.1. Realizacja praw osób fizycznych — Procesor pomaga ADMINISTRATOROWI w realizacji praw osób fizycznych wynikających z RODO: - (a) Prawo dostępu do danych (art. 15 RODO); - (b) Prawo do sprostowania danych (art. 16 RODO); - (c) Prawo do usunięcia danych (art. 17 RODO) — "prawo do bycia zapomnianym"; - (d) Prawo do ograniczenia przetwarzania (art. 18 RODO); - (e) Prawo do przenoszenia danych (art. 20 RODO).

12.1.2. Procedura: ADMINISTRATOR przesyła żądanie osoby fizycznej do Procesora wraz z weryfikacją tożsamości. Procesor ma 10 dni roboczych na wdrożenie żądania (chyba że żądanie jest zbyt skomplikowane).

12.1.3. Koszty: Procesor udzieli pomocy bezpłatnie dla żądań uzasadnionych i stanowiących część normalnej realizacji usługi. Jeśli żądanie jest nadmiernie skomplikowane (np. wymaga ręcznego przeanalizowania całego archiwum), Procesor może żądać refundacji kosztów (w wysokości uzasadnionej).

12.1.4. Realizacja praw osoby fizycznej (np. dostarczenie danych) odbywać się będzie za pośrednictwem ADMINISTRATORA — Procesor nie będzie kontaktować się bezpośrednio z osobą fizyczną.

12.2. Współpraca w ocenie skutków (DPIA):

12.2.1. Procesor zapewni ADMINISTRATOROWI informacje niezbędne do przeprowadzenia oceny skutków przetwarzania danych dla ochrony osób fizycznych (Data Protection Impact Assessment - DPIA, art. 35 RODO).

12.2.2. Informacje będą zawierać: - (a) charakterystykę przetwarzania; - (b) zastosowane środki techniczne i organizacyjne; - (c) ryzyka związane z przetwarzaniem; - (d) procedury zarządzania incydentami; - (e) plany dla przypadku naruszenia.

12.3. Inspekcja i audyt:

Prawo do inspekcji i audytu określone w § 13.

12.4. Pozostała pomoc:

12.4.1. Procesor, w ramach rozsądnego zakresu, udzielać będzie ADMINISTRATOROWI pomocy w innych sprawach związanych z bezpieczeństwem danych osobowych lub realizacją RODO.

12.4.2. Pomoc świadczona będzie w oparciu o dostępne zasoby, a Procesor może żądać dodatkowego wynagrodzenia za pomoc poza zakresem standardowego wsparcia.

§ 13. PRAWO DO AUDYTU

13.1. Prawo ADMINISTRATORA do audytu:

13.1.1. ADMINISTRATOR ma prawo do audytu bezpieczeństwa i zgodności procedur Procesora z niniejszą Umową i RODO (art. 28 ust. 3 lit. h RODO).

13.1.2. Audyt może być przeprowadzony osobiście przez ADMINISTRATORA lub przez audytora (Podwykonawcę) wyznaczonego przez ADMINISTRATORA (np. firma audytu bezpieczeństwa, biegły sądowy, doradca GDPR).

13.2. Procedura audytu:

13.2.1. ADMINISTRATOR zobowiązany jest do złożenia pisemnego wniosku o audyt co najmniej 30 dni przed planowanym audytem.

13.2.2. Wniosek musi zawierać: - (a) zakres audytu (obszary do sprawdzenia); - (b) imiona i nazwiska osób przeprowadzających audyt; - (c) proponowaną datę i godzinę; - (d) szacunkowy czas trwania.

13.2.3. Procesor ma prawo do zaproponowania alternatywnej daty, jeśli zaproponowana data koliduje z już zaplanowanym audytem lub pracami obsługi systemu.

13.2.4. Audyt będzie przeprowadzony w porze roboczych (9:00-17:00 CET, poniedziałek-piątek).

13.3. Limity audytu:

13.3.1. ADMINISTRATOR ma prawo do przeprowadzenia maksymalnie jednego audytu na rok w ramach normalnych operacji, chyba że: - (a) zachodzi podejrzenie naruszenia bezpieczeństwa; - (b) Inspektor Ochrony Danych przeprowadza śledztwo; - (c) ADMINISTRATOR ma wiarygodne dowody zagrożenia bezpieczeństwa.

13.3.2. W przypadkach wymienionych powyżej, audyt dodatkowy może być przeprowadzony poza límitem rocznym, ale do jednego audytu dodatkowego na rok.

13.4. Koszty audytu:

13.4.1. Audyt w ramach harmonogramu (raz na rok): Procesor będzie wspierać audyt poprzez dostarczenie dokumentacji, informacji o TOMs, logów, i dostęp do systemu. Koszty wsparcia (czas pracownika) pokrywane są przez Procesora do 8 godzin roboczych. Dodatkowe godziny będą rachmowane ADMINISTRATOROWI po stawce 200 PLN/godzinę.

13.4.2. Audyty dodatkowe: Koszty wsparcia pokrywane są przez ADMINISTRATORA od pierwszej godziny (200 PLN/godzinę).

13.4.3. Koszty audytora: Koszty wynagrodzenia audytora (firmy audytu) nosi ADMINISTRATOR.

13.5. Alternatywa — Raporty trzecich stron:

13.5.1. Zamiast przeprowadzania audytu, ADMINISTRATOR może żądać, aby Procesor dostarczył: - (a) Raport SOC2 Type II (System and Organization Controls); - (b) Raport ISO 27001 (certyfikat); - (c) Raport bezpieczeństwa przygotowany przez audytora bezpieczeństwa trzeciej strony.

13.5.2. Procesor zobowiązuje się do utrzymywania certyfikacji ISO 27001 lub SOC2 (w zależności od dostępności) dla infrastruktury hostingowej (Hetzner) oraz do dostarczenia ADMINISTRATOROWI kopii raportów na żądanie.

13.5.3. ADMINISTRATOR może zaspokoić wymóg audytu poprzez zaakceptowanie raportu SOC2 Type II lub ISO 27001 zamiast przeprowadzania audytu na miejscu.

13.5.4. Procedura żądania raportu: - (a) ADMINISTRATOR zgłasza żądanie na piśmie; - (b) Procesor dostarcza raport w ciągu 10 dni roboczych (jeśli jest dostępny) lub wskazuje datę dostępności; - (c) Raport jest poufny i może być wykorzystywany wyłącznie przez ADMINISTRATORA i jego doradców w celu oceny zgodności.

13.6. Poufność audytu:

13.6.1. Osoby przeprowadzające audyt zobowiązane są do podpisania umowy poufności (NDA) — Procesor dostarcza szablon.

13.6.2. Wyniki audytu stanowią poufne informacje handlowe Procesora i nie mogą być ujawnianych stronom trzecim bez zgody Procesora.

13.6.3. ADMINISTRATOR może ujawnić wyniki audytu regulacyjnym (np. Inspektorowi Ochrony Danych) jeśli wymaga tego organ publiczny.

13.7. Dostęp do systemu:

13.7.1. W trakcie audytu, ADMINISTRATOR będzie miał dostęp do: - (a) Dokumentacji dotyczącej TOMs; - (b) Logów systemu (jeśli możliwe bez dostępu do danych wrażliwych innych klientów); - (c) Procedur bezpieczeństwa; - (d) Umów z podprzetwarzającymi (redakcja danych handlowych); - (e) Raportów o incydentach bezpieczeństwa dotyczących ADMINISTRATORA.

13.7.2. Audytor nie będzie miał dostępu do: - (a) Danych osobowych innych klientów; - (b) Kodu źródłowego aplikacji (chyba że bezpośrednio związany z bezpieczeństwem danych ADMINISTRATORA); - (c) Umów z innymi klientami.

§ 14. USUNIĘCIE LUB ZWROT DANYCH

14.1. Okres przechowywania po wygaśnięciu Umowy:

14.1.1. Po wygaśnięciu lub rozwiązaniu Umowy Głównej, Procesor będzie przetwarzać dane osobowe wyłącznie w celu: - (a) usunięcia danych (jeśli ADMINISTRATOR tak żąda); - (b) zwrotu danych ADMINISTRATOROWI (jeśli ADMINISTRATOR żąda); - (c) spełnienia obowiązków wynikających z prawa (patrz pkt. 14.2).

14.1.2. ADMINISTRATOR ma prawo do wyboru jednej z opcji: - (Opcja A) Usunięcie danych — Procesor usuwa wszystkie dane osobowe w ciągu 30 dni od wygaśnięcia Umowy; - (Opcja B) Zwrot danych — Procesor dostarcza ADMINISTRATOROWI eksport danych w formacie CSV/JSON w ciągu 30 dni od wygaśnięcia Umowy; - (Opcja C) Przedłużenie dostępu — ADMINISTRATOR płaci dodatkową opłatę za przedłużenie dostępu do danych w systemie (wycena indywidualna).

14.2. Wyjątki od obowiązku usunięcia (przechowywanie wymagane prawem):

14.2.1. Procesor może przechowywać dane osobowe dłużej niż 30 dni w następujących przypadkach:

(a) Obowiązki podatkowe i rozliczeniowe: - Faktury, rejestry przetwarzania, logi operacji związanych z rozliczeniami — przechowywane na warunkach przepisów o podatku od towarów i usług (VAT) oraz podatku dochodowego (minimum 5 lat od końca roku, w którym operacja miała miejsce).

(b) Obowiązki księgowe: - Ksiąg przychodów i rozchodów (JPK), rejestry rachunkowe — przechowywane zgodnie z ustawą o rachunkowości (minimum 5 lat).

(c) Logi bezpieczeństwa: - Logi dostępu, logi operacji wrażliwych niezbędne do badania zdarzeń bezpieczeństwa — przechowywane do 1 roku od wygaśnięcia Umowy (w przypadku podejrzenia naruszenia — do czasu zamknięcia postępowania).

(d) Wykonalność roszczeń: - Dane niezbędne do dochodzenia roszczeń (np. dane do faktury, jeśli istnieje spór z ADMINISTRATOREM) — przechowywane do 3 lat od wygaśnięcia Umowy.

(e) Postępowania sądowe i administracyjne: - Dane niezbędne dla obrony Procesora w postępowaniu sądowym lub administracyjnym — przechowywane do zakończenia postępowania plus 3 lata.

(f) Decyzje organów publicznych: - Dane objęte zakazem usunięcia przez organ publiczny (np. Inspektor Ochrony Danych, prokuratura) — przechowywane do czasu zniesienia zakazu.

14.3. Procedura usunięcia/zwrotu:

14.3.1. ADMINISTRATOR musi wysłać pisemne (email) polecenie usunięcia lub zwrotu danych w ciągu 60 dni od wygaśnięcia Umowy. Po upływie 60 dni, Procesor może automatycznie usunąć dane bez dalszego powiadomienia.

14.3.2. Dla usunięcia: - Procesor usuwa wszystkie dane w ciągu 30 dni; - Dane usuwane są za pomocą metod nieodwracalnych (bezpieczne wymazywanie, niszczenie); - Procesor potwierdza na piśmie wykonanie usunięcia.

14.3.3. Dla zwrotu: - Procesor dostarcza eksport wszystkich danych w formacie CSV lub JSON; - Eksport wysyłany jest za pośrednictwem bezpiecznego kanału (SFTP, gwarantowana linku do pobrania z zabezpieczeniem); - ADMINISTRATOR ma 30 dni na pobranie danych; po upływie tego okresu, linki tracą ważność i Procesor usuwa dane automatycznie.

14.4. Brak obowiązku dla kopii zapasowych:

14.4.1. Procesor nie jest zobowiązany do usunięcia danych z kopii zapasowych w ciągu 30 dni, jeśli usunięcie wiąże się z dużymi nakładami technicznymi.

14.4.2. Dane w kopiach zapasowych będą usunięte podczas normalnego cyklu retencji kopii zapasowych (maksymalnie 90 dni od wygaśnięcia Umowy).

14.5. Brak odpowiedzialności za dane wywiezione przez ADMINISTRATORA:

14.5.1. ADMINISTRATOR jest odpowiedzialny za dane, które wyeksportował z systemu Procesora (do Google Sheets, Excel, Airtable, itp.). Procesor nie ponosi odpowiedzialności za usunięcie tych danych z platform eksportu.

14.5.2. Jeśli ADMINISTRATOR chce usunąć dane z platform eksportu, musi to uczynić samodzielnie.

§ 15. ODPOWIEDZIALNOŚĆ I OGRANICZENIE ODPOWIEDZIALNOŚCI

15.1. Odpowiedzialność Procesora:

15.1.1. Procesor odpowiada ADMINISTRATOROWI za szkody powstałe w wyniku naruszenia zobowiązań wynikających z niniejszej Umowy i RODO (art. 82 RODO).

15.1.2. Procesor odpowiada również za działania podprzetwarzających, jednakże na zasadach określonych w pkt. 15.3.

15.2. Ograniczenie odpowiedzialności Procesora:

15.2.1. CAP ODPOWIEDZIALNOŚCI (Limit odpowiedzialności):

Całkowita odpowiedzialność Procesora wobec ADMINISTRATORA z jakiejkolwiek przyczyny (naruszenie umowy, tort, nieuczciwość konkurencja, itp.) wynosi maksymalnie 12 miesięcy opłat, które ADMINISTRATOR zapłacił Procesorowi w ciągu 12 miesięcy przed zdarzeniem wywołującym odpowiedzialność.

Przykład: Jeśli ADMINISTRATOR płacił 100 PLN/miesiąc przez 12 miesięcy (łącznie 1200 PLN), maksymalna odpowiedzialność Procesora wynosi 1200 PLN.

15.2.2. WYŁĄCZENIE SZKÓD WTÓRNYCH I KONSEKWENCYJNYCH:

Procesor nie odpowiada ADMINISTRATOROWI za: - (a) Straty na zysku (lost profits); - (b) Utratę przychodów; - (c) Utratę danych (poza danymi będącymi przedmiotem niniejszej Umowy); - (d) Utratę szans biznesowych; - (e) Zadośćuczynienie moralne lub reputacyjne; - (f) Szkody pośrednie, przypadkowe, specjalne lub konsekwencyjne; - (g) Koszty postępowania sądowego poza ADMINISTRATOREM (np. koszty odprawy pracowników, wznowienia biznesu).

15.2.3. Ograniczenie odpowiedzialności stosuje się nawet, jeśli Procesor został uprzedzony o możliwości takich szkód.

15.3. Odpowiedzialność za podprzetwarzających:

15.3.1. Procesor pozostaje odpowiedzialny ADMINISTRATOROWI za działania podprzetwarzających (art. 28 ust. 4 RODO).

15.3.2. Jednakże odpowiedzialność Procesora za podprzetwarzających ograniczona jest do odpowiedzialności całkowitej Procesora określonej w pkt. 15.2.1 — limit nie jest podwajany ani nie jest multiplikowany.

15.3.3. Jeśli naruszenie spowodowane przez podprzetwarzającego powstałoby z powodu braku nadzoru lub braku kontroli Procesora, Procesor ponosi pełną odpowiedzialność (nie stosuje się limitu). Jeśli naruszenie spowodowane jest winą podprzetwarzającego mimo rozsądnych wysiłków nadzoru Procesora, limit stosuje się w normalny sposób.

15.4. Wyłączenie odpowiedzialności Procesora:

Procesor nie ponosi odpowiedzialności za:

15.4.1. Działania ADMINISTRATORA: - (a) Naruszenia wynikające z instrukcji ADMINISTRATORA (jeśli instrukcja była niezgodna z RODO, odpowiedzialność ponosi ADMINISTRATOR); - (b) Naruszenia wynikające z niewykonania przez ADMINISTRATORA obowiązków wynikających z § 7 (obowiązki ADMINISTRATORA); - (c) Naruszenia wynikające z niedostarczenia przez ADMINISTRATORA wymaganych informacji; - (d) Naruszenia wynikające z działań pracowników lub współpracowników ADMINISTRATORA (np. udostępnienie hasła).

15.4.2. Dane pobierane z KSeF: - (a) Nieprawdziwość, niekompletność, nieaktualność danych otrzymywanych z KSeF; - (b) Błędy, omyłki lub oszustwa popełnianych przez kontrahentów ADMINISTRATORA (wystawcy faktur); - (c) Niedostępność API KSeF, ograniczenia, awarie, zmiany w strukturze danych KSeF; - (d) Brak autoryzacji ADMINISTRATORA do pobrania określonych faktur z KSeF; - (e) Naruszenia bezpieczeństwa w samym systemie KSeF (MF).

15.4.3. Certyfikat KSeF: - (a) Kompromitacja Certyfikatu KSeF w wyniku działań ADMINISTRATORA lub nieprzestrzegania zasad bezpieczeństwa; - (b) Wygaśnięcie Certyfikatu KSeF; - (c) Unieważnienie Certyfikatu przez organ wydający; - (d) Naruszenia bezpieczeństwa w infrastrukturze KSeF lub MF.

15.4.4. Działania sił wyższych (force majeure): - (a) Katastrofy naturalne (trzęsienia ziemi, powodzie); - (b) Atak terrorystyczny, walka zbrojne; - (c) Decyzje organów publicznych (embargo, blokada, zawieszenie usług); - (d) Przerwy w dostawie energii elektrycznej poza kontrolą Procesora; - (e) Ataki DDoS lub cyber o skali nieprzypadkowej dla sektora.

15.4.5. Export do platform trzecich: - Procesor nie odpowiada za sposób, w jaki ADMINISTRATOR wykorzystuje dane po wyeksportowaniu do Google Sheets, Excel, Airtable, itp.; - Procesor nie odpowiada za bezpieczeństwo danych na tych platformach (odpowiada za to dostawca platformy); - Procesor nie odpowiada za naruszenia GDPR wynikające z działań ADMINISTRATORA po eksporcie.

15.5. Odszkodowanie ze strony ADMINISTRATORA wobec Procesora:

15.5.1. ADMINISTRATOR zobowiązuje się do odszkodowania Procesora za straty wynikające z: - (a) Naruszenia przez ADMINISTRATORA postanowień niniejszej Umowy; - (b) Naruszenia przez ADMINISTRATORA obowiązków wynikających z RODO; - (c) Roszczenia osób trzecich wynikające z działań ADMINISTRATORA; - (d) Roszczenia wynikające z instrukcji wydanej przez ADMINISTRATORA niezgodnej z RODO.

15.6. Brak zmiany limitu przez umowy trzecie:

Żadna umowa między ADMINISTRATOREM a trzecimi podmiotami (np. umowa z pracownikami, partnerami biznesowymi) nie może narzucić na Procesora odpowiedzialności przekraczającej limit określony w pkt. 15.2.1. Procesor nie będzie kierować roszczeń wobec ADMINISTRATORA na podstawie takich umów.

§ 16. POUFNOŚĆ

16.1. Obowiązek poufności:

16.1.1. Procesor zobowiązuje się do zachowania poufności danych osobowych i informacji dotyczących ADMINISTRATORA, do których dostęp uzyska w wyniku przetwarzania lub wykonywania niniejszej Umowy.

16.1.2. Obowiązek poufności dotyczy również pracowników, podwykonawców i podprzetwarzających Procesora.

16.2. Wyjątki od obowiązku poufności:

16.2.1. Procesor może ujawnić informacje poufne w następujących przypadkach: - (a) Na żądanie organu publicznego, sądu lub organów ścigania (organ publiczny musi dostarczyć zatwierdzenie sądowe lub nakaz); - (b) W celu obrony Procesora przed powództwami lub roszczeniami (np. w postępowaniu sądowym); - (c) Pracownikom i podwykonawcom Procesora, którym dostęp jest niezbędny dla wykonywania funkcji zawodowych (pod warunkiem zachowania przez nich poufności); - (d) Audytorom i doradcom prawnym Procesora (pod warunkiem NDA); - (e) Organom zajmującym się bezpieczeństwem publicznym, jeśli jest to wymagane przez prawo (np. poszukiwanie przestępcy).

16.3. Powiadomienie o żądaniu ujawnienia:

16.3.1. Jeśli organ publiczny żąda ujawnienia poufnych informacji ADMINISTRATORA, Procesor będzie starać się powiadomić ADMINISTRATORA o takim żądaniu, chyba że prawo zabrania ujawnienia (np. postępowanie karne).

16.4. Ochrona tajemnic handlowych Procesora:

16.4.1. Niniejsza Umowa stanowi tajemnicę handlową Procesora. ADMINISTRATOR zobowiązuje się do nieujawniania postanowień Umowy publice bez zgody Procesora.

16.4.2. Wyjątkiem jest ujawnianie postanowień w celach prawnych (np. Inspektor Ochrony Danych, biegły sądowy, doradca prawny).

§ 17. POSTANOWIENIA KOŃCOWE

17.1. Tożsamość obu stron:

17.1.1. Niniejsza Umowa zawarta jest między: - Procesorem: ANTENA Sp. z o.o., NIP: 9581754603; - Administratorem: podmiot wymieniony w Umowie Głównej.

17.1.2. Każda ze Stron potwierdza, że jest uprawniona do zawarcia Umowy.

17.2. Łączność z Umową Główną:

17.2.1. Niniejsza Umowa jest integralnym aneksem do Umowy Głównej zawartej między Stronami.

17.2.2. W przypadku konfliktu między postanowieniami Umowy Głównej a niniejszą Umową, zastosowanie mają postanowienia Umowy specjalistycznej (tj. niniejszej Umowy DPA), o ile nie stanowi to naruszenia RODO.

17.2.3. Postanowienia Umowy Głównej nie mogą ograniczać lub zmieniać uprawnienia ADMINISTRATORA i obowiązków Procesora wynikające z RODO.

17.3. Zmiana Umowy:

17.3.1. Niniejszą Umowę mogą zmienić warunki obowiązujące lub wymagane przez prawo (RODO, przepisy krajowe).

17.3.2. Każda zmiana Umowy wymagająca zgodnie z RODO dodatkowej zgody ADMINISTRATORA będzie dokonywana za pośrednictwem notyfikacji na email z co najmniej 30-dniowym okresem wypowiedzenia.

17.3.3. Jeśli ADMINISTRATOR nie wyrazi sprzeciwu w ciągu 30 dni, zmianę uważa się za zaakceptowaną.

17.3.4. Jeśli ADMINISTRATOR nie zaakceptuje zmian, ma prawo do rozwiązania Umowy bez kar.

17.4. Okres obowiązywania:

17.4.1. Niniejsza Umowa obowiązuje od dnia zawarcia Umowy Głównej i trwa, dopóki trwa Umowa Główna.

17.4.2. Po wygaśnięciu Umowy Głównej, postanowienia dotyczące ochrony danych (szczególnie § 14 dotyczący usunięcia/zwrotu danych) pozostają w mocy.

17.5. Rozwiązanie Umowy:

17.5.1. Umowa rozwiązuje się z dniem rozwiązania Umowy Głównej.

17.5.2. Rozwiązanie Umowy nie wpływa na obowiązki ochrony danych i poufności, które pozostają w mocy (patrz § 16).

17.6. Osoby uprawnione do kontaktu:

17.6.1. Ze strony Procesora: - Inspektor Ochrony Danych: kontakt@ksefimport.pl - Kontakt handlowy: kontakt@ksefimport.pl - Kontakt techniczny (support): kontakt@ksefimport.pl

17.6.2. Ze strony ADMINISTRATORA: - Kontakt określony w Umowie Głównej lub wskazany przez ADMINISTRATORA na piśmie.

17.7. Prawo właściwe i rozstrzyganie sporów:

17.7.1. Niniejsza Umowa podlegać będzie prawu Rzeczypospolitej Polskiej.

17.7.2. Wszelkie spory wynikające z niniejszej Umowy rozstrzygane będą przed sądami powszechnymi właściwymi dla siedziby Procesora (Gdynia).

17.7.3. W przypadku sporu dotyczącego RODO, miarodajne będą przepisy RODO i prawo krajowe wynikające z transpozycji dyrektywy RODO do prawa polskiego.

17.8. Wiążące części Umowy:

17.8.1. Jeśli jakakolwiek część niniejszej Umowy będzie uchylona przez sąd jako niezgodna z prawem, pozostałe postanowienia Umowy pozostają w mocy.

17.8.2. Wyjątkiem jest sytuacja, w której uchylenie postanowienia spowodowałoby istotną zmianę zakresu przetwarzania — w takim przypadku strony będą negocjować zmianę Umowy.

17.9. Całość porozumienia:

17.9.1. Niniejsza Umowa wraz z załącznikami stanowi całość porozumienia stron w kwestii przetwarzania danych osobowych.

17.9.2. Żaden list, umowa ustna, czy inne porozumienie nie modyfikuje niniejszej Umowy, chyba że zostało ono sporządzone na piśmie i podpisane przez obie Strony.

17.10. Brak obowiązku do wzajemnego wznowienia:

17.10.1. Niniejsza Umowa nie obowiązuje żaden ze Stron do wznawiania świadczeń po wygaśnięciu Umowy Głównej. Wznowienie wymaga nowej umowy, zgodnie z procedurą handlową Procesora.

ZAŁĄCZNIKI

ZAŁĄCZNIK 1: Szczegółowy opis przetwarzania danych osobowych

1. Cele przetwarzania

Świadczenie usług KSeF Import (pobieranie faktur z KSeF, eksport do platform wybranych przez ADMINISTRATORA)
Utrzymanie infrastruktury i bezpieczeństwa systemu
Rozliczenia podatkowe i księgowe (VAT, podatek dochodowy)
Badanie anomalii i zapobieganie oszustwom

2. Kategorie danych osobowych przetwarzanych

Kategoria danych	Źródło	Cel przetwarzania	Okres przechowywania
Imiona, nazwiska kontrahentów	Faktury z KSeF	Eksport do systemów ADMINISTRATORA	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Adresy siedziby/zamieszkania	Faktury z KSeF	Eksport do systemów ADMINISTRATORA	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Numery NIP	Faktury z KSeF	Eksport do systemów ADMINISTRATORA, walidacja KSeF	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Numery REGON	Faktury z KSeF	Eksport do systemów ADMINISTRATORA	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Numery identyfikacyjne zagraniczne	Faktury z KSeF	Eksport do systemów ADMINISTRATORA	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Dane transakcyjne (kwoty, daty, opisy)	Faktury z KSeF	Eksport do systemów ADMINISTRATORA	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Adresy e-mail, numery telefonów	Faktury z KSeF	Eksport do systemów ADMINISTRATORA, komunikacja	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Email użytkownika ADMINISTRATORA	Rejestracja konta	Komunikacja, potwierdzenie tożsamości, przywracanie dostępu	Do 30 dni po wygaśnięciu Umowy (wyjątek: VAT do 5 lat)
Hasło (hash) użytkownika	Rejestracja konta	Autentykacja użytkownika	Do 30 dni po wygaśnięciu Umowy
Historia logowania (IP, user agent, czas)	Logowanie do systemu	Monitorowanie bezpieczeństwa, badanie anomalii	90 dni (wyjątek: do 1 roku w przypadku podejrzenia naruszenia)
Logi operacji w systemie	Wykorzystywanie funkcji	Audyt, bezpieczeństwo, wsparcie techniczne	90 dni (wyjątek: do 1 roku w przypadku problemu)
Certyfikat KSeF (.p12)	Powierzenie przez ADMINISTRATORA	Autentykacja wobec API KSeF, pobieranie faktur	Do momentu usunięcia przez ADMINISTRATORA (najdłużej do 30 dni po wygaśnięciu Umowy)

3. Kategorie osób fizycznych, których dotyczą dane

Pracownicy Procesora (dostęp do infrastruktury systemu)
Kontrahenci (dostawcy, odbiorcy) ADMINISTRATORA widoczni na fakturach
Osoby fizyczne prowadzące działalność gospodarczą
Pracownicy ADMINISTRATORA posiadający dostęp do systemu KSeF Import
Pracownicy kontrahentów ADMINISTRATORA (jeśli widoczni na fakturach jako osoby kontaktowe)

4. Rodzaje operacji przetwarzania

Pobieranie danych z API KSeF (SELECT)
Zapisywanie danych w bazie danych Procesora (INSERT)
Przechowywanie danych w bazie (STORE)
Szyfrowanie/deszyfrowanie danych (Certyfikatu KSeF)
Eksport danych do platform wybranych przez ADMINISTRATORA (SELECT + transmisja)
Tworzenie kopii zapasowych (Copy)
Usuwanie danych (DELETE)
Czytanie logów (SELECT na logach)

5. Narzędzia techniczne do przetwarzania

Aplikacja webowa KSeF Import (Python, FastAPI)
Baza danych PostgreSQL
System kopii zapasowych (GPG-encrypted)
System logowania zdarzeń (centralized logging)
API KSeF (Ministerstwo Finansów)
Platformy eksportu (Google Sheets, Excel, CSV, itp.)

6. Transfery danych

Transfer do infrastruktury Hetzner Online GmbH (Niemcy, EU) — hosting;
Transfer do podprzetwarzających (patrz Załącznik 2);
Transfer do ADMINISTRATORA (eksport na żądanie).

ZAŁĄCZNIK 2: Lista zatwierdzonych podprzetwarzających

Podprzetwarzający zatwierdzona do wdrażania:

Lp.	Nazwa podprzetwarzającego	Funkcja	Lokalizacja	Kategorie danych	DPA / SCC	Notatki
1	Hetzner Online GmbH	Hosting infrastruktury (serwery, baza danych, backup)	Niemcy (Falkenstein)	Wszystkie	Tak (GDPR DPA, ISO 27001)	ISO 27001 certified
2	Cloudflare Inc.	CDN, DNS, firewall aplikacyjny (DDoS protection)	Global (SCC)	Dane dostępu (IP, user agent), logi	Tak (SCC, DPA)	Data Processing Agreement
3	Stripe Inc.	Przetwarzanie płatności (dla faktur subskrypcji)	USA (SCC)	Email (do rozliczenia), kwota płatności	Tak (PCI DSS Level 1, SCC)	Nie przetwarza danych z faktur KSeF
4	Resend	Wysyłanie emaili transakcyjnych (potwierdzenia, alerty)	USA	Email ADMINISTRATORA, tekst emaili	Tak (DPA, SCC)	GDPR DPA
5	Sentry (Functional Software, Inc.)	Monitorowanie błędów, analityka incydentów	USA	Logi błędów, stack traces, kontekst błędu	Tak (SCC, DPA)	GDPR compliant
6	Google LLC (jeśli ADMINISTRATOR wybierze eksport)	Hosting wyeksportowanych danych (Google Sheets)	USA (SCC)	Wyeksportowane dane faktury	Tak (SCC, GDPR DPA)	ADMINISTRATOR odpowiada za zgodność
7	Microsoft Corp. (jeśli ADMINISTRATOR wybierze eksport do Excel Online)	Hosting plików Excel (OneDrive / SharePoint)	USA (SCC)	Wyeksportowane dane faktury	Tak (SCC, GDPR DPA)	ADMINISTRATOR odpowiada za zgodność
8	Airtable Inc. (Faza 3, na żądanie)	Hosting tabel Airtable	USA	Wyeksportowane dane faktury	Tak (SCC, DPA)	Faza 3 — pod warunkiem
9	Notion Labs Inc. (Faza 3, na żądanie)	Hosting baz danych Notion	USA	Wyeksportowane dane faktury	Tak (SCC, DPA)	Faza 3 — pod warunkiem

Notatki:

Wszystkie podprzetwarzający podpisały umowy zawierające zapewnienia ochrony danych osobowych na poziomie co najmniej równoważnym RODO.
Podprzetwarzający z USA działają na podstawie Standardowych Klauzul Umownych (SCC) lub mechanizmów zatwierdzonych przez KE.
Dla podprzetwarzających eksportujących platformy (Google Sheets, Notion, itp.), ADMINISTRATOR odpowiada za warunki użytkowania tych platform i za ochronę danych na nich przechowywanych.
ADMINISTRATOR zostaje poinformowany o dodaniu nowego podprzetwarzającego zgodnie z § 8.3.

ZAŁĄCZNIK 3: Środki techniczne i organizacyjne (TOMs)

1. INFRASTRUKTURA I LOKALIZACJA

1.1. Hosting - Lokalizacja: Hetzner Online GmbH, Falkenstein, Niemcy (Unia Europejska) - Certyfikacja: ISO 27001:2013 - SLA: 99.9% uptime gwarantowany umową - Redundancja: Load balancing, failover automatyczny - Backup: Daily full backups + incremental backups

1.2. Sieć - Protokół transportu: TLS 1.3+ (wymuszony dla wszystkich połączeń HTTPS) - Firewall: WAF (Web Application Firewall) z Cloudflare - DDoS Protection: Cloudflare DDoS mitigation - Rate limiting: 100 req/min per user (standard), 10 req/min na /login endpoint

1.3. Bezpieczeństwo fizyczne - Dostęp do serwerów: Kontrolowany dostęp, kartami RFID - Monitoring: CCTV w całym datacenter - Klimatyzacja: Redundantna, z monitoring temperatury - Zasilanie: UPS, zasilanie z 2 niezależnych źródeł

2. SZYFROWANIE DANYCH

2.1. Szyfrowanie w spoczynku (at rest) - Certyfikat KSeF (.p12): AES-256-GCM - Klucz szyfrowania: HKDF (HMAC-based Key Derivation Function) z master_key + tenant_id - Master encryption key: Przechowywany osobno, poza bazą danych - Baza danych: PostgreSQL 16 z row-level encryption (dla wrażliwych kolumn) - Backupy: GPG 2048-bit RSA encryption

2.2. Szyfrowanie przesyłu (in transit) - Wszystkie połączenia HTTP: Wymuszony redirect na HTTPS - TLS 1.3 minimum (TLS 1.2 tylko dla starszych klientów, z ostrzeżeniem) - Perfect Forward Secrecy (PFS): Włączony - HSTS: strict-transport-security nagłówek, max-age=31536000

2.3. Haszowanie haseł - Algorytm: bcrypt - Współczynnik kosztu: minimum 12 - Salt: Generowany losowo dla każdego hasła - Brak reverse engineeringu: Niemożliwe odzyskanie hasła z hash'a

3. ZARZĄDZANIE DOSTĘPEM

3.1. Uwierzytelnianie - Logowanie: Email + hasło (bcrypt) - Sesje: Cookie-based (httponly, secure, samesite=Lax) - Session timeout: 30 minut nieaktywności - Multi-factor authentication (MFA): Dostępna dla pracowników (TOTP) - Login history: Przechowywanie logów loginów przez 90 dni

3.2. Kontrola dostępu (RBAC) - Role: Admin, User, Auditor (przyszłość) - Permissions: Granular (read, write, delete per resource) - Least Privilege: Każdy pracownik dostęp tylko do minimum niezbędnych danych - Row-Level Security (RLS): PostgreSQL RLS policy per tenant - Zmiana roli: Wymaga zatwierdzenia przez Management

3.3. Dostęp pracowników do danych - Produkcja (Production): Dostęp tylko dla on-call engineers, wymagany audit log - Stagowanie (Staging): Dostęp dla developerów + QA - Środowisko testowe (Testing): Zanonimizowane dane (fake names, obfuscated sensitive info) - Aprobacja dostępu: Wymagana dla dostępu do produkcji (minimum 2 approvals)

3.4. SSH Keys / API Keys - SSH keys: 4096-bit RSA minimum - API keys: Generated securely, rotated yearly - Stored: Hashed w bazie, nigdy w plaintext - Revocation: Natychmiastowa (działanie w ciągu minut)

4. AUDYTOWANIE I LOGOWANIE

4.1. Audit Logs (Logi audytu) - Zapisywane operacje: Upload certyfikatu, delete certyfikatu, login, logout, zmiana konfiguracji, zmiana ustawień bezpieczeństwa - Przechowywanie: Minimum 90 dni, maximum 1 rok (z wyjątkiem dłuższej retencji wymaganej prawem) - Format: JSON structured logs - Elementy logu: timestamp (ISO 8601 UTC), user_id, action, resource, result, ip_address, user_agent - Niemożliwość zmiany: Logi write-once (append-only, niemożliwe delete/update przez użytkownika)

4.2. Application Logs - Logging level: INFO (standard), DEBUG (dla troubleshooting) - Centralized logging: ELK stack (Elasticsearch, Logstash, Kibana) lub Sentry - Log retention: 30 dni (rolling retention) - Error tracking: Sentry (error aggregation + alerting)

4.3. Database Logs - Query logging: Włączone dla wrażliwych operacji (INSERT, UPDATE, DELETE) - Slow query log: Operacje powyżej 1 sekundy - Connection logging: Kto się łączy, kiedy, skąd

4.4. Security Event Logging - Failed login attempts: Logowane, alert po 5 nieudanych próbach z tego samego IP - Brute force detection: Automatyczne zablokowanie IP po 10 nieudanych loginach w 10 minut - Anomaly detection: Machine learning na logach (np. logowanie z nowego kraju w ciągu 24h)

5. MONITORING I INCIDENT RESPONSE

5.1. Monitoring systemu - Uptime monitoring: UptimeRobot (co 5 minut) - Performance monitoring: APM (Application Performance Monitoring) via Sentry - Infrastructure monitoring: Prometheus + Grafana (CPU, RAM, disk, network) - Database monitoring: Slow queries, connection pool exhaustion, disk space

5.2. Security monitoring - WAF logs: Analiza ataków (SQLi, XSS, itp.) - DDoS monitoring: Cloudflare analytics - Intrusion detection: Fail2ban (IP bans) - Vulnerability scanning: Weekly automated scans (OWASP ZAP, Snyk)

5.3. Incident Response Plan - On-call schedule: 24/7 rotation - Response time: P1 (security breach) < 1 hour, P2 (data loss) < 4 hours - Escalation: Engineer → Lead → CTO → Management - Communication: Email, Slack, phone (for critical issues) - Post-mortem: Within 48 hours (lessons learned)

5.4. Alerting - High priority: CPU > 80%, Memory > 90%, Disk > 95%, Error rate > 5% - Medium priority: Response time > 2s, Database latency > 500ms - Low priority: Warnings, deprecation notices - Alert channels: Email, Slack, SMS (for critical)

6. KOPIE ZAPASOWE I DISASTER RECOVERY

6.1. Backup strategy - Frequency: Daily full backup + hourly incremental backups - Retention: Last 7 daily backups + last 4 weekly + last 12 monthly - Encryption: GPG 2048-bit RSA + AES-256-CBC - Off-site storage: Separate datacenter (Hetzner + external provider) - Verification: Restore test monthly (validation of backup integrity)

6.2. RTO and RPO - RTO (Recovery Time Objective): < 4 hours (total downtime) - RPO (Recovery Point Objective): < 1 hour (data loss) - Test schedule: Full restore test every 6 months

6.3. Disaster Recovery Plan - Primary datacenter failure: Automatic failover to backup (DNS update within 5 minutes) - Database corruption: Restore from last known good backup - Data loss: Restore from off-site backup - Major breach: Activate IR plan (patrz § 11)

7. Development & DEPLOYMENT SECURITY

7.1. Code security - Version control: Git (GitHub, private repository) - Code review: Mandatory peer review before merge to main - Static analysis: Linting (Ruff, Black), SAST (Bandit) - Dependency scanning: Snyk (weekly scans, auto-updates for critical) - Secrets management: No secrets in code, all in .env (excluded from repo)

7.2. Deployment pipeline - CI/CD: GitHub Actions (automated tests, linting, security checks) - Staging: Pre-production environment (exact copy of production) - Canary deployment: 10% traffic to new version, monitor for errors - Rollback: Automatic rollback if error rate > 5% in 5 minutes

7.3. Access to code - Repository: Private, access via SSH keys only - Code review permissions: Lead/Senior engineers only - Production deployment: Requires minimum 2 approvals - Branch protection: Main branch cannot be force-pushed

8. SZKOLENIA I ŚWIADOMOŚĆ BEZPIECZEŃSTWA

8.1. Szkolenia personelu - Onboarding: Security training dla wszystkich nowych pracowników (8h) - Annual refresher: Obowiązkowe szkolenie raz na rok (4h) - GDPR training: Focused training dla zespołu przetwarzającego dane (4h) - Phishing awareness: Symulacje phishingu co 3 miesiące

8.2. Polityki bezpieczeństwa - Acceptable Use Policy (AUP): Wymagane zaakceptowanie przez pracownika - Password policy: Minimum 12 characters, uppercase, lowercase, number, special char - Device policy: Company devices only (no BYOD for production access) - NDA: Signed by all employees and contractors - Background check: For employees with access to production

8.3. Incident response training - Table-top exercises: Quarterly simulations of security incidents - Role clarity: Clear roles in incident response (technical lead, communications, management)

9. ZARZĄDZANIE DOSTAWCAMI (VENDOR MANAGEMENT)

9.1. Vendor assessment - Initial assessment: Security questionnaire, SOC2/ISO 27001 review - Annual re-assessment: Updated questionnaire, audits if needed - Risk scoring: High/Medium/Low based on data sensitivity + vendor security posture

9.2. Contracts - DPA requirement: All vendors must sign Data Processing Agreement - SLA: Uptime, response time, RTO/RPO defined in contract - Termination clause: 30-day notice to migrate to alternative vendor

9.3. Vendor monitoring - Performance: Monthly review of SLA compliance - Security: Annual re-assessment, incident tracking - Financial: Monitoring of vendor stability (news, regulatory filings)

10. COMPLIANCE & CERTIFICATIONS

10.1. Standards adherence - GDPR: Full compliance with Regulation (EU) 2016/679 - ISO 27001: Infrastructure (Hetzner) certified; application roadmap for 2025 - PCI DSS: Not applicable (no credit card storage); Stripe handles payments - SOC2 Type II: Target for 2025 (current: Type II equivalent through Hetzner)

10.2. Regular audits - Internal audits: Quarterly (controls, policies, procedures) - External audits: Annual penetration test - Vulnerability assessment: Quarterly automated scans

10.3. Documentation - Security policies: Documented and version-controlled - Procedures: Step-by-step guides for security operations - Incident logs: Centrally stored, indexed for analysis - Training records: Proof of completion

PODPISY STRON

PROCESOR:

ANTENA Sp. z o.o.

Data: ____

Imię i nazwisko osoby upoważnionej: ____

Podpis: ____

ADMINISTRATOR:

[Nazwa i adres ADMINISTRATORA z Umowy Głównej]

Data: ____

Imię i nazwisko osoby upoważnionej: ____

Podpis: ____

KONIEC UMOWY POWIERZENIA PRZETWARZANIA DANYCH OSOBOWYCH

Dokument przygotowany: 2026-03-07 Wersja: 1.0 Obowiązywanie: Z dniem zawarcia Umowy Głównej