Nowy podręcznik NIST dla kadry zarządzającej. Co z niego wziąć do SZBI według ustawy o KSC i ISO/IEC 27001?

NIST SP 800-100r1 to projekt, nie wymaganie. Co daje kierownikowi podmiotu, jak ma się do ISO/IEC 27001 i art. 8 ustawy o KSC i gdzie łatwo się pomylić.

Autor: Paweł Rosół
Data: 03.11.2026
Czytanie: 10 min
Kategoria: Zarządzanie ryzykiem

Stan prawny sprawdzony: 03.11.2026

Spis treści

Co NIST właściwie opublikował?
Czy ISO mówi „co”, a NIST „jak”?
Jak NIST ma się do NIS2 i prawa w Polsce?
Co bym z tego podręcznika wziął?
Gdzie to samo słowo znaczy co innego?
Jak to złożyć z normą i ustawą?
Od czego zacząć?

NIST, amerykański Narodowy Instytut Standardów i Technologii, opublikował 21 października 2026 r. projekt nowego wydania podręcznika SP 800-100 dla kadry zarządzającej. Kierownik podmiotuKierownik podmiotu Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie. kluczowego lub ważnego dostaje z niego przede wszystkim słownik do rozmowy o ryzyku i porządek tematów. Nie dostaje żadnego wymagania: podręcznik nie wspomina ani o ISO/IEC 27001, ani o NIS2Dyrektywa NIS2 Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. o cyberbezpieczeństwie w Unii. W Polsce wdraża ją ustawa o KSC po nowelizacji z 2026 r., a o tym, czy system spełnia prawo, rozstrzyga w Polsce art. 8 ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawy o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.).

Czytam go więc jako dodatek do systemu zarządzania bezpieczeństwem informacjiSystem zarządzania bezpieczeństwem informacji Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów. (SZBI), który podmiot i tak musi mieć. Poniżej piszę, co bym z niego wziął, gdzie spotyka się z normą i ustawą i gdzie ten sam termin znaczy co innego.

Co NIST właściwie opublikował?

Poprzednie wydanie pochodzi z 2006 r. Nowe ma streszczać najważniejsze tematy dla osób, które zarządzają bezpieczeństwem informacji i ryzykiem, ale nie muszą mieć obowiązków technicznych: kierownictwa, CIO, CISODyrektor ds. bezpieczeństwa informacji Osoba odpowiedzialna w organizacji za program bezpieczeństwa informacji, zwykle raportująca zarządowi o stanie zabezpieczeń i ryzykach., kierowników programów i właścicieli systemów. Układ idzie za funkcjami NIST Cybersecurity FrameworkNIST Cybersecurity Framework Dobrowolne ramy amerykańskiego NIST opisujące rezultaty zarządzania ryzykiem cyberbezpieczeństwa w sześciu funkcjach, od Govern po Recover. Same nie wskazują, jak te rezultaty osiągnąć. 2.0 (CSF): zarządzanie (Govern), identyfikacja (Identify), ochrona (Protect) oraz wspólny rozdział o wykrywaniu, reagowaniu i odtwarzaniu. Po szczegóły podręcznik odsyła do innych publikacji NIST.

To wciąż projekt. Uwagi NIST przyjmuje do 4 grudnia 2026 r., a w tekście widać robocze ślady, na przykład niedziałające odesłania („Error! Reference source not found”). Nie wpisywałbym go jeszcze do dokumentacji SZBI jako źródła, bo numeracja i treść mogą się zmienić.

Dla organizacji spoza administracji federalnej USA dokument jest dobrowolny, co NIST pisze wprost. Autorzy zapowiadają mniejszy nacisk na odbiorcę federalnego, ale ten odbiorca wciąż jest w tekście: pierwsza rola na liście to „Head of Agency”, sekcja 3.4 wylicza amerykańskie ustawy, a sekcja 7.2 omawia zgłoszenia do US-CERT. I drobna pułapka przy czytaniu: w sekcji 6.2 skrót ISO oznacza właściciela systemu informacyjnego (information system owner), nie organizację normalizacyjną.

