Cyber Resilience Act + NIS2 + DORA: zgodność w 2026 roku dla headless WordPressa
W latach 2024-2026 trzy unijne akty zbiegły się w tej samej treści operacyjnej. Cyber Resilience Act (rozporządzenie (UE) 2024/2847) reguluje produkty z elementami cyfrowymi wprowadzane na rynek UE. Dyrektywa NIS2 (2022/2555) reguluje podmioty świadczące usługi kluczowe lub ważne. Rozporządzenie DORA (2022/2554) reguluje podmioty finansowe i zewnętrznych dostawców usług ICT, z których korzystają. Headless WordPress wdrożony dla podmiotu regulowanego, z komercyjnym komponentem w zestawie, trafia pod wszystkie trzy akty naraz. Dobra wiadomość: jeden pakiet dowodów może spełnić wymogi wszystkich trzech, jeśli ułoży się go według kontroli, a nie według aktów.
Ten artykuł zamyka filar o NIS2 i DORA w WordPressie i spina ścieżkę dowodową z załącznika II, audyt dostawców z art. 28 DORA, 24-godzinny playbook incydentowy oraz tekst o dostępności BFSG i EAA.
Czym w skrócie jest zestaw wymogów CRA, NIS2 i DORA?
- CRA reguluje produkty. NIS2 reguluje podmioty. DORA reguluje podmioty finansowe.
- Headless WordPress dla podmiotów regulowanych może podlegać wszystkim trzem.
- Jeden pakiet dowodów ułożony według kontroli wygrywa z trzema osobnymi stosami dokumentów.
- Obowiązki zgłoszeniowe CRA od 2026 roku, pełne obowiązki producentów od 2027 roku.
- NIS2 od terminu transpozycji 2024-10-17; DORA stosowana bezpośrednio od 2025-01-17.
Jak headless WordPress wpływa na zgodność z CRA, NIS2 i DORA?
Headless WordPress rozdziela dwie warstwy. Warstwa treści to WordPress jako edytor i źródło prawdy, udostępniający treści przez REST API albo GraphQL. Warstwa prezentacji to framework frontendowy (Next.js, Astro, Nuxt, SvelteKit), który pobiera te treści i renderuje je dla użytkowników.
Z punktu widzenia zgodności taki podział zmienia powierzchnię ryzyka na trzy sposoby.
Frontend jest produktem. Aplikacja Next.js z komercyjnymi bibliotekami, wdrożona przez agencję, może być “produktem z elementami cyfrowymi” w rozumieniu CRA, gdy zostaje sprzedana lub udostępniona na licencji podmiotowi finansowemu. Sam WordPress, jako darmowe oprogramowanie open source wydawane przez społeczność, nie wchodzi w zakres CRA zgodnie z motywem 15 rozporządzenia (UE) 2024/2847; komercyjne pakiety zbudowane na nim mogą wejść.
Łańcuch dostaw jest szerszy. Projekty headless wciągają zależności npm (często setki), funkcje brzegowe CDN, usługi optymalizacji obrazów, dostawców wyszukiwania, systemy komentarzy. Zarówno art. 21(2)(d) NIS2, jak i art. 28(2) DORA wymagają, by ten łańcuch był zinwentaryzowany, sklasyfikowany i objęty kontrolą umowną.
Powierzchnia incydentów jest podzielona. Podatność może siedzieć w backendzie WordPressa, w bundlu frontendu, w funkcji brzegowej albo w zewnętrznym API. 24-godzinny zegar NIS2 i terminy zgłoszeń z DORA dotyczą podmiotu niezależnie od tego, gdzie jest błąd. Runbook agencji musi wykrywać i klasyfikować zdarzenia we wszystkich czterech warstwach.
Czego wymagają CRA, NIS2 i DORA?
CRA (rozporządzenie (UE) 2024/2847)
Obejmuje produkty z elementami cyfrowymi wprowadzane na rynek UE. Art. 13 określa obowiązki producenta: cyberbezpieczeństwo już na etapie projektowania i domyślnie, obsługę podatności przez cały okres wsparcia, aktualizacje bezpieczeństwa, wykaz komponentów oprogramowania (SBOM), zgłaszanie aktywnie wykorzystywanych podatności do ENISA w ciągu 24 godzin od powzięcia wiedzy oraz zgłaszanie poważnych incydentów w ciągu 24 godzin od powzięcia wiedzy.
Harmonogram stosowania według art. 71:
- Obowiązki zgłaszania podatności i incydentów od 2026 roku.
- Pełne obowiązki producentów od 2027 roku (36 miesięcy po wejściu w życie).
- Wymogi oceny zgodności dla “ważnych” i “krytycznych” produktów z elementami cyfrowymi mają osobne ścieżki.
Oprogramowanie open source rozwijane i dostarczane bez działalności komercyjnej pozostaje poza zakresem CRA. Motywy rozporządzenia odróżniają niekomercyjny wkład w open source od komercyjnego pakietowania. Rdzeń WordPressa to niekomercyjny open source; oferta zarządzanego WordPressa sprzedawana jako produkt, z wtyczkami premium objętymi jedną licencją, może już wejść w zakres CRA.
NIS2 (dyrektywa 2022/2555)
Obejmuje podmioty (kluczowe i ważne) wymienione w załącznikach I i II. Art. 21(2) wymienia dziesięć środków zarządzania ryzykiem (szczegółowo w artykule o ścieżce dowodowej z załącznika II). Art. 23 ustala wczesne ostrzeżenie w 24 godziny, zgłoszenie w 72 godziny i raport końcowy po miesiącu (szczegółowo w 24-godzinnym playbooku reagowania na incydenty). Art. 21(2)(d) wciąga dostawców w zakres przez zobowiązania umowne.
Termin transpozycji minął 2024-10-17. Kilka państw członkowskich się spóźniło; przed każdym audytem końcowym sprawdź stan krajowy.
DORA (rozporządzenie 2022/2554)
Obejmuje podmioty finansowe wymienione w art. 2 oraz kluczowych zewnętrznych dostawców usług ICT (CTPP) wyznaczonych przez Europejskie Urzędy Nadzoru. Art. 28 dotyczy zarządzania ryzykiem ICT związanym z podmiotami trzecimi (szczegółowo w artykule o audycie dostawców z art. 28 DORA). Art. 16-19 opisują cykl zarządzania incydentami ICT. Art. 24-27 dotyczą testowania operacyjnej odporności cyfrowej, w tym TLPT.
Stosuje się bezpośrednio w całej UE od 2025-01-17.
Gdzie CRA, NIS2 i DORA się pokrywają?
Wdrożenie headless WordPressa dla podmiotu finansowego, z komercyjnym bundlem frontendu w zestawie, trafia na następujące punkty wspólne:
| Obszar kontroli | Odniesienie CRA | Odniesienie NIS2 | Odniesienie DORA |
|---|---|---|---|
| Obsługa podatności | Art. 13 (obowiązki producenta) | Art. 21(2)(e) | Art. 16, art. 17 |
| Aktualizacje bezpieczeństwa | Art. 13 (okres wsparcia) | Art. 21(2)(e) | Art. 8 (utrzymanie systemów ICT) |
| Wykaz komponentów oprogramowania | Art. 13 (SBOM) | Art. 21(2)(e) (nabywanie i rozwój) | Art. 8 |
| Zgłaszanie incydentów | Art. 14 (poważne incydenty do ENISA, 24 h) | Art. 23 (24/72/30) | Art. 19 (terminy dla podmiotów finansowych) |
| Łańcuch dostaw | Załącznik I sekcja II (należyta staranność producenta) | Art. 21(2)(d) | Art. 28 (zarządzanie ryzykiem podmiotów trzecich) |
| Zarządzanie ryzykiem | Art. 13(1) | Art. 21(2)(a) | Art. 6 (ramy zarządzania ryzykiem ICT) |
| Uwierzytelnianie | Art. 13(1) (bezpieczeństwo domyślne) | Art. 21(2)(j) (MFA) | Art. 8 (bezpieczeństwo informacji) |
| Kryptografia | Załącznik I sekcja I | Art. 21(2)(h) | Art. 9 (ochrona danych) |
Osiem wspólnych kontroli. Jeden pakiet dowodów z ośmioma folderami, z odniesieniami do wszystkich trzech aktów w każdym z nich, spełnia wymogi całej trójki.
Jak zbudować wspólny pakiet dowodów dla CRA, NIS2 i DORA?
Pakiet układam według obszarów kontroli, nie według aktów. Każdy folder kontroli zawiera:
- Politykę. Zatwierdzoną przez organ zarządzający podmiotu. Z odniesieniami do właściwych artykułów CRA / NIS2 / DORA.
- Właściciela procesu. Wskazaną rolę po stronie podmiotu oraz imienną osobę kontaktową po stronie agencji.
- Dowody wdrożenia. Logi, raporty z audytów, wyniki skanów, wyniki testów, klauzule umowne.
- Tabelę mapowania. Trzy kolumny: artykuł CRA, artykuł NIS2, artykuł DORA. Gdzie polityka mieści się w każdym akcie.
- Zapis przeglądu. Przegląd roczny lub częstszy, z datą i podpisem.
- Historię audytów. Audyty zewnętrzne, testy penetracyjne, zapytania regulatora, wszystko z datami i oznaczeniami.
Wspólny pakiet eliminuje najczęstsze marnotrawstwo przy zgodności z kilkoma aktami: pisanie tego samego rejestru ryzyk trzy razy dla trzech regulatorów. Jeden rejestr, trzy odniesienia do artykułów w metadanych.
Jakich dowodów dla CRA, NIS2 i DORA wymaga wdrożenie headless?
Projekt headless dokłada artefakty, których monolityczne wdrożenie WordPressa nie potrzebuje:
- SBOM bundla frontendu. Plik CycloneDX lub SPDX z listą wszystkich zależności npm, z wersją i licencją. Generowany przez
npm audit signaturesplus generator CycloneDX. SBOM to produkt wymagany przez art. 13 CRA; przy NIS2 i DORA służy obsłudze podatności. - SBOM backendu WordPressa. Inwentarz wtyczek i motywów z wersją i licencją. Plugin checker z WordPress.org plus wewnętrzne pliki blokady wersji.
- Inwentarz funkcji brzegowych. Cloudflare Workers, Netlify Functions, Vercel Edge. Każda funkcja jest elementem łańcucha dostaw i elementem powierzchni incydentów.
- Dokumentacja kontraktu API. Schemat OpenAPI lub GraphQL dla API headless, z definicjami zabezpieczeń, limitami zapytań i uwierzytelnianiem.
- Dowody z pipeline’u wdrożeń frontendu. Logi CI/CD, wyniki skanowania kontenerów, dowody skanowania sekretów, przegląd zależności przy każdym PR.
- Monitoring międzywarstwowy. Jeden dashboard albo runbook, który koreluje zdarzenia z backendu WordPressa, aplikacji frontendowej, warstwy brzegowej i zewnętrznych API.
Dla podmiotu regulowanego ten zestaw artefaktów jest obowiązkowy. Dla podmiotu nieregulowanego to dobra praktyka, ale rozmowa o budżecie robi się trudniejsza.
Czego nie obejmuje wspólny pakiet dla CRA, NIS2 i DORA?
Są trzy obszary, których jeden pakiet nie pokrywa.
Ocena zgodności według CRA. “Ważne” i “krytyczne” produkty z elementami cyfrowymi wymagają oceny zgodności przez stronę trzecią zgodnie z załącznikiem VII CRA. NIS2 i DORA nie mają odpowiednika w postaci bazowej certyfikacji przez stronę trzecią (najbliżej jest TLPT z DORA). Ocenę zgodności zaplanuj jako osobny strumień prac.
TLPT według art. 26 DORA. Testy penetracyjne prowadzone w oparciu o analizę zagrożeń dla wyznaczonych istotnych podmiotów finansowych odbywają się według ram TIBER-EU. NIS2 i CRA nie wymagają testów tej głębokości.
Nadzór sektorowy. NIS2 ma sektorowe organy właściwe. DORA ma wspólne zespoły egzaminacyjne z art. 31. CRA ma organy nadzoru rynku z załącznika VIII. Trzy różne kanały nadzorcze nadal wymagają osobnych procesów komunikacji.
Czego CRA, NIS2 i DORA wymagają od agencji WordPress?
Agencja WordPress, która w 2026 roku chce dostarczać projekty headless podmiotom regulowanym, musi:
- Raz zbudować szablon wspólnego pakietu dowodów i używać go w kolejnych zleceniach.
- Generować SBOM w ramach pipeline’u wdrożeń, a nie na doczepkę.
- Prowadzić rejestr dostawców jako żywy dokument.
- Utrzymywać gotowość do reagowania na incydenty w obu warstwach (WordPress i frontend).
- Śledzić akty wykonawcze do CRA, które ENISA będzie publikować przez cały 2026 rok.
Wycena jest indywidualna; długość współpracy wyznacza zakres wymogów zgodności, a nie stały miesięczny abonament.
Powiązane poradniki o CRA, NIS2 i DORA
- Filar: NIS2 i DORA w WordPressie: zestaw wymogów zgodności na 2026 rok
- Załącznik II NIS2 dla agencji WordPress: zakres, terminy, ścieżka dowodowa
- Art. 28 DORA, ryzyko ICT podmiotów trzecich: audyt dostawców hostingu i WAF dla WordPressa
- Reagowanie na incydenty w WordPressie według NIS2: playbook wczesnego ostrzeżenia w 24 godziny
- BFSG a EAA: niemiecka ustawa o dostępności i termin 2025 dla sklepów na WordPressie
