NIS2 Załącznik II dla agencji WordPress: zakres, terminy, ścieżka dowodowa

#NIS2 Załącznik II dla agencji WordPress: zakres, terminy, ścieżka dowodowa

Artykuł 21 Dyrektywy 2022/2555 to klauzula operacyjna, która rozstrzyga, jak wygląda audyt. Załącznik I i Załącznik II rozstrzygają, kto przez ten audyt musi przejść. Ten tekst odwzorowuje dziesięć środków z artykułu 21 ust. 2 na konkretne kontrolę w agencji WordPress oraz na pliki dowodowe, których oczekuję, gdy regulowany klient uruchamia ocenę dostawcy.

To artykuł wspierający w filarze NIS2 i DORA na WordPress, z odsyłaczami do przewodnika po artykule 28 DORA i 24-godzinnego playbooka reakcji na incydent.

#TL;DR

• Artykuł 21 ust. 2 wymienia dziesięć środków zarządzania ryzykiem. Żaden nie jest opcjonalny.
• Załączniki I i II wymieniają sektory; to artykuł 3 rozstrzyga, kto jest podmiotem kluczowym, a kto ważnym. Te same środki, inny nadzór.
• Audytor szuka czterech artefaktów dla każdego środka: polityki, właściciela, zapisu wdrożenia, rytmu przeglądów.
• Kary z artykułu 34 dotyczą podmiotu, nie dostawcy WordPress, lecz klauzule łańcucha dostaw przenoszą obowiązki w dół.
• W każdym mandacie regulowanym prowadzę po jednym folderze na każdą literę artykułu 21.

#Kto wpada w zakres: Załącznik I a Załącznik II

Załącznik I wymienia sektory kluczowe: energetyka, transport, bankowość, infrastruktury rynku finansowego, zdrowie, woda pitna i ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT (B2B), administracja publiczna, kosmos. Załącznik II wymienia sektory ważne: usługi pocztowe i kurierskie, gospodarka odpadami, chemia, żywność, produkcja wyrobów medycznych, komputerów i elektroniki, maszyn oraz pojazdów silnikowych, dostawcy usług cyfrowych, organizacje badawcze.

Oba załączniki stosuje się do podmiotów średnich i większych (50 lub więcej pracowników albo roczny obrót i roczna suma bilansowa jednocześnie powyżej 10 mln EUR). Mikroprzedsiębiorcy i małe przedsiębiorstwa są poza bezpośrednim zakresem, z wyjątkami z artykułu 2 ust. 2: dostawcy usług zaufania, rejestry TLD, niektórzy dostawcy DNS, administracja publiczna, dostawcy publicznych sieci łączności elektronicznej.

Praktyczny filtr dla agencji WordPress: szpital, bank, zakład chemiczny, operator data center, rejestr TLD. Jeśli klient jest jednym z nich, scoping startuje. Jeśli klient to hotel, startup SaaS lub regionalny detalista, scoping zwykle kończy się stwierdzeniem „poza zakresem, dobre praktyki bezpieczeństwa nadal obowiązują”.

#Środki z artykułu 21 NIS2 w agencji WordPress

Tekst dyrektywy czyta się jako dziesięć liter od a do j. Każda litera staje się folderem w moim repozytorium projektu.

(a) Polityki analizy ryzyka i bezpieczeństwa systemów informatycznych. Podpisany rejestr ryzyka z aktywami, zagrożeniami, prawdopodobieństwem, wpływem i sposobem postępowania. Dla WordPress: serwer produkcyjny, serwer staging, zestaw wtyczek, API zewnętrzne (płatności, e-mail, analityka, AI), konta administracyjne, baza treści. Zagrożenia: RCE we wtyczce, credential stuffing, ransomware na backupach, naruszenie RODO przez eksport. Postępowanie: harmonogram aktualizacji, MFA, off-site szyfrowany backup, zestaw reguł WAF.

(b) Obsługa incydentów. Wykrywanie, klasyfikacja, reakcja, odzyskiwanie, podsumowanie. Dowód: runbook IR z imiennymi właścicielami, narzędzie monitorujące wyzwalające alerty (Wordfence, Sucuri, IDS hostingu, alerty Cloudflare), kanał Slack lub PagerDuty, szablon post-mortem.

(c) Ciągłość działania, w tym zarządzanie kopiami zapasowymi i odzyskiwanie po awarii oraz zarządzanie kryzysowe. Backup z magazynem off-site, zdefiniowane RPO i RTO, przetestowane przywrócenie. Plan komunikacji kryzysowej z osobą do mediów i osobą do regulatora. Doroczne ćwiczenie odtworzenia z raportem.