Czy ISO mówi „co”, a NIST „jak”?

To popularne uproszczenie i ma w sobie trochę prawdy, ale po przeczytaniu dokumentów się rozsypuje. CSF 2.0 opisuje sam siebie odwrotnie: dokument mówi, do jakich rezultatów organizacja może dążyć („what desirable outcomes an organization can aspire to achieve”), a nie wskazuje, jak je osiągnąć. „Jak” jest u NIST w innych publikacjach, na przykład w katalogu SP 800-53.

Po stronie ISO jest podobnie. Rozdziały 4 do 10 normy PN-EN ISO/IEC 27001:2023-08 to wymagania wobec systemu zarządzania, a załącznik A wynika bezpośrednio z ISO/IEC 27002:2022, który rozwija te zabezpieczenia. Irlandzkie NCSC ustawia to jeszcze inaczej: „co” to krajowe środki zarządzania ryzykiemZarządzanie ryzykiem To, co podmiot robi z oszacowanym ryzykiem: dobiera zabezpieczenia, a ryzyko, którego nie ogranicza, akceptuje świadomie. („the ‘what’ organisations need to do”), a ISO 27001, COBIT i NIST są sposobami ich spełnienia.

Dla podmiotu w Polsce „co” wyznacza ustawa, a ISO i NIST są dwiema półkami z materiałem, po który może sięgnąć.

Przydatniejszy podział ma polskie zestawienie dokumentów normalizacyjnych z art. 45 ust. 3 ustawy o KSC, które we wrześniu 2026 r. opublikowało Ministerstwo Cyfryzacji. Dzieli ono dokumenty według typu. Tak wygląda to dla kilku pozycji:

Dokument	Typ w zestawieniu	Do czego go użyć	Dostęp
PN-EN ISO/IEC 27001:2023	certyfikowalna	zbudować system, który oceni jednostka certyfikująca	płatny
PN-EN ISO/IEC 27002:2023	wytyczne	dobrać i opisać zabezpieczenia	płatny
NIST CSF 2.0, NIST RMF	framework	analiza luk i rozmowa z zarządem	bezpłatny
NSC 800-30, NSC 800-61, NSC 800-34	wytyczne	szacowanie ryzykaSzacowanie ryzyka Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”., incydenty, plany awaryjne po polsku	bezpłatny

Opis frameworku w legendzie zestawienia dobrze oddaje to, po co sięgać po CSF: służy on „do analiz typu gap analysis i komunikacji z zarządem”. Podręcznik SP 800-100 idzie w tę samą stronę, choć sam w zestawieniu się nie znalazł.

NSC to Narodowe Standardy Cyberbezpieczeństwa, opracowane w Kancelarii Prezesa Rady Ministrów na podstawie standardów NIST. Zanim ktoś w firmie zacznie tłumaczyć amerykański katalog zabezpieczeń, niech sprawdzi tę listę. Jest na niej także NSC 800-53 MAP, czyli mapowanie na PN-ISO/IEC 27001, ale zestawienie podaje oznaczenie normy bez roku, więc wydanie trzeba sprawdzić przed użyciem.

Jak NIST ma się do NIS2 i prawa w Polsce?

Art. 21 ust. 1 dyrektywy NIS2 wymaga uwzględnienia najnowszego stanu wiedzy oraz, „w stosownych przypadkach, odpowiednich norm europejskich i międzynarodowych”, a art. 25 ust. 1 zobowiązuje państwa członkowskie, żeby zachęcały do ich stosowania. Ten podręcznik NIST przygotował na podstawie amerykańskiej ustawy FISMA, a nie jako normę. Polski minister i tak umieścił inne publikacje NIST w zestawieniu, a w raporcie z konsultacji dopuszcza też inne rozwiązania:

