RODO art. 32: bezpieczeństwo przetwarzania

W jednym zdaniu. Artykuł 32 RODO nakłada na administratorów i podmioty przetwarzające obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych zapewniających bezpieczeństwo danych, a dobór tych środków zależy od rzeczywistego ryzyka dla praw i wolności osób.

Najważniejsze punkty

• Art. 32 ust. 1 wymienia cztery grupy przykładowych środków: pseudonimizację i szyfrowanie; ciągłą poufność, integralność, dostępność i odporność; przywracanie dostępności; regularne testowanie i ocenę skuteczności.
• Wybór środków opiera się na analizie ryzyka (art. 32 ust. 2).
• Naruszenie art. 32 — sankcja do 10 mln EUR lub 2% obrotu (art. 83 ust. 4).
• Sprawa Morele.net pokazuje znaczenie testowania i monitorowania; decyzja została ponownie rozpatrzona w 2024 r.
• Standardy ISO i NIST mogą pomagać, lecz nie zastępują oceny ryzyka wymaganej przez RODO.
• Środki muszą podlegać regularnym testom i ewaluacji.

Treść normatywna art. 32

Art. 32 ust. 1 wymaga, aby administrator i podmiot przetwarzający wdrożyli “odpowiednie środki techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający ryzyku”. Wskazuje cztery grupy przykładowych środków w lit. a–d, ale lista nie jest wyczerpująca. Wybór środków uwzględnia: stan wiedzy technicznej, koszt wdrożenia, charakter, zakres, kontekst, cele przetwarzania, ryzyko dla osób fizycznych — te same czynniki, które wchodzą do oceny skutków dla ochrony danych (DPIA), gdy ryzyko jest wysokie. Poziom zabezpieczeń należy odnieść do zasad przetwarzania z art. 5, a skutki ich naruszenia opisuje tryb zgłoszenia naruszenia z art. 33 oraz katalog kar administracyjnych. Elementem organizacyjnym bezpieczeństwa jest gotowa procedura naruszenia ochrony danych (wzór) uruchamiana po wykryciu incydentu.

Pseudonimizacja i szyfrowanie

Pseudonimizacja (art. 4 pkt 5) to przetwarzanie w taki sposób, aby danych nie można było przypisać konkretnej osobie bez dodatkowych informacji przechowywanych osobno. Szyfrowanie danych w spoczynku i w transmisji to częste środki ochrony, lecz technologię dobiera się do systemu i ryzyka. Hasła należy chronić właściwymi mechanizmami, a decyzję techniczną okresowo weryfikować; sam numer algorytmu nie jest gwarancją zgodności.

Integralność i dostępność

Art. 32 ust. 1 lit. b i c wymaga zdolności do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów oraz zdolności szybkiego przywrócenia dostępności i dostępu po incydencie. W praktyce: kopie zapasowe (backup 3-2-1), Disaster Recovery Plan, Business Continuity Plan, replikacja, monitorowanie systemu.

Przykład: dostęp do danych pracowników

Firma przechowuje dokumenty kadrowe w chmurze. Dotąd wszyscy kierownicy działów mają dostęp do całego katalogu. Pierwszy krok to rozdzielenie ról: kierownik potrzebuje danych swojego zespołu do określonych czynności, dział płac innych danych, a administrator techniczny może potrzebować dostępu awaryjnego. Samo usunięcie ogólnej grupy nie wystarczy, jeżeli wcześniejsze linki do folderów nadal działają. Zespół testuje konto zwykłego kierownika, konto byłego pracownika i konto dostawcy, aby zobaczyć, jakie pliki można otworzyć. Wynik testu zapisuje wraz z datą i poprawką.

Następnie ustala sposób nadawania i odbierania dostępu. Zmiana stanowiska powinna wywołać przegląd, a odejście z pracy skutkować zamknięciem konta i sesji. Dostęp awaryjny można dopuścić z dodatkową autoryzacją i logiem. MFA może znacznie ograniczyć ryzyko przejęcia konta, ale nie naprawi błędnego przypisania uprawnień. Taki przykład pokazuje, dlaczego art. 32 wymaga kombinacji kontroli organizacyjnych i technicznych, a także ich okresowego testowania.

