Ocena ryzyka IT dla WordPressa: prosta metoda

Ocena ryzyka IT dla witryny WordPress mieści się na jednej stronie. Wymienia, co Państwo posiadają, co realnie może pójść źle, jak poważne byłyby skutki oraz kto i do kiedy to naprawia. Szkic można przygotować jeszcze dziś, stosując pięcioetapową metodę opisaną poniżej. Efektem jest konkretny dokument, który można pokazać, gdy kwestionariusz klienta, ubezpieczyciel lub organ nadzorczy zapyta, na jakiej podstawie dobrano środki bezpieczeństwa.

Dlaczego ocena ryzyka IT jest pierwsza w RODO i NIS2

Art. 32 ust. 1 RODO wymaga wdrożenia środków technicznych i organizacyjnych odpowiednich do ryzyka, z uwzględnieniem stanu wiedzy technicznej i kosztów. Nie da się wykazać, że środek jest odpowiedni, jeśli wcześniej nie określono, jakie to ryzyko. Art. 5 ust. 2 dodaje, że administrator musi móc wykazać zgodność z przepisami, więc ocenę trzeba spisać. Same środki omawiamy w artykule o art. 32 RODO w kontekście WordPressa.

Jeśli firma podlega dyrektywie NIS2, lista minimalnych środków z art. 21 ust. 2 zaczyna się od lit. a: polityk analizy ryzyka i bezpieczeństwa systemów informatycznych. Wiążące obowiązki wynikają z prawa krajowego, dlatego warto sprawdzić przepisy wdrażające NIS2 w Państwa kraju. Najpierw można sprawdzić, czy NIS2 dotyczy Państwa firmy.

Ta metoda to pragmatyczny punkt wyjścia. Nie jest wdrożeniem ISO 27001 ani formalnym audytem zewnętrznym.

Krok 1: Lista aktywów (witryny, dane, konta, dostawcy)

Aktywem jest wszystko, czego utrata lub nadużycie by Państwu zaszkodziły. W typowej małej firmie cztery grupy obejmują niemal wszystko. Dane osobowe warto wpisać na początku, bo to one podlegają RODO i tam skutki są największe.

Należy pisać konkretnie. „Strona internetowa” to za mało. „shop.example.pl, WooCommerce z ok. 40 wtyczkami, zamówienia od 2021 r.” – to już coś użytecznego. Jeśli przy sporządzaniu listy znajdzie się zapomnianą kopię stagingową albo konto administratora po byłym freelancerze, trzeba to zanotować. Samo to odkrycie uzasadnia całe ćwiczenie.

Krok 2: Realistyczne zagrożenia dla każdego aktywa

Nie potrzebują Państwo katalogu wszystkich możliwych ataków. W witrynach WordPress cztery grupy zagrożeń obejmują większość rzeczywistych incydentów:

• Podatne lub porzucone wtyczki i motywy. Ktoś wykorzystuje znaną lukę, zanim zdążą Państwo zaktualizować oprogramowanie, albo lukę, która nigdy nie zostanie naprawiona.
• Skradzione lub współdzielone dane logowania. Powtórnie użyte hasło, wspólne konto „admin” albo dostęp agencji, którego nikt nie usunął.
• Awaria hostingu lub serwera. Przerwa w działaniu, utrata danych u dostawcy albo błąd w samym oprogramowaniu serwera. Przykładem są podatności PHP2Shell: występowały w środowisku uruchomieniowym PHP, więc w pełni zaktualizowany WordPress nadal był narażony.
• Błąd ludzki. Nieudana aktualizacja psująca proces zakupowy, usunięta podstrona albo redaktor, któremu nadano rolę administratora „tylko na chwilę”.

Zagrożenie związane z wtyczkami trzeba ocenić uczciwie. Dostawca Patchstack w raporcie State of WordPress Security in 2026 naliczył w 2025 r. w ekosystemie WordPressa 11 334 nowe podatności. 91% dotyczyło wtyczek, a w 46% przypadków w chwili publicznego ujawnienia nie było poprawki od twórcy. Dla intensywnie wykorzystywanych podatności ważona mediana czasu do masowej eksploatacji wyniosła 5 godzin. To dane dostawcy, ale wyjaśniają, dlaczego „podatna wtyczka” zwykle trafia na górę rejestru WordPressa.

Krok 3: Ocena prawdopodobieństwa i wpływu w skali 1–3

Wystarczą trzy poziomy, zdefiniowane zwykłymi słowami, tak aby dwie osoby oceniające to samo ryzyko doszły do tego samego wyniku.

Prawdopodobieństwo

1. Mało prawdopodobne w ciągu roku
2. Możliwe w ciągu roku
3. Spodziewane albo już się zdarzyło Państwu lub podobnej witrynie

Wpływ

1. Uciążliwość: naprawa zajmuje godzinę, dane nie są dotknięte
2. Przestój lub ograniczona ilość danych niewrażliwych
3. Ujawnienie danych osobowych, wpływ na płatności lub zatrzymanie działalności

Należy pomnożyć obie wartości. Wynik 1–2 oznacza akceptację, 3–4 zaplanowanie środka, a 6–9 natychmiastowe działanie. Wyniki 5, 7 i 8 w tej skali nie występują, dzięki czemu przedziały pozostają czytelne.

Ryzyko oceniamy w stanie na dziś. Zabezpieczenie, które istnieje i działa, obniża prawdopodobieństwo. „Mamy kopie zapasowe” liczy się tylko wtedy, gdy ktoś choć raz odtworzył z nich dane. Nie warto dodawać ułamków ani współczynników wagowych. Skala 1–3 jest świadomie zgrubna, a fałszywa precyzja sprawia, że rejestr wygląda na bardziej naukowy, niż wynika z posiadanej wiedzy.

