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. 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
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. UODO obniża karę średnio o 25-30% jeśli administrator wykaże, że incydent wystąpił mimo wdrożenia adekwatnych środków zgodnych ze stanem wiedzy technicznej. 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. 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.
Podstawa prawna i źródła
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial