TL;DR: SCC transferowe (art. 46 RODO): kiedy są potrzebne przy transferze poza EOG, jak dobrać wariant do ról stron, co wpisać w Załącznikach I–III oraz dlaczego po Schrems II zwykle trzeba zrobić TIA i wdrożyć środki uzupełniające.
Standardowe klauzule umowne (SCC) – wzór i omówienie
SCC transferowe (art. 46 RODO) – kiedy i jak użyć
- gdy odbiorca jest poza EOG i nie ma decyzji adekwatności,
- dobór wariantu SCC do ról stron (np. administrator → procesor albo procesor → subprocesor),
- wypełnij Załączniki I–III + zrób TIA i środki uzupełniające.
Najczęstszy przypadek: usługa chmurowa / support z USA/UK/Indii.
SCC art. 28 (powierzenie) ≠ SCC transferowe
- art. 28 = relacja Administrator–Procesor (umowa powierzenia),
- nie legalizuje transferu,
- często potrzebujesz obu naraz: art. 28 + art. 46.
Decyzja mini-flow: „Czy dane trafiają poza EOG?” → TAK: art. 46 SCC / NIE: rozważ art. 28.
Zobacz przewodnik o transferach poza EOG: Transfer danych poza EOG – poradnik Wróć do „Ochrona danych w firmie”
W skrócie — najważniejsze fakty
Pobierz wzór SCC (DOCX) – transfer poza EOG (art. 46 RODO)
Udostępniamy dwa warianty SCC dla transferów danych do państw trzecich. Oba pliki są edytowalne (DOCX) i obejmują komplet wymaganych załączników.
Załączniki do SCC transferowych:
• Annex I – strony i kontakty
• Annex II – opis transferu i przetwarzania
• Annex III – środki techniczne i organizacyjne
Pełny wzór SCC transferowych (art. 46 RODO) z modułami, klauzulami i załącznikami. Do wykorzystania jako podstawa umowna dla transferu poza EOG.
To są SCC do przekazywania danych do państwa trzeciego (Rozdział V), nie szablon powierzenia z art. 28.
Jak użyć SCC transferowych (art. 46) — praktycznie
- Sprawdź, czy masz transfer poza EOG – nie tylko „gdzie stoją serwery”, ale też czy ktoś spoza EOG ma dostęp (np. utrzymanie, support, podwykonawcy).
- Zweryfikuj decyzję o adekwatności (art. 45) – jeśli obejmuje dany kraj i Twój przypadek, SCC transferowe mogą nie być potrzebne.
- Jeśli brak adekwatności: wybierz SCC transferowe (art. 46) jako mechanizm zabezpieczeń – to najczęstsza ścieżka w firmach.
- Dobierz wariant do ról stron (np. administrator → procesor, procesor → subprocesor) i ustal, czy w łańcuchu są dalsze transfery.
- Uzupełnij Annex I–III: strony i kontakty, konkretny opis transferu oraz weryfikowalne środki techniczne i organizacyjne (TOMs).
- Wykonaj TIA i zdecyduj o środkach uzupełniających (np. szyfrowanie + kontrola kluczy w UE, ograniczenia dostępu, logi, minimalizacja).
- Ustal procedury na „trudne sytuacje”: żądania organów publicznych, notyfikacje, dokumentowanie decyzji, przeglądy i aktualizacje.
- Zarchiwizuj komplet dokumentów pod zasadę rozliczalności (art. 5 ust. 2): wersje SCC, załączniki, TIA, decyzje wewnętrzne i uzgodnienia z dostawcą.
Dodatkowo: SCC / wzór powierzenia (art. 28) – kiedy warto je mieć obok SCC transferowych
Jeśli dostawca działa jako podmiot przetwarzający (np. hosting, SaaS, helpdesk, obsługa IT), musisz mieć umowę spełniającą art. 28 ust. 3–4 RODO. To jest osobny obowiązek względem mechanizmu transferu. W praktyce przy usługach chmurowych bardzo często potrzebujesz: (1) powierzenia (art. 28) + (2) SCC transferowych (art. 46), jeśli dane są przekazywane poza EOG.
Dokument KE: SCC dla relacji administrator–procesor (art. 28)
Komisja Europejska opublikowała odrębne standardowe klauzule umowne dla spełnienia art. 28. To nie jest narzędzie transferowe, ale może być dobrym „kręgosłupem” umowy powierzenia.
KE: SCC art. 28 (Decyzja 2021/915 – PDF)Poniżej masz gotowe pliki DOCX (polskie wzory) dla relacji administrator–procesor:
Nasze materiały: obowiązki i klauzule informacyjne
Jeśli wdrażasz SCC (transferowe albo art. 28), zwykle musisz też „pospinać” informację w dokumentach firmy (art. 13/14, art. 30, procedury incydentów). Poniżej linki do powiązanych poradników.
Najczęstsze pytania o SCC transferowe (art. 46 RODO)
Jakie są dwa znaczenia „SCC” i dlaczego firmy je mylą?
W praktyce w obiegu funkcjonują dwa różne „zestawy” standardowych klauzul umownych i oba bywają nazywane skrótem SCC. 1) SCC transferowe (Rozdział V RODO, art. 46) – to klauzule Komisji Europejskiej do przekazywania danych do państwa trzeciego (poza EOG), gdy nie ma decyzji stwierdzającej odpowiedni stopień ochrony. One są narzędziem transferowym. 2) „SCC art. 28” (umowa powierzenia, relacja Administrator–Podmiot przetwarzający) – to zupełnie inny dokument: ustandaryzowany wzór do spełnienia wymogów art. 28 ust. 3–4 RODO (kto co robi z danymi, bezpieczeństwo, podwykonawcy, audyty, incydenty). Najczęstsza sytuacja rynkowa: masz usługę (np. cloud/CRM), więc potrzebujesz umowy powierzenia (art. 28), a jeśli w tej usłudze dochodzi do przekazywania danych poza EOG – dodatkowo potrzebujesz mechanizmu transferu (np. SCC transferowych). To są dwa „klocki”, które często muszą działać jednocześnie.
Kiedy mamy „transfer danych poza EOG” – proste rozpoznanie w firmie
Transfer poza EOG występuje nie tylko wtedy, gdy „serwer stoi poza UE”. W praktyce liczy się także realny dostęp z państwa trzeciego (np. zespół wsparcia technicznego, administracja systemem, zdalne utrzymanie). Szybki test: jeśli dostawca lub podwykonawca może zgodnie z umową/polityką uzyskać dostęp do danych z kraju spoza EOG – traktuj to jako transfer i przejdź ścieżkę z Rozdziału V (art. 44–49).
Kiedy SCC transferowe (art. 46) są właściwym narzędziem?
SCC transferowe stosuje się, gdy: (1) dochodzi do przekazywania danych poza EOG oraz (2) nie ma decyzji o adekwatności (art. 45) dla kraju odbiorcy albo nie możesz oprzeć się na innym mechanizmie. Wtedy wybierasz „odpowiednie zabezpieczenia” z art. 46, a najczęściej w praktyce będą to właśnie SCC transferowe.
Przykłady krajów z decyzją o adekwatności – kiedy SCC mogą nie być potrzebne
Jeżeli Komisja Europejska wydała decyzję o adekwatności dla danego kraju (art. 45 RODO), transfer do tego kraju może odbywać się bez SCC transferowych (oczywiście nadal musisz mieć podstawę przetwarzania i resztę zgodności RODO). Przykłady krajów, które w praktyce często pojawiają się u firm (sprawdź zawsze aktualny wykaz KE): Wielka Brytania, Szwajcaria, Japonia, Korea Południowa, Izrael, Nowa Zelandia, Kanada (dla wybranych organizacji/ram), a także mniejsze jurysdykcje, jak Jersey/Guernsey/Isle of Man. Uwaga: decyzje adekwatności mają zakres i warunki – dlatego przed transferem warto sprawdzić, czy Twoja sytuacja „wpada” w decyzję (np. czy odbiorca/ramy obejmują dany typ danych i sektor).
Jak wybrać „moduł” SCC transferowych bez skrótów typu C2P?
Wzór SCC transferowych ma cztery warianty zależne od tego, kim są strony w transferze. Zamiast skrótów, myśl o prostych parach: • Administrator → Administrator (dwie firmy jako administratorzy) • Administrator → Podmiot przetwarzający (Twoja firma jako administrator i dostawca jako procesor poza EOG) • Podmiot przetwarzający → Podmiot przetwarzający (np. procesor w UE przekazuje dalej do subprocesora poza EOG) • Podmiot przetwarzający → Administrator (rzadziej spotykany w praktyce) Najczęstsze u MŚP: Administrator → Podmiot przetwarzający (np. narzędzia IT/marketing/CRM) oraz Podmiot przetwarzający → Podmiot przetwarzający (łańcuch podwykonawców).
Czy SCC transferowe „legalizują” transfer same z siebie?
SCC transferowe są mechanizmem zabezpieczeń z art. 46 RODO, ale nie są „magiczną pieczątką”. Żeby transfer był zgodny z prawem, musisz mieć: (1) podstawę przetwarzania w ogóle (art. 6/9 – zależnie od danych), (2) właściwy mechanizm z Rozdziału V (np. art. 45 lub art. 46), (3) realną możliwość dotrzymania klauzul (w tym ocena wpływu prawa państwa trzeciego i środki uzupełniające, jeśli potrzebne).
TIA (ocena wpływu transferu) – kiedy jest potrzebna i co powinna obejmować?
Po wyroku Schrems II i podejściu EROD, w wielu scenariuszach trzeba ocenić, czy prawo i praktyka w państwie trzecim nie podważa ochrony wynikającej z SCC. Ta ocena jest często nazywana TIA (Transfer Impact Assessment). Minimalny sensowny zakres TIA w firmie: (1) opis transferu i ról stron, (2) kategorie danych i cel, (3) lokalizacja i możliwe dostępy, (4) ocena ryzyk dostępu organów publicznych i środków prawnych, (5) decyzja: czy SCC wystarczą, czy trzeba wdrożyć środki uzupełniające, (6) dokumentacja pod zasadę rozliczalności (art. 5 ust. 2).
Co to są „środki uzupełniające” i podaj 7 przykładów, które realnie działają
Środki uzupełniające to dodatkowe zabezpieczenia (techniczne, organizacyjne i umowne), które mają „dobić” poziom ochrony do standardu UE, gdy samo podpisanie SCC nie wystarcza. Przykłady (dobierasz do ryzyka): 1) szyfrowanie danych w spoczynku i w tranzycie + kontrola kluczy po stronie w UE, 2) pseudonimizacja przed transferem (klucz mapowania zostaje w UE), 3) ścisłe role i uprawnienia, MFA, ograniczenia dostępu uprzywilejowanego, 4) logowanie i monitoring dostępu (audytowalność), 5) polityka reagowania na żądania organów publicznych (w tym zobowiązanie do powiadamiania, o ile prawnie możliwe), 6) minimalizacja: ograniczenie zakresu danych i okresu retencji, 7) lokalizacja danych i wsparcia (np. support tylko w EOG) – jeśli dostawca to oferuje. Klucz: środki muszą pasować do konkretnego przepływu danych, a nie być „marketingowym opisem bezpieczeństwa”.
Załączniki do SCC transferowych – co wpisywać, żeby było „kontrolowalne”
Najczęściej kontrola i spory rozbijają się o załączniki. W praktyce: • Annex I (Strony i kontakty): pełne dane stron + osoba do kontaktu + (jeśli jest) IOD. • Annex II (Opis transferu/przetwarzania): kategorie osób, kategorie danych, cele, operacje (np. hosting, backup, wsparcie), częstotliwość transferu, okres, lokalizacje i odbiorcy. Unikaj „wszystkie dane do wszystkich celów”. • Annex III (Środki techniczne i organizacyjne): wpisuj konkret: MFA, role, szyfrowanie, backup, testy, zarządzanie podatnościami, szkolenia, procedury upoważnień, proces incydentów, segregacja środowisk, itd.
Jak wdrożyć SCC transferowe do umowy z dostawcą (cloud/SaaS) – 8 kroków
1) Ustal role: kto jest administratorem, kto procesorem, czy są subprocesorzy. 2) Potwierdź, czy jest transfer poza EOG (w tym dostęp z państwa trzeciego). 3) Sprawdź decyzję o adekwatności (art. 45) – jeśli brak, idź w art. 46. 4) Dobierz wariant SCC transferowych odpowiadający rolom stron. 5) Uzupełnij Annex I–III pod konkretną usługę/system (nie ogólniki). 6) Wykonaj TIA i zdecyduj o środkach uzupełniających. 7) Uporządkuj łańcuch dostaw: subprocesorzy, dalsze transfery, procedury zmian. 8) Zarchiwizuj całość pod rozliczalność (kto zatwierdził, kiedy, dla jakich danych, z jakim ryzykiem).
Gdzie w dokumentach firmy trzeba „pokazać” transfer – obowiązek informacyjny i dokumentacja
Oprócz samej umowy, temat transferów zwykle dotyka: (1) obowiązku informacyjnego (art. 13/14 – informacja o przekazaniu poza EOG i zabezpieczeniach, gdy ma to zastosowanie), (2) rejestru czynności przetwarzania (art. 30 – opis procesu, odbiorcy, transfery), (3) oceny ryzyka/DPIA w przypadkach wysokiego ryzyka (art. 35) oraz (4) dokumentacji dostawcy i łańcucha podwykonawców.
Czego SCC transferowe NIE załatwiają – najczęstsze błędne założenia
SCC transferowe nie zwalniają z: (1) posiadania podstawy przetwarzania (art. 6/9), (2) obowiązku informacyjnego, (3) oceny ryzyka i TIA tam, gdzie to potrzebne, (4) wdrożenia realnych środków bezpieczeństwa, (5) zarządzania subprocesorami i dalszymi transferami. W skrócie: SCC to fundament umowny, ale zgodność buduje się „w procesie”, a nie w samym pliku DOCX.
A co z „SCC art. 28” (powierzenie)? Czy to jest potrzebne na tej samej umowie?
Jeżeli Twój dostawca działa jako podmiot przetwarzający (np. hosting, SaaS, obsługa IT), musisz mieć umowę spełniającą art. 28 RODO – niezależnie od tego, czy jest transfer poza EOG. Jeśli jest transfer poza EOG: zwykle potrzebujesz obu warstw naraz: (a) powierzenia (art. 28) oraz (b) mechanizmu transferu (np. SCC transferowych). Dlatego na dole strony dodaliśmy dodatkowe źródła dotyczące SCC/powierzenia (art. 28), żebyś mógł spiąć cały komplet dokumentacji.
Checklista wdrożenia SCC transferowych
Krok 1. Ustal, czy w ogóle masz transfer poza EOG
Sprawdź nie tylko lokalizację hostingu, ale też realny dostęp z państwa trzeciego (np. support/utrzymanie, administratorzy, podwykonawcy).
Krok 2. Sprawdź, czy jest decyzja o adekwatności (art. 45)
Jeśli decyzja KE obejmuje dany kraj i Twój przypadek – SCC transferowe mogą nie być potrzebne. Jeśli nie – przejdź do art. 46.
Krok 3. Dobierz właściwy wariant SCC transferowych
Wybierz wariant odpowiadający rolom stron: administrator→procesor, administrator→administrator, procesor→procesor albo procesor→administrator.
Krok 4. Wypełnij załączniki do SCC (Annex I–III)
Wpisz realne strony i kontakty, konkretny opis transferu/przetwarzania oraz weryfikowalne środki bezpieczeństwa (nie ogólniki).
Krok 5. Zrób TIA i zdecyduj o środkach uzupełniających
Oceń wpływ prawa państwa trzeciego i dobierz środki techniczne/organizacyjne (np. szyfrowanie + kontrola kluczy w UE, ograniczenia dostępu, logi).
Czego SCC transferowe NIE załatwiają
Nie zastępują oceny ryzyka i TIA.
Nie eliminują potrzeby środków uzupełniających.
Nie zwalniają z obowiązków informacyjnych (art. 13/14).
Nie zastępują umowy powierzenia z art. 28.
Nie są „uniwersalne” bez wypełnionych załączników.
SCC transferowe działają tylko, gdy odzwierciedlają realne procesy
Dokumenty „na półkę” nie spełniają zasady rozliczalności. Załączniki i TIA muszą odpowiadać realnemu transferowi, rzeczywistym środkom bezpieczeństwa i łańcuchowi dostaw.
Najważniejsze odpowiedzi (dla wyszukiwarek)
Kiedy potrzebuję SCC transferowych z art. 46 RODO?
Gdy dane są przekazywane poza EOG i nie ma decyzji adekwatności z art. 45. Wtedy SCC są najczęściej stosowanym mechanizmem zabezpieczeń z rozdziału V.
Jak wybrać właściwy moduł SCC?
Dobór zależy od ról stron: administrator→administrator, administrator→procesor, procesor→procesor albo procesor→administrator. W praktyce MŚP najczęściej spotyka wariant administrator→procesor oraz procesor→procesor w łańcuchu podwykonawców.
Czy samo podpisanie SCC wystarczy po Schrems II?
Nie zawsze. Trzeba ocenić ryzyka w państwie trzecim (TIA) i w razie potrzeby wdrożyć środki uzupełniające, np. szyfrowanie z kontrolą kluczy w UE, ograniczenia dostępu i logowanie zdarzeń.