Krok 4: Środki, osoby odpowiedzialne i terminy przeglądu

Dla każdego ryzyka z wynikiem 3 lub wyższym należy wybrać jeden–dwa konkretne środki. „Poprawić bezpieczeństwo” nie jest środkiem. „Włączyć uwierzytelnianie dwuskładnikowe dla wszystkich czterech administratorów do 17 listopada” – jest. Odpowiedzialną powinna być konkretna osoba, nie „dział IT” ani „agencja”, i trzeba wyznaczyć termin.

Same środki omawiają pogłębione artykuły: obsługa podatnych wtyczek oraz kopie zapasowe WordPressa, które naprawdę da się odtworzyć. Rejestr ryzyka ma tylko odnotować decyzję i odsyłać do dowodów.

W każdym wierszu powinny się znaleźć jeszcze dwie rzeczy. Po pierwsze, „akceptacja” jest prawidłową decyzją dla niskich wyników, o ile zapiszą Państwo uzasadnienie. Po drugie, warto odnotować ryzyko szczątkowe, czyli wynik oczekiwany po wdrożeniu środka. Jeśli środek nie obniża wyniku, to prawdopodobnie jest źle dobrany.

Przykład: rejestr ryzyka małego sklepu WooCommerce

Poniższy przykład dotyczy fikcyjnego sklepu. Ma jedną witrynę WooCommerce, kopię stagingową, dwoje pracowników, zewnętrzną agencję i hosting współdzielony. „P” oznacza prawdopodobieństwo, „W” wpływ, a „Po” oczekiwany wynik szczątkowy.

Tabelę czyta się od góry. W tym tygodniu sklep usuwa konto agencji i pyta hosting o PHP. Oba działania są tanie i zajmują mniej niż godzinę. Porządkowanie wtyczek następuje do przyszłego tygodnia, bo ma najwyższy wynik. Uwierzytelnianie dwuskładnikowe i test odtworzenia są zaplanowane w ciągu miesiąca.

Wiersze o błędach pracowników i formularzu kontaktowym mogą poczekać do grudnia. Ich wyniki są niższe, a w przypadku pomyłek pracowników kopia zapasowa z czwartego wiersza już zapewnia plan awaryjny. Awaria newslettera zostaje zaakceptowana, z uzasadnieniem i datą przeglądu. Każdy wiersz kończy się wynikiem 3 lub niższym. Nie znaczy to, że nic się nie może zdarzyć. To udokumentowany, uzasadniony poziom ryzyka.

Jak utrzymać ocenę ryzyka IT w mocy

Ocena ryzyka IT, do której nikt nie wraca, staje się dowodem, że przestali Państwo patrzeć. Powinna być przeglądana, gdy zajdzie jedna z poniższych okoliczności:

• po każdym incydencie lub zdarzeniu bliskim incydentu, w tym fali nieudanych logowań czy wtyczce, którą trzeba było wycofać
• po większych zmianach, takich jak nowa wtyczka przetwarzająca dane osobowe, nowy hosting, nowa agencja lub uruchomienie sklepu
• gdy dostawca lub klient objęty NIS2 przysyła kwestionariusz bezpieczeństwa
• w stałych odstępach wybranych samodzielnie, np. co kwartał lub raz w roku. To Państwa decyzja, nie wymóg prawny

Dokument warto opatrzyć numerem wersji i datą oraz zachowywać stare wersje. Historia pokazująca, że wynik 9 spadł do 3 po wdrożeniu środka, jest dobrym dowodem rozliczalności. Nasz przewodnik po dokumentacji audytu bezpieczeństwa pokazuje, jak rejestr współgra z pozostałymi zapisami.

Wtyczka audytowa „Security Audit & Compliance” z secaudit.eu może pomóc w kroku 2 i przy każdym przeglądzie. Przypisuje swoje ustalenia do art. 32 RODO i art. 21 NIS2 oraz eksportuje je jako raport lub CSV, które można porównać z rejestrem. Decyzje w rejestrze pozostają Państwa; wtyczka dostarcza aktualnych danych wejściowych. → secaudit.eu

Następny krok: skopiować przykładową tabelę, zastąpić wiersze własnymi aktywami i wyznaczyć datę pierwszego przeglądu, zanim zamkną Państwo plik.

FAQ

Czy potrzebuję do tego ISO 27001?

Nie. Ta metoda to praktyczny początek, który można przeprowadzić własnym zespołem. ISO 27001 to pełna norma systemu zarządzania, a ewentualne jej wdrożenie to osobna decyzja biznesowa, często wymuszana przez dużych klientów.

Ile to zajmuje dla jednej witryny?

Dla pojedynczej witryny ze znaną konfiguracją pierwszy szkic mieści się w jednej sesji roboczej. Najwięcej czasu pochłania krok 1, czyli odnalezienie kont i dostawców. Kolejne przeglądy są znacznie szybsze, bo aktualizuje się tylko to, co się zmieniło.

Czy agencja robi to raz, czy dla każdego klienta?

Każdy klient jest administratorem danych dla własnej witryny i odpowiada za swoją ocenę ryzyka. Agencja może przygotować projekt do zatwierdzenia przez klienta. Powinna też prowadzić osobny rejestr dla własnych systemów, takich jak laptopy, menedżer haseł i dostęp do hostingu klientów. Umowa powierzenia przetwarzania danych powinna opisywać, kto za co odpowiada.

Niniejszy artykuł ma charakter ogólnej informacji i nie stanowi porady prawnej.