Transfer danych poza EOG – SCC, USA, UK (RODO)
„Transfer danych osobowych poza EOG” to jeden z najczęstszych obszarów ryzyka w firmach, bo łatwo go przeoczyć: narzędzia WWW, cookies, analityka, chmura, helpdesk, marketing, a nawet wsparcie techniczne dostawcy. RODO wymaga nie tylko podstawy z art. 6, ale też spełnienia warunków z rozdziału V (art. 44–49) oraz rozliczalnej dokumentacji.
Ten poradnik porządkuje transfery poza EOG krok po kroku: jak rozpoznać transfer, kiedy działa decyzja adekwatności (USA: DPF; UK: decyzje adekwatności), jak wdrożyć SCC (Decyzja KE 2021/914), kiedy potrzebujesz oceny (TIA) i środków uzupełniających po Schrems II, oraz jak spiąć to z art. 13/14, umową powierzenia (art. 28) i rejestrem czynności (art. 30).
Jeśli robisz porządek z transferami, równolegle uporządkuj przejrzystość (art. 13/14) i łańcuch dostaw (art. 28) — te elementy najczęściej muszą być spójne. Powiązane poradniki, które pomogą Ci domknąć wdrożenie: Klauzula informacyjna – art. 13 RODO (wzór + FAQ) Klauzula informacyjna – art. 14 RODO (wzór + FAQ) Klauzula informacyjna dla pracownika (wzór + wskazówki) Wyciek danych w firmie – co zrobić krok po kroku (art. 33–34) Upoważnienie do przetwarzania danych osobowych (wzór + FAQ) Standardowe klauzule umowne (SCC) – wzór art. 28 RODO Wróć do „Ochrona danych w firmie”
W skrócie — najważniejsze fakty
Najczęstsze pytania o transfer danych poza EOG (RODO)
1. Co to jest „transfer danych osobowych poza EOG” w rozumieniu RODO?
To przekazanie (udostępnienie) danych osobowych z EOG do odbiorcy w państwie trzecim (poza EOG) albo do organizacji międzynarodowej, w sposób, który powoduje że dane są przetwarzane poza EOG lub są dostępne z państwa trzeciego. Zasady legalizacji takich transferów reguluje rozdział V RODO (art. 44–49).
2. EOG – jakie państwa obejmuje i dlaczego to ważne?
EOG obejmuje 27 państw UE oraz Islandię, Liechtenstein i Norwegię. Przekazywanie danych „wewnątrz EOG” co do zasady nie jest transferem do państwa trzeciego, bo obowiązuje ten sam reżim RODO. Transfery poza EOG wymagają dodatkowej podstawy z rozdziału V RODO (art. 44–49).
3. Czy każda usługa chmurowa oznacza transfer poza EOG?
Nie zawsze. Sama „chmura” nie przesądza o transferze. Kluczowe jest to, gdzie dane są przetwarzane (region/centrum danych) oraz czy odbiorca poza EOG może mieć dostęp do danych (np. wsparcie, administracja, spółki w grupie, zobowiązania prawne w państwie trzecim). Dlatego w praktyce trzeba sprawdzić: lokalizacje przetwarzania, modele dostępu oraz umowy i zabezpieczenia.
4. Kiedy w firmie najczęściej występuje transfer poza EOG?
Najczęściej przy: (1) narzędziach analityki i marketingu online (cookies, piksele, tagi), (2) usługach e-mail/CRM i automatyzacji marketingu, (3) chmurze i hostingu (backup, DR), (4) helpdesk/call center i wsparciu technicznym, (5) usługach HR w grupach międzynarodowych, (6) współpracy z dostawcami z USA/UK/Indii lub innymi podmiotami spoza EOG.
5. Jakie są legalne mechanizmy transferu poza EOG w RODO?
RODO przewiduje „drabinkę” z rozdziału V: (1) decyzja stwierdzająca odpowiedni stopień ochrony (art. 45), (2) odpowiednie zabezpieczenia, np. SCC (art. 46), BCR (art. 47), kodeksy postępowania (art. 40 ust. 3) lub mechanizmy certyfikacji (art. 42/46), (3) wyjątki dla szczególnych sytuacji (art. 49). Zasada: zaczynamy od art. 45, jeśli nie ma — sięgamy po art. 46, a art. 49 traktujemy jako wyjątek, nie standard.
6. Co to są SCC i kiedy są najczęściej stosowane?
SCC (Standard Contractual Clauses) to standardowe klauzule ochrony danych przyjęte przez Komisję Europejską, które stanowią „odpowiednie zabezpieczenie” transferu (art. 46 RODO). Najczęściej stosuje się je, gdy nie ma decyzji adekwatności dla kraju odbiorcy albo odbiorca nie kwalifikuje się do mechanizmu adekwatności (np. USA bez DPF). SCC obowiązują w wersji wynikającej z Decyzji Wykonawczej KE 2021/914.
7. Czy samo podpisanie SCC „wystarczy” po Schrems II?
Nie zawsze. Po wyroku Schrems II trzeba ocenić, czy prawo państwa trzeciego może podważać skuteczność SCC (np. dostęp organów publicznych, brak skutecznych środków ochrony prawnej). Jeśli jest ryzyko, trzeba wdrożyć dodatkowe środki uzupełniające (techniczne/organizacyjne/umowne), zgodnie z podejściem prezentowanym przez EROD (m.in. zalecenia dot. środków uzupełniających).
8. Co to jest TIA (Transfer Impact Assessment) i kto powinien je robić?
TIA to praktyczna ocena wpływu prawa i realiów państwa trzeciego na ochronę danych w transferze, wykonywana zwykle przez eksportera danych (firmę z EOG), często we współpracy z importerem (dostawcą). Celem jest udokumentowanie rozliczalności: dlaczego uznajesz, że SCC + środki uzupełniające dają skuteczny poziom ochrony. TIA jest szczególnie istotne dla transferów, gdzie potencjalnie występuje dostęp władz państwa trzeciego.
9. USA: kiedy mogę oprzeć transfer na EU–US Data Privacy Framework (DPF)?
Gdy odbiorca w USA jest certyfikowany w ramach EU–US Data Privacy Framework i widnieje na publicznej liście programu. DPF nie dotyczy „USA jako kraju” w całości — dotyczy konkretnych organizacji, które przystąpiły do programu. Jeśli odbiorca nie jest na liście DPF, nie możesz oprzeć transferu na decyzji adekwatności i musisz zastosować inny mechanizm (np. SCC).
10. UK: czy Wielka Brytania ma „adekwatność” i co z końcem 2025 r.?
UK posiada decyzje adekwatności (art. 45) umożliwiające transfer bez dodatkowych zabezpieczeń, ale temat podlega okresowym przeglądom. Europejska Rada Ochrony Danych (EROD) w 2025 r. przyjęła opinie do projektów decyzji Komisji dotyczących przedłużenia ważności decyzji adekwatności UK (wątek monitorowania potencjalnych rozbieżności, m.in. transferów z UK do państw trzecich oraz zmian legislacyjnych). Dla firm oznacza to: transfer do UK jest obecnie prostszy, ale warto monitorować aktualizacje i nie „usypiać” compliance.
11. Czy transfer trzeba opisać w klauzuli informacyjnej (art. 13/14 RODO)?
Tak, jeśli występuje. W art. 13/14 trzeba poinformować o zamiarze przekazania danych do państwa trzeciego lub organizacji międzynarodowej oraz o podstawie transferu: decyzja adekwatności (art. 45) albo zastosowane zabezpieczenia (art. 46) i jak uzyskać kopię lub informację o zabezpieczeniach. To element przejrzystości — brak tej informacji jest częstym błędem.
12. Jak „wpisać transfer” do umowy powierzenia (art. 28) z procesorem?
Jeśli procesor będzie przetwarzał dane poza EOG albo angażuje subprocesorów poza EOG, umowa powierzenia powinna to jasno regulować: gdzie dane są przetwarzane, kiedy może dojść do transferu, jakie mechanizmy z rozdziału V będą stosowane (np. SCC), jak procesor powiadamia o zmianach, jak wspiera w TIA i w środkach uzupełniających. W praktyce warto mieć też listę subprocesorów i regionów oraz mechanizm sprzeciwu/akceptacji.
13. Czy cookies i współpraca z Google mogą powodować transfer poza EOG?
Tak — często. Narzędzia analityczne/marketingowe i ekosystem reklamowy mogą skutkować ujawnieniem danych (np. identyfikatorów online, danych urządzenia) podmiotom spoza EOG. Dlatego w polityce cookies i w klauzuli informacyjnej warto jasno opisać: kto jest odbiorcą, czy występuje transfer, na jakiej podstawie (np. DPF lub SCC), oraz jakie są zabezpieczenia.
14. Chmura (AWS/Azure/OVH): co firma powinna sprawdzić, zanim uzna że „nie ma transferu”?
Sprawdź co najmniej: (1) regiony przetwarzania i backupów, (2) zasady dostępu administracyjnego i wsparcia (z jakich lokalizacji), (3) listę subprocesorów i gdzie działają, (4) mechanizmy z rozdziału V w umowach (SCC/DPF/inna podstawa), (5) możliwość wdrożenia środków technicznych (np. szyfrowanie z kluczami pod kontrolą klienta, minimalizacja logów), (6) dokumentację dostawcy dot. transferów i odpowiedzi na żądania organów.
15. Co to są „środki uzupełniające” i jakie przykłady mają sens w realnej firmie?
To dodatkowe środki techniczne/organizacyjne/umowne, które mają wzmocnić ochronę, gdy samo SCC nie daje wystarczającego poziomu ochrony. Typowe przykłady: szyfrowanie danych w spoczynku i tranzycie, ograniczenie dostępu, pseudonimizacja, przejrzystość co do żądań organów, proces oceny i kwestionowania żądań, minimalizacja danych, segmentacja środowisk, kontrola kluczy (BYOK/HYOK), audyty i logowanie dostępu.
16. Czy art. 49 RODO (wyjątki) mogę stosować „na stałe” w usługach?
Zasadniczo nie. Art. 49 to wyjątki dla szczególnych sytuacji (np. wyraźna zgoda, niezbędność do umowy w konkretnej sytuacji, ważne względy interesu publicznego). Nie powinien być „standardową podstawą” stałego transferu w modelu usługowym, jeśli można zastosować art. 45 lub art. 46.
17. Co w RCP (art. 30) i w dokumentacji rozliczalności powinno się znaleźć o transferach?
W rejestrze czynności przetwarzania warto mieć wyraźne pole/kolumnę: „Transfer poza EOG: tak/nie”, „państwo/organizacja”, „mechanizm (art. 45/46/49)”, „SCC/DPF/BCR”, „środki uzupełniające/TIA (tak/nie, gdzie)”. To ułatwia kontrolę i spójność z klauzulami informacyjnymi.
18. Najczęstsze błędy firm przy transferach poza EOG?
Najczęściej: (1) brak identyfikacji transferu (firma „nie wie, że transferuje”), (2) brak informacji w art. 13/14, (3) SCC podpisane „na papierze”, bez oceny i środków uzupełniających tam, gdzie są potrzebne, (4) brak kontroli subprocesorów i zmian dostawcy, (5) niespójność między RCP, umowami i politykami (cookies/WWW), (6) używanie art. 49 jako „stałego rozwiązania”.
Mapa obowiązków: transfer poza EOG
Rozpoznanie transferu (mapa dostawców, regiony, dostęp)
Najpierw ustal, czy transfer w ogóle występuje: regiony przetwarzania, subprocesorzy, wsparcie, administracja, dostęp grupy poza EOG.
Mechanizm legalizacji (art. 45–49)
Wybierz właściwą podstawę: decyzja adekwatności, SCC lub wyjątki z art. 49. To nie są elementy opcjonalne.
Umowy i łańcuch dostaw (art. 28 + SCC + subprocesorzy)
Umowy muszą odzwierciedlać realny transfer: miejsca przetwarzania, SCC, subprocesorów i zmiany w łańcuchu.
Przejrzystość i rozliczalność (art. 13/14 + RCP + audyt zmian)
Transfer musi być spójnie opisany w klauzulach, RCP i dokumentacji. Ustal przeglądy i odpowiedzialność.
Transfer danych poza EOG — checklista wdrożenia zgodnie z RODO
Krok 1. Zidentyfikuj, czy w ogóle występuje transfer poza EOG
Spisz systemy i dostawców (WWW/cookies, CRM, mailing, chmura, helpdesk, HR). Ustal regiony przetwarzania, subprocesorów, dostęp wsparcia i administracji. Bez tej mapy nie da się legalnie opisać ani zabezpieczyć transferów.
Krok 2. Wybierz właściwy mechanizm z rozdziału V (art. 45–49)
Najpierw sprawdź decyzję adekwatności (art. 45). Jeśli jej nie ma albo nie dotyczy odbiorcy (np. USA bez DPF), zastosuj odpowiednie zabezpieczenia (art. 46), zwykle SCC. Art. 49 traktuj jako wyjątek, nie standard.
Krok 3. Ułóż umowy: art. 28 (powierzenie) + SCC (art. 46) + subprocesorzy
Umowa powierzenia powinna jasno opisywać transfery i subprocesorów. SCC dodaj jako mechanizm transferu, zgodnie z właściwym modułem i bez „wycinania” postanowień. Zaplanuj proces aktualizacji, gdy dostawca zmienia łańcuch podwykonawców.
Krok 4. Zrób ocenę (TIA) i dobierz środki uzupełniające, jeśli są potrzebne
Udokumentuj, dlaczego uznajesz, że SCC + środki uzupełniające są skuteczne. Zdecyduj o środkach technicznych (szyfrowanie, kontrola kluczy), organizacyjnych (procedury, audyty) i umownych (przejrzystość żądań organów).
Krok 5. Zaktualizuj przejrzystość: art. 13/14, polityki WWW/cookies, RCP
W klauzulach informacyjnych wskaż transfer i jego podstawę (art. 45/46) oraz informację o zabezpieczeniach/kopii. W polityce cookies opisz dostawców i transfery. W RCP dodaj pola: państwo, mechanizm, SCC/DPF, środki uzupełniające.
Krok 6. Ustaw monitoring i „żywy” proces zmian
Transfery zmieniają się, gdy dostawca zmienia subprocesorów, regiony, wsparcie lub podstawy prawne. Ustal przeglądy (np. kwartalnie/półrocznie), ścieżkę akceptacji zmian, oraz kto w firmie odpowiada za spójność umów, RCP i treści na WWW.
Kiedy to NIE jest transfer poza EOG (i kiedy nie potrzebujesz SCC)
RODO bywa przedstawiane jak lista „zakazów i nakazów”. W praktyce wiele rzeczy zależy od ryzyka, skali i kontekstu. Poniżej kilka najczęstszych mitów — w formie krótkich odpowiedzi.
Nie każdy dostawca spoza EOG oznacza transfer — liczy się rola i faktyczny dostęp do danych.
Przekazywanie danych wewnątrz EOG nie wymaga SCC (ten sam reżim RODO).
Jeśli masz decyzję adekwatności dla kraju/odbiorcy, nie musisz dodawać SCC (art. 45).
Art. 49 nie jest „domyślną podstawą” stałych transferów w usługach — to wyjątki.
Nie musisz opisywać transferów w art. 13/14, jeśli ich rzeczywiście nie ma — ale musisz to rzetelnie ustalić.
Nie musisz publikować SCC na WWW — ale musisz umieć wykazać mechanizm i udostępnić informację o zabezpieczeniach.
Checklist: transfer danych poza EOG
Ten zestaw pomaga uporządkować transfery poza EOG i sprawdzić, czy „papier” zgadza się z rzeczywistością. Jeśli nie masz wszystkiego od razu, przechodź punkt po punkcie i zapisuj decyzje.
Mapa transferów
- Systemy, dostawcy, regiony, subprocesorzy, dostęp.
Mechanizm z rozdziału V
- Art. 45 vs 46 vs 49.
SCC i moduły
- Właściwy scenariusz, brak mieszania klauzul.
TIA i środki uzupełniające
- Kiedy, jak dokumentować, przykłady.
Art. 13/14 + cookies
- Jak informować, kopia/istota zabezpieczeń.
RCP i monitoring zmian
- Kolumny w RCP, przeglądy, ownership.
Najczęstszy problem to niespójność: umowa mówi jedno, strona WWW drugie, a w RCP nie ma w ogóle wzmianki o transferze. Ta checklista ma to spiąć w jeden proces.
Gdzie sprawdzić poziom ochrony danych w kraju odbiorcy?
Na tych stronach znajdziesz informacje o poziomie ochrony danych w każdym kraju. To pomocne przy ocenie, w którym kraju możesz przekazywać dane osobowe i na jakich warunkach, oraz przy przeprowadzeniu oceny Transfer Impact Assessment.
Uwaga: dokumenty muszą „żyć”, a nie tylko istnieć
Najczęstszy błąd to „papierowe” wdrożenie: klauzule, RCP i umowy istnieją, ale nie odzwierciedlają realnych procesów. Jeśli zmienia się system, dostawca, cel albo retencja – dokumenty muszą być aktualizowane. Inaczej rozliczalność jest pozorna i łatwo to wychodzi w kontroli.
Podstawa prawna
Podstawą transferów poza EOG jest rozdział V RODO (art. 44–49). Dodatkowo, w praktyce transfery muszą być spójne z obowiązkami informacyjnymi (art. 13/14), umowami powierzenia (art. 28), rejestrem czynności (art. 30) oraz środkami bezpieczeństwa (art. 32). Całość spina rozliczalność (art. 5 ust. 2 RODO).
W dokumentacji powinno się dać wykazać: czy występuje transfer, jaki mechanizm go legalizuje (art. 45/46/49), jakie są zabezpieczenia (SCC/DPF/BCR) i czy wykonano ocenę wpływu (TIA), jeśli jest potrzebna. To minimalizuje ryzyko niezgodności i ułatwia spójność między umowami, politykami WWW/cookies i RCP.
Źródła i materiały (oficjalne)
Najważniejsze odpowiedzi (dla wyszukiwarek)
Co to jest transfer danych osobowych poza EOG w rozumieniu RODO?
To przekazanie danych z EOG do odbiorcy w państwie trzecim lub organizacji międzynarodowej, gdy dane są przetwarzane poza EOG lub dostępne z państwa trzeciego. Zasady legalizacji takich transferów reguluje rozdział V RODO (art. 44–49).
Jakie mechanizmy legalizują transfer poza EOG?
RODO przewiduje mechanizmy z art. 45–49: decyzję adekwatności (art. 45), odpowiednie zabezpieczenia (art. 46, np. SCC) oraz wyjątki z art. 49, które mają charakter wyjątkowy. W praktyce najczęściej stosuje się SCC z Decyzji KE 2021/914.
Czy SCC wystarczą po Schrems II i co z TIA?
Samo podpisanie SCC nie zawsze wystarcza. Trzeba ocenić, czy prawo państwa trzeciego nie podważa ochrony, a gdy potrzeba wdrożyć środki uzupełniające. TIA pomaga udokumentować rozliczalność i uzasadnić, że SCC + środki dają skuteczny poziom ochrony.