Przykład: kopia zapasowa i odtwarzanie

Kopia zapasowa jest użyteczna dopiero wtedy, gdy można z niej przywrócić właściwe dane w potrzebnym czasie. Ustal, które dane są krytyczne, jaką utratę najnowszych zmian proces może zaakceptować i po jakiej przerwie szkoda dla osób staje się istotna. Zrób próbę odtworzenia wybranego systemu w odseparowanym środowisku. Sprawdź nie tylko to, czy plik się otwiera, lecz także integralność rekordów, uprawnienia i brak przypadkowego ujawnienia. Zapisz czas próby, błąd i decyzję o poprawce. Jeżeli kopia jest szyfrowana, sprawdź dostępność klucza po awarii pierwotnego systemu.

Zgodnie z art. 32 ust. 1 lit. c ważna jest zdolność szybkiego przywrócenia dostępności danych po incydencie fizycznym lub technicznym. Nie oznacza to, że każda organizacja musi mieć identyczną architekturę trzech kopii. Dla niewielkiej usługi różnica między bezpieczną kopią poza głównym systemem a brakiem jakiegokolwiek odtwarzania może być większa niż różnica między dwoma drogimi platformami backupu. Kontrolę dobiera się do danych, ich ilości i potrzeb osób.

Testowanie i ewaluacja

Art. 32 ust. 1 lit. d wymaga “regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych”. Program może obejmować testy penetracyjne, przegląd kodu, skanowanie podatności, ćwiczenia odtwarzania i kontrolę uprawnień. Częstotliwość wynika z ryzyka oraz zmian systemu; art. 32 nie ustala jednego rocznego ani kwartalnego terminu dla każdej organizacji.

Testowanie, które naprawdę sprawdza skuteczność

Skan podatności wykrywa znane problemy, ale nie dowodzi, że pracownik nie wyśle pliku do niewłaściwego odbiorcy. Pentest aplikacji nie pokaże, czy po odejściu pracownika odebrano jego uprawnienia. Dlatego plan testów powinien obejmować różne mechanizmy: przegląd uprawnień, próbę odtworzenia, kontrolę logów, ćwiczenie reakcji na incydent i test najważniejszych funkcji aplikacji. Wynik „przeszło” potrzebuje kryterium, a wynik „nie przeszło” właściciela poprawki i ponownej próby. Mierzenie skuteczności jest odrębną czynnością od zakupu narzędzia.

Po znaczącej zmianie systemu albo po incydencie ocena ryzyka wraca do zespołu. Nowy integrator może uzyskać dostęp do danych, nowy kanał eksportu może omijać dotychczasowy log, a przeniesienie usługi do chmury może zmienić role dostawców. Zaktualizuj wtedy umowę powierzenia i wymagania dla podmiotu przetwarzającego, jeśli jest on zaangażowany. Certyfikat dostawcy może być przydatnym dowodem dla określonego zakresu i daty, ale nie zastępuje testu konfiguracji konkretnego klienta.

Analiza ryzyka jako podstawa wyboru środków

Art. 32 ust. 2 nakazuje uwzględnić ryzyko związane z “przypadkowym lub niezgodnym z prawem zniszczeniem, utratą, modyfikacją, nieuprawnionym ujawnieniem lub nieuprawnionym dostępem”. Metodyka: ENISA Risk Management Framework, ISO 27005, NIST 800-30, OCTAVE. Wynik: macierz ryzyka, priorytetyzacja środków, akceptowalny poziom ryzyka rezydualnego.

Od zagrożenia do konkretnej kontroli

Art. 32 nie jest zakupową listą programów. Zespół powinien najpierw zidentyfikować proces, dane, osoby i możliwy skutek zdarzenia. W systemie kadrowym nieuprawniony odczyt informacji o zdrowiu może naruszyć prywatność pracowników i prowadzić do dyskryminacji; utrata dostępności może uniemożliwić wypłatę. W sklepie internetowym ryzyko obejmuje przejęcie kont, podszywanie się pod klienta i utratę historii zamówień. Te scenariusze nie wymagają identycznych środków. Oba mogą wymagać kontroli dostępu, ale inne będą zakres uprawnień, czas przechowywania logów i procedura odzyskiwania.

