AWS, Google Cloud i transfer danych poza EOG – co sprawdzić pod RODO?
Twoja firma decyduje się na migrację do chmury. Wybór pada na AWS, Google Cloud, Microsoft lub inny podmiot z centrami danych poza UE. Dział IT klika „Akceptuj” w panelu administracyjnym i zaczyna proces korzystania z usługi. Sześć miesięcy później, w trakcie audytu RODO, okazuje się, że dane Twoich klientów trafiają do Stanów Zjednoczonych lub w inne miejsca na świecie, a mechanizm transferu w Twojej dokumentacji pozostaje niejasny. To bardzo częsty scenariusz w polskich firmach i jeden z głównych obszarów ryzyka regulacyjnego, na które zwraca się uwagę nie tyko w RODO, ale też w DORA.
W tym artykule pokazujemy, jak w 2026 roku zgodnie z prawem korzystać z usług globalnych dostawców chmury. Wyjaśniamy, co to jest transfer danych poza EOG, jakie mechanizmy prawne umożliwiają legalny transfer, jak wygląda zgodność z RODO w praktyce kontraktowej. Wskazujemy też, jak przeprowadzić ocenę skutków transferu (TIA) i czy certyfikacja Data Privacy Framework rozwiązuje problem, który wcześniej zamknął wyrok Schrems II. Tekst pomoże również ocenić, czym jest umowa powierzenia danych w kontekście transferu poza EOG, jak wygląda zgodność z RODO w przekazywaniu danych w praktyce oraz dlaczego ocena ryzyka transfer danych do USA stała się obowiązkowym elementem dokumentacji.
Sprawdź również : Audyt prawny usług chmurowych
Kiedy korzystanie z chmury oznacza transfer danych poza EOG?
Transfer danych poza EOG to każda sytuacja, w której dane osobowe przetwarzane w Europejskim Obszarze Gospodarczym stają się dostępne dla podmiotu zlokalizowanego poza tym obszarem. Europejski Obszar Gospodarczy obejmuje 27 państw członkowskich UE oraz Norwegię, Islandię i Liechtenstein. Definicja transferu jest szeroka: nie chodzi tylko o fizyczne przeniesienie danych na serwery poza EOG, ale także o udostępnienie ich do wglądu, kopiowania lub inne formy korzystania. To pierwsze rozróżnienie, które każda umowa powierzenia przetwarzania danych z dostawcą globalnym powinna jasno regulować.
Z perspektywy operacyjnej to oznacza, że wymogi RODO transferu danych osobowych poza EOG uruchamiają również sytuacje, których Twój zespół IT może nie traktować jako transfer. Najczęstsze przypadki:
- Hosting – dane produkcyjne na serwerach w regionach UE, ale dostęp administracyjny z USA lub Indii (np. inżynierowie zespołu dostawcy).
- Wsparcie techniczne – zgłaszasz incydent przez panel, sprawa trafia do specjalisty w USA, który uzyskuje dostęp do Twoich danych w celu diagnostyki.
- Backupy – produkcja w regionie EU-Frankfurt, ale kopie zapasowe replikowane do innego regionu poza EOG.
- Logi i telemetria – zbierane przez dostawcę do diagnostyki i przesyłane do centralnego systemu monitoringu poza EOG.
- Podprocesorzy – dostawca podstawowy hostuje w EOG, ale jego podwykonawcy (np. narzędzia analitycznego) operują spoza EOG.
Transfer danych poza EOG jest regulowany w przepisach RODO. Podstawowa zasada to: transfer jest możliwy tylko wtedy, gdy spełniony zostanie jeden z mechanizmów przewidzianych w tych przepisach. Bez podstawy prawnej transfer jest niezgodny z RODO niezależnie od tego, jak dobre zabezpieczenia techniczne zostały wdrożone.
Jakie mechanizmy pozwalają legalnie przekazywać dane poza EOG?
RODO przewiduje hierarchię mechanizmów, które umożliwiają zgodne z prawem przekazywanie danych poza EOG. Przy wyborze mechanizmu obowiązuje zasada: najpierw decyzja o adekwatności, potem zabezpieczenia odpowiednie (SCC, BCR).
Decyzja o adekwatności – najprostsza podstawa transferu
Komisja Europejska może uznać, że dane państwo trzecie zapewnia odpowiedni stopień ochrony danych. W takim przypadku transfer nie wymaga dodatkowych mechanizmów. Aktualnie decyzje o adekwatności obejmują m.in. Wielką Brytanię, Szwajcarię, Japonię, Kanadę, Korea Południową oraz częściowo USA poprzez certyfikację Data Privacy Framework.
Standardowe klauzule umowne SCC – kiedy są potrzebne?
Standardowe klauzule umowne RODO to wzorzec klauzul zatwierdzony decyzją wykonawczą Komisji 2021/914. SCC realizują transfer danych poza EOG poprzez zobowiązania kontraktowe między eksporterem (Twoja firma) a importerem (np. AWS). SCC obejmują cztery moduły dostosowane do różnych konfiguracji ról stron. Najczęstszy w praktyce to Moduł 2 (administrator do procesora) oraz Moduł 3 (procesor do podprocesora).
BCR – mechanizm dla grup kapitałowych
Binding Corporate Rules to wewnętrzne polityki grupy kapitałowej zatwierdzane przez organ nadzorczy ochrona danych. Skuteczny mechanizm dla dużych grup transgranicznych, ale procedura zatwierdzania jest długa i kosztowna. W praktyce używany przez korporacje, rzadziej przez średnie firmy.
Schrems II i Data Privacy Framework – czy transfer danych do USA jest bezpieczny prawnie?
Privacy Shield, czyli ramy transferu danych do USA z 2016 roku, został unieważniony przez TSUE w lipcu 2020 roku w wyroku Schrems II (sprawa C-311/18). Głównym argumentem trybunału był brak proporcjonalnego ograniczenia dostępu organów bezpieczeństwa USA do danych obywateli UE. Po Schrems II wszystkie transfery do USA realizowane na podstawie Privacy Shield stały się nielegalne, a polskie firmy stanęły przed koniecznością błyskawicznego przepisania kontraktów na SCC z dodatkowymi środkami uzupełniającymi.
Czy Privacy Shield nadal obowiązuje? Nie, od 2020 roku. Ale jego następca, Data Privacy Framework wszedł w życie w lipcu 2023 roku decyzją wykonawczą Komisji (UE) 2023/1795. DPF to odbudowa mechanizmu transferu między UE a USA na nowych podstawach: certyfikowane firmy amerykańskie zobowiązują się do przestrzegania zasad ochrony danych, a obywatele UE otrzymują mechanizmy odwoławcze poprzez amerykański system prawny.
Czy certyfikacja Data Privacy Framework zastępuje standardowe klauzule umowne? Tak, w przypadku transferu do firm certyfikowanych w DPF, certyfikacja jest samodzielną podstawą transferu. Lista certyfikowanych firm jest publicznie dostępna. AWS, Google Cloud i Microsoft są certyfikowane w DPF.
Mimo to DPF nie eliminuje wszystkich wątpliwości. Część ekspertów wskazuje na ryzyko, że kolejny wyrok TSUE („Schrems III”) może unieważnić również DPF, podobnie jak stało się z Privacy Shield.
Jak korzystać z AWS i Google Cloud zgodnie z RODO?
Czy korzystanie z AWS lub Google Cloud jest zgodne z RODO? Tak, jeśli wdrożysz odpowiednie mechanizmy. Sami dostawcy oferują zestaw narzędzi prawnych, które umożliwiają zgodne korzystanie, ale wymaga to świadomych decyzji konfiguracyjnych po Twojej stronie.
AWS a RODO – DPA, SCC, DPF i wybór regionu
AWS udostępnia administratorom standardowe DPA (GDPR Data Processing Addendum) automatycznie aktywne dla każdego konta. Dokument zawiera SCC w aktualnej wersji 2021/914 i obejmuje przetwarzanie danych przez Amazon Web Services Inc. (USA) oraz spółki zależne. AWS jest również certyfikowany w Data Privacy Framework. Zgodność korzystania z usługi AWS z RODO wymaga jednak również świadomego wyboru regionów przetwarzania (regiony EU-Frankfurt, EU-Ireland, EU-Stockholm) oraz najlepiej włączenia mechanizmu potencjalnych transferów poza EOG.
Google Cloud a RODO – DPA, SCC i transfery poza EOG
Google Cloud, jeśli chodzi o RODO, posługuje analogicznymi narzędziami jak AWS: Data Processing Addendum z wbudowanymi SCC oraz certyfikację DPF dla Google LLC. Dla zaawansowanych konfiguracji warto rozważyć dedykowane rozwiązania dla danych pozostających w UE. Z perspektywy oceny prawnej AWS oraz Google Cloud mają podobny poziom dojrzałości kontraktowej.
Globalny dostawca chmury udostępnia zwykle Data Processing Agreement w panelu administracyjnym jako dokument do akceptacji, a nie jako umowa do indywidualnej negocjacji. To istotna zmiana w porównaniu z umowami z mniejszymi dostawcami. Praktyka pokazuje, że AWS, praktycznie nie negocjują standardowych klauzul DPA.
Jak przeprowadzić ocenę ryzyka transferu danych TIA?
Po wyroku Schrems II TSUE wprowadził wymóg, którego nie było wcześniej w jasnej formie: sam fakt zawarcia SCC nie wystarcza, by transfer był zgodny z prawem. Eksporter danych musi przeprowadzić ocenę ryzyka transfer danych (Transfer Impact Assessment, TIA) i wdrożyć środki uzupełniające, jeśli prawo państwa importera nie zapewnia poziomu ochrony porównywalnego z RODO.
TIA to dokumentowana procedura, którą Twoja firma jako administrator musi przeprowadzić dla każdego transferu. Składa się z sześciu kroków wskazanych w rekomendacjach Europejskiej Rady Ochrony Danych (EROD 01/2020):
- Krok 1: Zinwentaryzuj transfery – zmapuj wszystkie sytuacje, w których dane Twojej firmy opuszczają EOG. Pamiętaj o backupach, logach, wsparciu technicznym i podprocesorach.
- Krok 2: Zidentyfikuj mechanizm transferu – dla każdego transferu wskaż podstawę prawną: decyzja o adekwatności, SCC, BCR, DPF.
- Krok 3: Oceń skuteczność mechanizmu – zbadaj, czy prawo państwa importera zapewnia ochronę porównywalną z RODO.
- Krok 4: Zidentyfikuj środki uzupełniające – jeśli mechanizm sam w sobie nie wystarcza, dodaj zabezpieczenia: szyfrowanie end-to-end z kluczami w EOG, pseudonimizację, segmentację danych, przeniesienie do regionu UE.
- Krok 5: Przeprowadź procedurę formalną – udokumentuj decyzje, podejmij potrzebne kroki kontraktowe i operacyjne.
- Krok 6: Monitoruj – TIA nie jest jednorazowym aktem. Zmiana prawa importera lub praktyki dostawcy wymaga aktualizacji oceny.
Z mojej praktyki wynika, że większość polskich firm średniej wielkości nie ma sformalizowanej TIA. To luka, która w razie kontroli UODO może skutkować zarzutem braku rozliczalności wobec Twojej firmy. Sporządzenie TIA – nawet w prostym formacie tabelarycznym – jest jednym z podstawowych działań, które warto wykonać.
Zobacz : Audyt RODO
Jakie klauzule warto dodać do umowy z dostawcą chmury?
W przypadku transferu danych poza EOG część klauzul wynika z wzorca SCC i nie podlega negocjacji. Pozostałe – zwłaszcza klauzule reagujące na sytuacje specyficzne dla relacji z dostawcą – mogą być negocjowane lub uzupełniane. Trzy obszary, w których warto mieć przygotowane brzmienia:
Klauzula wskazująca podstawę transferu poza EOG
Poniżej miejsce na konkretną propozycję brzmienia klauzuli, która jednoznacznie wskazuje, na jakiej podstawie odbywa się transfer danych poza EOG:
Sugerowane elementy klauzuli: wskazanie podstawy transferu (DPF, SCC, BCR), w przypadku SCC – wskazanie zastosowanego modułu, obowiązek importera do utrzymania certyfikacji DPF (jeśli dotyczy) i niezwłocznego informowania eksportera o jej utracie, mechanizm zmiany podstawy transferu w razie istotnej zmiany regulacyjnej.
Klauzula dotycząca żądań organów z państw trzecich
Poniżej miejsce na konkretną propozycję brzmienia klauzuli, która reguluje sytuację, gdy organy państwa importera zwracają się o ujawnienie danych:
Sugerowane elementy klauzuli: obowiązek niezwłocznego informowania eksportera o każdym żądaniu władz państwowych, obowiązek wykorzystania wszystkich dostępnych środków prawnych do zakwestionowania żądania, ograniczenie ujawnienia do absolutnego minimum, raport okresowy o liczbie i charakterze otrzymanych żądań, pełna współpraca z eksporterem w razie postępowania.
Co grozi za niezgodny z RODO transfer danych poza EOG?
Niezgodny z prawem transfer danych poza EOG to jedno z naruszeń objętych karami administracyjnymi w RODO: do 20 mln EUR lub 4% rocznego światowego obrotu, w zależności od tego, która kwota jest wyższa (art. 83 ust. 5 lit. c RODO). To dwukrotnie wyższy próg niż naruszenia podstawowych zasad RODO.
W praktyce decyzyjnej europejskich organów nadzorczych (głównie z Irlandii) kary za niezgodne transfery do USA sięgały kwot rekordowych. Decyzja organu z Irlandii z 2023 roku w sprawie Meta dotycząca transferu danych Facebook do USA na podstawie SCC bez wystarczających środków uzupełniających, skończyło się na 1,2 mld EUR. To skala, która nawet dużym koncernom robi różnicę.
Zgodne z prawem przetwarzanie danych w chmurze wymaga zatem nie tylko technicznej konfiguracji, ale także udokumentowanej oceny prawnej. Sankcje administracyjne to nie jedyne ryzyko. Dochodzi również odpowiedzialność cywilna wobec podmiotów danych (art. 82 RODO).
Kiedy warto przeprowadzić audyt transferów danych poza EOG?
Z mojej praktyki wynika, że są trzy momenty, w których zaangażowanie prawnika daje największy zwrot.
- Przed migracją – audyt mechanizmów transferu, ocena DPF i SCC w kontekście konkretnej konfiguracji, sporządzenie TIA. To optymalny moment.
- Przy okresowym przeglądzie zgodności – zwłaszcza po istotnych zmianach regulacyjnych (np. ewentualny wyrok Schrems III) lub po zmianach po stronie dostawcy (np. utrata certyfikacji DPF).
- Przy zmianie dostawcy lub regionu – każda zmiana lokalizacji przetwarzania wymaga ponownej oceny mechanizmu transferu i aktualizacji TIA.
- Po kontroli UODO (najmniej opłacalny moment) – wsparcie prawne jest możliwe, ale w warunkach postępowania rzadko prowadzi do istotnej zmiany pozycji.
Jeśli korzystasz z usług AWS, Google Cloud, Microsoft lub innych dostawców spoza EOG – a większość polskich firm korzysta – audyt prawny mechanizmów transferu i sporządzenie TIA powinno być jednym z podstawowych działań.
FAQ – transfer danych poza EOG, AWS, Google Cloud i RODO
Co to jest Privacy Shield i czy nadal obowiązuje po wyroku Schrems II?
Privacy Shield to ramy transferu danych między UE a USA z 2016 roku. TSUE unieważnił je w lipcu 2020 roku w wyroku Schrems II z powodu nieproporcjonalnego dostępu organów bezpieczeństwa USA do danych obywateli UE. Privacy Shield nie obowiązuje od 2020 roku. Jego następca – Data Privacy Framework – wszedł w życie w lipcu 2023 roku decyzją Komisji (UE) 2023/1795.
Jak podpisać DPA z AWS lub Google Cloud?
Standardowe DPA dostawców akceptuje się zazwyczaj w panelu administracyjnym konta. AWS i Google udostępnia je automatycznie. Indywidualna negocjacja klauzul jest ograniczona dla większości klientów – można jednak negocjować dodatkowe moduły dla wymogów sektorowych (DORA) lub dedykowane rozwiązania dla danych wrażliwych.
Czy certyfikacja Data Privacy Framework zastępuje standardowe klauzule umowne?
Dla transferów do firm certyfikowanych w DPF – tak, certyfikacja jest samodzielną podstawą transferu. AWS, Google Cloud i Microsoft są certyfikowane w DPF.
Zobacz : obsługa incydentów RODO
Jak bezpiecznie korzystać z chmury poza EOG – podsumowanie
Transfer danych poza EOG to obszar, w którym praktycznie każda polska firma korzystająca z chmury musi mieć udokumentowane decyzje prawne. Mechanizmy transferu danych – decyzja o adekwatności, SCC, BCR, DPF – to podstawa, ale samo ich wskazanie nie wystarcza. Po Schrems II konieczna jest ocena skutków transferu (TIA) oraz wdrożenie środków uzupełniających tam, gdzie sam mechanizm nie zapewnia poziomu ochrony porównywalnego z RODO.
Korzystanie z AWS, Google Cloud czy innych globalnych dostawców jest zgodne z prawem – ale wymaga świadomych decyzji konfiguracyjnych i kontraktowych. Przetwarzanie danych osobowych w chmurze publicznej spoza EOG stało się obszarem, w którym audyt prawny mechanizmów transferu, sporządzenie TIA i okresowy przegląd zgodności to działania, które obniżają ryzyko regulacyjne i pozwalają spokojnie patrzeć na ewentualną kontrolę UODO.
