Metodologia narzędzi NIS2 — silnik, źródła, IP firewall

Cztery narzędzia w pigułce

Serwis utrzymuje cztery główne narzędzia — wszystkie z deterministyczną logiką, pełną ścieżką cytatów, działaniem wyłącznie w przeglądarce (bez transmisji danych) i stanem zakodowanym w hash URL (link udostępnienia nie wysyła danych na serwer).

Klasyfikator NIS2 — wieloetapowy kreator audytora (43 reguł w 5-krokowym drzewie decyzyjnym). Ocena czy konkretny podmiot jest Kluczowy, Ważny czy wyłączony.
Klasyfikator dostawców NIS2 — scorecard ryzyka dostawcy ICT (6 wymiarów, 4 pasma ryzyka). Strukturalna ocena formalnej analizy z Art. 21 ust. 2 lit. d NIS2 + Art. 66a KSC.
Mapowanie NIS2 × KSC × ISO 27001:2022 — tabela referencyjna 10 środków z Art. 21 odwzorowanych na obowiązki KSC i 56 kontroli ISO 27001:2022 Annex A, z analizą luk rezydualnych i 4 polskimi dodatkami.
Profil eksperta — dane autora odpowiadającego za merytorykę serwisu, ze strukturalną listą 3 certyfikatów, 3 ról kariery, 9 specjalizacjami i 2 państwowymi zatwierdzeniami.

Architektura silników

Klasyfikator NIS2 i klasyfikator dostawców są zaimplementowane jako funkcje czyste w TypeScript (SupplierInput → SupplierScore, QualificationInput → QualificationResult) — bez I/O, bez DOM, bez fetch. Te same funkcje działają identycznie w przeglądarce, w testach Vitest i w czasie build. Każda zmiana silnika musi przejść przez 222+ test jednostkowych zanim trafi na produkcję.

Reguły scoringowe są zapisane w deklaratywnych plikach danych (rules-as-data), nie w kodzie warunkowym. Dzięki temu:

Każda reguła ma stabilny identyfikator (np. R36-sectoral-overrides), własną narrację w języku polskim i odnośnik do EUR-Lex / ISAP / ISO.
Dodanie reguły wymaga jednej zmiany w pliku danych, nie refaktoru silnika.
Audytor czytający wynik widzi pełną ścieżkę reguł — każda z cytatem, każda z opisem dlaczego zadziałała.

