Zgodność z NIS2 / KSC

Dyrektywa NIS2 (UE) 2022/2555  ·  Ustawa o KSC (Dz.U. 2018 poz. 1560 ze zm.)  ·  Ostatnia aktualizacja: 2026-10-22  ·  Wersja: 1.0

§1. Zakres i odbiorca

Platforma jest adresowana do JST, szkół publicznych i instytucji podległych, które mogą być zobowiązane do spełnienia wymogów NIS2/KSC jako operatorzy usług kluczowych lub — po nowelizacji KSC — jako podmioty ważne. Platforma obsługuje również organizacje stosujące NIS2 dobrowolnie jako ramy zarządzania cyberbezpieczeństwem.

Dokument opisuje funkcje platformy według dziesięciu obszarów art. 21 §2 NIS2 (lit. a–j) oraz dodatkowych wymogów proceduralnych KSC.

§2. Samoidentyfikacja (Kategoria podmiotu NIS2 / KSC)

Przed wdrożeniem kontroli niezbędne jest ustalenie, czy organizacja jest objęta zakresem NIS2 / KSC i w jakiej kategorii. Platforma udostępnia kreator samoidentyfikacji, który prowadzi administratora przez proces kwalifikacji.

Jak działa kreator

• Rozgałęziający kwestionariusz — pytania o rodzaj podmiotu (JST, szkoła, podmiot leczniczy, biblioteka i in.), szczebel samorządu, liczbę etatów i inne fakty, od których zależy kwalifikacja w ustawie o KSC.
• Propozycja, nie decyzja — metodyka ksc-2026.1 proponuje kategorię: podmiot kluczowy, podmiot ważny, podmiot ważny będący podmiotem publicznym, poza zakresem albo „wymaga konsultacji prawnej”, z uzasadnieniem i podstawą prawną. Wynik nie jest opinią prawną.
• Zatwierdzenie przez osobę uprawnioną — kwalifikację przyjmuje (albo zmienia z pisemnym uzasadnieniem) osoba z uprawnieniem do zatwierdzenia w zakresie danej oceny — administrator Dzierżawcy, dyrektor placówki lub kierownik JST — po ponownym potwierdzeniu tożsamości. Każda placówka ma osobną samoidentyfikację.
• Ślad audytowy — przebieg kreatora jest zapisywany w dzienniku audytu kodami nis2.self_identification.started, nis2.selfid.completed (propozycja), nis2.selfid.confirmed (zatwierdzenie), nis2.obligations.applied, nis2.selfid.reset i nis2.selfid.step_back, każdy z identyfikatorem aktora.
• Zadania — zatwierdzenie kwalifikacji tworzy zadania z katalogu obowiązków KSC właściwych dla tej kwalifikacji.

§3. Cykl raportowania incydentów NIS2

Art. 23 NIS2 i art. 11 KSC nakładają obowiązek raportowania incydentów w trzech etapach czasowych. Platforma obsługuje pełny cykl — od wykrycia do raportu finalnego — z wbudowanymi timerami terminów i stanem przepływu pracy.

Wszystkie trzy etapy są powiązane z jednym rekordem incydentu. Zmiana stanu (np. 24h_reported → 72h_reported) jest nieodwracalna i rejestrowana w dzienniku audytu z sumą kontrolną SHA-256.

§4. Biblioteka obowiązków KSC

Platforma dostarcza katalog obowiązków KSC (wersja 2026.1, 63 pozycje), z którego powstają zadania kontrolne (ControlTask). Po zatwierdzeniu kwalifikacji podmiotu platforma tworzy zadania dla obowiązków właściwych dla tej kwalifikacji. Każde zadanie ma:

• placówkę, której dotyczy, albo poziom całej organizacji,
• osobę odpowiedzialną (użytkownika platformy) i termin,
• status: do zrobienia / w trakcie / zrobione / zablokowane / nie dotyczy,
• notatki; utworzenie i każda zmiana zadania są zapisywane w dzienniku audytu.

Zadania nie mają własnych załączników. Pliki dowodowe dołącza się do stanów zgodności w module programów kontroli (wymagania przypisywane placówkom przez JST), a potwierdzenia szkoleń pochodzą z importu z platformy szkoleniowej Irenly, gdy Operator skonfigurował połączenie platformy z Irenly (jedno ustawienie całej platformy we wdrożeniu paraKSCol, a nie ustawienie Dzierżawcy).

Zakres katalogu (przykłady)