(d) Bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa dotyczące relacji każdego podmiotu z bezpośrednimi dostawcami lub usługodawcami. To miejsce, w którym ląduje agencja WordPress. Regulowany podmiot prowadzi rejestr dostawców, klasyfikuje ich według krytyczności, prowadzi due diligence, wpisuje klauzule bezpieczeństwa do umów. Powiązanie: artykuł 28 DORA stosuje tę samą logikę, ostrzej dla finansów.

(e) Bezpieczeństwo w nabywaniu, rozwoju i utrzymaniu sieci i systemów informatycznych, w tym obsługa i ujawnianie podatności. Udokumentowany bezpieczny cykl wytwarzania. Dla WordPress: review kodu własnych wtyczek i motywów, skanowanie zależności (Snyk, Dependabot), Plugin Check (PCP) z WordPress.org dla własnych wtyczek, adres e-mail do zgłaszania podatności, polityka zarządzania łatkami.

(f) Polityki i procedury oceny skuteczności środków zarządzania ryzykiem cyberbezpieczeństwa. Audyt wewnętrzny, zewnętrzny lub test penetracyjny. Dowód: opis zakresu, raport z testu, rejestr działań naprawczych, protokół retestu.

(g) Podstawowe praktyki cyberhigieny i szkolenia. Doroczne szkolenie wszystkich pracowników, szkolenia rolowe dla administratorów. Dowód: rejestr szkoleń z imionami, datami i treścią.

(h) Polityki i procedury dotyczące stosowania kryptografii i, w stosownych przypadkach, szyfrowania. TLS 1.3 na brzegu, szyfrowanie kopii zapasowych, szyfrowanie kopii bazy w spoczynku. Polityka algorytmów haszowania (bez MD5 i SHA-1). Inwentarz kluczy kryptograficznych.

(i) Bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i zarządzanie aktywami. Proces joiner-mover-leaver. Imienne konta administracyjne, brak współdzielonych poświadczeń. Inwentarz aktywów obejmujący wszystkie instalacje WordPress, środowiska staging, dostępy do repozytoriów, dostępy do konsoli hostingowych. Kwartalny przegląd uprawnień.

(j) Stosowanie uwierzytelniania wieloskładnikowego lub rozwiązań ciągłego uwierzytelniania, zabezpieczonej komunikacji głosowej, wideo i tekstowej oraz zabezpieczonej komunikacji awaryjnej. MFA na każdym logowaniu admina WordPress, każdej konsoli hostingowej, każdej konsoli CDN, każdym repozytorium kodu, każdej skrzynce e-mail. Bez wyjątków dla „zaufanych kont wewnętrznych”.

#Podmiot kluczowy czy ważny według artykułu 3 NIS2

Załącznik, w którym znajduje się sektor, sam nie rozstrzyga o kategorii. Artykuł 3 ust. 1 lit. a uznaje podmiot z Załącznika I za kluczowy tylko wtedy, gdy przekracza pułapy dla średnich przedsiębiorstw z zalecenia 2003/361/WE, czyli jest dużym przedsiębiorstwem: 250 lub więcej pracowników albo roczny obrót powyżej 50 mln EUR łącznie z roczną sumą bilansową powyżej 43 mln EUR. Artykuł 3 ust. 2 uznaje za podmiot ważny każdy inny podmiot z Załącznika I lub II, który nie jest kluczowy. Średni szpital z Załącznika I jest więc podmiotem ważnym, tak samo jak duży producent z Załącznika II.

Niektóre przypadki nie zależą od wielkości. Artykuł 3 ust. 1 lit. b uznaje za kluczowych kwalifikowanych dostawców usług zaufania, rejestry nazw domen najwyższego poziomu i dostawców usług DNS bez względu na ich wielkość. Państwa członkowskie mogą też wskazać konkretne podmioty na podstawie artykułu 2 ust. 2 lit. b do e.

Wniosek praktyczny dla agencji: klient powinien znać swoją kategorię, zanim wyśle kwestionariusz. Artykuł 3 ust. 3 zobowiązał państwa członkowskie do sporządzenia do 17 kwietnia 2025 r. wykazu podmiotów kluczowych i ważnych oraz do przeglądu go co najmniej co dwa lata. Jeśli klient nie umie wskazać swojej kategorii, ocena dostawcy zaczyna się od otwartego pytania, a to pytanie należy do jego prawników, nie do agencji.