Dla każdego scenariusza zapisz prawdopodobieństwo, możliwą wagę szkody dla osoby, istniejące zabezpieczenia i ryzyko po ich zastosowaniu. Właściciel procesu powinien potwierdzić, czy opis odpowiada temu, jak ludzie rzeczywiście pracują. Administrator systemu potwierdza, czy kontrola jest włączona; specjalista ochrony danych ocenia skutki dla osób. Przy wysokim ryzyku sprawdź również, czy potrzebna jest ocena skutków dla ochrony danych. Nie zamieniaj tej oceny w tabelę kolorów bez uzasadnienia: gdy wynik zmienia się z czerwonego na zielony, wskaż konkretny mechanizm i dowód jego działania.

Polskie standardy i wytyczne

Przykłady środków organizacyjnych

• Polityka bezpieczeństwa zatwierdzona przez zarząd.
• Procedury kontroli dostępu (least privilege).
• Procedura zarządzania kontami (onboarding/offboarding).
• Klauzule poufności w umowach z pracownikami i kontrahentami.
• Szkolenia dostosowane do ról i zmian zagrożeń, z weryfikacją skuteczności.
• Procedura incydentów (Incident Response Plan).
• Dziennik zdarzeń bezpieczeństwa (SIEM/logi).

Przykłady środków technicznych

• MFA dla wszystkich kont administracyjnych.
• Szyfrowanie dysków (BitLocker/FileVault) i bazy danych.
• Ochrona transmisji odpowiednim aktualnym protokołem.
• Firewall + WAF dla aplikacji webowych.
• Endpoint Detection and Response (EDR).
• Terminy usuwania podatności wynikające z ich ważności i ekspozycji systemu.
• Kopie zapasowe z testem przywrócenia dobranym do ryzyka i dopuszczalnego czasu przerwy.

Sprawa Morele.net — naruszenie art. 32

Sprawa Morele.net dotyczyła bezpieczeństwa danych klientów i adekwatności zastosowanych środków. Po kontroli sądowej organ ponownie rozpatrzył sprawę; dlatego przywoływanie wyłącznie pierwszej decyzji z 2019 r. bez późniejszego rozstrzygnięcia byłoby mylące. Praktyczna nauka to konieczność wykazania, że środki dostępu, monitorowania i testowania odpowiadały rzeczywistemu ryzyku.

Sprawa Virgin Mobile Polska

Sprawa Virgin Mobile pokazuje potrzebę weryfikacji zabezpieczeń aplikacji w praktyce. W komunikacie UODO opisano decyzję dotyczącą środków technicznych i organizacyjnych oraz jej dalszy przebieg; aktualny stan sprawy należy sprawdzać w oficjalnych materiałach zamiast przenosić historyczną kwotę kary do dzisiejszego poradnika.

Bezpieczeństwo w łańcuchu dostaw (art. 28)

Administrator odpowiada za bezpieczeństwo również po stronie procesora. Art. 28 ust. 3 lit. c wymaga zobowiązania procesora do podjęcia wszystkich środków z art. 32. Opis konkretnych zabezpieczeń w umowie lub aktualizowanym załączniku TOMs może ułatwić weryfikację; nazwa i osobna forma załącznika nie są wymogiem ustawowym. Umowa ma też zapewniać informacje potrzebne do wykazania zgodności i umożliwiać audyty zgodnie z art. 28 ust. 3 lit. h. Art. 28 nie nakłada powszechnego obowiązku posiadania certyfikatu ISO lub SOC 2.

Dostawca, transfer i zakres testu

