Art. 32 RODO a WordPress: co znaczy „odpowiednie bezpieczeństwo”

Art. 32 RODO nie wskazuje konkretnej wtyczki, ustawienia serwera ani długości hasła. Wymaga bezpieczeństwa odpowiedniego do ryzyka, co dla większości stron na WordPressie oznacza krótką i konkretną listę: HTTPS wszędzie, aktualne oprogramowanie, imienne konta z uwierzytelnianiem dwuskładnikowym, kopie zapasowe, które faktycznie udało się przywrócić, oraz regularne kontrole. Kto to wszystko robi i potrafi to wykazać, spełnia już większość tego, czego art. 32 oczekuje od typowej strony na WordPressie.

Ten poradnik przekłada art. 32 ust. 1 lit. a–d na konkretne środki w WordPressie, punkt po punkcie. Omawia też dwa powiązane obowiązki: dokumentowanie stosowanych środków (rozliczalność) oraz dopilnowanie, by dostawca hostingu i agencja wywiązywali się ze swojej części.

RODO a bezpieczeństwo WordPressa: co mówi art. 32

Art. 32 RODO zobowiązuje zarówno administratora (Państwa firmę), jak i każdy podmiot przetwarzający (np. firmę hostingową) do wdrożenia odpowiednich środków technicznych i organizacyjnych. To, co jest odpowiednie, zależy od stanu wiedzy technicznej, kosztów wdrożenia, charakteru, zakresu, kontekstu i celów przetwarzania oraz od ryzyka dla osób, których dane są przetwarzane.

Następnie przepis wymienia cztery elementy, które środki te obejmują „między innymi, w stosownym przypadku”:

• (a) pseudonimizację i szyfrowanie danych osobowych;
• (b) zdolność do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów i usług przetwarzania;
• (c) zdolność do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu;
• (d) proces regularnego testowania, mierzenia i oceniania skuteczności tych środków.

U podstaw leży art. 5 ust. 1 lit. f: dane osobowe muszą być przetwarzane w sposób zapewniający odpowiednie bezpieczeństwo. A typowa strona na WordPressie przetwarza więcej danych osobowych, niż spodziewa się jej właściciel: konta użytkowników, komentarze z imionami, adresami e-mail i IP, wpisy z formularzy kontaktowych, zapisy do newslettera, zamówienia WooCommerce i logi serwera.

Podejście oparte na ryzyku: stan wiedzy technicznej a koszty

Art. 32 celowo opiera się na ocenie ryzyka. Strona firmowa z jednym formularzem kontaktowym, sklep z tysiącami kont klientów i strefa członkowska przechowująca informacje o zdrowiu nie wymagają takiego samego nakładu pracy, ale każda z nich potrzebuje poziomu ochrony adekwatnego do tego, co może pójść nie tak. Art. 32 ust. 2 wymienia ryzyka, które należy wziąć pod uwagę: przypadkowe lub niezgodne z prawem zniszczenie, utratę, zmodyfikowanie, nieuprawnione ujawnienie danych osobowych lub nieuprawniony dostęp do nich.

„Stan wiedzy technicznej” najlepiej rozumieć jako rozwiązania sprawdzone i powszechnie dostępne, a nie „najdroższy produkt na rynku”. HTTPS, wspierane wersje oprogramowania i logowanie dwuskładnikowe dla administratorów to dziś standard, a przy tym kosztują niewiele. Koszty mogą uzasadniać prowadzenie małego bloga bez korporacyjnej zapory aplikacji webowych (WAF). Rzadko jednak uzasadniają pominięcie podstaw.

Art. 32 ust. 1 lit. a–d w praktyce WordPressa

Tabela przypisuje każdemu punktowi typowe środki w WordPressie oraz dowody, które warto przechowywać.

(a) Szyfrowanie i pseudonimizacja

Cała strona, łącznie z /wp-admin/ i każdym formularzem, powinna działać wyłącznie przez HTTPS; gdy to działa niezawodnie, można dodać HSTS. Hasła nie są szyfrowane, lecz haszowane – i w ich przypadku to właściwe podejście: od WordPressa 6.8 hasła użytkowników są haszowane algorytmem bcrypt.

Kopie zapasowe to egzemplarz danych osobowych, o którym najczęściej się zapomina. Należy je szyfrować i przechowywać z dala od serwera WWW. Prawdziwa pseudonimizacja jest na typowej stronie WordPress rzadkością, ale pokrewne kroki zmniejszają ryzyko: skracanie adresów IP w statystykach i logach oraz nieprzechowywanie wpisów z formularzy w bazie dłużej, niż to konieczne. Danych, których się już nie przechowuje, nie da się wykraść.

(b) Poufność, integralność, dostępność i odporność

Na pierwszym miejscu są aktualizacje. Patchstack, dostawca rozwiązań bezpieczeństwa, naliczył w 2025 roku 11 334 nowe podatności w ekosystemie WordPressa, z czego 91% we wtyczkach. W przypadku najintensywniej atakowanych podatności ważona mediana czasu do masowego wykorzystania wyniosła pięć godzin (raport Patchstack). Automatyczne aktualizacje warto włączyć tam, gdzie mają sens (rdzeń oferuje je dla wtyczek i motywów od WordPressa 5.5), a nieużywane wtyczki usunąć. Jak je przejrzeć, wyjaśnia nasz poradnik o podatnych wtyczkach.