„Podmioty mogą stosować również inne dokumenty normalizacyjne, standardy lub rozwiązania zapewniające spełnienie wymagań wynikających z uKSC, o ile gwarantują one osiągnięcie co najmniej równoważnego poziomu realizacji tych wymagań”.

Równoważność trzeba jednak umieć pokazać. Część „Ważne informacje” samego zestawienia mówi też krótko: „Wdrożenie normy nie zwalnia podmiotu z obowiązku realizacji wymagań uKSC”. ENISA w wytycznych do rozporządzenia 2024/2690 odwzorowuje wymagania między innymi na ISO/IEC 27001:2022 i CSF 2.0 oraz cytuje w przypisach SP 800-53, SP 800-61 i SP 800-161, ale zastrzega, że nie jest to miara równoważności. Pisałem o tym szerzej w tekście o SZBI i systemie zgodnym z ISO/IEC 27001.

Państwa członkowskie rozwiązały to różnie:

Belgia wpisała do przepisów CyberFundamentals (CyFun), ramy oparte między innymi na NIST CSF, ISO/IEC 27001, CIS Controls i IEC 62443, jako podstawę domniemania zgodności.
Irlandia przejmuje CyFun i go poleca, ale dobrowolnie. NCSC zaznacza, że to „not a statutory presumption of compliance”, a uznanie certyfikacji za domniemanie zgodności zostawia właściwym organom. Uznaje też inne standardy, w tym ISO 27001.
Włochy mają obowiązkowe środki podstawowe ułożone w funkcje, kategorie i podkategorie krajowego Framework Nazionale: 37 środków z 87 wymaganiami dla podmiotów ważnych i 43 środki ze 116 wymaganiami dla kluczowych. Kody takie jak ID.AM-03 czy PR.AT-02 mają te same oznaczenia co w CSF 2.0.

Polska ustawa o KSC nie ma takiego mechanizmu ani dla NIST, ani dla ISO. Włoski i belgijski przykład przydają się więc jako podpowiedź, jak ułożyć środki, a nie jako argument przed polskim organem.

Co bym z tego podręcznika wziął?

Rozdzielenie apetytu na ryzyko i tolerancji ryzyka

Apetyt na ryzyko ustala najwyższy szczebel: jakiego rodzaju i ile ryzyka kierownictwo jest gotowe przyjąć. Tolerancja to konkretny poziom w ramach tego apetytu, więc jest zawsze bardziej szczegółowa. Norma wymaga kryteriów akceptacji ryzyka (pkt 6.1.2 lit. a normy), a tych dwóch pojęć nie rozdziela. Ustawa o KSC ich nie używa, ale art. 8d pkt 1 przypisuje kierownikowi podmiotu decyzje o systemie.

Tu rozróżnienie NIST ma praktyczny sens, bo zarząd nie musi oceniać każdego wiersza rejestru ryzyka. Podaję przykład wymyślony na potrzeby tego tekstu: zarząd spółki wodociągowej zapisuje, że nie godzi się na przerwę w dostawie wody dłuższą niż doba, a z tego wynika tolerancja dla systemu dyspozytorskiego, na przykład odtworzenie w ciągu 8 godzin. Dopiero wtedy właściciel systemu wie, kiedy ryzyko musi wrócić do zarządu.

Trzy poziomy zarządzania ryzykiem

Podręcznik, za SP 800-39, rozróżnia poziom organizacji, poziom procesów i poziom systemu. Art. 8 ust. 1 ustawy o KSC wyznacza zakres przez „system informacyjny wykorzystywany w procesach wpływających na świadczenie usługi”, więc moim zdaniem właśnie środkowy poziom jest tu najważniejszy.

Zarząd rozmawia o strategii, informatycy o systemach, a procesu, od którego zależy usługa, łatwo może nie wziąć na siebie nikt.

To miejsce na pracę osoby, której kierownik powierzył cyberbezpieczeństwo. Opisałem to w tekście o tym, kto tłumaczy cyberbezpieczeństwo na język zarządu.

