O czym jest ten dokument
NIS2 Directive (EU) 2022/2555 weszła w życie w styczniu 2023 i od października 2024 roku ma być wdrożona w państwach członkowskich. Polska implementacja - ustawa o krajowym systemie cyberbezpieczeństwa w nowelizacji NIS2 - stanowi kotwicę prawną dla podmiotów essential i important entities w Polsce; aktualny status legislacyjny zmienia się dynamicznie i wymaga bieżącej weryfikacji. Dyrektywa wymaga od tych podmiotów wdrożenia odpowiednich środków zarządzania ryzykiem cybersec, ale sama definiuje je w kategoriach ogólnych.
Implementing Regulation (EU) 2024/2690 z 17 października 2024 wypełnia tę lukę dla podsektorów cyfrowej infrastruktury i usług ICT - sprecyzowuje wymogi techniczne i metodologiczne. ENISA Technical Implementation Guidance idzie o krok dalej: przekłada każdy z trzynastu obszarów cybersec na konkretną listę guidance i evidence, które audytor może zobaczyć. Dokument explicite zaznacza, że jest non-binding i ma jedynie advisory character - nie zastępuje krajowych wytycznych, ale daje wspólną mapę dla państw członkowskich.
Adresat to każdy podmiot, który podlega Implementing Regulation 2024/2690 - przede wszystkim dostawcy usług DNS, rejestratorzy nazw TLD, dostawcy usług chmurowych, centra danych, sieci dostarczania treści, dostawcy zarządzanych usług, dostawcy zarządzanych usług cyberbezpieczeństwa, marketplace internetowe, wyszukiwarki, dostawcy social networking, dostawcy zaufania. Pośrednio jednak guidance jest baseline metodologicznym dla wszystkich essential i important entities pod NIS2 - również w sektorach takich jak energetyka, transport, finanse, zdrowie, administracja publiczna.
Licencja Creative Commons Attribution 4.0 International (CC BY 4.0) pozwala na pełne cytowanie, adaptację i tłumaczenie z atrybucją do ENISA. To kontrastuje z wcześniejszymi tomami z naszej biblioteki - TOM 056 Kenney Governing Intelligence ma klauzulę proprietary, TOM 057 LEGIT ma arXiv preprint license. ENISA daje nam najszerszy zakres adaptacji.
Trzynaście obszarów - mapa pełna
| # | Obszar | Podsekcje |
|---|---|---|
| 1 | Policy on the security of network and information systems | 2 (policy + roles) |
| 2 | Risk management policy | 3 (framework, compliance monitoring, independent review) |
| 3 | Incident handling | 6 (policy, monitoring/logging, event reporting, classification, response, post-incident) |
| 4 | Business continuity and crisis management | 3 (BCDR plan, backup/redundancy, crisis management) |
| 5 | Supply chain security | 2 (policy + directory of suppliers) |
| 6 | Security in network and information systems acquisition, development and maintenance | 9+ (incl. network security, segmentation, malware protection) |
| 7 | Policies on the effectiveness of cybersecurity risk-management measures | compliance assessment |
| 8 | Basic cyber hygiene practices and cybersecurity training | training program, awareness |
| 9 | Use of cryptography and where appropriate, encryption | cryptographic controls |
| 10 | Human resources security | screening, agreements, disciplinary |
| 11 | Access control policies and asset management | access control, MFA |
| 12 | Asset management | 5 (incl. inventory, removable media, deposit/return upon termination) |
| 13 | Environmental and physical security | 3 (utilities, environmental threats, perimeter access) |
Plus dwa aneksy: Annex I National Frameworks i Annex II Glossary. Mapping na ISO/IEC 27005:2022 (information security risk management), ISO/IEC 27001 (Information Security Management Systems), NIST CSF, ENISA Threat Landscape - każdy obszar ma footnote do konkretnego standardu europejskiego lub międzynarodowego.
Recenzja właściwa
Pattern każdego rozdziału - GUIDANCE plus EXAMPLES OF EVIDENCE
Każdy z trzynastu obszarów następuje tej samej struktury. Pierwsze: cytat z odpowiedniego punktu Annexu do Implementing Regulation 2024/2690 - co dokładnie tekst regulacji wymaga. Drugie: sekcja GUIDANCE - bullet points wyjaśniające jak wymóg interpretować, z odniesieniami do standardów ISO i frameworks. Trzecie: sekcja EXAMPLES OF EVIDENCE - konkretna lista artefaktów, które audytor może zobaczyć podczas inspekcji.
Dla rozdziału 1.1 (Policy on the security of network and information systems) lista evidence obejmuje: dokumentowaną politykę zawierającą wszystkie elementy wymagane przez Annex (a-k, jedenaście elementów), datę formalnego zatwierdzenia przez management body, formularze potwierdzenia odczytania polityki przez personel, podpisane kontrakty service provision potwierdzające zapoznanie się przez external parties, dowody że management bodies rozumieją swoją rolę (alokacja zasobów, komunikaty do personelu, briefingi). Polityka musi być nie tylko napisana - musi być wdrożona, podpisana, akceptowana i utrzymywana w cyklu rocznym minimum.
Dla rozdziału 2.1 (Risk Management Framework) framework musi obejmować risk treatment plan z siedmioma elementami: opis zidentyfikowanego ryzyka, opcja treatment (avoidance/mitigation/transfer/acceptance), powiązane aktywa, środki łagodzące, procedura oceny skuteczności środków, terminy implementacji, role odpowiedzialne. Residual risks muszą być zaakceptowane przez management bodies. Evidence: udokumentowany framework, wyniki poprzednich risk assessments, treatment plan, zapisy zatwierdzeń, zapisy akceptacji residual risks.
To jest jakość operacyjna, której polskie podmioty NIS2 zwykle nie mają na piśmie. Procedury mogą być wdrożone w praktyce - ale bez udokumentowanej polityki, bez podpisanych kontraktów, bez zapisów zatwierdzeń przez zarząd, dla audytora nie istnieją. Dokument ENISA nie tworzy nowego wymogu - on rozkłada na czynniki pierwsze to, czego Implementing Regulation 2024/2690 wprost żąda.
Cztery obszary najmocniejsze dla polskiej kancelarii
Risk Management Framework (rozdz. 2.1). Dla polskiej kancelarii jako "important entity" pod NIS2 i jako administratora danych pod RODO art. 32 to jest fundament. Framework Kenneya (TOM 045 Runtime Enforcement, TOM 056 Atlas) i EDPB DPIA Guidelines (TOM 054) mówią o tym samym mechanizmie z różnych kątów. ENISA Risk Management Framework dorzuca konkretną strukturę treatment plan z siedmioma elementami i przy okazji explicite mapuje na ISO/IEC 27005:2022. Polska kancelaria może użyć tej struktury jako szablon dla swojego art. 32 RODO i NIS2 risk management - jeden dokument, dwa reżimy. Mechanizm baseline-eskalacja, który omawialiśmy w TOM 054, znajduje tu swoje technical-level uzupełnienie.
Incident Handling (rozdz. 3.1-3.6). Sześć podsekcji: policy, monitoring i logging, event reporting, event assessment i classification, incident response, post-incident reviews. To jest kompletny lifecycle, którego większość polskich podmiotów ma wdrożony fragmentarycznie. ENISA daje strukturę, którą można nakładać na istniejące procesy SIEM/SOC. Dla polskiej kancelarii kluczowe są dwa wymogi - udokumentowana procedura raportowania (art. 23 NIS2 wymaga early warning, incident notification, final report w określonych terminach) oraz post-incident reviews z opisanym mechanizmem rejestracji wniosków na przyszłość.
Supply Chain Security (rozdz. 5.1-5.2). Dwa elementy: polityka oraz directory of suppliers and service providers. Inwentarz dostawców jest oczekiwany jako pełny - z mappingiem dostawców na poziomy krytyczności, z dokumentacją kontraktów, z zapisami sub-processor disclosure. Bezpośrednio koresponduje z 12 klauzulami DPA Kenneya z dzisiejszej Aktualności "AI Compliance for the Enterprise" - inwentarz dostawców ICT z DPA i sub-processor list to ten sam artefakt w dwóch różnych aktach prawnych (art. 28 RODO, NIS2 art. 21).
Asset Management (rozdz. 12). Pięć podsekcji: politykę asset management, inventory, removable media policy, deposit/return/deletion przy zakończeniu zatrudnienia. Inventory ma być pełny - hardware, software, dane, sub-processors, użytkownicy, klucze kryptograficzne, certyfikaty. Polska kancelaria która nie ma takiego inwentarza w jednym miejscu, podlega gap nr 12 z listy Kenneya (shadow AI unmanaged) i jednocześnie nie spełnia art. 32 RODO ani NIS2 art. 21. Asset Management to fundament wszystkich innych dwunastu obszarów.
Czego ENISA nie powiedziała, a co musi powiedzieć polski compliance
ENISA pisze o ogólnoeuropejskim mechanizmie, nie o polskich strukturach kompetencyjnych. Pomost zbudują polscy prawnicy.
Pierwsza linia. Polski organ właściwy dla NIS2 i koordynator krajowy. Zgodnie z ustawą o krajowym systemie cyberbezpieczeństwa w nowelizacji NIS2 funkcję organu właściwego ds. cyberbezpieczeństwa pełni Minister Cyfryzacji, a operacyjnie współpracują CSIRT NASK (sektor cywilny), CSIRT GOV (sektor rządowy) i CSIRT MON (sektor wojskowy) wraz z sektorowymi CSIRT-ami dla wybranych branż (interpretacja MateMatic, nie stanowisko Ministerstwa Cyfryzacji ani CSIRT). Każdy podmiot essential lub important entity musi się zarejestrować i raportować incidenty zgodnie z polskimi terminami i polskim formularzem - których ENISA guidance nie zawiera.
Druga linia. Mechanizm baseline-eskalacja. W TOM 054 EDPB DPIA opisaliśmy wzorzec art. 32 RODO (baseline) do art. 35 RODO (DPIA, eskalacja) - mechanizm zarządzania ryzykiem z ISO/IEC TR 13335-3:1998 wpisany w tekst RODO bez przypisu. NIS2 art. 21 i Implementing Regulation 2024/2690 dodają trzeci poziom tej samej piramidy - i ENISA Technical Guidance jest jego operacyjną wykładnią. Dla polskiej kancelarii zarządzającej tajemnicą zawodową: art. 32 RODO i NIS2 art. 21 to jeden proces zarządzania ryzykiem w dwóch aktach prawnych - nie dwa oddzielne checkboxy.
Trzecia linia. Tajemnica zawodowa adwokacka i radcowska. Karta Etyki Adwokata (art. 19) i Kodeks Etyki Radcy Prawnego (art. 14-17) wymagają ochrony tajemnicy w sposób, który dla NIS2 art. 21 ust. 2 lit. e (encryption, where appropriate) oznacza mocniejszy standard niż dla podmiotu nie świadczącego usług prawnych. Stack zero-cloud i lokalna inferencja AI, które omawialiśmy wielokrotnie, są tutaj nie luksusem ale spełnieniem proportionality test (interpretacja MateMatic, nie stanowisko NRA ani KRRP). Cryptographic controls z rozdziału 9 ENISA guidance powinny być adaptowane do polskiej kancelarii z uwagą na ten dodatkowy wymiar.
Czwarta linia. Powiązanie z RODO art. 33-34 (notification). NIS2 art. 23 wymaga notification do organów cyberbezpieczeństwa, RODO art. 33-34 do PUODO i podmiotów danych. Te dwa reżimy notyfikacji incydentów mają różne terminy, różne formularze, różnych adresatów - i polska kancelaria musi mieć mechanizm który obsługuje oba w jednym przebiegu incident response. ENISA mówi o NIS2 notification, RODO mówi swoje, polska kancelaria łączy. Procedura post-incident review (rozdz. 3.6) jest naturalnym miejscem do udokumentowania faktu, że oba reżimy zostały obsłużone.
Cross-mapping w bibliotece MateMatic
Co z tego wynika
ENISA Technical Implementation Guidance nie jest dokumentem, który polska kancelaria czyta od deski do deski. To jest dokument referencyjny, do którego sięga w trzech sytuacjach. Pierwsza - audyt NIS2 albo audyt art. 32 RODO, gdzie potrzebujesz konkretnej listy evidence per obszar. Druga - implementacja policy lub procedury, gdzie chcesz mieć mapping na ISO 27005, ISO 27001 i równocześnie na regulację UE. Trzecia - klient pyta "co konkretnie mamy mieć udokumentowane" i potrzebujesz odpowiedzi opartej na autorytecie europejskim, nie na opinii doradczej.
Dla polskiej kancelarii reprezentującej klienta z sektorów essential/important entities pod NIS2 dokument jest twardym fundamentem do przygotowania compliance roadmap. Każdy z trzynastu obszarów to osobny workstream, każdy z evidence list to konkretny deliverable. Mapping na ISO 27005:2022 i ISO 27001 zmniejsza koszt - jeśli klient ma już wdrożone te standardy, większość evidence powinna już istnieć (potencjalnie tylko z innym etykietowaniem).
Dla samej kancelarii jako potencjalnego "important entity" pod NIS2 (jeśli powyżej progów) - dokument jest checklistą gap analysis. Trzynaście obszarów, evidence list per obszar, mapping na art. 32 RODO i NIS2 art. 21. Roczny review polityki, kwartalny review approved tools list, post-incident review po każdym incydencie. Dyscyplinę wdrażasz raz, przegląd jest cykliczny.
Dokument jest mostem między czterema warstwami: tekstem dyrektywy NIS2, regulacją wykonawczą 2024/2690, krajowymi standardami i operacyjną praktyką podmiotu. Bez tego mostu każda z czterech warstw stoi sama - z mostem stają się jednym procesem.
Pierwszy europejski dokument, który przekłada wymogi cybersec NIS2 na konkretną listę evidence dla każdego z trzynastu obszarów - od policy, przez risk management i incident handling, po asset management i environmental security. Licencja CC BY 4.0 pozwala na pełne cytowanie i adaptację z atrybucją do ENISA - możemy budować polskie szablony bez pytania o zgodę. Razem z TOM 054 EDPB DPIA i TOM 045 Kenney Runtime Enforcement to operacyjny baseline dla polskiej kancelarii zarządzającej klientami pod NIS2 albo dla samej kancelarii jako "important entity" powyżej progów.