Zarząd pyta „czy jesteśmy zgodni z NIS2?”, termin wisi nad Tobą, więc otwierasz ustawę i szukasz w niej słów „modelowanie zagrożeń”. Nie znajdziesz ich. Nie ma ich też w DORA ani w CRA. To nie znaczy, że temat Cię nie dotyczy. Znaczy tylko, że szukasz nie tam, gdzie trzeba.
Teza tego artykułu jest prosta. Modelowanie zagrożeń (ang. threat modeling) nie jest wymagane wprost, z nazwy. Ale jest silnie implikowane przez dwa twarde obowiązki, które w tych regulacjach jak najbardziej są: bezpieczne wytwarzanie oprogramowania i analizę ryzyka. Pokażemy, gdzie dokładnie w przepisach jest na nie miejsce, od kiedy to obowiązuje i co realnie musisz mieć. Po kolei: NIS2 i polska ustawa KSC (z konkretami i karami), potem DORA, potem CRA, na końcu „jedna praktyka, wiele wymogów naraz” i plan działania. Zapraszamy!
Krótko: czego tu szukasz, a czego nie znajdziesz
Żebyśmy się dobrze zrozumieli na starcie. To nie jest kolejny ogólny tekst „co to jest NIS2 i kogo dotyczy”. Od tego są osobne, pełne opracowania per regulacja (do nich linkujemy). To jest odpowiedź na jedno konkretne pytanie: gdzie w tych regulacjach jest miejsce na modelowanie zagrożeń i co Ci ono realnie daje.
I jedno zastrzeżenie, bo gramy w otwarte karty. Nie jesteśmy kancelarią: pełna wykładnia prawna należy do Twojego działu compliance albo radcy. My pokazujemy to, na czym się znamy, czyli gdzie technicznie modelowanie zagrożeń wpina się w wymogi. Trzymamy się przy tym jednej zasady: oddzielamy twardy obowiązek (to, co musisz mieć) od konkretnej techniki, którą ten obowiązek spełniasz (to już Twój wybór).
NIS2 i KSC: czy wymagają modelowania zagrożeń?
Krótka odpowiedź: z nazwy nie. W praktyce tak, bo bez tego trudno spełnić wymóg bezpiecznego wytwarzania i analizy ryzyka. Rozłóżmy to na konkrety, bo tu jest najmocniejszy grunt.
Łańcuch zaczyna się w dyrektywie. NIS2 (art. 21 ust. 2 lit. e) wymaga „bezpieczeństwa w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych, w tym postępowania w przypadku podatności”. Polska implementacja idzie dalej i jest twardsza. Ustawa o KSC, w art. 8 ust. 1 pkt 2 lit. b, nakłada obowiązek zapewnienia „bezpieczeństwa w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, w tym testowania”. To nie jest wytyczna ani dobra praktyka, lecz obowiązek ustawowy (MUST), z klauzulą proporcjonalności do oszacowanego ryzyka.
Schodząc niżej, rozporządzenie wykonawcze (UE) 2024/2690 doprecyzowuje, jak ten bezpieczny cykl rozwojowy ma wyglądać. Punkt 6.2 to wprost „Bezpieczny cykl rozwojowy”, a punkt 6.2.2 lit. a–b każe „przeprowadzać analizę wymogów bezpieczeństwa na etapie specyfikacji i projektowania” oraz „stosować zasady inżynierii bezpieczeństwa i bezpiecznego kodowania”, w tym security-by-design. I to jest dokładnie miejsce, w którym mieszka modelowanie zagrożeń: ustrukturyzowana analiza tego, co może pójść źle, na etapie projektowania. Nie jest nazwane po imieniu, ale jest jednym z naturalnych sposobów, żeby ten wymóg spełnić.
Jest i druga, równoległa podstawa: analiza ryzyka (NIS2 art. 21 ust. 2 lit. a). Modelowanie zagrożeń to po prostu proaktywna technika analizy ryzyka na poziomie systemu i aplikacji.
Dwa uczciwe zastrzeżenia, żebyś nie przeszacował podstawy prawnej. Po pierwsze, rozporządzenie 2024/2690 jest formalnie wiążące tylko dla wymienionych dostawców usług cyfrowych (DNS, chmura, data center, CDN, dostawcy usług zarządzanych i podobni). Dla pozostałych podmiotów kluczowych i ważnych stanowi wzorzec interpretacyjny art. 21 NIS2 i art. 8 KSC, a nie bezpośrednią podstawę. Po drugie, konkretne techniki (jak SAST czy DAST) pojawiają się dopiero w niewiążących wytycznych ENISA („Technical Implementation Guidance” v1.0 z 2025 roku), które mapują wymogi m.in. do ISO/IEC 27001, NIST CSF i IEC 62443. To poziom „warto” (SHOULD), nie „musisz” (MUST). Modelowanie zagrożeń sytuuje się jednak wyżej w tym łańcuchu, przy bezpiecznym projektowaniu, więc i jego podstawa jest mocniejsza.
Od kiedy i jakie kary
Polska ustawa KSC weszła w życie 3 kwietnia 2026 (Dz.U. 2026 poz. 252). Ale obowiązki rozkładają się w czasie i to jest dla Ciebie ważniejsze niż sama data wejścia. Wdrożenie systemu zarządzania bezpieczeństwem informacji (SZBI) masz do 2027 roku. Pierwszy audyt podmiotu kluczowego i realne ryzyko kar to rok 2028. Innymi słowy: prawdziwy termin na poukładanie bezpiecznego wytwarzania to nie „pojutrze”, ale i nie „kiedyś”. Masz na to najbliższe kilkanaście miesięcy: dość, żeby zrobić to sensownie, i za mało, żeby zwlekać.
A stawka? Dla podmiotów kluczowych kary sięgają 10 mln EUR lub 2% rocznego obrotu (wyższa z wartości), dochodzi do tego osobista odpowiedzialność kierownictwa oraz obowiązkowy audyt co dwa lata. To przestaje być abstrakcją z prezentacji, a staje się ryzykiem biznesowym i osobistym zarządu.
Tryb pod compliance: jeśli systemy już działają
Częste pytanie: „mam dziesiątki systemów na produkcji, mam je teraz wszystkie modelować od zera?”. Nie. Jeśli robisz modelowanie wstecz, pod regulację, robisz je globalnie, na poziomie systemu lub całej organizacji, a nie iteracyjnie dla każdej funkcjonalności. Iteracyjne modelowanie „wstecz” na pojedynczych funkcjach nie zwraca włożonego wysiłku. Globalny model systemu albo organizacji daje natomiast dokładnie ten artefakt, którego oczekuje audyt. Jak ujął to Andrzej Dyjak: „Wstecz wartość umyka, ale ma sens dla compliance: dla podzbioru systemów robimy modele wstecz, ale globalnie, nie iteracyjnie”. Który poziom modelujesz i jakim artefaktem to domykasz, rozkładamy w przewodniku po poziomach modelowania zagrożeń.
I jedna rzecz, której nie wolno pomylić
Compliance to nie to samo co bezpieczeństwo. Można odhaczyć regulację i wciąż być dziurawym, czyli mieć realne podatności. Odhaczenie paragrafu to jedno, faktyczne obniżenie ryzyka to drugie. Dobra wiadomość jest taka, że dobrze zrobione modelowanie zagrożeń daje Ci jedno i drugie naraz: dowód na audyt i naprawdę bezpieczniejszy system.
DORA: odporność operacyjna w finansach
Jeśli działasz w sektorze finansowym, Twoją główną regulacją jest DORA (ang. Digital Operational Resilience Act, rozporządzenie UE 2022/2554), stosowana od 17 stycznia 2025. Dla podmiotów finansowych jest ona przepisem szczególnym wobec NIS2, czyli ma przed nią pierwszeństwo. Szczegóły techniczne doprecyzowuje akt delegowany, RTS 2024/1774.
Gdzie w tym wszystkim modelowanie zagrożeń? Pośrednio, ale solidnie. RTS 2024/1774 (art. 16 ust. 1 lit. a) wymaga zdefiniowania praktyk i metod bezpieczeństwa w pozyskiwaniu, rozwoju i utrzymaniu systemów ICT, a cała DORA stoi na zarządzaniu ryzykiem ICT. Modelowanie zagrożeń to konkretny sposób, by proaktywnie mapować scenariusze zagrożeń dla krytycznych systemów i ich integracji. Co ciekawe, DORA jako jedyna w tej siatce nazywa wprost przegląd kodu oraz testy statyczne i dynamiczne (art. 16 ust. 3 RTS). To jednak dotyczy testowania kodu, nie modelowania zagrożeń, więc ten wątek zostawiamy tam, gdzie jest jego miejsce, czyli przy automatyzacji bezpieczeństwa w cyklu wytwórczym. Pełny rozkład DORA na czynniki pierwsze trafi do osobnego opracowania.
CRA: bezpieczeństwo produktów z elementami cyfrowymi
Jeśli wytwarzasz produkt z elementem cyfrowym (oprogramowanie, urządzenie, IoT), dotyczy Cię CRA (ang. Cyber Resilience Act, rozporządzenie UE 2024/2847). Ma twarde, konkretne terminy: raportowanie aktywnie wykorzystywanych podatności rusza od 11 września 2026, a pełne wymogi zasadnicze wraz z obowiązkiem SBOM od 11 grudnia 2027. Kary sięgają 15 mln EUR lub 2,5% obrotu, więc nie jest to temat do odłożenia.
Modelowanie zagrożeń wpina się tu przez wymóg oceny ryzyka i zasadę security-by-design. Załącznik I do CRA wymaga, by produkt był projektowany i dostarczany „bez znanych możliwych do wykorzystania podatności” oraz z ograniczoną powierzchnią ataku. Trudno to spełnić bez systematycznej, udokumentowanej analizy tego, co może pójść źle, a normy branżowe (jak IEC 62443-4-1 dla bezpiecznego cyklu wytwórczego) czynią modelowanie zagrożeń de facto standardem. Dla Ciebie zysk jest podwójny: model zagrożeń to zarazem realna mapa ryzyka i gotowy dowód do dokumentacji technicznej, której CRA będzie wymagać.
Jedna praktyka, wiele wymogów naraz
Tu jest sedno argumentu biznesowego. Nie kupujesz osobnego narzędzia pod każdy paragraf. Modelowanie zagrożeń jako jedna praktyka pokrywa wiele wymogów regulacyjnych jednocześnie. Spójrz, jak to się mapuje:
- Analiza ryzyka (NIS2 art. 21 ust. 2 lit. a, ryzyko ICT w DORA): modelowanie daje ustrukturyzowaną, proaktywną analizę ryzyka per system i aplikacja.
- Bezpieczne wytwarzanie (KSC art. 8 ust. 1 pkt 2 lit. b, rozp. 2024/2690 pkt 6.2.2, security-by-design w CRA): modelowanie generuje konkretne wymagania bezpieczeństwa już na etapie projektowania.
- Priorytety testów: wynik modelowania kieruje pentesty i testy bezpieczeństwa na najistotniejsze zagrożenia, zamiast strzelać na oślep. To „requirement-driven security testing”.
- Ryzyko łańcucha dostaw: modelowanie na poziomie organizacji i systemu obejmuje integracje oraz zależności od dostawców, których dotyczą wymogi supply chain.
Jest też wątek, który spina to z poziomami modelowania. Na poziomie organizacji model zagrożeń jest formalny i służy jako wkładka do analizy ryzyka oraz ciągłości działania. To właśnie tego szuka audytor. Na poziomie aplikacji i funkcjonalności modelowanie realizuje bezpieczne wytwarzanie w cyklu. Którą warstwą spełniasz który wymóg, pokazujemy w przewodniku po poziomach modelowania zagrożeń.
Przyświeca nam przy tym prosta zasada: bezpieczeństwo to proces, nie produkt. Regulacja nie każe Ci kupić pudełka. Każe mieć proces. A to, że taniej i sensowniej jest unikać błędów na etapie projektowania, niż gasić je później na produkcji? To już wisienka na torcie.
Co robić, jak żyć?
Zbierzmy to w pięć kroków dla decydenta:
- Ustal, które regulacje Cię dotyczą. NIS2/KSC, jeśli jesteś podmiotem kluczowym lub ważnym; DORA, jeśli finanse; CRA, jeśli wytwarzasz produkt z elementem cyfrowym. Szczegóły per regulacja znajdziesz w dedykowanych opracowaniach.
- Sprawdź, czy masz udokumentowaną analizę ryzyka per system i bezpieczne wytwarzanie. Jeśli nie, modelowanie zagrożeń to najtańszy sposób, żeby realnie je mieć, a nie tylko na papierze.
- Wepnij modelowanie w to, co już masz. Zwykle nie wymaga nowego procesu, wpina się w istniejący cykl wytwórczy (SDLC).
- Zacznij od poziomu, który Cię uwiera. Pod compliance zaczynasz globalnie, od systemu albo organizacji, gdzie formalny model jest wkładką do analizy ryzyka. Iteracyjne modelowanie pojedynczych funkcji to wartość „do przodu”, nie pod audyt poziomy modelowania zagrożeń.
- Udokumentuj. Formalny model na poziomie systemu i organizacji to dowód na audyt i zarazem realna mapa zagrożeń. Model na poziomie aplikacji idzie po prostu do backloga deweloperskiego.
Nie traktuj modelowania zagrożeń jako kolejnego „muszę pod regulację”. Potraktuj je jako jedną praktykę, która jednocześnie spełnia wymóg i realnie obniża ryzyko.
Damy Ci znać, gdy opublikujemy coś nowego.
Artykuł albo odcinek podcastu. Bez spamu. W każdej chwili możesz się wypisać.
Zapisując się, akceptujesz politykę prywatności.
Referencje i wzmianki: NIS2 (dyrektywa UE 2022/2555, art. 21 ust. 2 lit. a i e); rozporządzenie wykonawcze (UE) 2024/2690 (Załącznik, pkt 6 „Bezpieczny cykl rozwojowy”); ustawa o KSC (Dz.U. 2026 poz. 252; art. 8 ust. 1 pkt 2 lit. b); wytyczne ENISA „Technical Implementation Guidance” v1.0 (2025); ISO/IEC 27001; DORA (rozporządzenie UE 2022/2554) z RTS 2024/1774; CRA (rozporządzenie UE 2024/2847); IEC 62443-4-1.