Jedna osoba, która przyjmuje ryzyko

W ramach zarządzania ryzykiem NIST (RMF) jest urzędnik zatwierdzający (authorizing official), według podręcznika jedyna osoba, która może przyjąć ryzyko w imieniu organizacji. Zgoda na działanie systemu jest przy tym okresowa albo ciągła, więc wraca. Całego federalnego mechanizmu bym nie kopiował. Norma mówi o akceptacji ryzyka rezydualnego przez właścicieli ryzyka (pkt 6.1.3 lit. f normy) i to się sprawdza, dopóki wszyscy pamiętają o art. 8c ust. 3 ustawy o KSC: kierownik odpowiada także wtedy, gdy powierzył obowiązki innej osobie.

Z NIST wziąłbym samą zasadę: przy każdym systemie w zakresie SZBI ma być wiadomo, kto i kiedy przyjął ryzyko, które zostało, i kiedy ta decyzja wygasa. Podpis właściciela ryzyka nie zamyka sprawy, jeśli kierownik nie zna kryteriów, według których właściciel podpisywał.

Pomiary zamiast deklaracji

Sekcja 4.4 opisuje pomiary, które pomagają wskazać luki i podejmować decyzje, także o budżecie i ludziach. Ustawa wymaga „polityki i procedury oceny skuteczności środków technicznych i organizacyjnych” (art. 8 ust. 1 pkt 2 lit. h), a norma określenia, co się mierzy, kto i kiedy (pkt 9.1 normy). Podręcznik sam miar nie podaje i odsyła do SP 800-55, więc i tak trzeba je wybrać pod własną usługę.

Gdzie to samo słowo znaczy co innego?

Największa pułapka to monitorowanie ciągłe. Art. 8 ust. 1 pkt 2 lit. g ustawy o KSC wymaga objęcia systemu „systemem monitorowania w trybie ciągłym”, a Ministerstwo Cyfryzacji tłumaczy, że podmiot powinien monitorować zdarzenia w systemie, między innymi po to, żeby dało się odtworzyć, co się w nim stało (FAQ, pytanie 3.3). Bliżej temu do logów i narzędzi typu SIEM, które u NIST należą do wykrywania.

Rozdział 6 podręcznika o ciągłym monitorowaniu bezpieczeństwa informacji (ISCM) mówi o czymś innym: analizuje skuteczność zabezpieczeń względem tolerancji ryzyka, obejmuje ocenę zabezpieczeń i raportowanie stanu, a jego wyniki trafiają do decydentów. To odpowiada raczej lit. h niż lit. g.

Podmiot, który zbiera i analizuje zdarzenia, może spełniać lit. g, a wciąż nie wiedzieć, czy jego zabezpieczenia działają.

Druga pułapka to role. CISO i CIO z listy NIST nie są funkcjami ustawowymi. Ustawa zna kierownika podmiotu, a art. 14 nakazuje podmiotowi powołać wewnętrzne struktury albo zawrzeć umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa. Tak samo z rolą inspektora: starszy urzędnik ds. prywatności z podręcznika (SAOP) prowadzi zarządzanie ryzykiem prywatności, a zadania inspektora ochrony danych (IOD) określa art. 39 RODO, więc jednego na drugiego bym nie przekładał. Podręcznik omawia NIST Privacy Framework, ale nie pisze o ocenie skutków dla ochrony danych. Tematy RODO opisuję na pawel.rosol.pl.

Jak to złożyć z normą i ustawą?

Tak czytałbym podręcznik obok własnego systemu. Tabela jest moim skrótem i pokazuje, gdzie szukać, a nie że te fragmenty są sobie równe:

