Nota zgodności 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. Dla kogo jest ta platforma

Platforma jest zaprojektowana z myślą o:

• Dyrektorach szkół publicznych — zobowiązanych do wyznaczenia osoby odpowiedzialnej za bezpieczeństwo informacji (ITSO) i spełnienia wymogów KSC jeśli szkoła wchodzi w zakres ustawy.
• Koordynatorach ds. cyberbezpieczeństwa JST — zarządzających compliance dla wielu podległych placówek.
• Pracownikach IT szkół i JST — realizujących zadania kontrolne i dokumentujących incydenty.

Platforma obsługuje również organizacje stosujące NIS2/KSC dobrowolnie (sposób dobrej praktyki) bez formalnego objęcia zakresem ustawy.

§2. Samoidentyfikacja (Kategoria podmiotu NIS2 / KSC)

Platforma udostępnia kreator samoidentyfikacji, który prowadzi użytkownika przez proces kwalifikacji. Jest to szczególnie ważne w sektorze edukacji, gdzie nowelizacja KSC może objąć szkoły ponadgimnazjalne i JST jako podmioty ważne.

Jak działa kreator

• Rozgałęziający kwestionariusz — pytania o fakty, od których zależy kwalifikacja w znowelizowanej ustawie o KSC (Dz.U. 2026 poz. 252): szczebel samorządu i liczba etatów urzędu gminy, organ prowadzący szkołę lub bibliotekę, forma prawna jednostki, realizacja zadania publicznego z wykorzystaniem systemów informacyjnych oraz data, od której przesłanki są spełnione.
• Propozycja, nie decyzja — metodyka ksc-2026.1 proponuje kategorię: podmiot kluczowy, podmiot ważny, podmiot ważny będący podmiotem publicznym (zał. 4), poza zakresem albo „wymaga konsultacji prawnej”, z uzasadnieniem i podstawą prawną. Większość reguł opiera się na interpretacji przepisów czekającej na opinię eksperta — strona wyniku to zaznacza. Wynik nie jest opinią prawną.
• Zatwierdzenie przez osobę uprawnioną — kwalifikację przyjmuje (albo zmienia z uzasadnieniem) administrator lub dyrektor placówki dla swojej placówki, po ponownym potwierdzeniu tożsamości. Każda placówka ma osobną samoidentyfikację.
• Ślad audytowy — przebieg 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.
• Zadania — zatwierdzenie tworzy zadania z katalogu obowiązków KSC (po jednym na obowiązek właściwy dla kwalifikacji) z terminami liczonymi według ustawy (część terminów to interpretacja czekająca na opinię eksperta).

§3. Cykl raportowania incydentów NIS2

Art. 23 NIS2 i art. 11 KSC nakładają obowiązek raportowania poważnych incydentów w trzech etapach. Platforma obsługuje pełny cykl z wbudowanymi timerami terminów.

§4. Biblioteka obowiązków KSC dla sektora edukacji

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 organu nadzorczego lub podczas audytu wewnętrznego platforma generuje paczkę audytową ZIP:

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 placówek

W strukturze JST każda szkoła może mieć własnego ITSO (Inspektora ds. bezpieczeństwa informacji). Platforma obsługuje wielopoziomową hierarchię:

• JST (poziom nadrzędny) — widzi dane wszystkich podległych placówek; może przypisywać zadania kontrolne do dowolnej szkoły.
• Dyrektor szkoły — widzi dane swojej placówki. Gdy szkoła jest osobnym Dzierżawcą, rozdziela je izolacja Dzierżawców przez FORCE RLS. W jednym Dzierżawcy JST obejmującym kilka szkół rolę dyrektora nadaje się per placówka: ogranicza ona dyrektora do zadań kontrolnych, samoidentyfikacji, incydentów, wyjątków i przypisań jego szkoły oraz rekordów dotyczących całej organizacji (poza wyjątkami od polityk i przypisaniami wymagań skierowanymi do wszystkich placówek). Najpierw egzekwuje to kod aplikacji, a pod nim RLS per jednostka (org_unit_id) — każda szkoła ma własną jednostkę organizacyjną. Ryzyka, aktywa i stany zgodności kontroli są rozdzielane per szkoła wyłącznie w kodzie aplikacji.
• Koordynator IT szkoły — pełny dostęp do danych compliance w zakresie swojej placówki.

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)

§8. Interfejs RODO

Szkoły i JST są organizacjami publicznymi i są zobowiązane do wyznaczenia IOD (art. 37 ust. 1 lit. a RODO). Platforma obsługuje jednoczesne prowadzenie procesu NIS2 i RODO:

• Incydent NIS2 obejmujący dane uczniów lub pracowników może równocześnie stanowić naruszenie RODO — platforma umożliwia powiązanie obu raportów jednym ID incydentu.
• Rejestr czynności przetwarzania (RCP) per placówka może być prowadzony wewnątrz platformy jako zadania kontrolne lub zewnętrznie — platforma obsługuje oba warianty.
• Prawa podmiotów danych (uczniów, rodziców, pracowników) — wnioski mogą być rejestrowane jako zadania kontrolne z terminem odpowiedzi (30 dni).

§9. Czego platforma nie robi

§10. Kontakt