NIS2 i DORA na WordPressie: co musi spełniać strona w 2026

#NIS2 i DORA na WordPressie: co musi spełniać strona w 2026

Dwa akty prawne UE definiują w 2026 roku, czego od strony cyberbezpieczeństwa wymaga się od strony WordPress prowadzącej działalność regulowaną w Unii: Dyrektywa NIS2 (2022/2555) oraz Rozporządzenie DORA (2022/2554). Nie są wymienne. NIS2 to dyrektywa o szerokim zakresie sektorowym, transponowana do prawa krajowego. DORA to rozporządzenie sektorowe (finanse), działające bezpośrednio. Obie aplikują do WordPress wtedy i tylko wtedy, gdy podmiot prowadzący stronę jest objęty zakresem.

Artykuł łączy się z opisem usługi headless WordPress, gdzie warstwa techniczna jest opisana, oraz z tekstem o WCAG, BFSG i EAA, bo zgodność dostępności i cyberbezpieczeństwa coraz częściej trafiają w to samo zapytanie zakupowe.

#TL;DR

• NIS2 termin transpozycji: 2024-10-17. DORA stosowany od 2025-01-17.
• NIS2: 18 sektorów, podział na podmioty kluczowe i ważne.
• DORA: sektor finansowy plus krytyczni dostawcy ICT.
• Wymagania: udokumentowane zarządzanie ryzykiem, zgłaszanie incydentów (24/72/30), audyty.
• WordPress sam w sobie nie jest objęty; objęty jest podmiot prowadzący stronę, jeśli jest regulowany.

#Trzy rzeczy, które trzeba wiedzieć od razu

Pierwsza, NIS2 i DORA aplikują do podmiotu, nie do technologii. WordPress nie jest “compliant” ani “non-compliant” jako CMS. Compliant lub nie jest podmiot, który prowadzi stronę. Jeśli szpital, bank, dostawca chmury lub operator e-commerce powyżej progu jest objęty zakresem, to jego strona WordPress wchodzi w zakres jako element infrastruktury podmiotu.

Druga, transpozycja krajowa NIS2 jest opóźniona w wielu państwach członkowskich. Termin 2024-10-17 minął, ale część państw, w tym Polska, była na różnych etapach procesu legislacyjnego po tej dacie. W Polsce projekt nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa jest publicznie dostępny i należy zweryfikować jego aktualny stan w ISAP przed finalnym audytem. Stan na 2026-04 wymaga osobnej weryfikacji prawnej; ten artykuł nie zastępuje porady prawnej.

Trzecia, DORA stosuje się bezpośrednio. Rozporządzenie nie wymaga transpozycji. Jeśli podmiot finansowy lub krytyczny dostawca ICT prowadzi stronę WordPress, obowiązki DORA aplikują od 2025-01-17 bez względu na to, co zrobiła Polska.

#NIS2: zakres podmiotowy

Dyrektywa NIS2 wymienia 18 sektorów. Najczęściej spotykane przypadki, w których WordPress wchodzi w zakres:

Podmioty kluczowe (essential entities):

• Energetyka (elektryczność, gaz, ropa, ciepło, wodór).
• Transport (lotniczy, kolejowy, wodny, drogowy).
• Bankowość.
• Infrastruktury rynku finansowego.
• Sektor zdrowia (szpitale, laboratoria referencyjne, producenci leków, urządzenia medyczne).
• Woda pitna i ścieki.
• Infrastruktura cyfrowa (dostawcy DNS, rejestry domen, dostawcy usług cloud computing, dostawcy usług data center, sieci dostarczania treści, dostawcy usług zaufania, dostawcy publicznych sieci łączności elektronicznej).
• Zarządzanie usługami ICT (B2B).
• Administracja publiczna (warunki zdefiniowane w art. 2).
• Przestrzeń kosmiczna.

Podmioty ważne (important entities):

• Usługi pocztowe i kurierskie.
• Gospodarka odpadami.
• Produkcja, przetwórstwo i dystrybucja chemikaliów.
• Produkcja, przetwórstwo i dystrybucja żywności.
• Produkcja w sektorach: medycznym, komputerowym i elektronicznym, maszynowym, motoryzacyjnym.
• Dostawcy usług cyfrowych (rynki online, wyszukiwarki, platformy społecznościowe).
• Organizacje badawcze.