Temat i sekcja SP 800-100r1	ISO/IEC 27001	Ustawa o KSC
Role i odpowiedzialność (1.2, 3.2)	pkt 5.1 i 5.3	art. 8c, 8d, 14
Strategia i szacowanie ryzyka (3.1, 4.2)	pkt 6.1.2, 6.1.3, 8.2, 8.3	art. 8 ust. 1 pkt 1
Polityka (3.3)	pkt 5.2, zabezpieczenie 5.1	art. 8 ust. 1 pkt 2 lit. a
Łańcuch dostaw (2.7, 3.1.1)	zabezpieczenia 5.19 do 5.23	art. 8 ust. 1 pkt 2 lit. e, art. 8 ust. 2
Aktywa (4.1)	zabezpieczenie 5.9	art. 8 ust. 1 pkt 2 lit. m
Pomiary i ciągłe monitorowanie (4.4, 6)	pkt 9.1	art. 8 ust. 1 pkt 2 lit. h
Szkolenia (5.2)	pkt 7.3, zabezpieczenie 6.3	art. 8 ust. 1 pkt 2 lit. i, art. 8d pkt 4
Plany awaryjne i ciągłość (5.3)	zabezpieczenia 5.29 i 5.30	art. 8 ust. 1 pkt 2 lit. f
Konfiguracja (5.4)	zabezpieczenia 8.9 i 8.32	art. 8 ust. 1 pkt 2 lit. b
Incydenty (7)	zabezpieczenia 5.24 do 5.28	art. 8 ust. 1 pkt 4, art. 11

Prawa kolumna ma pozycje, których w lewej nie znajdziesz w żadnej formie. Podręcznik nie zna terminów 24 godzin i 72 godzin na zgłoszenia do CSIRT sektorowego (art. 11 ust. 1 pkt 4 i 4a), informacji z Krajowego Rejestru Karnego (art. 8f ust. 1), corocznego szkolenia kierownika (art. 8e) ani audytu podmiotu kluczowego co najmniej raz na 3 lata (art. 15 ust. 1).

Kto zbuduje system wyłącznie według podręcznika NIST albo wyłącznie według normy, zostanie z tymi samymi lukami ustawowymi.

Od czego zacząć?

Nie dawałbym zarządowi całego dokumentu. Osobie odpowiedzialnej za cyberbezpieczeństwo wystarczą na początek sekcje 1.2, 3.1, 3.2, 4.4 i rozdział 6, a do zarządu niech trafią trzy pytania z nich wynikające:

Czy mamy zapisane, jakiego ryzyka dla usługi nie przyjmujemy, i czy właściciele systemów znają wynikającą z tego tolerancję?
Kto przy każdym systemie w zakresie SZBI przyjął ryzyko, które zostało, i kiedy ta decyzja wraca na stół?
Które dwie albo trzy liczby pokazują nam co kwartał, czy zabezpieczenia działają?

Odpowiedzi trafiają do protokołu jako decyzje kierownika z art. 8d. Kto chce wpłynąć na ostateczny tekst, ma czas do 4 grudnia 2026 r. NIST pyta między innymi o to, jakie źródła dopisać, więc można mu wskazać ISO/IEC 27001 i NIS2, których w projekcie nie ma.

Pojęcia w tym tekście (18)