Zewnętrzna firma utrzymująca system nie zwalnia administratora z oceny bezpieczeństwa. Wybór procesora wymaga sprawdzenia gwarancji, zakresu dostępu, podwykonawców i sposobu raportowania incydentu. Dane pracowników u pracodawcy są dobrym przykładem: dostawca systemu kadrowego może mieć dostęp techniczny, choć kadry pozostają odpowiedzialne za określenie celów i uprawnień. Sprawdź uprawnienia serwisowe, logowanie działań administratorów oraz usuwanie dostępu po zakończeniu umowy. Sam certyfikat dostawcy nie dowodzi, że klient włączył MFA i prawidłowo skonfigurował role.

Jeśli administrator lub jego dostawca umożliwia dostęp z państwa trzeciego, dodatkowo oceń transfery poza EOG. Szyfrowanie jest ważną kontrolą bezpieczeństwa, ale nie zastępuje mechanizmu z rozdziału V RODO. Sporządź mapę przepływu: kto może odczytać dane, skąd, kiedy i na jakiej podstawie. Potem sprawdź, czy zapis w umowie, konfiguracja kont i praktyka pomocy technicznej odpowiadają sobie nawzajem.

Po wdrożeniu nie kończ testów na jednym udanym skanie. Ustal częstotliwość kontroli na podstawie zmian i ryzyka: aplikacja często aktualizowana wymaga innego cyklu niż odłączone archiwum. Każdy raport powinien wskazać zakres, datę, ograniczenia metody i wynik ponownego testu po naprawie. Jeżeli test pomijał integrację zewnętrzną, nie podpisuj oświadczenia, że sprawdzono cały proces. W ten sposób dokumentacja wyjaśnia, co rzeczywiście było zabezpieczone w dniu incydentu, a czego jeszcze nie oceniono.

Mapa drogowa wdrożenia art. 32

Krok 1 — inwentaryzacja systemów i danych. Krok 2 — analiza ryzyka (zagrożenia, podatności, wpływ). Krok 3 — wybór środków (techniczne i organizacyjne). Krok 4 — wdrożenie z dokumentacją. Krok 5 — testy i audyt. Krok 6 — przegląd roczny i aktualizacja. Zobacz też angielską GDPR Article 32 guide oraz security measures.

Dla kierownictwa: cztery mierzalne pytania

Ile krytycznych systemów ma właściciela ryzyka i aktualny opis danych? Ile kont uprzywilejowanych skontrolowano po zmianie pracowników? Kiedy ostatnio przywrócono dane z kopii w próbie, a nie tylko wykonano kopię? Ile istotnych luk pozostaje po terminie ich usunięcia? Odpowiedzi nie są certyfikatem zgodności, ale pokazują, czy proces żyje. Kierownictwo może wtedy przydzielać środki tam, gdzie brak kontroli powoduje realną szkodę dla osób. Takie podejście odpowiada zasadzie rozliczalności i pozwala wyjaśnić dobór zabezpieczeń podczas kontroli.

Decyzje i ostrożność przy porównywaniu kar

W sprawach Morele.net i Virgin Mobile urząd badał konkretne zabezpieczenia, historię naruszenia i dowody ich działania. Warto odczytać pełną decyzję, a nie kopiować kwotę z innego roku: rozstrzygnięcia podlegały kontroli sądowej i ponownemu rozpatrzeniu. Komunikat UODO o Morele.net opisuje nową decyzję z 2024 r. na ponad 3,8 mln zł. Informacja UODO o Virgin Mobile opisuje decyzję i jej przebieg. Nie traktuj żadnej kwoty jako taryfy za jeden brakujący środek.

Co zapisać po incydencie

Gdy nastąpi incydent, zbierz oś czasu wykrycia, systemy i dane, decyzje o ograniczeniu skutków, wyniki kopii i logi. Następnie oceń osobno, czy powstało naruszenie ochrony danych osobowych wymagające zgłoszenia z art. 33 i czy osoby wymagają powiadomienia zgodnie z art. 34. Naruszenie art. 32 nie wynika automatycznie z samego faktu ataku; organ bada adekwatność środków do wcześniejszego ryzyka. Również brak wycieku nie dowodzi, że system był bezpieczny. Wewnętrzny raport powinien wskazać, które kontrole działały, które zawiodły i dlaczego, oraz termin poprawy.

Egzekucja UODO i sankcje za art. 32

