Zgodność z NIS2 / KSC

Dyrektywa NIS2 (UE) 2022/2555  ·  Ustawa o KSC (Dz.U. 2018 poz. 1560 ze zm.)  ·  Ostatnia aktualizacja: 2026-05-15  ·  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 sektor (lista załączników I i II NIS2), wielkość organizacji, progi usługowe i progi KSC (art. 5 ustawy).
• Silnik decyzyjny — na podstawie odpowiedzi platforma sugeruje jedną z kategorii: OUK, Podmiot ważny, IBTI, Poza zakresem. Wynik jest zapisywany w profilu Dzierżawcy.
• Ślad audytowy — każda zmiana kategorii jest rejestrowana w dzienniku audytu z kodem nis2.identification.update i identyfikatorem aktora.
• CTA do pulpitu — po wyborze kategorii kreator generuje spersonalizowany plan działań z priorytetyzowanymi kontrolami z biblioteki KSC.

§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 wbudowaną bibliotekę obowiązków wynikających z KSC i NIS2, zmapowanych na zadania kontrolne (ControlTask). Każdy obowiązek może mieć przypisane:

• dowód realizacji (załącznik plikowy lub link do wymagania systemowego),
• osobę odpowiedzialną (rola platformy),
• termin przeglądu (roczny lub wyzwalany zdarzeniem),
• status: spełniony / w realizacji / nie dotyczy / do weryfikacji.

8 głównych grup obowiązków KSC (przykłady)

§5. Paczka audytowa (eksport dowodów)

Na żądanie audytora lub organu nadzorczego platforma generuje paczkę audytową w formacie ZIP. Paczka jest podpisana hash–em SHA-256 i zawiera:

audit-pack-{tenant}-{date}.zip
├── manifest.json          # skroty SHA-256 wszystkich plikow, wersja, data generowania
├── audit-log.csv          # pelny dziennik audytu (chain-verified)
├── controls/
│   ├── controls-export.csv  # status wszystkich zadan kontrolnych
│   └── evidence/            # zalaczone dowody (pliki PDF, screenshoty)
├── incidents/
│   ├── incident-list.csv    # lista incydentow z kodami KSC-INC
│   └── reports/             # raporty 24h/72h/30d jako PDF
├── risk-register.csv      # rejestr ryzyk z leczeniami
└── nis2-alignment.csv     # mapowanie art. 21 §2 (a-j) ze statusem

Weryfikacja integralności paczki jest możliwa niezależnie od platformy — manifest.json zawiera sygnatury wszystkich plików. Paczka nie zawiera hasłeń ani sekretów uwierzytelniających.

§6. Wyznaczenie IBTI / ITSO i izolacja jednostek

Platforma obsługuje wielopoziomową strukturę organizacyjną (JST → jednostki podległe → szkoły / instytucje). Każda jednostka posiada własny profil desygnacji IBTI/ITSO.

Mechanizm izolacji danych

Każda tabela chroniona RLS nosi kolumny tenant_id i org_unit_id. Middleware ustawia parę GUC app.current_tenant_id + app.current_org_unit_id przy każdym żądaniu. PostgreSQL wymusza reguły RLS na poziomie silnika — kod aplikacji nie może ich ominąć.

Przykładowy efekt: koordynator cyberbezpieczeństwa JST widzi dane wszystkich podległych jednostek; dyrektor szkoły widzi wyłącznie dane swojej szkoły — bez żadnej logiki filtrowania w kodzie Python.

Rejestr desygnacji

§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