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 niedopełnienie tego obowiązku było podstawą polskich kar od 1 do 4,9 mln zł.
Najważniejsze punkty
- Art. 32 wskazuje 4 przykładowe środki: pseudonimizacja, szyfrowanie, integralność, kopie zapasowe.
- 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).
- Morele.net 2,8 mln zł — sztandarowa polska sprawa.
- Standard de facto: ISO 27001, ISO 27701, NIST CSF.
- Środki muszą podlegać regularnym testom i ewaluacji.
1. 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 przykładowe środki, 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.
2. 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 obejmuje dane w spoczynku (AES-256), w tranzycie (TLS 1.3), oraz końcowe szyfrowanie (E2E w komunikacji). UODO traktuje brak szyfrowania bazy haseł (Morele.net) jako naruszenie art. 32.
3. 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.
4. Testowanie i ewaluacja
Art. 32 ust. 1 lit. d wymaga “regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych”. Praktyka: testy penetracyjne minimum raz w roku, skanowanie podatności (Vulnerability Assessment) co kwartał, audyt SOC 2 lub ISO 27001, code review aplikacji, symulacje phishingowe.
5. 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.
6. Polskie standardy i wytyczne
| Standard | Zakres |
|---|---|
| KSC (ustawa o KSC) | infrastruktura krytyczna |
| Rekomendacja D KNF | banki |
| ISO 27001 | system zarządzania bezpieczeństwem |
| ISO 27701 | system zarządzania prywatnością |
| NIST CSF | framework cybersecurity |
| OWASP ASVS | aplikacje webowe |
7. Środki organizacyjne — minimum
- 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 bezpieczeństwa min. raz w roku, weryfikacja.
- Procedura incydentów (Incident Response Plan).
- Dziennik zdarzeń bezpieczeństwa (SIEM/logi).
8. Środki techniczne — minimum
- MFA dla wszystkich kont administracyjnych.
- Szyfrowanie dysków (BitLocker/FileVault) i bazy danych.
- TLS 1.3 dla całej komunikacji zewnętrznej.
- Firewall + WAF dla aplikacji webowych.
- Endpoint Detection and Response (EDR).
- Patching systemu operacyjnego w 30 dni, krytyczne w 7 dni.
- Kopie zapasowe testowane przez przywrócenie raz w roku.
9. Sprawa Morele.net — naruszenie art. 32
Decyzja DKN.5130.2484.2019 wskazała następujące braki Morele.net: brak adekwatnego mechanizmu autoryzacji systemu rat (przesyłanie hasła w URL), brak testów penetracyjnych, brak monitorowania anomalii w logach, brak procedury wykrywania włamań. UODO ustalił, że 2,2 mln rekordów wyciekło z powodu fundamentalnych braków technicznych.
10. Sprawa Virgin Mobile Polska
Decyzja DKN.5112.1.2020 — kara 1 968 524 zł za niewystarczające środki techniczne i organizacyjne, które umożliwiły pobranie danych klientów z systemu (luka w aplikacji internetowej). UODO podkreślił, że nawet po wykryciu podatności firma nie wdrożyła pełnej weryfikacji wszystkich endpointów aplikacji.
11. Bezpieczeństwo w łańcuchu dostaw (art. 28)
Administrator odpowiada za bezpieczeństwo również po stronie procesora. Umowa powierzenia musi określać konkretne środki bezpieczeństwa (art. 28 ust. 3 lit. c). Praktyka: załącznik bezpieczeństwa (TOMs — Technical and Organisational Measures), prawo do audytu, obowiązek certyfikacji (ISO 27001 lub SOC 2 dla SaaS).
12. 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.
13. Polskie sprawy enforcement opierające się na art. 32
Poza Morele.net i Virgin Mobile UODO konsekwentnie wykorzystuje art. 32 jako podstawę kar. Fortum Marketing (DKN.5131.31.2021, 4 911 732 zł) — brak weryfikacji środków bezpieczeństwa procesora skutkujący nieuprawnionym dostępem do 137 tys. rekordów. ID Finance Poland (1 069 850 zł) — niewystarczające zabezpieczenia bazy danych klientów platformy pożyczkowej, wyciek 5,5 mln rekordów. Cyfrowy Polsat (DKN.5131.40.2022, 1 136 975 zł) — brak procedur wewnętrznych weryfikujących dane przed wysyłką do nieprawidłowych adresów. Toyota Bank Polska — naruszenie bezpieczeństwa systemu bankowości elektronicznej, kara 760 tys. zł i wymóg pełnego audytu zewnętrznego. P4 sp. z o.o. (operator Play) — wycieki list klientów u podwykonawców marketingowych, kara z 2024 r. Każda decyzja zawiera szczegółowe wymienienie zaniedbanych TOMs.
14. Egzekucja UODO i sankcje za art. 32
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. Minimum: MFA, kopie zapasowe, hasła nie w plaintext, podstawowe szkolenie pracowników.
Czy szyfrowanie jest obowiązkowe?
Nie wprost, ale art. 32 ust. 1 lit. a wymienia szyfrowanie jako przykład. W praktyce UODO traktuje brak szyfrowania danych szczególnych kategorii i danych finansowych jako naruszenie.
Jak często prowadzić testy penetracyjne?
Minimum raz w roku oraz po istotnych zmianach w systemie. Branże regulowane (banki, infrastruktura krytyczna) — częściej. Test musi pokrywać aplikację, infrastrukturę i procesy.
Co to są TOMs?
Technical and Organisational Measures — załącznik do umowy powierzenia opisujący konkretne środki bezpieczeństwa stosowane przez procesora. Wymagany przez art. 28 ust. 3 lit. c.
Czy ISO 27001 wystarcza do zgodności z art. 32?
ISO 27001 jest dobrym fundamentem, ale nie obejmuje wszystkich wymogów RODO. Należy uzupełnić o ISO 27701 (zarządzanie prywatnością) oraz specyficzne wymogi art. 25 i 32 RODO.
Jakie hasła i polityki haseł akceptuje UODO?
UODO podziela rekomendacje NIST 800-63B i ENISA: minimum 12 znaków dla użytkowników (8 z MFA), brak wymogu okresowej zmiany jeśli nie ma podejrzenia kompromitacji, blokada po 5 nieudanych próbach, hashowanie hasłem bcrypt/Argon2/scrypt z saltem (nigdy SHA-256 bez peppera), brak przechowywania w plaintext lub odwracalnym szyfrowaniu. Brak hashowania to klasyczna podstawa kary (Morele.net, ID Finance). MFA obowiązkowe dla wszystkich kont administracyjnych oraz dla użytkowników mających dostęp do danych szczególnych kategorii.
Czy backup w chmurze poza UE narusza art. 32?
Nie sam fakt lokalizacji — narusza dopiero przy braku odpowiednich zabezpieczeń. Backup u dostawcy z USA wymaga: umowy powierzenia (art. 28), SCC lub DPF (art. 46), TIA (Transfer Impact Assessment), szyfrowania kluczami pod kontrolą administratora (BYOK lub HYOK), opcjonalnie HSM. Backup u dostawcy unijnego z certyfikacją ISO 27001 + SOC 2 Type II zwykle spełnia oba wymogi (art. 32 + art. 44-49). Patrz wyrok Schrems II (C-311/18) i wytyczne EROD 01/2020.
Jak art. 32 odnosi się do AI i uczenia maszynowego?
Modele AI wymagają dodatkowych środków: kontroli dostępu do zbiorów treningowych, anonimizacji/pseudonimizacji danych treningowych, ochrony przed model inversion i membership inference attacks, dokumentacji datasetu (datasheets for datasets), audytu modelu po wdrożeniu. AI Act art. 15 (systemy wysokiego ryzyka) doprecyzowuje wymogi cyberbezpieczeństwa, w tym ochronę przed adversarial examples. UODO i przyszły polski organ AI (AI Act) będą wspólnie sankcjonować luki.