tel. +48 730 000 481 e-mail: bok@orbis-software.pl

Integracja systemów a RODO – jak zapewnić zgodność z polskimi przepisami

Dla kogo jest ten artykuł?

Ten przewodnik powstał z myślą o zespołach IT, operacyjnych i Inspektorach Ochrony Danych w firmach e-commerce. Przez 12 lat realizacji ponad 500 projektów integracyjnych widzieliśmy te same błędy w dziesiątkach firm. Ten artykuł to destylacja praktycznej wiedzy – pokazujemy, jak projektować i utrzymywać integracje (ERP/WMS/PIM/OMS ↔ e-commerce, płatności, kurierzy, BI) w zgodzie z RODO.

Kluczowa zmiana w 2025: 3 września Sąd UE podtrzymał ważność EU–US Data Privacy Framework, co stabilizuje transfery danych do USA. To dobra wiadomość dla firm korzystających z amerykańskich dostawców.

1. Gdzie w integracjach najczęściej „wycieka" RODO – mapa ryzyka

Po 500+ wdrożeniach widzimy te same punkty zapalne:

Payloady API z nadmiarem danych

Przykład z życia: jeden z naszych klientów przekazywał do kuriera pełne adresy wraz z NIP-ami i telefonami, choć do wygenerowania listu przewozowego wystarczył ID zamówienia. Każde dodatkowe pole to dodatkowe ryzyko.

Rozwiązanie: Audyt mapowania danych w integracjach – sprawdź, czy każde pole jest absolutnie niezbędne.

Logi i monitoring z danymi osobowymi

E-maile, numery telefonów, tokeny sesji w logach aplikacyjnych. Problem pogłębia się, gdy logi trafiają do zewnętrznych systemów monitoringu.

Rozwiązanie: Logging oparty o identyfikatory techniczne, automatyczne maskowanie PII (np. j***@domena.pl zamiast pełnego adresu), retencje 14–30 dni.

Środowiska DEV/TEST na kopii produkcji

Deweloperzy potrzebują danych do testów. Najgorsze rozwiązanie? Pełna kopia bazy produkcyjnej bez anonimizacji.

Rozwiązanie: Generatory syntetycznych danych lub pseudonimizacja. W naszych projektach standardowo implementujemy procedury anonimizacji.

Shadow IT i „wtyczki na skróty"

Marketer zainstalował wtyczkę do synchronizacji danych. Nie ma umowy powierzenia, nie ma kontroli retencji, nikt nie wie, gdzie te dane trafiają.

Rozwiązanie: Inwentaryzacja wszystkich połączeń API, obowiązkowa procedura zatwierdzania nowych integracji.

2. Role i odpowiedzialności: kto za co odpowiada

Administrator (ADO) – decyduje o celach i sposobach przetwarzania. To Ty.

Procesor – działa wyłącznie na Twoje polecenie. Dostawca WMS, który przetwarza Twoje zamówienia.

Podprocesor – procesor Twojego procesora. Dostawca chmury, z której korzysta Twój WMS. Potrzebujesz zgody ADO na każdego podprocesora.

W praktyce: Przy wdrożeniach BaseLinker z ERP często widzimy chaos w ustaleniu ról. Pamiętaj: role wynikają z faktycznej kontroli nad danymi, nie z zapisów w umowie.

3. Umowa powierzenia (art. 28) – co musi zawierać

Każda integracja, w której ktoś przetwarza dane „w Twoim imieniu", wymaga DPA (Data Processing Agreement). To nie formalność – to instrukcja operacyjna na gorszy dzień.

Minimalna zawartość DPA:

Podstawy:

  • Przedmiot, czas trwania, rodzaj i cel przetwarzania
  • Kategorie danych i osób
  • Działanie wyłącznie na instrukcje ADO

Zabezpieczenia (TOMs):

  • Konkretne środki: szyfrowanie, RBAC, retencje logów
  • Segmentacja klientów (multi-tenant)
  • Dokumentacja procedur

Podpowierzenie:

  • Jawna lista podprocesorów (np. AWS, Azure)
  • Mechanizm zgody na nowych podprocesorów

Wsparcie operacyjne:

  • Obsługa DSR (praw osób)
  • Wsparcie przy DPIA
  • Procedura zgłaszania naruszeń (72h)
  • Usuwanie/zwrot danych po zakończeniu

