WordPress, reakcja na incydent pod NIS2: 24-godzinny playbook wczesnego ostrzeżenia
Artykuł 23 Dyrektywy 2022/2555 ściska wczesny etap reakcji na incydent w trzy terminy: 24 godziny, 72 godziny, miesiąc. Zegar 24-godzinny zaskakuje operatorów WordPress, bo startuje przy powzięciu wiedzy, nie przy naprawie, a powzięcie wiedzy w typowej witrynie WordPress przychodzi raczej z wiadomości na Slacku niż z dashboardu SOC.
To artykuł wspierający w filarze NIS2 i DORA na WordPress, z odsyłaczami do ścieżki dowodowej Załącznika II i audytu dostawcy z artykułu 28 DORA.
TL;DR
- 24 godziny od powzięcia wiedzy: wczesne ostrzeżenie do CSIRT.
- 72 godziny od powzięcia wiedzy: zgłoszenie z oceną wstępną.
- 1 miesiąc od zgłoszenia 72-godzinnego: raport końcowy z przyczyną i naprawą.
- „Powzięcie wiedzy” to wyzwalacz, nie alert SIEM.
- Sześć sygnałów WordPress, które dla mnie znaczą „zegar idzie”.
- Szablony plików w językach narodowych w tym playbooku.
Co dokładnie mówi artykuł 23
Artykuł 23 ust. 1 ustanawia obowiązek: zgłoszenie każdego incydentu mającego istotny wpływ na świadczenie usług do CSIRT lub właściwego organu. Artykuł 23 ust. 3 definiuje „poważny”: mogący spowodować poważne zakłócenie operacyjne usług lub stratę finansową dla podmiotu albo szkody materialne lub niematerialne u innych osób fizycznych lub prawnych.
Artykuł 23 ust. 4 dzieli oś czasu:
- (a) Bez nieuzasadnionej zwłoki, w każdym razie w ciągu 24 godzin od powzięcia wiedzy o poważnym incydencie: wczesne ostrzeżenie wskazujące, czy incydent jest podejrzewany o przyczynę bezprawną lub złośliwą oraz czy może mieć skutek transgraniczny.
- (b) Bez nieuzasadnionej zwłoki, w każdym razie w ciągu 72 godzin: zgłoszenie aktualizujące wczesne ostrzeżenie i zawierające ocenę wstępną z dotkliwością, wpływem i wskaźnikami kompromitacji.
- (c) Na żądanie CSIRT lub właściwego organu: raport pośredni o stanie.
- (d) Nie później niż miesiąc po zgłoszeniu z lit. b: raport końcowy ze szczegółowym opisem, typem zagrożenia lub przyczyną źródłową, podjętymi działaniami naprawczymi, ewentualnym skutkiem transgranicznym.
Zegar startuje przy powzięciu wiedzy o poważnym incydencie. Dyrektywa tego momentu nie definiuje, a motyw 102 powtarza jedynie terminy. Ten playbook zapisuje powzięcie wiedzy, gdy fachowa osoba w podmiocie z wystarczającą pewnością uzna, że doszło do poważnego incydentu, i notuje, kto to stwierdził i na jakiej podstawie. To istotne dla WordPress, bo powzięcie wiedzy zwykle przychodzi z e-maila klienta, zewnętrznej usługi monitorującej lub skanera podatności, nie z wewnętrznego SOC.
Kiedy incydent jest poważny według rozporządzenia wykonawczego 2024/2690
Artykuł 23 ust. 3 dyrektywy daje ogólny test. Dla części rodzajów podmiotów Komisja go doprecyzowała. Rozporządzenie wykonawcze Komisji (UE) 2024/2690 obejmuje dostawców usług DNS, rejestry nazw TLD, dostawców usług chmurowych, dostawców usług ośrodka przetwarzania danych, dostawców sieci dostarczania treści, dostawców usług zarządzanych, dostawców usług zarządzanych w zakresie bezpieczeństwa, dostawców internetowych platform handlowych, wyszukiwarek internetowych i platform usług sieci społecznościowych oraz dostawców usług zaufania (art. 1). Agencja WordPress, która prowadzi klientom hosting, utrzymanie i monitoring, może mieścić się w kategorii dostawcy usług zarządzanych. To, czy się mieści, wynika z klasyfikacji według załączników dyrektywy i prawa krajowego, a nie z tego playbooka.
Dla tych podmiotów art. 3 ust. 1 rozporządzenia uznaje incydent za poważny, gdy spełnione jest co najmniej jedno kryterium:
- bezpośrednia strata finansowa przekraczająca 500 000 EUR lub 5% całkowitego rocznego obrotu podmiotu w poprzednim roku obrotowym, w zależności od tego, która kwota jest niższa;
- eksfiltracja tajemnic przedsiębiorstwa w rozumieniu dyrektywy (UE) 2016/943;
- śmierć osoby fizycznej albo znaczna szkoda dla zdrowia osoby fizycznej;
- udany, podejrzewany o złośliwy charakter i nieuprawniony dostęp do sieci i systemów informatycznych, który może spowodować poważne zakłócenia operacyjne;
- progi właściwe dla danego rodzaju podmiotu z art. 5 do 14.
Dla dostawców usług zarządzanych i usług zarządzanych w zakresie bezpieczeństwa te progi ustala art. 10: usługa jest całkowicie niedostępna dłużej niż 30 minut; dostępność jest ograniczona dla ponad 5% jej użytkowników w Unii lub ponad 1 miliona użytkowników, w zależności od tego, która liczba jest mniejsza, przez ponad godzinę; albo integralność, poufność lub autentyczność danych związanych z usługą zostaje naruszona w wyniku działania podejrzewanego o złośliwy charakter lub z wpływem na ponad 5% użytkowników albo 1 milion użytkowników, w zależności od tego, która liczba jest mniejsza.
Dwie reguły zmieniają ocenę w parku WordPress. Art. 3 ust. 2 wyłącza zaplanowane przerwy w świadczeniu usług i planowane skutki zaplanowanych prac konserwacyjnych, więc zapowiedziane okno serwisowe nie jest poważnym incydentem według tego testu. Art. 4 dodaje incydenty powtarzające się: incydenty, które osobno nie są poważne, liczy się łącznie jako jeden poważny incydent, gdy wystąpiły co najmniej dwa razy w ciągu sześciu miesięcy, mają tę samą widoczną przyczynę źródłową i łącznie spełniają kryterium straty finansowej. Pkt 3.4.2 lit. b załącznika wymaga sprawdzania takich incydentów co kwartał. W WordPress tę kontrolę powinno zwrócić ponowne zainfekowanie przez tę samą niezałataną wtyczkę.
Podmioty spoza listy z art. 1 nadal stosują test z art. 23 ust. 3 w brzmieniu przeniesionym do prawa krajowego.
Jak rozpoznać włamanie na stronę WordPress
Te ustalenia wymagają otwarcia rekordu i natychmiastowej oceny znaczenia. Nie uruchamiają automatycznie terminu NIS2. Artykuł 23 ma zastosowanie, gdy objęty regulacją podmiot poweźmie wiedzę, że incydent jest poważny według właściwych zasad.
1. Defacement na stronie klienckiej. Indeksowane defacementy, podmieniona strona główna, podmienione strony produktów. Widoczność ułatwia ocenę dotkliwości: szkoda dla zaufania klienta jest dana.
2. Kompromitacja konta admina z potwierdzonym logowaniem. Nowe konto admina, istniejące konto admina z logowaniami z nietypowego zakresu IP lub kraju, konto admina zmieniające inne konta. Wykrywane przez wtyczki audit log (WP Activity Log, Stream, Wordfence audit log).
3. Instalacja złośliwej wtyczki lub upload motywu. Plik wtyczki w wp-content/plugins/ poza zwykłym kanałem aktualizacji albo z PHP wywołującym eval, base64_decode, gzinflate czy assert na danych użytkownika. Wykrywane przez monitoring integralności plików lub skan Wordfence.
4. Iniekcja do bazy z potwierdzonym zapisem. SQL injection, który zdołał wstawić lub zmienić wiersze. Potwierdzone diff-em audit log lub manipulacją w wp_users lub wp_options. Klasyczny sygnał: opcja siteurl nagle wskazuje na obcą domenę.
5. Nieuprawniony eksport danych osobowych. Eksport WordPress, wywołanie REST API zwracające listę użytkowników, duża odpowiedź wp-json/wp/v2/users z nieoczekiwanej IP. RODO artykuł 33 może zadziałać równolegle z NIS2 artykułem 23.
6. Ransomware lub szyfrowanie systemu plików na produkcji albo backupach. Pliki z nowymi rozszerzeniami, .html z notą okupu w katalogach upload, zaszyfrowane archiwa kopii. To sygnał wysokiej wagi, ale zakres i znaczenie nadal wymagają udokumentowanej decyzji.
Dla każdego z tych ustaleń runbook agencyjny mówi: oznacz znacznikiem czasu moment powzięcia wiedzy w tickecie IR, nazwij osobę odpowiedzialną, wystartuj zegar 24-godzinny, powiadom CISO podmiotu lub jego odpowiednik w pierwszej godzinie. Agencja nie składa do CSIRT; podmiot składa. Agencja dostarcza treść techniczną.
Wzór wczesnego ostrzeżenia NIS2 w 24 godziny
Wczesne ostrzeżenie jest celowo krótkie. Szablon, który składam zespołowi compliance podmiotu:
Podmiot: [nazwa prawna]
Sektor: [klasyfikacja Załącznika I lub II]
Identyfikator krajowy: [NIP lub numer rejestrowy]
Streszczenie incydentu
Data i czas powzięcia wiedzy: [ISO-8601 ze strefą czasową]
Źródło wykrycia: [audit log / zgłoszenie klienta / zewnętrzny skaner / powiadomienie hostera]
Dotknięta usługa: [publiczna witryna WordPress pod https://example.com, portal klienta itd.]
Klasyfikacja wstępna
Domniemana przyczyna: [złośliwa / przypadkowa / w toku]
Skutek transgraniczny: [tak / nie / w toku]
Wskaźniki skutku transgranicznego: [jeśli tak, co na to wskazuje]
Wstępna ocena wpływu
Dostępność usługi: [działa / pogorszona / niedostępna]
Potwierdzony dostęp do danych: [brak / podejrzenie / potwierdzony]
Liczba potencjalnie dotkniętych osób: [liczba jeśli znana, w przeciwnym razie „w toku"]
Pierwsza reakcja
Działania powstrzymujące: [rotacja poświadczeń, usunięcie wtyczki, blokada IP itd.]
Forensyka w toku: [tak / nie, z nazwą dostawcy jeśli zewnętrzny]
Następne uaktualnienie: [czas zgłoszenia 72-godzinnego lub wcześniejszego raportu pośredniego]
Kontakt
Imię i rola: [CISO, szef IT itd.]
E-mail i telefon: [linia bezpośrednia]To wczesne ostrzeżenie, nie zgłoszenie. Zgłoszenie 72-godzinne rozszerza je o ocenę dotkliwości, wskaźniki kompromitacji i jaśniejszą ocenę transgraniczną.
Co zawiera zgłoszenie incydentu NIS2 po 72 godzinach
W ciągu 72 godzin od powzięcia wiedzy zgłoszenie dodaje:
- Ocenę dotkliwości. Liczbę dotkniętych użytkowników, rozkład geograficzny, oszacowanie straty finansowej, szacowany czas odzyskania.
- Wskaźniki kompromitacji. Adresy IP, hashe plików, URL-e, złośliwe ciągi User-Agent, sygnatury ataku. Artykuł 23 ust. 4 lit. b wymaga ich, o ile są dostępne.
- Ocenę skutku transgranicznego. Potwierdzony lub wykluczony, z uzasadnieniem.
- Stan powstrzymywania. Co jest opanowane, co otwarte.
- Potrzeby współpracy. Czy podmiot potrzebuje wsparcia CSIRT lub innych organów.
W WordPress blok wskaźników zwykle zawiera: IP atakujących z access logów, ścieżki złośliwych plików w wp-content/, hashe złośliwych plików, ciągi User-Agent obserwowane w trakcie eksploitacji oraz HTTP request body zachowane przez WAF.
Jakie elementy musi zawierać raport końcowy NIS2 po incydencie
Artykuł 23 ust. 4 lit. d: raport końcowy nie później niż miesiąc po zgłoszeniu. Treść:
- Szczegółowy opis incydentu.
- Typ zagrożenia lub przyczyna źródłowa.
- Podjęte i trwające działania naprawcze.
- Skutek transgraniczny w stosownym zakresie.
Dla incydentów WordPress sekcja przyczyny zwykle ląduje na jednym z: nieaktualna wtyczka z znanym CVE, słabe poświadczenia admina bez MFA, wystawiony wp-config.php z pliku backupu, RCE przez funkcję motywu, kompromitacja łańcucha dostaw kanału aktualizacji, błędna konfiguracja na serwerze. Sekcja działań naprawczych mapuje przyczynę na środek z artykułu 21 ust. 2, który powinien był temu zapobiec, i aktualizuje rejestr ryzyka podmiotu.
Co jeszcze nakazuje artykuł 23 NIS2 poza trzema raportami
Terminy 24 godzin, 72 godzin i miesiąca zna każdy. Ten sam artykuł zawiera kolejne obowiązki i jedną ochronę:
- Incydent wciąż trwa. Według art. 23 ust. 4 lit. e, jeśli incydent trwa w chwili składania raportu końcowego, podmiot przekazuje wtedy sprawozdanie z postępów, a raport końcowy w ciągu miesiąca od zakończenia obsługi incydentu.
- Odpowiedź CSIRT. Art. 23 ust. 5 zobowiązuje CSIRT lub właściwy organ do odpowiedzi bez zbędnej zwłoki i w miarę możliwości w ciągu 24 godzin od otrzymania wczesnego ostrzeżenia, ze wstępną informacją zwrotną, a na wniosek podmiotu ze wskazówkami co do środków ograniczających. Gdy incydent może mieć charakter przestępstwa, CSIRT wskazuje też, jak zgłosić go organom ścigania.
- Odbiorcy usług. W stosownych przypadkach podmiot bez zbędnej zwłoki powiadamia odbiorców swoich usług o poważnych incydentach, które mogą niekorzystnie wpłynąć na świadczenie tych usług (art. 23 ust. 1). Według art. 23 ust. 2 odbiorcy potencjalnie dotknięci poważnym cyberzagrożeniem dowiadują się, jakie środki mogą sami zastosować. Dla sklepu lub portalu klienta na WordPress to komunikat do klientów przygotowany zawczasu.
- Dostawcy usług zaufania. W drodze odstępstwa od lit. b dostawca usług zaufania zgłasza poważne incydenty dotyczące jego usług zaufania w ciągu 24 godzin od powzięcia wiedzy, a nie 72.
- Odpowiedzialność. Art. 23 ust. 1 stanowi, że samo zgłoszenie nie zwiększa odpowiedzialności podmiotu zgłaszającego.
- Informowanie opinii publicznej. Według art. 23 ust. 7 CSIRT lub właściwy organ może po konsultacji z podmiotem poinformować opinię publiczną albo zobowiązać do tego podmiot, gdy świadomość społeczna jest potrzebna, by zapobiec incydentowi lub go opanować, albo gdy ujawnienie leży w interesie publicznym.
- Potencjalne zdarzenia dla cyberbezpieczeństwa. Art. 6 pkt 5 definiuje je jako zdarzenia, które mogły naruszyć dostępność, autentyczność, integralność lub poufność danych lub usług, ale udało się im zapobiec albo nie doszły do skutku. Art. 30 pozwala podmiotom kluczowym i ważnym dobrowolnie zgłaszać incydenty, cyberzagrożenia i takie zdarzenia. Zablokowana próba wykorzystania podatności wtyczki WordPress nie podlega obowiązkowemu zgłoszeniu, ale może trafić do CSIRT tą drogą.
Gdzie zgłosić incydent NIS2 w Polsce i UE
Każde państwo członkowskie wyznacza co najmniej jeden CSIRT i jeden właściwy organ. Aktualną listę prowadzi portal ENISA. Najczęstsze kierunki dla podmiotów, z którymi pracuję:
- Polska. CSIRT NASK dla sektorów cywilnych, CSIRT GOV dla administracji publicznej, CSIRT MON dla obszaru obronnego. Krajowy organ właściwy zależy od sektora.
- Niemcy. Bundesamt für Sicherheit in der Informationstechnik (BSI) i CERT-Bund.
- Hiszpania. INCIBE-CERT dla sektora prywatnego i obywateli, CCN-CERT dla administracji publicznej.
- Norwegia. Nie jest państwem członkowskim UE. Dyrektywa jest skierowana do państw członkowskich (art. 46), więc norweskie obowiązki zgłoszeniowe wynikają z prawa norweskiego; aktualne zasady sprawdź w NSM.
- Portugalia. CERT.PT pod CNCS (Centro Nacional de Cibersegurança).
Dla podmiotów działających w wielu jurysdykcjach ENISA prowadzi listę pojedynczych punktów kontaktowych (SPOC) do koordynacji transgranicznej.
Aktualizacja, . Przy ataku, który nie dotyczy tylko twojej strony, jest jeszcze jeden adres. Wordfence uruchomił 26 października 2026 Threat Response Team, zespół odpowiedzialny za pierwsze 72 godziny od sygnału o nowym zagrożeniu do stabilizacji (ogłoszenie Wordfence). Zgłoszenia przyjmuje [email protected] w trzech sytuacjach: wtyczka lub motyw wykorzystywane w ataku, podmieniona aktualizacja wtyczki lub motywu (atak na łańcuch dostaw) albo kampania na wiele stron WordPress naraz. Wordfence prosi o opis tego, co widzisz i od kiedy, nazwę i wersję wtyczki lub motywu, wskaźniki (podejrzane pliki, nieznane konta admina, adresy IP, wpisy z logów) i kontakt. Te same dane zbierasz do wczesnego ostrzeżenia z wzoru wyżej, więc jedna paczka dowodów obsłuży oba zgłoszenia. Adresy IP z logów to dane osobowe: wysyłaj adresy atakujących, nie logi odwiedzin klientów. To zgłoszenie nie zastępuje artykułu 23, CSIRT dostaje wczesne ostrzeżenie w 24 godziny niezależnie od reakcji dostawcy zabezpieczeń.
Jak przygotować plan reakcji na incydent WordPress
Termin 24-godzinny jest bezlitosny dla podmiotów, które przygotowują się dopiero po powzięciu wiedzy. Przed jakimkolwiek incydentem:
- Imienna rotacja on-call. Dwie osoby, główna i zastępcza, z numerami w runbooku IR.
- Drzewo eskalacji do CISO podmiotu. Agencja nie składa wczesnego ostrzeżenia; robi to podmiot, więc droga od „agencja widzi” do „podmiot decyduje” musi być pod godzinę.
- Szablony komunikacji przygotowane wcześniej. Notyfikacja klienta, notyfikacja wewnętrzna, notyfikacja regulatora. Wszystkie trzy w odpowiednich językach.
- Możliwość snapshotu produkcyjnej instancji WordPress. Przed jakąkolwiek zmianą powstrzymującą zachowaj system plików i bazę dla forensyki.
- Relacja z dostawcą forensyki, zakontraktowana zawczasu. Forensyka pod artykułem 23 w 72 godziny wymaga dostawcy, który odbiera telefon, nie zapytania ofertowego.
- Off-site backup w trybie immutable. Bez niego ransomware może uniemożliwić raport końcowy, niszcząc dowody.
Wycena przygotowania tej gotowości jest indywidualna i zależy od skali parku WordPress; nie jest to pozycja na fakturze hostingowej.
Wymogi obsługi incydentów w rozporządzeniu wykonawczym 2024/2690
Sekcja 3 załącznika do rozporządzenia wykonawczego 2024/2690 określa wymogi obsługi incydentów z art. 21 ust. 2 lit. b dyrektywy dla podmiotów wymienionych w jego art. 1. Przeniesione na park WordPress, te punkty zmieniają codzienną pracę:
- Polityka obsługi incydentów (3.1). Role, obowiązki i procedury wykrywania, analizy, powstrzymywania, przywracania, dokumentowania i zgłaszania incydentów, z systemem kategoryzacji, planami komunikacji na potrzeby eskalacji i zgłaszania oraz dokumentami używanymi w reakcji: podręcznikami, schematami eskalacji, listami kontaktów i szablonami (3.1.2). Wzór wczesnego ostrzeżenia powyżej jest jednym z tych dokumentów. Politykę testuje się i przegląda w zaplanowanych odstępach oraz po poważnych incydentach (3.1.3).
- Rejestrowanie zdarzeń (3.2.3). W stosownych przypadkach logi obejmują tworzenie, zmianę lub usuwanie użytkowników i rozszerzanie uprawnień, zdarzenia uwierzytelniania, każdy dostęp uprzywilejowany i działania kont administracyjnych oraz dostęp do krytycznych plików konfiguracyjnych i kopii zapasowych lub ich zmiany. W języku WordPress: zmiany użytkowników i ról, logowania administratorów, zmiany
wp-config.php,.htaccessi archiwów kopii. - Chronione logi (3.2.5). Logi przechowuje się przez z góry określony okres i chroni przed nieuprawnionym dostępem lub zmianą. Log leżący wyłącznie na zaatakowanym serwerze WordPress może zmienić atakujący, więc trudno uznać go za chroniony.
- Zsynchronizowany czas (3.2.6). Systemy korzystają ze zsynchronizowanych źródeł czasu, by logi dało się korelować. Bez tego znacznika powzięcia wiedzy z wczesnego ostrzeżenia nie da się zestawić z logami serwera WWW, WAF i bazy.
- Zgłaszanie zdarzeń (3.3). Prosty mechanizm pozwala pracownikom, dostawcom i klientom zgłaszać podejrzane zdarzenia, a dostawcy i klienci w stosownych przypadkach są o nim informowani.
- Reakcja (3.5). Powstrzymanie, eliminacja i przywrócenie; plany komunikacji z CSIRT lub właściwym organem; rejestrowanie działań reakcji wraz z dowodami; testowanie procedur w zaplanowanych odstępach.
- Przegląd po incydencie (3.6). W stosownych przypadkach przegląd po przywróceniu ustala przyczynę źródłową i kończy się udokumentowanymi wnioskami. Raport końcowy z art. 23 ust. 4 lit. d i ten przegląd korzystają z tych samych dowodów.
Jak ocenić incydent w WordPress i zabezpieczyć dowody
Po wiarygodnym sygnale zespół otwiera jeden główny rekord incydentu. Zapisuje pierwotną obserwację, czas ze strefą, źródło, środowisko i osobę prowadzącą. Ocenia autentyczność, wpływ na poufność, integralność i dostępność, a dopiero potem możliwe spełnienie kryteriów poważnego incydentu. Poziomy operacyjne, takie jak zdarzenie, incydent wysokiego priorytetu i kryzys, porządkują zasoby, ale nie zastępują artykułu 23 ani prawa krajowego. Potwierdzony dostęp, konta, komponenty, ścieżki klientów, czas, zasięg, dostawcy i poziom pewności są aktualizowane. Niewiadome pozostają oznaczone.
Powstrzymywanie i zabezpieczenie dowodów biegną równolegle. Przed przebudową lub usunięciem podejrzanego kodu, jeśli jest to bezpieczne, zapisuje się snapshot lub kopię plików, stan bazy, identyfikator wdrożenia, sesje, administratorów i logi. Oryginały zostają zachowane, pliki otrzymują sumy kontrolne, a kopie robocze są oddzielone. Każda zmiana, w tym rotacja danych dostępowych, reguła WAF, usunięcie wtyczki, odtworzenie i DNS, trafia do osi czasu. Bezpieczeństwo ma pierwszeństwo, gdy zachowanie dowodu przedłuża szkodę; brak trzeba uzasadnić.
Obok osi technicznej działa chronologiczny dziennik decyzji z faktami, założeniami, alternatywami, właścicielem i terminem przeglądu. Technika, zarząd, prawo i prywatność oraz komunikacja do klientów mają oddzielne strumienie uzgadniane przez koordynatora. Agencja przekazuje komponenty, czas wykrycia, referencje do dowodów, stan powstrzymania, podejrzewany dostęp i szacunek odtworzenia. Podmiot podejmuje decyzję i zgłasza, chyba że wyraźna autoryzacja stanowi inaczej.
Jak przetestować plan reakcji na incydent
Ćwiczenie powinno połączyć hostera, agencję, lidera incydentu, prywatność i komunikację. Przechodzi od alertu przez dowody i ocenę znaczenia do przekazania regulatorowi, zgody na odtworzenie i wiadomości dla klientów. Akceptacja wymaga reakcji dyżuru, prawidłowego rekordu, zebrania dowodów bez improwizowanego dostępu, przekazania do decydenta, aktualnych szablonów, czystego punktu odtworzenia oraz właściciela i terminu dla każdej poprawy.
Po odtworzeniu zostają oś czasu, dziennik decyzji, indeks dowodów, kopie zgłoszeń, lista aktywów, analiza przyczyny, dowód restore, komunikacja i weryfikacja napraw. Tymczasowe zabezpieczenie zastępuje trwała kontrola albo formalna decyzja o ryzyku rezydualnym.
W celu przygotowania lub próby wyślij pisemny opis przez usługę gotowości NIS2 i DORA. Podaj podmiot, jurysdykcje, środowiska WordPress, hosting, kluczowe ścieżki, logowanie, backupy, kontakty, wcześniejsze ćwiczenia i luki. Nie przesyłaj początkowo danych dostępowych, osobowych ani surowych dowodów kompromitacji. Praca poprawia gotowość i dowody, ale nie jest opinią prawną, gwarancją ani automatycznym stwierdzeniem obowiązku zgłoszenia.
Powiązane teksty o zgodności
- Filar: NIS2 i DORA na WordPress: stos zgodności 2026
- NIS2 Załącznik II dla agencji WordPress: zakres, terminy, ścieżka dowodowa
- DORA artykuł 28 ryzyko stron trzecich ICT: audyt dostawcy hostingu i WAF dla WordPress
- Cyber Resilience Act + NIS2 + DORA: stos zgodności 2026 dla headless WordPress
- NIS2 zgłoszenie incydentu WordPress: 24 godziny, 72 godziny, miesiąc
- NIS2 vs DORA pokrywanie się zakresów dla agencji WordPress 2026
- Audyt zgodności EU dla WordPress