#Czy agencja utrzymująca WordPress jest dostawcą usług zarządzanych w NIS2

Artykuł 6 pkt 39 definiuje dostawcę usług zarządzanych jako podmiot, który świadczy usługi związane z instalacją, eksploatacją lub konserwacją produktów, sieci, infrastruktury, aplikacji ICT lub innych sieci i systemów informatycznych lub z zarządzaniem nimi, w formie wsparcia lub aktywnej administracji, w siedzibie klienta lub zdalnie. Załącznik I pkt 9 umieszcza tych dostawców w sektorze zarządzania usługami ICT (między przedsiębiorstwami). Umowa na utrzymanie WordPressa z dostępem administracyjnym, aktualizacjami i monitoringiem serwera pasuje do brzmienia tej definicji. Czy konkretna agencja się w niej mieści, to ocena prawna, której za nikogo nie wykonuję.

Wielkość nadal decyduje. Agencja zatrudniająca mniej niż 50 osób, z rocznym obrotem lub sumą bilansową do 10 mln EUR, pozostaje poza artykułem 2 ust. 1. Średnia agencja świadcząca usługi zarządzane byłaby podmiotem ważnym, duża kluczowym. Dla tych dostawców artykuł 26 ust. 1 lit. b przypisuje jurysdykcję państwu członkowskiemu, w którym mają główną siedzibę w Unii.

Jest też druga konsekwencja. Rozporządzenie wykonawcze Komisji (UE) 2024/2690, przyjęte na podstawie artykułu 21 ust. 5, określa wymogi techniczne i metodyczne środków z artykułu 21 ust. 2 między innymi dla dostawców usług zarządzanych. Jego artykuł 3 uznaje incydent za poważny na przykład wtedy, gdy spowodował lub może spowodować bezpośrednią stratę finansową powyżej 500 000 EUR lub 5 % całkowitego rocznego obrotu z poprzedniego roku obrotowego, w zależności od tego, która kwota jest niższa. Agencja objęta zakresem stosuje to rozporządzenie bezpośrednio, a nie przez umowę z klientem.

#Jakich dowodów audytor NIS2 wymaga dla każdego środka

Dla każdej z dziesięciu liter oczekuję czterech artefaktów, gdy zjawia się audytor:

Tę czterokolumnową tabelę prowadzę dla każdej litery artykułu 21 ust. 2. Dziesięć liter, czterdzieści artefaktów. Tak wygląda segregator audytowy w 2026.

#Terminy zgłoszenia incydentu NIS2 z artykułu 23

Artykuł 21 reguluje stan ustalony. Gdy incydent się zdarzy, działa artykuł 23:

• 24 godziny od powzięcia wiedzy: wczesne ostrzeżenie do CSIRT lub właściwego organu.
• 72 godziny od powzięcia wiedzy: zgłoszenie z oceną wstępną i wskaźnikami kompromitacji.
• 1 miesiąc od zgłoszenia incydentu: raport końcowy ze szczegółowym opisem, prawdopodobną przyczyną źródłową, zastosowanymi i trwającymi środkami ograniczającymi oraz ewentualnym wpływem transgranicznym.
• Jeśli incydent nadal trwa w tym momencie: sprawozdanie z postępów, a raport końcowy w ciągu miesiąca od zakończenia obsługi incydentu (artykuł 23 ust. 4 lit. e).
• Raport pośredni na każde żądanie regulatora w trakcie.

Szczegółowy playbook na pierwsze 24 godziny żyje w artykule WordPress, reakcja na incydent pod NIS2.

#Kary NIS2 i odpowiedzialność zarządu

Artykuł 34 ustanawia pułapy, których krajowe transpozycje nie mogą obniżać:

• Podmioty kluczowe: co najmniej 10 mln EUR albo 2% całkowitego rocznego obrotu światowego, w zależności od tego, która wartość jest wyższa.
• Podmioty ważne: co najmniej 7 mln EUR albo 1,4% całkowitego rocznego obrotu światowego, w zależności od tego, która wartość jest wyższa.

Artykuł 20 ust. 1 nakłada odpowiedzialność na organy zarządcze, w tym obowiązek nadzoru nad wdrożeniem. Artykuł 20 ust. 2 wymaga odbywania szkoleń przez członków organu. Krajowe transpozycje mogą dodać sankcje osobowe wobec osoby odpowiedzialnej; status polskiej ustawy o krajowym systemie cyberbezpieczeństwa należy weryfikować w ISAP przed audytem.