Drugim filarem jest kontrola dostępu: jedno imienne konto na osobę, najniższa wystarczająca rola (Redaktor, Autor lub Współpracownik zamiast Administratora) oraz uwierzytelnianie dwuskładnikowe dla każdego administratora. Rdzeń WordPressa go nie zawiera. Aby chronić integralność, warto usunąć edytory plików z kokpitu, dodając w wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Od czasu do czasu warto też porównać pliki rdzenia z oficjalnymi sumami kontrolnymi (wp core verify-checksums w WP-CLI). Z myślą o dostępności i odporności należy wybrać hosting z odpowiednimi zasobami i monitoringiem. Żadna wtyczka nie wchłonie dużego ataku DDoS – to zadanie dla CDN lub zapory brzegowej. Oficjalny przewodnik po zabezpieczaniu WordPressa opisuje kolejne ustawienia po stronie serwera.

(c) Przywracanie dostępności po incydencie

Kopia zapasowa ma wartość tylko wtedy, gdy da się ją przywrócić. Należy archiwizować pliki i bazę danych, trzymać co najmniej jedną kopię poza serwerem i poza zasięgiem konta administratora WordPressa oraz przetestować pełne przywrócenie w środowisku testowym (staging). Warto zapisać, ile to trwało: „szybkie” przywrócenie znacznie łatwiej wykazać zmierzonym czasem niż nadzieją.

(d) Regularne testowanie, mierzenie i ocenianie

RODO nie określa częstotliwości, więc trzeba ją ustalić samodzielnie i się jej trzymać. Rozsądny punkt wyjścia dla małej firmy: automatyczny skan co tydzień, przegląd kont użytkowników i wtyczek co kwartał, test przywracania dwa razy w roku oraz dodatkowy przegląd po każdym incydencie lub większej zmianie. Ustalenia i poprawki należy zapisywać wraz z datami.

Wtyczka Security Audit & Compliance od secaudit.eu może przejąć część testów: wyszukuje złośliwe oprogramowanie, zmienione pliki rdzenia, nieaktualne wtyczki i słabe hasła, przypisuje wyniki do art. 32 RODO i pokazuje na ekranie podsumowanie zgodności; podpisane raporty (PDF, CSV) są dostępne w secaudit.eu Pro. Skan wspiera dokumentację, ale sam w sobie nie zapewnia zgodności strony z przepisami.

Rozliczalność: dokumentowanie działań (art. 5 ust. 2)

Zgodnie z art. 5 ust. 2 administrator musi być w stanie wykazać przestrzeganie przepisów. W praktyce oznacza to krótki, aktualizowany na bieżąco dokument o bezpieczeństwie, a nie segregator, którego nikt nie czyta. Powinien on obejmować:

• Wykaz: hosting, wersja WordPressa, wtyczki, motywy, usługi zewnętrzne
• Kto ma dostęp, z jaką rolą i kto zatwierdza nowe konta
• Środki dla punktów (a)–(d) wraz z notatką o ryzyku, która je uzasadnia
• Dziennik aktualizacji oraz daty skanów, przeglądów dostępów i testów przywracania
• Procedurę na wypadek incydentu, w tym zgłoszenie naruszenia w ciągu 72 godzin
• Umowy powierzenia przetwarzania danych zawarte z podmiotami przetwarzającymi

Dokument należy przeglądać raz w roku i przy każdej istotnej zmianie strony. Dobrym punktem wyjścia do sporządzenia wykazu jest nasza lista kontrolna bezpieczeństwa WordPressa.

Hosting i agencje jako podmioty przetwarzające (art. 28)

Dostawca hostingu przechowuje bazę danych i kopie zapasowe. Agencja lub freelancer z dostępem administratora może odczytać dane każdego klienta. Oboje działają zwykle jako podmioty przetwarzające, a wtedy z każdym z nich trzeba zawrzeć umowę powierzenia przetwarzania danych zgodnie z art. 28. Ten sam artykuł stanowi, że wolno korzystać wyłącznie z usług podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, a umowa musi zobowiązywać je do podjęcia środków wymaganych na mocy art. 32.

Zamiast polegać na szablonie, warto zadać konkretne pytania. Gdzie i jak długo przechowywane są kopie zapasowe? Czy logowanie dwuskładnikowe jest wymuszone w panelu hostingu i na kontach agencji? Jak szybko poinformują Państwa o incydencie bezpieczeństwa? Po zakończeniu współpracy z agencją jej konta należy usunąć, a wspólne dane logowania zmienić tego samego dnia.

Naruszenie art. 25–39, w tym art. 32, może skutkować administracyjną karą pieniężną w wysokości do 10 mln euro lub do 2% całkowitego rocznego światowego obrotu, w zależności od tego, która kwota jest wyższa (art. 83 ust. 4 lit. a). Dokumentacja najpewniej przyda się jednak w innej sytuacji: po incydencie, gdy organ nadzorczy (w Polsce Prezes UODO) zapyta, jakie środki były stosowane.

Najczęstsze pytania

Czy art. 32 wymaga konkretnej wtyczki bezpieczeństwa?

Nie. Wymaga odpowiednich środków, a nie produktów. Wtyczka może pomóc w realizacji niektórych z nich, np. logowania dwuskładnikowego czy skanowania, ale aktualizacje, kopie zapasowe, przeglądy dostępów i umowy są równie ważną częścią całości.

Czy art. 32 dotyczy małej strony bez kont użytkowników?

Tak, jeśli tylko strona przetwarza dane osobowe, np. wpisy z formularza kontaktowego, komentarze czy logi serwera z adresami IP. Zakres środków zależy od ryzyka.

Czy HTTPS wystarczy do spełnienia punktu (a)?

Nie. HTTPS chroni dane podczas przesyłania. Kopie zapasowe, eksporty i baza danych na serwerze wymagają osobnej ochrony.

Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.