Kontrola:

  • Prawo do audytu (zdalnego lub na miejscu)
  • Dokumentacja zgodności

Praktyczna rada: DPA bez konkretnych TOMs to tylko papier. Widzieliśmy umowy z zapisem „procesor zapewni odpowiednie środki techniczne" – to za mało. Wymagaj szczegółów.

4. Privacy by Design – konkretne wdrożenie

Minimalizacja danych w API

Zamiast:

{
  "order_id": "12345",
  "customer": {
    "email": "jan.kowalski@example.com",
    "phone": "+48123456789",
    "nip": "1234567890",
    "address": "ul. Kwiatowa 5/12, 00-001 Warszawa"
  }
}

Użyj:

{
  "order_id": "12345",
  "customer_ref": "cust_a8f9e2"
}

Dodatkowe dane pobieraj tylko gdy absolutnie konieczne, z osobnego endpointu z silniejszą autentykacją.

Maskowanie PII w logach

// Źle
logger.info(`Zamówienie dla ${customer.email}`);

// Dobrze
logger.info(`Zamówienie dla ${maskEmail(customer.email)}`); 
// Wynik: "Zamówienie dla j***@example.com"

Środowiska DEV/TEST

Nasza standardowa procedura w Orbis:

  1. Export danych produkcyjnych z flagą --anonymize
  2. Automatyczne zastąpienie e-maili, telefonów, nazwisk
  3. Zachowanie integralności referencyjnej (ID pozostają spójne)
  4. Testy na zanonimizowanych danych

Retencje logów:

  • Logi błędów: 14–30 dni
  • Logi audytowe: zgodnie z wymogami prawnymi
  • Dostęp: tylko uprawnionym administratorom, z logowaniem dostępu

5. Rejestr czynności (art. 30) – wpis dla integracji

Przykładowy wpis w rejestrze:

Nazwa czynności: Integracja Subiekt GT ↔ BaseLinker ↔ kurierzy

Cel: Realizacja sprzedaży online i automatyzacja wysyłek

Zakres danych:

  • Identyfikacyjne: imię, nazwisko, adres
  • Kontaktowe: e-mail, telefon
  • Transakcyjne: zamówienia, płatności
  • Logistyczne: dane do wysyłki

Odbiorcy:

  • BaseLinker (procesor – OMS)
  • InPost, DPD, DHL (procesor – kurierzy)
  • Przelewy24 (procesor – płatności)
  • AWS Ireland (podprocesor – hosting BaseLinker)

Podstawa prawna: Art. 6 ust. 1 lit. b RODO (wykonanie umowy)

Retencja:

  • Logi integracyjne: 30 dni
  • Dokumenty sprzedaży: 5 lat (ustawa o rachunkowości)

Transfery: AWS Ireland (EOG) – brak transferów poza EOG

Zabezpieczenia:

  • TLS 1.3 w tranzycie
  • Tokeny API z rotacją co 90 dni
  • IP allowlist
  • Logi dostępu z retencją 12 miesięcy

6. DPIA – kiedy jest konieczna

W Polsce obowiązuje wykaz operacji wymagających DPIA (M.P. 2019 poz. 666). Twoja integracja wymaga DPIA, jeśli:

  • Łączysz dane z wielu źródeł na dużą skalę (100k+ rekordów)
  • Używasz profilowania lub AI
  • Przetwarzasz dane szczególnych kategorii
  • Monitoring pracowników przez integracje

Praktyczna matryca DPIA

Przykład z naszego projektu:

Klient chciał integrację ERP + WMS + CRM + marketing automation z centralnym data warehouse. Łącznie 500k rekordów klientów, scoring RFM, targetowanie kampanii.

Ocena ryzyka:

  • Prawdopodobieństwo: Średnie (możliwy wyciek przez błąd w segmentacji)
  • Skutek: Wysoki (precyzyjne profile zakupowe)
  • Wynik: DPIA obligatoryjna

Środki obniżające ryzyko:

  • Pseudonimizacja w data warehouse
  • Segmentacja na poziomie bazy (row-level security)
  • Audit log wszystkich zapytań
  • Encryption at rest
  • RBAC z MFA

Decyzja: Ryzyko rezydualne akceptowalne, projekt zatwierdzony.

7. Transfery poza EOG – praktyczne scenariusze

Opcja 1: EU–US Data Privacy Framework (DPF)