Samoidentyfikacja i wpis do wykazu; systematyczne szacowanie ryzyka i polityki bezpieczeństwa; środki z art. 8 ustawy (m.in. ciągłość działania, łańcuch dostaw, kryptografia, kontrola dostępu, zarządzanie aktywami, cyberhigiena); środki z załącznika nr 4 dla podmiotów publicznych (m.in. kopie zapasowe i testy ich odtworzenia, nadawanie i cofanie uprawnień, oprogramowanie antywirusowe, szkolenia pracowników); coroczny przegląd SZBI i coroczne szkolenie kierownika podmiotu; audyt bezpieczeństwa co 3 lata; obowiązki zdarzeniowe przy incydentach (24 h, 72 h, sprawozdanie końcowe). Częstotliwość wynika z obowiązku: jednorazowo, co roku, co 3 lata, w sposób ciągły albo przy zdarzeniu. Przypisanie części obowiązków i terminów to interpretacja przepisów czekająca na opinię eksperta.

§5. Paczka audytowa (eksport dowodów)

Na żądanie audytora lub organu nadzorczego platforma generuje paczkę audytową w formacie ZIP. Paczka zawiera:

nis2-audit-pack-{subdomena}-{RRRRMMDDTHHMMSSZ}.zip
├── manifest.json               # wersja 2: zakres, liczniki, kotwica łańcucha audytu oraz lista „files”
│                             #   ze skrótem SHA-256 i rozmiarem każdego pozostałego pliku
├── audit_chain_anchor.json     # wynik weryfikacji łańcucha audytu w chwili eksportu, skrót ostatniego wiersza
├── audit_chain_rows.json       # wiersze łańcucha audytu od początku (do 50 000) do niezależnego przeliczenia
├── obligations.json            # katalog obowiązków
├── control_tasks.json          # zadania kontrolne
├── incidents.json              # incydenty
├── incident_reports.json       # zgłoszenia/raporty incydentów
└── self_identification.json    # historia samoidentyfikacji

Wszystkie pliki są w katalogu głównym archiwum i mają format JSON (UTF-8). Jeżeli podmiot ma włączone dodatkowe moduły, paczka zawiera też ich pliki (control_programs_*.json, vendors_*.json, assets_*.json) — każdy z nich również jest wymieniony w manifest.json. Paczka nie zawiera załączników (plików PDF, zrzutów ekranu), plików CSV ani haseł i sekretów uwierzytelniających.

Weryfikacja niezależna od platformy. Po rozpakowaniu (unzip nis2-audit-pack-….zip -d paczka && cd paczka) poniższe polecenie (Python 3, wyłącznie biblioteka standardowa; flaga -I sprawia, że Python nie wczyta żadnego modułu z rozpakowanej paczki i pominie zmienne środowiskowe PYTHON* — bez niej plik json.py podrzucony do paczki mógłby wypisać fałszywe OK) przelicza SHA-256 każdego pliku i porównuje z manifest.json; wypisuje OK albo listę plików zmienionych, brakujących lub dodanych i kończy się kodem 1:

python3 -I -c 'import hashlib,json,os,sys; m=json.load(open("manifest.json")); L={f["path"]: f for f in m["files"]}; bad=[p for p, f in L.items() if not os.path.isfile(p) or hashlib.sha256(open(p, "rb").read()).hexdigest() != f["sha256"]]; bad += sorted(set(os.listdir(".")) - set(L) - {"manifest.json"}); print("FAIL:", bad) if bad else print("OK:", len(L), "file(s) match manifest.json"); sys.exit(1 if bad else 0)'

Skróty w manifest.json wykrywają zmianę, obcięcie, usunięcie lub dodanie pliku po eksporcie. Nie są podpisem: kto może podmienić plik, może też podmienić manifest. Dlatego treść dziennika audytu weryfikuje się osobno — przeliczając łańcuch z audit_chain_rows.json według instrukcji w polu note pliku audit_chain_anchor.json i sprawdzając, że latest_row_hash występuje w kolumnie row_hash_hex eksportu dziennika audytu pobranego z platformy (/api/audit/export.csv).

§6. Wyznaczenie IBTI / ITSO i izolacja jednostek

Platforma obsługuje wielopoziomową strukturę organizacyjną (JST → jednostki podległe → szkoły / instytucje). Każdej placówce można wskazać imiennego ITSO (zob. niżej).

Mechanizm izolacji danych