#Klauzule łańcucha dostaw NIS2 w umowie z agencją WordPress

Artykuł 21 ust. 3 wymaga, aby podmiot przy wyborze środków z lit. d uwzględniał podatności specyficzne dla każdego bezpośredniego dostawcy, ogólną jakość jego produktów i praktyki cyberbezpieczeństwa, w tym procedury bezpiecznego opracowywania. Artykuł 21 ust. 4 wymaga podjęcia bez zbędnej zwłoki środków naprawczych, gdy podmiot stwierdzi, że środków nie spełnia. W agencji WordPress przekłada się to na pytania o review kodu, zarządzanie zależnościami i terminy łatek.

Najbardziej szczegółowy oficjalny tekst o treści umowy to pkt 5.1.4 załącznika do rozporządzenia wykonawczego 2024/2690. Wymienia elementy, które umowy z dostawcami określają w stosownych przypadkach: wymogi cyberbezpieczeństwa; świadomość, umiejętności, szkolenia i certyfikaty pracowników dostawcy; sprawdzanie przeszłości tych pracowników; zgłaszanie bez zbędnej zwłoki incydentów stwarzających ryzyko; prawo do audytu lub do otrzymywania sprawozdań z audytu; obowiązek postępowania z podatnościami; wymogi dotyczące podwykonawstwa; obowiązki przy rozwiązaniu umowy, na przykład zwrot i usunięcie informacji.

Rozporządzenie wiąże tylko podmioty z jego artykułu 1: dostawców usług DNS, rejestry TLD, dostawców chmury, centrów danych i CDN, dostawców usług zarządzanych i usług zarządzanych w zakresie bezpieczeństwa, platformy handlowe online, wyszukiwarki, serwisy społecznościowe i dostawców usług zaufania. Szpitala ani producenta nie wiąże, ale osiem punktów działa jako lista kontrolna do projektu umowy. Gdy któregoś brakuje, agencja przed podpisem pyta klienta, jak go pokrywa.

#Jak określić zakres usług agencji w ocenie dostawcy NIS2

Pakiet agencji zaczyna się od opisu granicy. Należy wskazać strony umowy, usługę klienta, witryny produkcyjne, repozytoria, środowiska, integracje i dostawców faktycznie obsługiwanych przez agencję. Osobno rozpisuje się odpowiedzialność za kod WordPress, hosting, DNS, CDN, tożsamość, płatności i dostęp redakcyjny. Obecność narzędzia w architekturze nie czyni automatycznie agencji właścicielem kontroli.

W tym samym dokumencie zapisuje się wyłączenia i założenia. Jeśli klient utrzymuje dostawcę tożsamości albo sam zarządza bazą, trzeba to powiedzieć. Jeżeli agencja wdraża kod, lecz nie zatwierdza zmian produkcyjnych, ten podział również musi być widoczny. Klient regulowany odpowiada za kwalifikację NIS2 i prawo krajowe; agencja dostarcza dowody dotyczące własnej usługi.

#Macierz RACI NIS2 dla klienta, agencji i hostingu

Macierz w stylu RACI obejmuje akceptację zmian, wdrożenia awaryjne, triage podatności, dostęp uprzywilejowany, wykonywanie backupu, zgodę na restore, eskalację incydentu, przegląd logów i wyjście od dostawcy. Każdy wiersz wskazuje rolę klienta, rolę agencji, zatwierdzającego, miejsce dowodu i kanał eskalacji.

Kontrole współdzielone wymagają dokładności. Hosting może tworzyć kopię, agencja nadzorować wykonanie, a klient ustalać cel odtworzenia. Wpis „odpowiada hosting” ukrywa obowiązki kontrolne i decyzyjne pozostałych stron. Macierz aktualizuje się po zmianie zakresu, architektury albo osób.

#Dowody NIS2 dla zmian, podatności i dostępów

Dla zmiany zachowuje się wniosek, ocenę ryzyka, review drugiej osoby, test, akceptację, zapis wdrożenia i wynik rollbacku. Zmiana awaryjna ma krótszą ścieżkę, ale nie ścieżkę bez dokumentacji: zapisuje się uprawnienie decydenta, powód i termin przeglądu po fakcie. Release powinien łączyć ticket, commit i czas produkcyjny.