Kiedy: Twój dostawca (np. AWS, Google, Salesforce) ma aktywną certyfikację DPF.

Jak sprawdzić: Lista certyfikowanych firm: https://www.dataprivacyframework.gov/list

Przykład: Wdrażamy integrację z HubSpot (certyfikowany DPF). W DPA wystarczy zapis: „Transfer do USA na podstawie decyzji adekwatności z 10.07.2023 (DPF)".

Uwaga: Po wyroku z 3.09.2025 DPF jest stabilniejszy, ale nadal warto monitorować orzecznictwo.

Opcja 2: Standardowe Klauzule Umowne (SCC) + Transfer Impact Assessment (TIA)

Kiedy: Dostawca poza EOG bez certyfikacji DPF lub chcesz dodatkowe zabezpieczenie.

Co musisz zrobić:

  1. Implementacja SCC 2021/914
  2. Transfer Impact Assessment (TIA):
    • Ocena prawa lokalnego (np. CLOUD Act w USA)
    • Dodatkowe środki techniczne (np. szyfrowanie end-to-end)
    • Dokumentacja, że środki są skuteczne

Przykład z praktyki: Klient chciał integrację z indyjskim call center. Wdrożyliśmy:

  • SCC z indyjskim kontrahentem
  • TIA pokazujące ryzyko dostępu władz
  • Dodatkowe szyfrowanie E2EE
  • Minimalizacja danych (tylko ID + status, bez PII)

Opcja 3: Pełna lokalizacja w EOG

Najprostsze rozwiązanie: Wybieraj dostawców z infrastrukturą w EOG. W naszych integracjach priorytetowo rekomendujemy polskich i europejskich dostawców.

8. Incydenty i „72 godziny" – gotowy playbook

Naruszenie to nie tylko wyciek – również utrata dostępności, zmiana danych czy nieuprawniony dostęp.

Typowe incydenty w integracjach:

  • Publiczny bucket z logami (widzieliśmy to 5x w ciągu roku)
  • Błędne webhooki (zamówienia klienta A wysłane do klienta B)
  • Wyciek tokenów API w logach GitHuba
  • DEV na produkcji (testy na rzeczywistych danych)

Playbook 72h – kroki działania

Godzina 0 – Wykrycie:

09:15 – Alert: nieautoryzowany dostęp do API
09:17 – Izolacja: tokeny API zrotowane
09:20 – Zabezpieczenie logów dostępu

Godzina 0-2 – Kwalifikacja:

  • Jakie dane? (identyfikacyjne, kontaktowe, płatności?)
  • Ilu osób dotyczy? (5, 500, 50 000?)
  • Jakie ryzyko? (niskie / średnie / wysokie)

Godzina 2-24 – Ocena:

  • Czy dane były zaszyfrowane?
  • Czy osoba nieuprawniona zrozumie dane?
  • Czy mogą powstać szkody dla osób?

Decyzja o zgłoszeniu:

  • Ryzyko niskie: Można nie zgłaszać, ale dokumentuj
  • Ryzyko średnie/wysokie: Zgłoszenie do UODO w 72h

Godzina 24-72 – Zgłoszenie:

  • Formularz UODO: https://uodo.gov.pl
  • Dokumentacja: czas, zakres, przyczyna, środki zaradcze
  • Jeśli ryzyko wysokie: powiadomienie osób

Po 72h – Wnioski:

  • Root cause analysis
  • Poprawki w systemie
  • Aktualizacja procedur

Praktyczna rada: Przygotuj szablon zgłoszenia WCZEŚNIEJ. W stresie ciężko pisać od zera.

9. Prawa osób (DSR) w systemach zintegrowanych

End-to-end proces DSR

Scenariusz: Klient wysyła żądanie usunięcia danych.

Krok 1 – System master (CRM/ERP):

  • Rejestracja żądania (numer sprawy: DSR-2025-001)
  • Weryfikacja tożsamości
  • Sprawdzenie podstawy prawnej przetwarzania

Krok 2 – Propagacja do systemów downstream:

CRM → ERP → WMS → BaseLinker → kurierzy

Krok 3 – Wykonanie w określonym SLA:

  • Systemy operacyjne: 24h
  • Archiwa/backupy: 30 dni
  • Rachunkowość: WYJĄTEK (5 lat retencji ustawowej)