Stan każdego narzędzia jest kodowany w hash URL (po znaku #). Hash nie jest wysyłany na serwer — to standardowy mechanizm przeglądarki. Dzięki temu link udostępnienia (np. /klasyfikator#eyJ2...) niesie pełen kontekst wyniku do odbiorcy, ale przez całą drogę między nadawcą a odbiorcą dane pozostają w przeglądarkach — Cloudflare, Google Analytics i nasz serwer nigdy ich nie widzą.

Klasyfikator NIS2 — pełna logika

43 reguł podzielonych na 5 kroków odpowiadających mentalnemu modelowi audytora KSC:

Krok 1: Profil usługowy — zbiera reguły z tego etapu (przykłady reguł i pełna ścieżka uzasadnienia w wyniku każdego klasyfikatora).
Krok 2: Struktura kapitałowa — zbiera reguły z tego etapu (przykłady reguł i pełna ścieżka uzasadnienia w wyniku każdego klasyfikatora).
Krok 3: Pułapy MŚP — zbiera reguły z tego etapu (przykłady reguł i pełna ścieżka uzasadnienia w wyniku każdego klasyfikatora).
Krok 4: Nadpisania — zbiera reguły z tego etapu (przykłady reguł i pełna ścieżka uzasadnienia w wyniku każdego klasyfikatora).
Krok 5: Klasyfikacja i konsekwencje — zbiera reguły z tego etapu (przykłady reguł i pełna ścieżka uzasadnienia w wyniku każdego klasyfikatora).

Kluczowe wzorce scoringowe:

R6 — klif kapitału publicznego ≥25% (rygor bezwzględny — spółka nie może być MŚP niezależnie od liczby pracowników).
R7/R8 — konsolidacja grup (przedsiębiorstwa powiązane: 100% danych matki sumuje się; partnerskie: proporcjonalnie).
R16-R18 — klauzula niezależności MC Q&A pkt 1.6 (ucieczka od konsolidacji), z dwoma pułapkami: PKD-trap (wspólny makro-sektor) i Shared Services trap (wspólne IT).
R24 — spadochron 2-letni z Art. 4 ust. 2 rozporządzenia 651/2014.
R36 — NIS2 Art. 2 ust. 2 — 7 enumerowanych klauzul rozmiaru-niezależnych (telekomunikacja, kwalifikowani dostawcy usług zaufania, TLD/DNS, administracja centralna, wyłączni dostawcy krajowi, znaczące ryzyko systemowe, krytyczne dla sektorów współzależnych).
R14 — wyznaczenie z urzędu (decyzja administracyjna organu jest nadrzędna nad macierzą wielkość × załącznik).

Pasmo pewności klasyfikacji (wysokie / średnie / niskie) jest pochodną tego, czy wynik opiera się na samodeklaracji użytkownika. Np. wskazanie nadpisania z urzędu lub klauzuli Art. 2(2) automatycznie obniża pasmo z wysokiego na średnie — bo silnik nie weryfikuje, czy podmiot rzeczywiście podlega wskazanej klauzuli.

Klasyfikator dostawców — rubryka punktacji

Scorecard używa 6 ważonych wymiarów (sumujących się do 100%) z 31 regułami scoringowymi:

Certyfikacja — waga 20%
Jurysdykcja — waga 15%
Dojrzałość BCP — waga 15%
Transparentność podwykonawców — waga 10%
Vendor lock-in — waga 5%
Integracja operacyjna — waga 35%

Wymiar integracji operacyjnej ma najwyższą wagę (35%) ponieważ uprzywilejowany dostęp dostawcy do produkcji ma największy blast radius w razie kompromitacji.

Conservative defaults — gdy użytkownik nie zna odpowiedzi (np. RTO/RPO nieznane), silnik podnosi ryzyko, zamiast je pomijać. Zapobiega oszukiwaniu narzędzia poprzez pozostawianie pól pustych.

Krytyczne ostrzeżenia (sygnalizowane jako Krytyczne w wyniku):

OPS_NO_MFA — dostawca ma zdalny dostęp administracyjny do produkcji bez wymogu MFA.
OPS_REPEATED_BREACHES — 2 lub więcej incydentów u dostawcy w ostatnich 24 miesiącach (sygnał systemowej słabości — kandydat do wymiany).

Najwyższe pasmo ryzyka (Krytyczne, 86+) automatycznie generuje rekomendację oceny pod kątem Art. 67b/67c KSC (procedura uznania dostawcy za wysokiego ryzyka) — to mechanizm administracyjny bez odpowiednika w ISO 27001.

Klasyfikator grupowy — apparatus holdingów

Holdingi i grupy kapitałowe potrzebują klasyfikacji per-entity dla każdej spółki zależnej oraz grupowego memo audytowego, które audytor zweryfikuje jednym plikiem zamiast N. Klasyfikator grupowy (/klasyfikator-grupa) implementuje trzywarstwowy apparatus obrony audytowej:

Silnik qualifyGroup — pure-function orkiestracja per-entity qualify() z agregowanym podsumowaniem grupy (suma kar Art. 34 NIS2, suma kontaktów Art. 9 ust. 2 KSC, rozkład K/V/W). Defensywne odrzucenie duplikatów entityId — silnik wymaga unikalności, by per-entity werdykty pozostały jednoznaczne. 50× iteracji × 3 fixture w teście determinizmu gwarantuje byte-identical output (audytor z tym samym wejściem zawsze dostanie ten sam memo).
Memo grupowe — schema.org JSON-LD Report ze zewnętrzną warstwą integralności (groupHash, FNV-1a nad kanoniczną treścią całego pliku) oraz zagnieżdżonymi per-entity memo, każde z własnym memoHash. Naiwna edycja jakiegokolwiek pola w pliku psuje groupHash w mikrosekundach.
Niezależny weryfikator grupowy — /audyt-pack rozpoznaje memo grupowe po obecności tablicy entities i uruchamia: kontrolę groupHash, dla każdego zagnieżdżonego memo pełny re-run silnika (warstwa SS-2 z weryfikatora pojedynczego), oraz krzyżową weryfikację agregatu podsumowania względem zsumowania per-entity wyników.

Werdykt grupowy zawiera tabelę per-entity. Jeśli holding ma 50 spółek i jedna trzyma niezgodne dane wejściowe, audytor od razu widzi którą — zamiast szukać niespójności w 50-stronicowym pliku.

Pinning wersji ma trzy poziomy: groupMemoSchemaVersion (1.0.0 dla obecnego kształtu memo grupowego), memoSchemaVersion (2.0.0 dla zagnieżdżonych memo per-entity), ruleRegistryVersion (v1.5.0 dla silnika klasyfikującego). Bump jakiegokolwiek z trzech wymaga zgodnego aktualizowania zewnętrznych integracji GRC audytora.

Format wejściowy: CSV z wymaganymi kolumnami groupId, groupName, entityId, legalName, employees, revenueMlnEur, balanceSheetMlnEur, publicCapital25OrMore, twoYearContinuity, sector, annex. Wartości logiczne akceptują true/false, tak/nie lub 1/0. Liczby akceptują separator dziesiętny „.” albo „,” (konwencja polska). Parser zbiera wszystkie błędy w jednym przebiegu, by operator poprawił arkusz raz, a nie iteracyjnie.

Konsolidacja grup kapitałowych (R7/R8), klauzule rozmiaru-niezależne z Art. 2(2) NIS2, urząd gminy (R41), z urzędu (R14) i sektory dodatkowe — wszystkie zaawansowane pola są edytowalne per-entity w podglądzie po wczytaniu CSV. CSV v1 zakłada wszystkie podmioty autonomous; reszta to operator-side polish w UI.

Mapowanie NIS2 × KSC × ISO 27001:2022 — źródła

Cross-walk 10 środków Art. 21 ust. 2 NIS2 na kontrole ISO 27001:2022 Annex A oraz polskie obowiązki KSC. Trzy wartości pokrycia:

Pełne (4 wierszy) — wszystkie wymagania litery NIS2 wynikają wprost z wymienionych kontroli ISO.
Częściowe (6 wierszy) — pozostaje udokumentowana luka rezydualna (każdy taki wiersz ma opis konkretnej luki).
Luka (0 wierszy) — żadna kontrola ISO nie pokrywa wymogu; pełna implementacja ISO 27001 nie zwalnia z obowiązku.

Oprócz 10 wierszy NIS2, surfacujemy 4 polskie dodatki bez odpowiednika w NIS2 (S46, 2 osoby kontaktowe, kanał obywatelski, Art. 12a) — obowiązki polskiego KSC, których pełna implementacja ISO 27001 nie obejmuje.

Źródła użyte do budowy mapowania (wyłącznie publiczne):

EUR-Lex CELEX 32022L2555 — pełen tekst dyrektywy NIS2.
ISAP D20240001717 — skonsolidowany tekst ustawy o KSC.
ISO/IEC 27001:2022 — publiczny spis treści Annex A.
Komisja Europejska — NIS2

Profil eksperta — architektura E-E-A-T

Każdy artykuł serwisu odwołuje się do tego samego, kanonicznego identyfikatora Person w schema.org (https://dyrektywanis2.com/ekspert#dariusz). Dzięki temu Google traktuje wszystkie artykuły jako autorstwa jednej, weryfikowalnej osoby — nie 43 osobnych autorów anonimowych.

Strona profilu eksperta zawiera:

3 certyfikatów z linkami do organów wystawiających (możliwa zewnętrzna weryfikacja).
3 ról kariery z anonimizacją tam, gdzie wymaga tego NDA.
9 specjalizacji z linkami do pillarów/blogów dokumentujących każdą.
2 państwowych zatwierdzeń (NASK-PIB, ULC) — dokumentacje SZBI / lotnicze przeszły państwową weryfikację, a nie tylko wewnętrzną opinię firmy doradczej.

Wygasłe certyfikaty są automatycznie wykluczane z JSON-LD hasCredential[] — nigdy nie deklarujemy crawlerom nieaktywnego certyfikatu.

Polityka cytowań

Każda reguła silnika, każdy wiersz mapowania, każda rekomendacja klasyfikatora dostawców musi mieć cytat do publicznego źródła. Dozwolone źródła:

EUR-Lex — głęboki link do artykułu/ustępu/litery (np. ...#art_21.tit_1.pnt_2.lit_b).
ISAP — link do skonsolidowanego tekstu ustawy o KSC.
iso.org — strona normy ISO (sam tekst normy jest licencjonowany, używamy tylko publicznych identyfikatorów kontroli z Annex A).
etsi.org — opublikowane normy ETSI (np. EN 303 645).
enisa.europa.eu — wytyczne i raporty ENISA.
gov.pl — oficjalne komunikaty polskich organów.

Format URL jest weryfikowany w testach jednostkowych (matches(/^https:\/\//)). Nieprawidłowy format cytatu = failujący test = nie jest deployowany.

Polityka prywatności narzędzi

Wszystkie 4 narzędzia działają wyłącznie w przeglądarce. Wymierne konsekwencje:

Dane wejściowe (np. nazwa dostawcy, liczba pracowników, kapitał publiczny) nigdy nie opuszczają urządzenia użytkownika.
Stan udostępnienia kodowany w hash URL — fragment po # nie jest wysyłany do serwera, Cloudflare Analytics ani w nagłówku Referer.
Brak persystencji dostawców między sesjami — nie utrzymujemy bazy ocenionych dostawców. Każda ocena należy do osoby ją tworzącej.
Brak kont użytkowników, brak logowania, brak zewnętrznych integracji GRC (eksport do Markdown / CSV jest warstwą interop).
Cloudflare Web Analytics ogranicza się do liczników odsłon stron — żadnych zdarzeń od interakcji z narzędziem (klik checkboxa, wpisanie nazwy) nie przesyłamy do analityki.

Pełne wyjaśnienie postawy prywatności w Polityce prywatności.

IP firewall — czego nie używamy

Choć autorem treści serwisu jest Dariusz Zając (Lead vCISO Cyber Alterity), narzędzia merytoryczne tego serwisu są budowane niezależnie od komercyjnych produktów Cyber Alterity. Nie używamy:

93-punktowego Audytu Zerowego Cyber Alterity — to komercyjny produkt płatnej oceny dojrzałości; nie powielamy jego struktury w klasyfikatorze podmiotów ani w scorecard dostawców.
CSA STAR / SIG / SIG Lite — licencjonowane kwestionariusze oceny dostawców chmurowych. Możemy REFERENCJONOWAĆ je w cytatach, ale pytania w naszym scorecard są autorskie.
Polityk, procedur, klauzul kontraktowych Cyber Alterity — żadne materiały robocze klientów nie są publikowane jako przykłady.
Tekstu normy ISO 27001:2022 — tekst normy jest licencjonowany, używamy tylko publicznych identyfikatorów kontroli z opublikowanego spisu treści Annex A (kody A.5.1 itd. nie podlegają ochronie copyright).

Polityka jest egzekwowana w testach jednostkowych (src/data/__tests__/crosswalk.test.ts, src/data/__tests__/expert-credentials.test.ts) — skanują wszystkie ciągi tekstowe pod kątem zakazanych wzorców i odrzucają wpisy zawierające „audyt zerowy” lub markery NDA.

Walidacja zmian — cykl utrzymania

KSC nowelizacja jest w fazie aktywnych zmian; NIS2 ma corocznie wprowadzane errata; ISO 27001:2022 publikuje minor updates. Reguły utrzymania:

Monthly — przegląd EUR-Lex (NIS2 errata + nowe acts implementing) i ISAP (KSC nowelizacja). Pole updatedAt per wiersz w mapowaniu, per pillar w sitemap, sumarycznie per route w src/data/routes.ts.
Per release — wszystkie nowe wartości updatedAt muszą być datami dzisiejszymi lub wcześniejszymi (test sanity check w build pipeline).
Schema versioning share-link — narzędzia mają STATE_VERSION. Stare linki z innej wersji schematu dekodują się do null i narzędzie wraca do domyślnego stanu (nie crashuje).
Test sanity — każda zmiana w pliku reguł musi przejść 253+ testów jednostkowych zanim trafi na produkcję (deployment workflow blokuje merge przy failing teście).

Limity narzędzi — wsparcie decyzyjne, nie audyt

Każdy wynik z narzędzi serwisu kończy się jasno zaznaczonym disclaimerem:

Wsparcie decyzyjne, nie porada prawna. Wynik klasyfikatora to ramowa struktura oceny — formalny audyt wymaga indywidualnej weryfikacji.

Konkretne ograniczenia:

Klasyfikator NIS2 nie weryfikuje sektorowych nadpisań progów (Prawo Bankowe, PKE, ustawa o świadczeniu opieki zdrowotnej mogą zaostrzyć wynik) ani jurysdykcji DSP transgranicznej (NIS2 Art. 26).
Klasyfikator dostawców nie zastępuje pełnego audytu dostawcy na próbie dowodowej (logi, polityki, kontrakty, SOC 2 reports). Historia incydentów jest samodeklaracją użytkownika — nie pobieramy threat intel.
Mapowanie ISO wymienia kontrole Annex A relewantne dla każdej litery Art. 21 — to nie jest pełna ocena luk; rzeczywista ocena luk wymaga porównania konkretnej implementacji SZBI w organizacji z każdą kontrolą indywidualnie.

W razie wątpliwości — bezpłatna 20-minutowa rozmowa konsultacyjna z autorem treści jest dostępna z każdej strony narzędzia.

Słownik metodologii

Definicje pojęć inżynierskich stojących za narzędziami. Każda pozycja ma własną kotwicę URL (np. #rules-as-data) — te same identyfikatory pojawiają się w schema.org DefinedTermSet, więc Google może je surfaceować jako odpowiedzi „people also ask”.

Rules-as-data: Architektura w której każda reguła silnika klasyfikującego jest osobnym wpisem w pliku danych (z cytatem, narracją i metadanymi), nie kodem warunkowym. Pozwala na audytowalność, niezależne testowanie i bezpieczne edytowanie reguł bez modyfikacji silnika.
Conservative defaults: Wzorzec scoringowy w którym niepewność wejścia (brak danych, „nieznane”) podnosi ryzyko, zamiast obniżać je. Zapobiega oszukiwaniu narzędzia poprzez pozostawianie pól pustych.
Confidence band — pasmo pewności: Pasmo pewności (wysokie / średnie / niskie) towarzyszące każdej klasyfikacji. Średnie/niskie pasmo sygnalizuje, że wynik opiera się na samodeklaracji użytkownika (np. nadpisanie z urzędu, Art. 2(2)) i wymaga weryfikacji ludzkiej.
Share-link hash: Sposób udostępniania stanu narzędzia przez fragment URL (po #). Hash nie jest przesyłany na serwer ani do Cloudflare Analytics ani w nagłówku Referer — dane wejściowe pozostają wyłącznie po stronie klienta.
Spadochron 2-letni: Zasada ciągłości z Art. 4 ust. 2 Załącznika I rozporządzenia 651/2014: jednoroczne przekroczenie pułapu wielkości nie zmienia statusu MŚP — wymagane są dwa kolejne lata przekroczenia.
Art. 2 ust. 2 NIS2 — wyłączenia rozmiarowe: Klauzule rozmiaru-niezależne dyrektywy NIS2 obejmujące m.in. operatorów telekomunikacyjnych (Art. 2(2)(a)(i)), kwalifikowanych dostawców usług zaufania (a)(ii), rejestrów TLD i operatorów DNS (a)(iii), administracji centralnej (f)(i).
5-etapowe drzewo decyzyjne audytora: Mentalny model audytora KSC dzielący klasyfikację podmiotu na pięć kroków: profil usługowy → struktura kapitałowa → pułapy MŚP → nadpisania → klasyfikacja i konsekwencje.
IP firewall: Polityka korzystania wyłącznie z publicznych źródeł (EUR-Lex, ISAP, ISO opublikowane spisy treści, ETSI, ENISA) przy budowie narzędzi merytorycznych. Wyklucza korzystanie z komercyjnych zasobów własnościowych Cyber Alterity (w tym 93-punktowego Audytu Zerowego) ani z licencjonowanych kwestionariuszy CSA STAR / SIG.

Rejestr reguł — historia wersji

Każdy wynik klasyfikacji zawiera numer wersji rejestru reguł. Pozwala to odtworzyć klasyfikację memorandum Zarządu sprzed miesięcy — wystarczy porównać użyty numer wersji z historią poniżej. Każda nowelizacja EUR-Lex / ISAP / KSC, która zmienia logikę reguł silnika, podnosi wersję i pojawia się jako nowy wpis.

Aktualna wersja: v1.5.0 (ostatnia zmiana: 2026-06-01).

v1.5.0 — 2026-06-01
Reguła R42 — K-wins tiebreaker jako jawna etykieta śladu audytowego (NIS2 Art. 3). Bez zmiany zachowania względem v1.4.0: silnik już wcześniej rozstrzygał spór między Załącznikiem I a Załącznikiem II w sektorach dodatkowych na korzyść Załącznika I (najbardziej restrykcyjny załącznik — R39). Od v1.5.0 ślad uzasadnienia jawnie wymienia regułę R42 zawsze, gdy tiebreaker faktycznie przesądził wynik — tj. gdy sektor podstawowy sam nie dałby Kluczowego, ale sektor dodatkowy z Załącznika I doprowadził do K. W pozostałych przypadkach (np. sektor podstawowy z Załącznika I) R42 nie wystąpi — żeby ślad nie szumiał. Etykieta dla obrony audytowej, nie nowa logika. Bump MINOR.
v1.4.0 — 2026-05-31
Reguła R41 — urząd gminy oraz próg 50 FTE na 1 stycznia (Min. Cyfr. pkt 1.8). Nowe opcjonalne pola urzadGminy + employeesOn1January: urząd gminy działający jako samorządowa jednostka budżetowa zawsze podlega pod KSC, ale jest Podmiotem Kluczowym wyłącznie gdy na dzień 1 stycznia danego roku zatrudnia co najmniej 50 osób w przeliczeniu na pełny etat na umowie o pracę. W przeciwnym razie jest Podmiotem Ważnym. Nowe ostrzeżenie GMINA_THRESHOLD_APPLIED z severity critical, gdy operator nie poda snapshotu z 1 stycznia (audyt-blokujące — wynik kierunkowy, confidence spada do medium). Bez zmiany istniejących reguł R1–R40 — bump MINOR.
v1.3.0 — 2026-05-30
Reguła R40 — telekomunikacja, mapowanie wielkości na K/V (Min. Cyfr. pkt 1.9). Doprecyzowanie istniejącego włączenia NIS2 Art. 2(2)(a)(i): wszyscy przedsiębiorcy telekomunikacyjni podlegają pod KSC niezależnie od wielkości, ale status zależy od rozmiaru — Duży i Średni telekom → Podmiot Kluczowy; Mały i Mikroprzedsiębiorca → Podmiot Ważny. Naprawa: 5-osobowy dostawca ISP lokalnego nie jest już błędnie klasyfikowany jako Kluczowy. Nowe ostrzeżenie TELECOM_SIZE_DOWNRANK. Bez zmiany istniejących reguł R1–R39 — bump MINOR.
v1.2.0 — 2026-05-28
Obsługa wielu sektorów. Nowe pole additionalSectors: podmiot może wskazać sektory dodatkowe poza podstawowym. Nowa reguła R39 (NIS2 Art. 3) — o klasyfikacji rozstrzyga najbardziej restrykcyjny załącznik (Załącznik I > Załącznik II), więc Duży operator usługi z Załącznika II prowadzący również usługę z Załącznika I jest Podmiotem Kluczowym, a nie Ważnym. Nowe ostrzeżenie MULTI_SECTOR_ESCALATION wskazuje, gdy to sektor dodatkowy — a nie podstawowy — podnosi klasyfikację. Bez zmiany istniejących reguł R1–R38; wyniki jednosektorowe pozostają identyczne — bump MINOR.
v1.1.0 — 2026-05-28
Wprowadzenie pola mainEstablishment (NIS2 Art. 26 — główne miejsce prowadzenia działalności). Nowe ostrzeżenie JURISDICTION_NOT_PL: gdy główne miejsce prowadzenia działalności jest poza Polską, klasyfikacja pozostaje kierunkowa, a wiążące ustalenia obowiązków pochodzą od organu państwa głównego miejsca prowadzenia działalności. Klauzule rygoru bezwzględnego (Art. 26 ust. 3 — przedstawiciel w UE dla podmiotów spoza EOG) oznaczone jako krytyczne. Bez zmiany istniejących reguł R1–R38 — bump MINOR.
v1.0.0 — 2026-05-28
Pierwsza wersja publiczna. 38 reguł obejmujących pułapy MŚP (EU 651/2014), konsolidację grup kapitałowych (Rules 7–8, 16–18), klauzule rozmiaru-niezależne NIS2 Art. 2(2) (Rule 36 z 7 wariantami), spadochron 2-letni (Rule 24), test niezależności MC Q&A pkt 1.6 oraz pełen zakres operacyjnych konsekwencji (Art. 9, Art. 12a, Art. 21, Art. 23, Art. 66a). Zgodność z Test Case 1 (Mały Gigant) i Test Case 2 (Grupa Kapitałowa, scenariusze A/B/C/D) zweryfikowana 269 testami jednostkowymi.

Mechanika: stała RULE_REGISTRY_VERSION w pliku src/lib/qualifier/version.ts jest podbijana semver: PATCH = wyjaśnienie cytatu, MINOR = nowa reguła dodatkowa, MAJOR = zmiana semantyki istniejącej reguły lub usunięcie. Każdy bump wymaga wpisu w tej liście — wymuszone testem jednostkowym.

Rejestr reguł dostawcy — historia wersji

Każda ocena dostawcy zawiera numer wersji rejestru reguł scorera. Mechanika identyczna jak w klasyfikatorze podmiotów: bump wymagany przy każdej zmianie wag wymiarów (DIMENSION_WEIGHTS), progów pasm ryzyka lub semantyki dowolnej reguły fire().

Aktualna wersja: v2.0.0 (ostatnia zmiana: 2026-05-28).

v2.0.0 — 2026-05-28
Wagi wymiarów zależne od kategorii dostawcy (zmiana semantyki wyniku → bump MAJOR). Ten sam sygnał ryzyka waży inaczej zależnie od typu dostawcy: dla OT/ICS/SCADA dominuje operationalIntegration (waga 0,45); dla SaaS rosną jurisdictional i vendorLockIn; dla MSSP rosną certPosture i operationalIntegration. 9 profili (8 strojonych + domyślny), każdy sumuje się do 1,0. Reguły fire() bez zmian — zmieniają się tylko wagi agregacji. Ocena dostawcy zawiera teraz etykietę użytego profilu wagowego.
v1.0.0 — 2026-05-28
Pierwsza wersja publiczna. 31 reguł fire() w 6 wymiarach: certPosture (waga 0.20), jurisdictional (0.15), bcpMaturity (0.15), subSupplierTransparency (0.10), vendorLockIn (0.05), operationalIntegration (0.35). Pasmo ryzyka low/medium/high/critical pochodzi z ważonej sumy 0-100. Defaults konserwatywne — brak danych podnosi ryzyko, nie obniża. Cytaty: NIS2 Art. 21 ust. 2 lit. d, KSC Art. 66a, ISO 22301, ISO/IEC 27001, ENISA Cloud Guidelines.

Zakres narzędzia. 31 reguł silnika to brama kierunkowa, nie pełna ocena dostawcy. Dla porównania: licencjonowane kwestionariusze CSA STAR mają ~290 kontroli, SIG ~800+ pytań. Polityka IP firewall wyklucza ich wykorzystanie. Gdy klasyfikacja podnosi się do High lub Critical, rekomendujemy eskalację do indywidualnej oceny technicznej (np. Audyt Zerowy Cyber Alterity).

Stack technologiczny + zgłaszanie problemów

Serwis zbudowany w Next.js 14 (App Router, static export), TypeScript, Tailwind CSS, Vitest. Hostowany na Cloudflare Pages. Logika silników klasyfikujących nie jest open-source, ale wszystkie reguły są jawne w wyniku każdego narzędzia z pełną ścieżką cytatów do publicznych źródeł.

Zgłoszenia podatności i błędów merytorycznych: security.txt lub bezpośrednio przez stronę profilu eksperta.