Dla podatności utrwala się źródło alertu, aktywo i wersję, uzasadnienie priorytetu, ekspozycję, decyzję, termin i retest. Sam eksport ze skanera nie mówi, czy problem dotyczył produkcji ani czy wyjątek zaakceptowano. Gdy wtyczka nie ma wspieranego patcha, potrzebne są kontrole kompensacyjne i decyzja o zastąpieniu.

Dla dostępu zapisuje się imienną tożsamość, rolę, uzasadnienie, zatwierdzającego, MFA, datę nadania i ostatni review. Usunięcie dostępu osoby odchodzącej lub wygasłego konta wsparcia także wymaga śladu. Hasła i kody odzyskiwania nie należą do segregatora dowodowego.

#Jak przetestować odtworzenie backupu jako dowód NIS2

Zielony status zadania backupu potwierdza utworzenie pliku, nie odzyskiwalność. Dowód opisuje zakres, rytm, szyfrowanie, lokalizację, retencję, alarm błędu i osoby uprawnione do restore. Następnie przeprowadza się odtworzenie w izolowanym środowisku, zapisując początek, koniec, kontrolę integralności, test aplikacji i odchylenia od RPO oraz RTO.

Trzeba uwzględnić zależności poza bazą: media, konfigurację, sekrety, DNS, reguły edge, zadania cykliczne i definicje deployu. Sam restore bazy może dać stronę, która się otwiera, ale nie wysyła wiadomości ani nie przyjmuje płatności. Protokół odbioru precyzuje, jaką usługę odzyskano, co zasymulowano i co wyłączono.

#Jak często przeglądać i odbierać dowody NIS2

Każdy dowód otrzymuje właściciela oraz wyzwalacz aktualizacji. Dostępy można przeglądać kwartalnie, ćwiczenia restore i incydentowe corocznie lub po istotnej zmianie, a podatności i patche na bieżąco. Zmiana umowy, architektury, dostawcy albo krytycznej wtyczki uruchamia przegląd celowany.

Artefakt jest przyjęty, gdy jest aktualny, przypisany, powiązany z kontrolą w zakresie, zapisany we właściwym miejscu i sprawdzony przez odpowiedzialną rolę. Luki prowadzi się osobno z ryzykiem, właścicielem i terminem. Nie wolno tworzyć brakującego historycznego zapisu tak, jakby istniał wcześniej.

Pakiet pokazuje wybrane kontrole dostawcy w określonym okresie. Nie jest certyfikatem NIS2, opinią prawną ani dowodem pełnej zgodności klienta. Nie gwarantuje też braku incydentów. Ograniczenia powinny znaleźć się na stronie tytułowej.

#Wycena pakietu dostawcy NIS2 dla WordPress

Do wyceny należy przesłać strony umowy, opis usługi, architekturę, środowiska, krytyczne integracje, kwestionariusz dostawcy, termin audytu i listę dostępnych dowodów. W pierwszej wiadomości nie należy przesyłać sekretów. Nasza usługa gotowości NIS2 i DORA może objąć pakiet dostawcy WordPress, macierz odpowiedzialności, luki dowodowe i odbiór. Nie zastępuje ona oceny prawnej klienta.

#Co zawiera pakiet bezpieczeństwa dostawcy dla klientów regulowanych

Agencja WordPress, która chce w 2026 utrzymać regulowanych klientów, dostarcza w każdym mandacie dwa artefakty:

1. Samodeklarację względem artykułu 21 ust. 2 lit. d, opisującą środki bezpieczeństwa wdrożone u samej agencji.
2. Dokument referencyjny, który klient wkleja do własnego segregatora artykułu 21, pokazujący, jak mandat WordPress mapuje się na każdy z dziesięciu środków.

Oba pakuję w „pakiet bezpieczeństwa dostawcy” i dołączam do oferty. To eliminuje rundę z działem zakupów i sygnalizuje rozumienie kontekstu regulacyjnego. Wycena mandatów compliance-engineering jest indywidualna; zakres segregatora dyktuje godziny, nie cennik.

#Powiązane teksty o zgodności

• Filar: NIS2 i DORA na WordPress: stos zgodności 2026
• DORA artykuł 28 ryzyko stron trzecich ICT: audyt dostawcy hostingu i WAF dla WordPress
• WordPress reakcja na incydent pod NIS2: 24-godzinny playbook wczesnego ostrzeżenia
• Cyber Resilience Act + NIS2 + DORA: stos zgodności 2026 dla headless WordPress