Kierownik podmiotu: Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie.
Dyrektywa NIS2: Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. o cyberbezpieczeństwie w Unii. W Polsce wdraża ją ustawa o KSC po nowelizacji z 2026 r.
Ustawa o KSC: Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.
System zarządzania bezpieczeństwem informacji: Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów.
Dyrektor ds. bezpieczeństwa informacji: Osoba odpowiedzialna w organizacji za program bezpieczeństwa informacji, zwykle raportująca zarządowi o stanie zabezpieczeń i ryzykach.
NIST Cybersecurity Framework: Dobrowolne ramy amerykańskiego NIST opisujące rezultaty zarządzania ryzykiem cyberbezpieczeństwa w sześciu funkcjach, od Govern po Recover. Same nie wskazują, jak te rezultaty osiągnąć.
Zarządzanie ryzykiem: To, co podmiot robi z oszacowanym ryzykiem: dobiera zabezpieczenia, a ryzyko, którego nie ogranicza, akceptuje świadomie.
Szacowanie ryzyka: Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”.
Incydent: Zdarzenie, które szkodzi albo może zaszkodzić bezpieczeństwu systemów informacyjnych. Zgłaszać trzeba nie każdy incydent, tylko incydent poważny.
Plan awaryjny: Plan na pierwsze godziny incydentu: kto decyduje, co odłączyć, kogo powiadomić i kto liczy termin zgłoszenia do CSIRT. Ustawa o KSC wymienia go obok planu ciągłości działania i planu odtworzenia.
Podmiot ważny: Podmiot z sektorów ustawy o KSC, który spełnia jej kryteria, ale nie jest podmiotem kluczowym. Wdraża SZBI i zgłasza incydenty poważne tak jak podmiot kluczowy.
System SIEM: Security Information and Event Management: system, który zbiera w jednym miejscu logi z wielu systemów i urządzeń, żeby można je było analizować i wykrywać w nich ślady incydentów.
Dostawca usług zarządzanych w zakresie cyberbezpieczeństwa: Firma, która na podstawie umowy prowadzi dla podmiotu działania z zakresu zarządzania ryzykiem, na przykład obsługę incydentów, testy lub audyty. Umowa z nią zastępuje własny zespół.
Inspektor ochrony danych: Osoba wyznaczona przez administratora lub podmiot przetwarzający do zadań z RODO. Tutaj pojawia się przy incydentach z danymi osobowymi i przy łączeniu tej funkcji z rolą pełnomocnika.
RODO: Rozporządzenie (UE) 2016/679 o ochronie danych osobowych. Tematy RODO omawiam na pawel.rosol.pl; tutaj pojawia się przy incydentach, które są też naruszeniem ochrony danych.
Łańcuch dostaw: Dostawcy sprzętu, oprogramowania i usług ICT, od których zależy świadczenie usługi. Ich bezpieczeństwo podmiot uwzględnia w swoim zarządzaniu ryzykiem.
CSIRT sektorowy: Zespół reagowania na incydenty dla jednego sektora lub podsektora, ustanowiony przez organ właściwy. To do niego podmiot kluczowy lub ważny zgłasza incydent poważny.
Podmiot kluczowy: Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata.

Najczęściej zadawane pytania

Czy stosowanie dokumentów NIST wystarczy, żeby spełnić ustawę o KSC?

Samo w sobie nie. Ustawa o KSC nie wskazuje żadnej normy ani ram, a wymagania określa art. 8 i kolejne. Minister w raporcie z konsultacji zestawienia z art. 45 ust. 3 dopuszcza stosowanie różnych dokumentów i rozwiązań, jeśli gwarantują co najmniej równoważny poziom realizacji wymagań, ale zastrzega, że standard odnoszący się tylko do części obowiązków nie zwalnia z pozostałych.

Czy NIST CSF 2.0 jest w polskim zestawieniu dokumentów normalizacyjnych?

Tak. Zestawienie opublikowane na podstawie art. 45 ust. 3 ustawy o KSC wymienia NIST CSF 2.0 jako bezpłatny framework na poziomie podstawowym, obok innych publikacji NIST i ich polskich opracowań NSC. Zestawienie ma charakter referencyjny i ujęcie w nim nie oznacza obowiązku stosowania dokumentu. Samego SP 800-100 w zestawieniu nie ma.

Czy certyfikat albo wdrożenie NIST daje w Polsce domniemanie zgodności z NIS2?

Ustawa o KSC nie przewiduje takiego mechanizmu ani dla NIST, ani dla ISO/IEC 27001. Zestawienie z art. 45 ust. 3 w części „Ważne informacje” stwierdza, że wdrożenie normy nie zwalnia podmiotu z obowiązku realizacji wymagań ustawy. Domniemanie zgodności dla CyberFundamentals ma natomiast Belgia.

Źródła

Stan prawny sprawdzony: 03.11.2026. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).