Krok 4 – Potwierdzenia:

  • Log z każdego systemu (timestamp + status)
  • Zbiorczy raport dla klienta
  • Dokumentacja wyjątków z uzasadnieniem

Wyzwanie: W jednym z projektów integracja obejmowała 7 systemów. DSR trwało 3 tygodnie przez ręczne potwierdzenia. Rozwiązanie? Automatyczny workflow DSR z centralnym dashboardem.

10. DEV/TEST i logowanie – zasady „zero wstydu na audycie"

Środowiska deweloperskie

Zasada #1: Zakaz produkcyjnych danych na DEV/TEST (chyba że pseudonimizowane).

Nasza procedura w Orbis:

# Export z produkcji z anonimizacją
./export-prod-anonymized.sh

# Wynik: dane zachowują strukturę, tracą PII
# jan.kowalski@example.com → user_a8f9e2@example.com
# +48123456789 → +48XXX XXX X89

Logowanie bez PII

Źle:

ERROR: Payment failed for jan.kowalski@example.com, 
       card ending 1234

Dobrze:

ERROR: Payment failed for order_id=12345, 
       payment_ref=pay_xyz, 
       error_code=INSUFFICIENT_FUNDS

Dostępy i uprawnienia

  • Just-in-Time Access: Admin dostaje uprawnienia na 4h, potem automatyczna deaktywacja
  • MFA obowiązkowe dla dostępu produkcyjnego
  • Audit log wszystkich działań adminów
  • Przeglądy dostępów co kwartał

11. Bezpieczeństwo (art. 32) – minimum techniczne

W tranzycie:

  • TLS 1.3 (minimum TLS 1.2)
  • Certyfikaty od zaufanych CA
  • Certificate pinning dla krytycznych API

At rest:

  • Szyfrowanie baz danych (transparent data encryption)
  • Szyfrowanie backupów
  • Zarządzanie kluczami (KMS/HSM)

Zarządzanie dostępem:

  • Least privilege – minimalne uprawnienia
  • Segmentacja klientów (multi-tenant)
  • IP allowlist dla API
  • Rate limiting przeciw DDoS
  • WAF dla aplikacji webowych

Rotacja sekretów:

  • Hasła API: 90 dni
  • Tokeny sesji: krótkie TTL (15 min)
  • Certyfikaty: przed wygaśnięciem

CI/CD i testy:

  • Automatyczne testy bezpieczeństwa w pipeline
  • SAST/DAST przed deploym
  • Dependency scanning (znane CVE)

BCP/DR:

  • Backupy z testami odtworzenia
  • Plan ciągłości na wypadek awarii
  • RTO/RPO zdefiniowane w DPA

Z doświadczenia: Po incydencie ransomware u jednego z klientów wdrożyliśmy pełną procedurę BCP. Koszt: 20k PLN. Koszt odtworzenia bez backupów: >200k PLN.

12. Najczęstsze błędy i szybkie korekty

1. Logi z PII

Błąd: Logger.info("Email sent to: " + customer.email)
Korekta:

  • Polityka logowania (co, jak długo, kto ma dostęp)
  • Automatyczne maskowanie
  • Retencja 14–30 dni
  • Koszt: 2-3 dni pracy developera

2. Brak DPA z podwykonawcami

Błąd: „Przecież to tylko API do weryfikacji NIP-ów"
Korekta:

  • Inwentaryzacja wszystkich processorów
  • Szablony DPA (mamy gotowe w Orbis)
  • Lista podprocesorów w załączniku
  • Koszt: 0 PLN (szablony dostępne)

3. DEV z produkcją

Błąd: Export prod → import DEV (1:1)
Korekta:

  • Procedura pseudonimizacji
  • Skrypt anonimizacji w CI/CD
  • Kontrola eksportów (approval)
  • Koszt: 3-5 dni setup + 1h/miesiąc maintenance

4. Brak DPIA przy integracji dużej skali

Błąd: „To tylko kolejna integracja"
Korekta:

  • Matryca decyzyjna DPIA
  • Szablon dokumentu DPIA
  • Przeszkolenie zespołu
  • Koszt: 5-10k PLN za konsultację + dokumentację

5. Transfer do USA „na czuja"

Błąd: „AWS to duża firma, na pewno jest OK"
Korekta:

  • Weryfikacja certyfikacji DPF
  • Lub implementacja SCC + TIA
  • Aktualizacja rejestrów i DPA
  • Koszt: 2-5k PLN za legal review

