Zanim wdrożysz procedury, znajdź człowieka. Pierwszy krok
Michał Nowakowski · 30 października 2026
Przepisy ustawy o krajowym systemie cyberbezpieczeństwa i szereg dokumentów, które produkuje Ministerstwo Cyfryzacji, mogą sprawić, że zakręci się nam w głowie. Jak sobie z tym poradzić?
Przepisy ustawy o krajowym systemie cyberbezpieczeństwa i szereg dokumentów, które produkuje Ministerstwo Cyfryzacji, mogą sprawić, że zakręci się nam w głowie. Od kwietnia przyszłego roku powinniśmy mieć gotowe ramy bezpieczeństwa informacji i być w stanie wykazać, że działają. Przynajmniej teoretycznie.
Co jednak w sytuacji, gdy jesteśmy „początkujący” i nie do końca wiemy, za co się zabrać? Możemy skorzystać z ChatGPT lub Claude. To prawda, ale może to nie być najlepszy kierunek, jeżeli zamierzamy podejść do tego rozsądnie. Rozsądnie, czyli także z uwzględnieniem dostępnych zasobów. A zasobów w cyberbezpieczeństwie zawsze brakuje. Mniej lub bardziej, ale brakuje.
Od czego więc zacząć i jak sensownie podejść do budowania naszej odporności, a jednocześnie nie zwariować?
Spróbuję na to odpowiedzieć w dzisiejszym felietonie, który przygotowuję równolegle ze szkoleniem z najnowszych norm dla AI, na które serdecznie zapraszam. Wróćmy jednak do meritum.
Ustawa o krajowym systemie cyberbezpieczeństwa w art. 8 ust. 1 pkt 2 dość wyraźnie daje nam do zrozumienia, że to, co będziemy wprowadzać w organizacji, powinno:
✅ być „odpowiednie”,
✅ być „proporcjonalne”,
✅ uwzględniać oszacowane ryzyko,
✅ uwzględniać najnowszy stan wiedzy, koszty wdrożenia, wielkość podmiotu, prawdopodobieństwo wystąpienia incydentów, narażenie podmiotu na ryzyko, a także skutki społeczne i gospodarcze.
Czy to oznacza, że możemy przyjąć zerowe ryzyko w zakresie bezpieczeństwa informacji i nic nie robić? Możemy, a jakże! Tyle że raczej wtedy, gdy wypasamy owce na zboczach gór lub gdy uwzględniamy ryzyko, że organ dopatrzy się błędów w kalkulacji.
Spójrzmy jeszcze na przykład, który może być nieoczywisty w kontekście cyberbezpieczeństwa, a o którym dyskutowaliśmy w trakcie ostatniego warsztatu AI Governance dla Elitmind Barbara Glowala. Nasi developerzy wykorzystują rozwiązania AI do kodowania i w ogóle developmentu. Są to narzędzia, które akceptujemy jako organizacja (shadow AI, to odrębny temat). To są potencjalne punkty, które mogą stać się "problemem".
I to w dwóch obszarach - kodu, który jest dziurawy jak ser szwajcarski i samych agentów. Dlatego warto spojrzeć tutaj np. na projektowane wytyczne ENISA, które mogą wpływać na nasze podejście do SZBI.
Innymi słowy, chodzi o to, abyśmy nie przesadzili ani w jedną (za niski poziom bezpieczeństwa), ani w drugą (za wysoki poziom) stronę. Każda decyzja dotycząca budowania i utrzymania tzw. systemu zarządzania bezpieczeństwem informacji ma swój koszt i znaczenie dla organizacji.
Na przykład, gdy identyfikujemy podatności (luki), każdej z nich przypisujemy poziom krytyczności, uwzględniając choćby tzw. Common Vulnerability Scoring System (CVSS). Pozwala nam to określić, jakie działania podjąć „od razu”, a jakie odłożyć na później. Możemy też pozostawić niektóre podatności bez zmian, jeżeli zasadniczo nie wpływa to na naszą organizację. Ma to potem znaczenie także przy „wycenie” naszego systemu zarządzania bezpieczeństwem informacji.
Wygenerowane w oparciu o bazę wiedzy i model Astra 6. Wymaga to rzecz jasna zrozumienia złożoności naszej architektury oraz wpływu poszczególnych rozwiązań czy funkcjonalności na całość. Bez odpowiednich kompetencji możemy wejść na minę. W praktyce może to oznaczać:
✅ pominięcie tych podatności, które na pierwszy rzut oka nie są istotne, ale w połączeniu z innymi obszarami stają się krytyczne,
✅ zastosowanie nieproporcjonalnych rozwiązań tam, gdzie nie jest to uzasadnione, co generuje koszty dla organizacji, także w postaci spowolnienia działania naszych produktów i usług.
Musimy także uwzględnić kwestie związane z tzw. łańcuchem dostaw: jacy dostawcy i w jakim zakresie wspierają świadczenie naszych usług czy dostarczanie produktów oraz jaki ma to na nas wpływ. W art. 8 ust. 2 znajdziemy wskazówkę: wdrażając środki pozwalające na „lepsze” zarządzanie łańcuchem dostaw, powinniśmy uwzględnić m.in.:
✅ podatności związane z dostawcą,
✅ ogólną jakość produktów, procesów i usług teleinformatycznych, a także
✅ pewne działania organów odpowiedzialnych za cyberbezpieczeństwo.
Do tego tematu jeszcze wrócimy. Skoro jednak przy podejmowaniu decyzji o zakresie i skali naszego systemu cyberbezpieczeństwa powinniśmy uwzględniać także te kwestie (np. czy korzystamy z rozwiązań open source, czy „pudełkowych”), warto jak najwcześniej zrobić rozeznanie. Czasem może się okazać, że zaangażowanie zewnętrznego dostawcy zdejmie nam z głowy wiele problemów. Nie możemy jednak zapominać, że to outsourcing. A outsourcing też jest źródłem ryzyka.
Tak czy inaczej, myśląc o SZBI, powinniśmy zrozumieć jedno - bez odpowiednich ludzi (choćby jednej osoby) trudno będzie nam dostosować system do naszych potrzeb i możliwości. Musimy więc kogoś takiego znaleźć.
A ustawa jest też bezlitosna, bo kierownik podmiotu kluczowego lub ważnego ponosi odpowiedzialność za wykonywanie obowiązków w zakresie SZBI (art. 8c). Czy to jednak oznacza, że np. prezes zarządu ma zajmować się cyberbezpieczeństwem?
A ma kompetencje w tym zakresie? Pewnie nie. Do tego zajmuje się innymi strategicznymi kwestiami. Dlatego musimy mieć „kogoś”, kto odpowiada za cyberbezpieczeństwo, a co najmniej komunikuje się z innymi podmiotami w ramach systemu cyberbezpieczeństwa, w tym w sprawach incydentów.
Zresztą wyznaczenie takiej osoby i powierzenie jej funkcji „bezpiecznika” na jak najwcześniejszym etapie pozwoli nam sprawniej dostosować nasze SZBI do potrzeb i możliwości organizacji. Powinno to być jedno z pierwszych zadań, których się podejmiemy.
Czy to wszystko? Nie, ale dzisiaj - szczególnie przy piątku - nie będę Was męczył. Temat pogłębimy w kolejnych felietonach. A ja zachęcam Was do zapisania się do mojego newslettera przez stronę (prawy górny róg).