Wymiar kar za art. 32 mieści się w niższej kategorii sankcji RODO (art. 83 ust. 4, do 10 mln EUR lub 2% obrotu globalnego), ale praktycznie często łączy się z naruszeniem art. 5 ust. 1 lit. f (integralność), aktywując wyższą kategorię (art. 83 ust. 5, do 20 mln EUR lub 4%). Strategia obrony: dokumentacja analizy ryzyka z datą sprzed incydentu, certyfikat ISO 27001 lub SOC 2 Type II, raporty pentestów, dziennik patchowania, log szkoleń bezpieczeństwa. Nie istnieje ustawowy procent obniżki za certyfikat lub samą deklarację o dobrych środkach. Organ ocenia okoliczności konkretnej sprawy według art. 83 ust. 2 RODO. Patrz Kary UODO 2025, Zgłoszenie naruszenia, umowa powierzenia wzór.

FAQ

Czy małe firmy też muszą stosować art. 32?

Tak. Art. 32 nie zwalnia MŚP, ale skala środków powinna być proporcjonalna do ryzyka i wielkości operacji. W praktyce warto ocenić MFA, kopie zapasowe, bezpieczne przechowywanie haseł i szkolenia, ale nie istnieje jednakowa ustawowa lista minimalna dla każdej firmy.

Czy szyfrowanie jest obowiązkowe?

Nie jest uniwersalnie obowiązkowe w każdym systemie, lecz art. 32 ust. 1 lit. a wymienia je jako przykład. Przy danych wrażliwych lub finansowych brak odpowiedniego szyfrowania może mieć znaczenie w ocenie konkretnego ryzyka; trzeba też uwzględnić inne zastosowane środki i rzeczywisty sposób dostępu.

Jak często prowadzić testy penetracyjne?

Art. 32 wymaga regularnej oceny skuteczności, ale nie wyznacza uniwersalnego odstępu dla pentestów. Ustal harmonogram na podstawie ryzyka, częstotliwości zmian i podatności, a po poważnej zmianie sprawdź krytyczne funkcje ponownie.

Co to są TOMs?

Technical and Organisational Measures to opis stosowanych zabezpieczeń technicznych i organizacyjnych. Może stanowić załącznik do umowy powierzenia, ale art. 28 ust. 3 lit. c wymaga zobowiązania do środków z art. 32, nie dokumentu o określonej nazwie.

Czy ISO 27001 wystarcza do zgodności z art. 32?

ISO 27001 jest dobrym fundamentem, ale nie obejmuje wszystkich wymogów RODO. W zależności od ryzyka można sięgnąć po ISO 27701, ale trzeba osobno wykazać spełnienie wymogów art. 25 i 32 RODO.

Jakie hasła i polityki haseł akceptuje UODO?

Nie ma jednej zatwierdzonej przez UODO długości hasła, liczby nieudanych prób lub obowiązkowego algorytmu dla wszystkich usług. Dobierz uwierzytelnianie, ograniczanie prób, bezpieczne przechowywanie poświadczeń i MFA do zagrożeń oraz weryfikuj działanie.

Czy backup w chmurze poza UE narusza art. 32?

Sama lokalizacja nie rozstrzyga bezpieczeństwa. Oceń szyfrowanie, dostęp, odtwarzanie i umowę z dostawcą. Jeżeli dochodzi do przekazania danych do państwa trzeciego, niezależnie sprawdź rozdział V RODO i odpowiedni mechanizm transferu.

Jak art. 32 odnosi się do AI i uczenia maszynowego?

Jeżeli system AI przetwarza dane osobowe, art. 32 nadal wymaga środków odpowiadających ryzyku: kontroli dostępu do danych wejściowych, ograniczenia eksportu, monitorowania i testowania. Dodatkowe wymogi innego prawa zależą od konkretnego systemu i terminu stosowania.

Podstawa prawna i źródła

• Rozporządzenie (UE) 2016/679 (RODO) — pełny tekst, EUR-Lex
• Urząd Ochrony Danych Osobowych (UODO)
• Europejska Rada Ochrony Danych (EROD) — wytyczne