13. Case study: e-commerce 50k zamówień/miesiąc

Firma: Sklep internetowy, branża elektroniki
Wyzwanie: Audit UODO wykazał 12 niezgodności w integracjach

Stan przed:

  • Logi z pełnymi adresami e-mail i telefonami
  • DEV na kopii produkcji bez anonimizacji
  • Brak DPA z 3/7 procesorów
  • Transfer do USA (Mailchimp) bez podstawy prawnej
  • Brak procedury DSR dla systemów zintegrowanych

Działania (3 miesiące):

Miesiąc 1 – Quick wins:

  • Maskowanie PII w logach → 3 dni
  • Retencje logów 30 dni → 1 dzień
  • DPA z procesorami → 2 tygodnie (negocjacje)

Miesiąc 2 – Średnie wyzwania:

  • Pseudonimizacja DEV/TEST → 1 tydzień (setup)
  • Transfer Impact Assessment dla Mailchimp → 1 tydzień
  • Dokumentacja w rejestrze → 2 dni

Miesiąc 3 – Kompleksowe rozwiązania:

  • Automatyczny workflow DSR → 3 tygodnie
  • IP allowlist + MFA → 1 tydzień
  • Procedury i szkolenia → 1 tydzień

Wynik:

  • Wszystkie 12 niezgodności usunięte
  • Koszt: 35k PLN (consulting + development)
  • Czas: 12 tygodni
  • ROI: Uniknięcie potencjalnej kary (do 20M EUR lub 4% obrotu)

Bonus: Udokumentowana zgodność przyspieszyła due diligence przy sprzedaży firmy.

14. Co zrobić „od jutra" – plan 30 dni

Tydzień 1 – Inwentaryzacja

  • [ ] Lista wszystkich integracji i processorów
  • [ ] Mapowanie przepływów danych (kto → komu → co)
  • [ ] Identyfikacja braków w DPA
  • Czas: 8h (można zrobić warsztatowo)

Tydzień 2 – Quick wins

  • [ ] Włączyć maskowanie PII w logach
  • [ ] Ustawić retencje logów na 30 dni
  • [ ] Wyłączyć zbędne endpointy API
  • Czas: 2-3 dni pracy dev

Tydzień 3 – Dokumentacja

  • [ ] Aktualizacja rejestrów (art. 30)
  • [ ] Podpisanie brakujących DPA
  • [ ] Weryfikacja certyfikacji DPF
  • Czas: 5 dni (+ negocjacje z dostawcami)

Tydzień 4 – Procedury

  • [ ] Matryca DPIA + szablon
  • [ ] SLA dla DSR end-to-end
  • [ ] Playbook 72h dla incydentów
  • Czas: 3 dni (+ przeszkolenie zespołu)

Priorytet #1: Jeśli musisz wybrać jedno – zacznij od DPA z procesorami. To podstawa, bez której reszta nie ma sensu.

15. Podsumowanie – kluczowe wnioski:

5 kluczowych zasad integracji RODO-compliant:

  1. Minimalizacja: Przekazuj tylko niezbędne dane
  2. Dokumentacja: DPA z każdym procesorem, wpisy w rejestrze
  3. Bezpieczeństwo: TLS, szyfrowanie, RBAC, rotacja kluczy
  4. Kontrola: Audyt logów, monitoring dostępów, procedury
  5. Gotowość: Playbook 72h, workflow DSR, plan BCP

Jak Orbis może pomóc:

Przez 12 lat zrealizowaliśmy ponad 500 projektów integracyjnych dla polskich firm e-commerce. Wiemy, gdzie są pułapki i jak ich uniknąć.

Nasze usługi:

Potrzebujesz pomocy?

Skontaktuj się z nami – w 30-minutowej konsultacji ocenimy Twoją sytuację i zaproponujemy konkretny plan działania.

 

Źródła prawne i materiały

Akty prawne:

Wytyczne EDPB:

Materiały UODO:

Orzecznictwo:

Więcej praktycznych porad:

 

(Materiał informacyjny. Nie stanowi porady prawnej.)

 

Kategoria: Integracje

Autor: Orbis Software Polska | Data publikacji: 07.10.2025

Porozmawiajmy o współpracy!

Bezpłatna konsultacja