Podstawowy próg: średnia firma (50 plus zatrudnionych lub roczny obrót lub bilans powyżej 10 mln EUR). Mikrofirmy i małe firmy są zazwyczaj poza zakresem, z wyjątkami (np. dostawcy usług zaufania, rejestry TLD, niektórzy dostawcy DNS).

Podmiot kluczowy ma surowsze obowiązki. Podmiot ważny ma te same wymogi techniczne, ale z mniej intensywnym nadzorem.

#DORA: zakres podmiotowy

DORA aplikuje do około 20 typów podmiotów finansowych:

• Instytucje kredytowe.
• Instytucje płatnicze.
• Instytucje pieniądza elektronicznego.
• Firmy inwestycyjne.
• Dostawcy usług kryptoaktywów.
• Centralne depozyty papierów wartościowych.
• Centralni kontrahenci.
• Systemy obrotu (giełdy).
• Repozytoria transakcji.
• Zakłady ubezpieczeń i reasekuracji.
• Pośrednicy ubezpieczeniowi i reasekuracyjni.
• Instytucje pracownicze emerytalne.
• Agencje ratingowe.
• Audytorzy badający sprawozdania finansowe podmiotów objętych DORA.
• Administratorzy wskaźników referencyjnych.
• Fundusze inwestycyjne (UCITS, AIFM).
• Crowdfunding service providers.
• Repozytoria sekurytyzacji.

Plus krytyczni dostawcy ICT (Critical ICT Third-Party Providers, CTPP) wskazani przez nadzór europejski. To jest mechanizm, którym DORA wciąga partnerów biznesowych w swój zakres, bez ich własnej rejestracji jako podmiotu finansowego.

WordPress prowadzony przez bank, ubezpieczyciela lub fundusz inwestycyjny wchodzi w zakres DORA jako element systemów ICT podmiotu.

#Co konkretnie trzeba zrobić: wspólny rdzeń

NIS2 i DORA mają zbieżny rdzeń wymagań technicznych i organizacyjnych. Implementacja na WordPressie:

Zarządzanie ryzykiem cybernetycznym. Udokumentowany rejestr ryzyk, procedura ich oceny i akceptacji, polityki bezpieczeństwa zatwierdzone przez zarząd. To dokumenty, nie tylko konfiguracja serwera.

Kontrola dostępu i uwierzytelnianie. Wymagane uwierzytelnianie wieloskładnikowe (MFA) dla administratorów WordPress. Wymagane silne hasła. Wymagane wygaszanie sesji. Wszystkie konta administratorskie muszą być imienne, nie współdzielone.

Zarządzanie incydentami. Procedura wykrywania, klasyfikacji i zgłaszania incydentów. Incydent istotny pod NIS2 to taki, który ma znaczący wpływ na świadczenie usługi. Zgłoszenie do CSIRT lub właściwego organu w 24 godzinach od stwierdzenia (early warning), w 72 godzinach z oceną wstępną, w miesiącu z raportem końcowym.

Bezpieczeństwo łańcucha dostaw. Plugin WordPress, hosting, CDN, dostawca poczty transakcyjnej, dostawca SMS, dostawca AI. Każdy z nich jest częścią łańcucha. Trzeba mieć ich rejestr, oceny ryzyka i klauzule kontraktowe.

Ciągłość działania i odzyskiwanie po awarii. Backup, plan ciągłości, odtwarzanie po awarii, testowane regularnie, nie tylko wykonywane.

Szkolenia personelu. Wymagane na poziomie zarządu i szerszej organizacji. Nie wystarczy “wewnętrzna prezentacja”; potrzebny jest udokumentowany plan szkoleniowy.

Bezpieczeństwo procesu rozwoju i utrzymania. Polityki dotyczące rozwoju oprogramowania, testowania i zarządzania podatnościami. WordPress core jest aktualizowany; pluginy też muszą być, z procesem testowania na staging przed produkcją.

Kryptografia. Polityka kryptografii, w tym TLS, szyfrowanie danych w spoczynku, podpisy cyfrowe. WordPress nie szyfruje bazy danych domyślnie; rozwiązaniem jest szyfrowanie na poziomie systemu plików lub bazy.

#DORA-specific: zarządzanie ICT third-party

DORA ma sekcję rozdziału V poświęconą zarządzaniu dostawcami ICT. Wymaga:

• Rejestru wszystkich umów z dostawcami ICT.
• Klasyfikacji umów (krytyczne, niekrytyczne).
• Klauzul kontraktowych obowiązkowych w umowach z dostawcami krytycznych funkcji.
• Procedury zakończenia współpracy z planem migracji.
• Testów penetracyjnych zaawansowanych (TLPT) co najmniej raz na 3 lata dla wybranych podmiotów.

Dla operatora WordPress oznacza to, że hostingodawca i krytyczne pluginy (security plugin, backup plugin, payment gateway plugin) wchodzą do rejestru ICT.

#NIS2-specific: kary i nadzór

Dyrektywa NIS2 określa kary administracyjne, które krajowe transpozycje przekładają na konkretne kwoty. Górne pułapy w samej dyrektywie:

• Podmiot kluczowy: do 10 mln EUR lub 2 procent rocznego światowego obrotu, w zależności co wyższe.
• Podmiot ważny: do 7 mln EUR lub 1.4 procent rocznego światowego obrotu, w zależności co wyższe.

Polska transpozycja może wprowadzać własne pułapy, weryfikować w aktualnej wersji ustawy.

Sankcje uzupełniające: tymczasowe zawieszenie certyfikatu, tymczasowe zakazy pełnienia funkcji zarządczych dla osoby odpowiedzialnej. Te ostatnie są najgłośniejszą zmianą NIS2: zarząd ma osobistą odpowiedzialność za zarządzanie ryzykiem cyber.

Polska nowelizacja KSC z kwietnia 2026 idzie krok dalej i rozszerza osobistą odpowiedzialność za niewłaściwe wdrożenie wymogów NIS2 i KSC poza członków zarządu na całą kadrę kierowniczą nadzorującą obszary objęte regulacją. W praktyce odpowiada nie tylko CEO i CFO, ale również dyrektor IT, CISO, dyrektor compliance, DPO oraz dyrektor operacji, jeśli ich obszar wpada w zakres KSC. Konsekwencja dla agencji WordPress jest taka, że adresat wdrożenia po stronie klienta nie ogranicza się do organu zarządzającego: rejestr ryzyk, runbook incydentów i wykaz dostawców muszą być zaakceptowane przez tę kadrę i jej trzeba dostarczyć materiał dowodowy w formie pozwalającej obronić się przed nadzorem.

#Praktyczna mapa wdrożenia na WordPressie

Cztery kategorie pracy, jeden audyt:

Layer 1, infrastruktura. Hosting compliant. Backup off-site. TLS 1.3. WAF. Monitoring 24/7 lub umowa z SOC. Polityka aktualizacji core, themes, plugins.

Layer 2, aplikacja. MFA dla administratorów. Mocne hasła. Logowanie wszystkich akcji administracyjnych do osobnego strumienia. Anti-CSRF. Anti-XSS na poziomie szablonów. Walidacja inputu. Limit prób logowania.

Layer 3, organizacja. Polityki bezpieczeństwa. Rejestr ryzyk. Plan IR. Plan BCDR. Rejestr dostawców ICT. Procedura zgłaszania incydentów do CSIRT/regulatora. Szkolenia.

Layer 4, dokumentacja i audyt. Dokumentacja procesów. Logi audytowe. Audyt zewnętrzny lub wewnętrzny okresowy. Retencja przygotowana pod wymagania RODO.

Nie istnieje wiarygodny procent wymagań, który WordPress spełnia „z pudełka”. Wynik zależy od roli serwisu, danych, architektury, dostawców i procesów organizacji. Konfiguracja CMS jest tylko częścią szerszego systemu kontroli.

#Kwalifikacja zakresu przed audytem technicznym

Pierwszym wynikiem pracy powinno być uzasadnione określenie zakresu, a nie lista wtyczek do zainstalowania. Trzeba ustalić podmiot świadczący usługę, sektor, wielkość organizacji, państwa prowadzenia działalności oraz rolę witryny w świadczeniu usługi. Następnie właściciel prawny lub compliance potwierdza, czy stosuje się transpozycja NIS2, DORA, oba reżimy albo wymagania kontraktowe klienta wykraczające poza ustawowy zakres.