Każda tabela danych Dzierżawcy chroniona RLS nosi kolumnę tenant_id, a PostgreSQL wymusza izolację Dzierżawców na poziomie silnika — kod aplikacji nie może jej ominąć. Każda placówka ma własną jednostkę organizacyjną (org_unit_id), nadawaną przez bazę danych i niezmienną. Politykę per jednostka (org_unit_scope) ma sześć tabel: placówki, wyjątki, przypisania zadań kontrolnych, Zadania Kontrolne NIS2, samoidentyfikacja i incydenty; jednostkę wiersza ustawia wyzwalacz bazy danych na podstawie placówki wiersza. Aplikacja ustawia app.current_tenant_id przy każdym żądaniu, a app.current_org_unit_id — listę jednostek — dla użytkownika, którego wszystkie role są ograniczone do placówek.

Efekt: koordynator cyberbezpieczeństwa JST z rolą dla całego Dzierżawcy widzi dane wszystkich podległych placówek. Dyrektor lub ITSO szkoły w Dzierżawcy JST — role nadawane tam wyłącznie per placówka — widzi zadania, samoidentyfikację, incydenty, wyjątki i przypisania swojej placówki i pracuje na nich w granicach swojej roli; widzi też rekordy dotyczące całej organizacji (bez placówki), z wyjątkiem wyjątków od polityk i przypisań wymagań skierowanych do wszystkich placówek. Najpierw ogranicza to kod aplikacji, a baza danych jest zabezpieczeniem pod nim. Ryzyka, aktywa i stany zgodności kontroli są ograniczane per placówka wyłącznie w kodzie aplikacji. Placówka założona jako osobny Dzierżawca jest odizolowana od pozostałych przez RLS. Szczegóły: Biała Księga Bezpieczeństwa, §2.3.

Rejestr desygnacji

Rekord wyznaczenia — nie jest zbudowany. Platforma nie prowadzi rejestru wyznaczeń z polami takimi jak rodzaj wyznaczenia, odwołanie do podstawy prawnej (np. art. 14 ust. 1 KSC) czy okres ważności. Wcześniejsza wersja tej strony publikowała taką tabelę pól; została wycofana 2026-10-12, bo żadne z tych pól nie istnieje w kodzie. Istnieje natomiast:

• wbudowana rola itso — jej nadanie lub odebranie jest zapisywane w dzienniku audytu kodem iam.user.role_change (role przed i po zmianie, aktor, czas);
• wskazanie imiennego ITSO dla placówki w rekordzie placówki — zmiana jest zapisywana jako tenant.site.update z identyfikatorami użytkownika poprzedniego i nowego ITSO, także przy wskazaniu przez zaproszenie (wiersze zapisane przed tą zmianą, w październiku 2026, nie zawierają informacji, kogo wskazano); placówka może wskazać tylko członka Dzierżawcy, a zawieszenie lub usunięcie członkostwa ITSO czyści wskazanie i jest zapisywane w ten sam sposób;
• uprawnienia nadawane per placówka — itso nadany w placówce pracuje na zadaniach kontrolnych, przypisaniach i incydentach tej placówki; w Dzierżawcy JST role itso i school_director nadaje się wyłącznie per placówka, a samo wskazanie kogoś jako ITSO placówki niczego mu nie nadaje; ITSO wskazany w placówce otrzymuje powiadomienie e-mail o nowym przypisaniu; przypomnienia o terminach zadań kontrolnych trafiają wyłącznie do ITSO będącego aktywnym członkiem.

Dokument wyznaczenia IBTI/ITSO pozostaje dokumentem organizacji, prowadzonym poza platformą.

§7. Mapowanie NIS2 Art. 21 §2 (lit. a–j)

Poniższa tabela pokazuje, jak konkretne funkcje platformy wspierają każdy z dziesięciu obszarów wymaganych przez NIS2 art. 21 §2.

§8. Interfejs RODO

NIS2 i RODO nakładają częściowo pokrywające się obowiązki. Platforma obsługuje oba jednocześnie:

• Incydent NIS2 a naruszenie RODO — jeśli incydent dotyczy danych osobowych, platforma umożliwia jednoczesne zgłoszenie do CSIRT (NIS2) i wygenerowanie raportu naruszenia dla UODO (RODO art. 33). Obydwa raporty są powiązane tym samym identyfikatorem incydentu.
• DPIA a ocena ryzyka NIS2 — zadania kontrolne mogą odwoływać się do istniejącej DPIA jako dowodu. Rejestr czynności przetwarzania (RCP) jest dostępny w ramach tego samego narzędzia.
• Prawa podmiotów danych — wnioski o dostęp / usunięcie / pseudonimizację są rejestrowane w dzienniku audytu; usunięcie danych osobowych z dziennika audytu wymaga procesu pseudonimizacji opisanego w Polityce Prywatności §11.

§9. Czego platforma nie robi (zakres negatywny)

§10. Kontakt i zgłoszenia