Dla samego WordPressa zinwentaryzuj funkcje biznesowe. Publiczna strona informacyjna, portal klienta, formularz danych medycznych i panel obsługi płatności mają inny profil ryzyka. Zapisz, jakie dane przechodzą przez system, które integracje mogą zmienić transakcję, gdzie znajdują się sekrety, kto ma dostęp administracyjny oraz od jakich usług zależy publikacja, logowanie i komunikacja z użytkownikiem. W zakresie uwzględnij również DNS, CDN, hosting, repozytorium, pipeline wdrożeniowy, pocztę transakcyjną, kopie zapasowe i narzędzia monitoringu.

Macierz zakresu powinna łączyć funkcję biznesową z właścicielem, systemem, dostawcą, rodzajem danych, krytycznością i podstawą kwalifikacji. Jeśli witryna jest wyłączona z części programu, zachowaj uzasadnienie, osobę zatwierdzającą i datę ponownej oceny. Taki zapis wspiera audyt, lecz nie zastępuje interpretacji właściwego organu ani porady prawnej.

#Od wymogu do dowodu: praktyczna macierz kontroli

Polityka bezpieczeństwa bez dowodu działania jest deklaracją. Z kolei konfiguracja bez wskazania, jaki wymóg i ryzyko obsługuje, pozostaje trudna do obrony. Dlatego każdą kontrolę mapuje się do właściciela, częstotliwości, źródła dowodu oraz procedury obsługi wyjątku.

Dla WordPressa pakiet dowodowy może obejmować eksport ról i kont uprzywilejowanych, potwierdzenie MFA, historię aktualizacji, wyniki skanów podatności, zatwierdzenia zmian, konfigurację retencji logów, raport z odtworzenia kopii i zapis testu ciągłości. Przy WAF liczy się nie tylko zrzut ekranu z włączoną funkcją, lecz również reguły, odpowiedzialność za alerty, historia ich obsługi i procedura bezpiecznej zmiany konfiguracji. Przy backupie dowodem jest udane, mierzone odtworzenie, nie sam komunikat o wykonaniu zadania.

Macierz powinna rozróżniać kontrolę zaprojektowaną, wdrożoną i sprawdzoną operacyjnie. Pozwala to uniknąć sytuacji, w której obecność dokumentu zostaje błędnie uznana za działający proces. Wyjątki zapisuj z ryzykiem, kompensującą kontrolą, właścicielem i terminem wygaśnięcia. Bez daty przeglądu wyjątek łatwo staje się trwałym, niewidocznym odstępstwem.

#Gotowość incydentowa bez dublowania procedury zgłoszeń

Szczegółowe terminy i zawartość zgłoszeń opisuje osobny przewodnik po zgłoszeniu incydentu NIS2. Na poziomie tego programu ważniejsze jest przygotowanie danych i odpowiedzialności, zanim zdarzenie wystąpi. Monitoring powinien umożliwiać rozpoznanie czasu, zakresu i wpływu incydentu. Logi administratora, aplikacji, WAF, hostingu i dostawcy tożsamości muszą mieć zsynchronizowany czas, kontrolowany dostęp oraz retencję uzgodnioną z bezpieczeństwem i ochroną danych.

Runbook określa, kto kwalifikuje zdarzenie, kto zabezpiecza dowody, kto podejmuje decyzję biznesową oraz kto komunikuje się z CSIRT, regulatorem, klientami i dostawcami. Lista kontaktów powinna działać poza WordPressem i poza podstawową skrzynką firmową. W ćwiczeniu stołowym warto sprawdzić utratę konta administratora, podatność aktywnie wykorzystywanej wtyczki, zmianę DNS, wyciek danych z formularza oraz niedostępność hostingu. Celem ćwiczenia nie jest przewidzenie każdego ataku, tylko wykrycie luk w decyzjach, danych i komunikacji.

Po ćwiczeniu zapisuje się czas wykrycia, eskalacji i podjęcia kluczowych decyzji, brakujące informacje oraz działania korygujące. Nie należy obiecywać, że plan zapobiegnie incydentom. Jego rolą jest skrócenie niepewności i umożliwienie udokumentowanej reakcji.

#Dostawcy, umowy i możliwość bezpiecznego wyjścia

Szczegółowe pola rejestru DORA i ocenę art. 28 rozwijają artykuły wspierające. Tutaj punktem wyjścia jest jeden właściciel rejestru obejmującego hosting, CDN, DNS, domenę, wtyczki SaaS, płatności, pocztę, analitykę, backup, repozytorium i wsparcie techniczne. Dla każdego dostawcy zapisz funkcję, przetwarzane dane, lokalizacje, podwykonawców, zależności, warunki powiadomień, dostęp do dowodów oraz plan zastąpienia usługi.

Ocena dostawcy nie kończy się na certyfikacie. Sprawdza się, czy umowa daje terminy powiadomienia, pomoc przy incydencie, zasady dostępu i audytu, wymagania dla podwykonawców, zwrot lub usunięcie danych oraz wsparcie przy wyjściu. Dla krytycznej wtyczki bez rozsądnej alternatywy ryzykiem jest także koncentracja i utrata utrzymania. Plan wyjścia powinien podawać właściciela, kolejność migracji, potrzebne eksporty, testy oraz akceptowalny okres ograniczenia usługi.

#Odbiór, ograniczenia i stałe zarządzanie

Przed rozpoczęciem napraw uzgodnij definicję zakończenia. Krytyczne konta mają przejść test MFA i odebrania dostępu, aktualizacja ma przejść przez staging i plan wycofania, kopia ma zostać odtworzona, alert ma dotrzeć do osoby dyżurnej, a rejestr dostawców ma mieć właściciela i termin przeglądu. Ustalenie zamyka się po retestcie na właściwym środowisku oraz dołączeniu dowodu, nie po samym wdrożeniu zmiany.

Raport końcowy powinien jasno oddzielać kontrole potwierdzone, częściowo wdrożone, nieweryfikowalne w dostępnym zakresie, zależne od dostawcy i zaakceptowane jako ryzyko rezydualne. Audyt WordPressa nie potwierdzi procesów całej organizacji, których nie objęto badaniem. Nie jest też certyfikatem zgodności ani gwarancją, że nie dojdzie do naruszenia.

Po pierwszej poprawie utrzymuj rejestr zmian, kwartalny przegląd dostawców i kont uprzywilejowanych, regularne testy odtworzenia oraz ćwiczenia według profilu ryzyka. Istotna zmiana architektury, logowania, hostingu albo integracji powinna uruchamiać ponowną ocenę. Zarząd lub wyznaczony właściciel ryzyka otrzymuje zwięzły obraz wyjątków, incydentów, testów i zaległych działań, a nie wyłącznie techniczną listę podatności.

Jeśli chcesz ustalić zakres możliwy do wyceny, wyślij pisemny brief z adresem serwisu, sektorem i rynkami, rolą WordPressa, krytycznymi ścieżkami, dostawcami, sposobem hostingu, znanymi ryzykami oraz oczekiwanym terminem. Audyt gotowości NIS2 i DORA może wtedy objąć kwalifikację technicznego zakresu, macierz dowodową, plan napraw i retest. Wymagania prawne oraz zgłoszenia do organów powinny zostać potwierdzone przez właściwy zespół prawny lub compliance.

#Co dalej

Konsekwencje praktyczne dla doboru zespołu prowadzącego WordPress: agencja, która prowadzi stronę dla podmiotu objętego NIS2 lub DORA, sama wchodzi w łańcuch dostaw. Nasza strona kariery wspomina jurysdykcję UE i compliance jako standard, bo to filtr zakupowy procurementu w 2026.

#Artykuły wspierające w tym klastrze

Pięć praktycznych pogłębień znajduje się pod tym filarem; każde adresuje jedną operacyjną deltę, którą regulowane wdrożenie WordPress musi rzeczywiście dostarczyć:

• NIS2 Załącznik II dla agencji WordPress: zakres, terminy, ścieżka dowodowa
• NIS2 zgłoszenie incydentu WordPress: 24 godziny, 72 godziny, miesiąc
• DORA artykuł 28 ryzyko stron trzecich ICT: audyt hostingu WordPress i WAF
• DORA Rejestr Informacji dla dostawców WordPress: pola obowiązkowe
• NIS2 vs DORA pokrywanie się zakresów dla agencji WordPress 2026
• Reakcja na incydent WordPress pod NIS2: playbook wczesnego ostrzeżenia 24h

#Gdzie ten artykuł pasuje

Artykuł łączy się z opisem usługi headless WordPress (warstwa techniczna), tekstem o WCAG/BFSG/EAA (zgodność dostępności w tych samych kryteriach zakupowych), audytem zgodności EU dla WordPress (jeden skonsolidowany audyt EAA, NIS2/DORA i AI Act), stroną kariery WPPoland (jurysdykcja UE) oraz artykułem o polskim nearshore (jurysdykcja UE jako wartość dla zachodniego klienta).