Nasz blog to praktyczne artykuły o cyberbezpieczeństwie i regulacjach, pisane prostym językiem zrozumiałym dla właścicieli firm i menedżerów. Poruszamy konkretne tematy, takie jak wymagania NIS2, DORA, CRA, wdrożenia norm ISO 27001, analiza incydentów, phishing, ransomware czy dobre praktyki dla MŚP.
Zamiast technicznego żargonu - oferujemy wskazówki, które można od razu zastosować w biznesie. Stawiamy na treści „do wdrożenia od zaraz": publikujemy checklisty, analizy zagrożeń, poradniki dla sektora MŚP i regularne aktualizacje o nowych przepisach.
WEF Global Cybersecurity Outlook 2026: wnioski dla zarządu
Co raport WEF Global Cybersecurity Outlook 2026 oznacza dla decyzji zarządu? Omawiamy siedem obszarów: AI, geopolitykę, oszustwa, cyberodporność, dostawców, luki kompetencyjne i przyszłe zagrożenia. Rozdzielamy wyniki badania od rekomendacji CCyber i pokazujemy, jak przełożyć je na wybór działań, odpowiedzialności i mierników. Artykuł zawiera również kartę decyzji zarządczej oraz przykład ryzyka wspólnego dostawcy. Globalnych statystyk nie traktujemy jako oceny bezpieczeństwa konkretnej polskiej firmy.
Opracowanie: Zespół redakcyjny CCyber
Raport WEF Global Cybersecurity Outlook 2026 wskazuje, że odporność organizacji zależy nie tylko od własnych zabezpieczeń, ale również od decyzji dotyczących AI, dostawców, kompetencji i współpracy. Publikacja łączy perspektywę technologiczną z gospodarczą i geopolityczną. Nie sprowadza cyberbezpieczeństwa do zakupu kolejnego narzędzia.
Dla zarządu proponujemy praktyczne zastosowanie: wybrać scenariusze istotne dla własnej działalności, sprawdzić zdolność reakcji i zdecydować, co trzeba poprawić. Wyniki ankiety mają pomagać zadawać trafniejsze pytania. Nie zastępują analizy ryzyka firmy ani dowodów działania jej zabezpieczeń.
19 września 2026 r.
Podstawą jest Global Cybersecurity Outlook 2026, opublikowany 12 stycznia 2026 r. przez World Economic Forum we współpracy z Accenture. Omówienie zachowuje siedem obszarów głównej części raportu. Propozycje działań, karta decyzji i przykład firmy są opracowaniem CCyber, nie wynikami badania WEF.
Dla zarządów, właścicieli firm, CISO, kierowników IT oraz osób odpowiedzialnych za ryzyko, operacje i zakupy. Szczególnie dla organizacji, które chcą wykorzystać raport branżowy do ustalenia priorytetów, zamiast jedynie dodać kilka procentów do prezentacji.
Badanie przeprowadzono od 25 sierpnia do 1 października 2025 r. Po kwalifikacji uwzględniono 804 uczestników z 92 krajów. Wśród nich było 105 CEO i 316 CISO. Ankietę uzupełniały rozmowy eksperckie oraz warsztaty. Szczegóły opisuje metodologia WEF.
Rok 2026 w tytule nie oznacza, że wszystkie odpowiedzi zebrano w 2026 r. Część pytań dotyczyła minionych 12 miesięcy, a część oczekiwań. Przy porównaniach między edycjami nie zakładaj, że mierzono zmianę w identycznej grupie firm. Globalnych wyników nie traktuj jako reprezentatywnej diagnozy polskiego rynku.
W raporcie oszustwa wykorzystujące technologie cyfrowe i phishing zajmują pierwsze miejsce wśród obaw CEO. U CISO na pierwszym miejscu pozostaje ransomware, a na drugim ryzyko łańcucha dostaw. To ranking obaw, nie ranking liczby incydentów. Porównanie przedstawia rozdział poświęcony perspektywie CEO.
Propozycja CCyber: podczas ustalania budżetu poproś finanse, operacje i bezpieczeństwo o opisanie skutków tych samych scenariuszy. Dla fałszywej płatności oceń stratę i sposób zatwierdzania. Dla ransomware sprawdź możliwość realizowania zamówień. Nie rozstrzygaj, kto ma rację, wyłącznie przez porównanie pozycji w rankingu.
Wynik WEF: 94% respondentów wskazało AI jako najważniejszy czynnik zmian w cyberbezpieczeństwie w nadchodzącym roku. Proces oceny bezpieczeństwa narzędzi AI deklarowało 64%, wobec 37% w poprzedniej edycji. Dane przedstawia podsumowanie wyników WEF.
Propozycja CCyber: rozdziel trzy pytania: jak chronimy własne zastosowania AI, jak wykorzystujemy AI w bezpieczeństwie i jak przygotowujemy się na jej użycie przez napastników. Wybierz jeden działający przypadek użycia i sprawdź dane wejściowe, uprawnienia, odpowiedzialność za wynik oraz możliwość zatrzymania automatyzacji.
Przy narzędziu analizującym alerty nie oceniaj wyłącznie szybkości. Zaplanuj test błędnej rekomendacji i ustal, kto może ją zakwestionować. Przy agencie wykonującym działania sprawdź, jakie operacje wymagają akceptacji i kto może odebrać mu dostęp.
Dowód postępu: udokumentowana ocena konkretnego zastosowania i wynik testu jego ograniczeń. Sam wpis „AI zatwierdzone” nie opisuje zakresu decyzji. Dalsze przykłady znajdziesz w kategorii Bezpieczeństwo AI i nowe zagrożenia.
Wynik WEF: 64% badanych organizacji uwzględnia ataki motywowane geopolitycznie w swoich strategiach ograniczania ryzyka. Raport omawia też zależności technologiczne i suwerenność cyfrową. Kontekst rozwija omówienie WEF dotyczące ryzyk 2026 r.
Propozycja CCyber: nie zaczynaj od ogólnej deklaracji, że „ryzyko geopolityczne jest wysokie”. Wskaż usługę, której utrata rzeczywiście zatrzyma pracę. Sprawdź zależność od lokalizacji infrastruktury, wsparcia dostawcy, łączności i możliwości przeniesienia danych.
Przy wyborze rozwiązania lokalnego lub określanego jako suwerenne wymagaj wyjaśnienia, który problem ma rozwiązać. Zmiana dostawcy bez testu migracji i oceny nowych zależności nie powinna być uznawana za zakończone działanie.
Dowód postępu: opisany scenariusz utraty usługi, uzgodniona reakcja i sprawdzone ograniczenia wariantu zastępczego.
Wynik WEF: 73% respondentów wskazało, że w minionych 12 miesiącach oszustwo dotknęło ich osobiście lub kogoś z ich sieci zawodowej bądź prywatnej. Tak sformułowano pytanie w wykresie 21 raportu. Nie oznacza to włamania do 73% badanych przedsiębiorstw.
Propozycja CCyber: wspólnie z finansami sprawdź zmianę numeru rachunku kontrahenta, pilny przelew i odzyskiwanie dostępu do konta. Zaprojektuj potwierdzenie przez wcześniej uzgodniony kanał, a nie numer lub odnośnik przekazany w podejrzanej wiadomości.
Przeprowadź uzgodnione ćwiczenie na danych testowych. Sprawdź również presję czasu i zastępstwa. Nie opieraj akceptacji ważnej operacji wyłącznie na rozpoznaniu głosu, obrazu albo stylu wiadomości.
Dowód postępu: wynik testu zatwierdzania płatności oraz lista wyjątków, które nadal umożliwiają obejście procedury. Materiały do przygotowania pracowników znajdziesz w kategorii Szkolenia i cyberświadomość.
Wniosek WEF: rozdział o odporności łączy bezpieczeństwo z ochroną wartości gospodarczej. Wśród organizacji ze środowiskami przemysłowymi tylko 16% deklarowało raportowanie kwestii bezpieczeństwa OT zarządowi. Dane i kontekst zawiera część 3.4 raportu.
Propozycja CCyber: wybierz jedną usługę ważną dla przychodów, zobowiązań wobec klientów lub bezpieczeństwa procesu. Ustal, jak długo może być niedostępna, czego potrzebuje do wznowienia oraz kto podejmuje decyzję o pracy awaryjnej.
Test odtwarzania połącz z potwierdzeniem wyniku przez właściciela procesu. W środowisku przemysłowym uzgodnij zakres z operacjami i osobami odpowiedzialnymi za bezpieczeństwo ludzi. Nie wykonuj destrukcyjnego testu na czynnej instalacji.
Dowód postępu: protokół potwierdzający uzgodniony poziom działania usługi, nie tylko odtworzenie serwera. Temat rozwijamy w materiałach o reagowaniu na incydenty i ciągłości działania.
Wynik WEF: 65% dużych firm według kryterium przychodów wskazywało podatności dostawców i łańcucha dostaw jako największe wyzwanie dla odporności, wobec 54% w poprzedniej edycji. WEF zwraca też uwagę na koncentrację zależności. Podsumowuje to komunikat towarzyszący raportowi.
Propozycja CCyber: poza oceną każdego dostawcy osobno sprawdź, czy kilka ważnych usług korzysta z tego samego podwykonawcy, środowiska chmurowego lub mechanizmu logowania. Dwie osobne umowy nie powinny być jedynym uzasadnieniem niezależności.
Zapytaj partnera o praktyczną współpracę podczas incydentu: kontakt, zakres przekazywanych informacji, możliwość odzyskania danych i udział w ćwiczeniu. Do ankiety dodaj sprawdzenie wybranego scenariusza.
Dowód postępu: mapa wspólnych zależności dla krytycznej usługi i wynik uzgodnionego ćwiczenia z dostawcą. Braki dostępu do informacji zapisz jawnie, zamiast zastępować je domniemaniem bezpieczeństwa.
Wynik WEF: w porównaniu mniejszych i większych organizacji niedobór kompetencji wskazywało odpowiednio 46% i 29%. Autorzy opisują szerszy problem nierównego dostępu do zasobów jako cyber inequity. Wyniki omawia analiza WEF. Nie jest to podział według polskiej definicji MŚP.
Propozycja CCyber: przygotuj listę zadań, których firma nie potrafi dziś wykonać, zamiast ograniczać analizę do liczby wakatów. Sprawdź na przykład zdolność oceny incydentu, przeprowadzenia odtworzenia i weryfikacji uprawnień.
Dla każdej luki wybierz sposób uzupełnienia: rozwój własnego zespołu, wsparcie eksperckie albo usługę zarządzaną. Uzgodnij dostępność i rezultat. W relacji z mniejszym partnerem zaproponuj wspólne ćwiczenie lub wymagania etapowe, zamiast wysyłać wyłącznie rozbudowaną ankietę.
Dowód postępu: konkretne zadanie ma wykonawcę, zastępstwo i sprawdzony sposób realizacji. Samo zatrudnienie osoby albo podpisanie abonamentu nie zamyka tej oceny.
Perspektywa WEF: część 3.7 obejmuje scenariusze do 2030 r. dotyczące autonomicznych systemów i robotyki, walut cyfrowych, infrastruktury kosmicznej i podmorskiej, klimatu oraz technologii kwantowych. Są to przewidywania, nie potwierdzenie, że wszystkie opisane skutki już wystąpiły. Szczegóły zawiera końcowa część rozdziału o trendach.
Propozycja CCyber: wybierz obszary rzeczywiście związane z działalnością. Producent długo używanych urządzeń może zacząć od możliwości aktualizacji i zależności kryptograficznych. Firma logistyczna może sprawdzić zależność od pozycjonowania, łączności i automatycznych decyzji.
Nie uzasadniaj kosztownego zakupu samą obecnością technologii w raporcie. Najpierw określ zasób, czas jego używania, możliwy skutek i warunek, który powinien uruchomić dalsze działania.
Dowód postępu: rejestr obserwowanych zmian z właścicielem i terminem ponownej oceny, zamiast ogólnego slajdu o „zagrożeniach przyszłości”.
Rekomendujemy omówienie kilku scenariuszy związanych z konkretnymi usługami, nie prezentowanie wszystkich statystyk po kolei. Dla każdego przygotuj krótką kartę.
Usługa i skutek: co przestanie działać lub co można utracić?
Zależność: który system, dostawca, dostęp lub brak kompetencji jest istotny?
Stan wiedzy: co sprawdzono, na jaką datę i czego nadal nie wiadomo?
Decyzja: jakie działanie proponujemy i jakie warianty odrzucamy?
Odpowiedzialność i zasoby: kto dostarcza rezultat, kto go zatwierdza i jakie wsparcie jest potrzebne?
Kryterium odbioru: po czym poznamy, że zadanie przyniosło oczekiwany efekt?
Nie wyznaczamy w tym wzorze uniwersalnego procentu budżetu IT na cyberbezpieczeństwo. Najpierw opisz potrzebę i warianty działania. Następnie oszacuj wdrożenie, utrzymanie, czas własnych pracowników i testy.
Przykład modelowy CCyber, nie opis rzeczywistego klienta. Firma kupuje system obsługi klientów i narzędzie do realizacji zamówień od dwóch różnych dostawców. W dokumentacji uznano je za niezależne.
Podczas przeglądu okazuje się, że obie usługi korzystają z tego samego podwykonawcy infrastruktury. Ćwiczenie utraty dostępu pokazuje, że awaria może zatrzymać zarówno przyjmowanie, jak i wykonanie zamówień. Zespół ma kontakty do obu dostawców, lecz nie ma uzgodnionej kolejności przywracania pracy.
Firma nie podejmuje automatycznie decyzji o zmianie technologii. Najpierw ustala możliwość eksportu danych, dopuszczalny tryb ręczny i zasady komunikacji. Dopiero wyniki ćwiczenia służą do oceny, czy potrzebny jest dodatkowy wariant techniczny.
Wartością przeglądu jest wykrycie wspólnej zależności i sprawdzenie reakcji, a nie samo powiększenie rejestru dostawców.
Wybierz ważną usługę oraz związane z nią zastosowanie AI, proces płatności lub dostawcę. Zbierz istniejące oceny i dowody. Zapisz luki, ale nie zakładaj, że brak dokumentu zawsze oznacza brak zabezpieczenia.
Przeprowadź uzgodnione ćwiczenie reakcji, test odtworzenia albo weryfikację zatwierdzania operacji. Włącz właściciela procesu i potrzebnego dostawcę. Dostosuj test do środowiska, aby nie zagrozić bieżącej działalności.
Zweryfikuj naprawy, przedstaw pozostałe ograniczenia i zatwierdź kolejne priorytety. Rozszerz przegląd na następne usługi na podstawie ryzyka. Ten plan jest propozycją organizacji pracy, nie powodem do odkładania reakcji na aktywny incydent.
Proponujemy sprawdzać odsetek ważnych usług z pozytywnym testem odtworzenia, zastosowań AI z aktualną oceną, krytycznych dostawców ze sprawdzoną eskalacją oraz istotnych zadań posiadających wykonawcę i zastępstwo.
Każdy wskaźnik powinien mieć zakres, mianownik i datę. Wyniku jednej aplikacji nie rozciągaj na całe środowisko. Czas odtwarzania mierz zgodnie z uzgodnionym początkiem i końcem, nie tylko przez czas działania narzędzia.
Oddziel deklarację, wdrożenie i sprawdzenie. To praktyczna zasada naszego modelu raportowania, a nie nowy wskaźnik WEF.
Tematy strategii, odpowiedzialności i pracy z dostawcami rozwijamy w kategorii Ryzyko cyber, governance i vCISO. Wcześniejsze poradniki o AI i incydentach pomagają przejść od wyboru priorytetu do szczegółowej realizacji.
Ten artykuł jest omówieniem raportu i propozycją jego wykorzystania w planowaniu. Nie zastępuje analizy właściwych dla firmy obowiązków regulacyjnych.
W ramach usługi vCISO CCyber wspiera strategię, zarządzanie ryzykiem i dostawcami, definiowanie mierników oraz raportowanie do zarządu.
Przełóż wyniki raportu na priorytety własnej organizacji. Punktem wyjścia do ustalenia zakresu współpracy mogą być lista ważnych usług, obecny plan bezpieczeństwa i pytania, na które zespół nie ma potwierdzonej odpowiedzi. Celem powinny być decyzje oraz sprawdzalne działania, nie kolejna prezentacja trendów.
Nie należy tak go interpretować. Obejmuje globalną grupę respondentów, a nie reprezentatywną próbę polskich przedsiębiorstw. Może pomóc zaplanować pytania do własnego przeglądu.
WEF pokazuje różnicę między priorytetami CEO i CISO. Nie rozstrzyga, które zagrożenie musi być najważniejsze dla konkretnej organizacji. Do tego potrzebna jest analiza jej procesów i skutków zdarzenia.
Sam trend nie wystarcza. Najpierw określ zadanie, oczekiwany efekt i ryzyko błędnego działania. Następnie sprawdź rozwiązanie w kontrolowanym zakresie i zaplanuj jego obsługę.
Nie rekomendujemy takiego podejścia. Wybierz powiązane scenariusze dotyczące ważnych usług. Jedno ćwiczenie może ujawnić braki w odpowiedzialności, dostępie i współpracy z dostawcą, bez tworzenia trzech osobnych inicjatyw.
Nie. Są perspektywą przyszłościową. W planowaniu warto odróżniać dane z ankiety od opinii i scenariuszy oraz aktualizować decyzje wraz z nowymi informacjami.
Wnioski końcowe WEF podkreślają znaczenie przywództwa, kompetencji i współpracy dla wspólnej odporności. To szersza perspektywa niż ochrona pojedynczej organizacji w oderwaniu od jej partnerów.
Nasza rekomendacja: zakończ lekturę raportu decyzją o sprawdzeniu konkretnego scenariusza. Wybierz usługę, wskaż zależności, ustal odpowiedzialność i zweryfikuj wynik. Wtedy globalne opracowanie staje się użyteczne dla firmy, zamiast pozostawać zbiorem statystyk.
ISO 27001:2022: 93 zabezpieczenia Załącznika A w praktyce
Załącznik A ISO/IEC 27001:2022 zawiera 93 zabezpieczenia, ale nie jest listą identycznych zakupów dla każdej firmy. Wyjaśniamy cztery grupy zabezpieczeń, prawidłowe oznaczenia wybranych pozycji oraz różnicę między wymaganiem, wdrożeniem i dowodem działania. Pokazujemy, jak dobierać zabezpieczenia, przygotować deklarację stosowania i uzasadniać wyłączenia. Przykład dostępu serwisowego ilustruje przejście od ryzyka do konkretnego działania, odpowiedzialności i sprawdzenia wyniku.
Opracowanie: Zespół redakcyjny CCyber
Załącznik A ISO/IEC 27001:2022 zawiera 93 zabezpieczenia uporządkowane w czterech grupach: organizacyjnej, dotyczącej ludzi, fizycznej i technologicznej. Jest katalogiem odniesienia przy sprawdzaniu, czy organizacja nie pominęła potrzebnej ochrony. Nie zastępuje oceny ryzyka ani całego systemu zarządzania bezpieczeństwem informacji.
Firma powinna ustalić, jakie zabezpieczenia są potrzebne w jej zakresie SZBI, uzasadnić wybór i wskazać stan wdrożenia. Decyzje zapisuje w deklaracji stosowania, czyli Statement of Applicability, w skrócie SoA. Następnie musi przełożyć je na działające procesy i rozwiązania.
Najważniejsze pytanie nie brzmi: „Ile pozycji zaznaczyliśmy?”. Brzmi: „Czy dobrane zabezpieczenia odpowiadają naszym potrzebom i czy potrafimy wykazać ich działanie?”.
19 września 2026 r.
Artykuł odnosi się do ISO/IEC 27001:2022 wraz z Amd 1:2024 oraz ISO/IEC 27002:2022. Punktem wyjścia jest poradnik Copla o Załączniku A. Zachowujemy podział na cztery grupy, natomiast numerację i zasady stosowania weryfikujemy w źródłach normatywnych oraz materiałach IAF.
Poniższe przykłady, kryteria odbioru i wzór rekordu są propozycją CCyber. Nie stanowią pełnego tekstu 93 zabezpieczeń ani oficjalnego tłumaczenia normy.
Dla osób wdrażających SZBI, kierowników IT, CISO, właścicieli procesów i zespołów przygotowujących organizację do certyfikacji. Szczególnie dla firm, które mają listę zabezpieczeń w arkuszu, ale nie potrafią jeszcze połączyć jej z ryzykami, odpowiedzialnością i rzeczywistym zakresem ochrony.
ISO/IEC 27001 określa wymagania wobec SZBI. Rozdziały 4-10 obejmują zarządzanie systemem, a nie tylko techniczne zabezpieczenia. Nie można ich wyłączać, deklarując zgodność z normą. Zakres wyjaśnia oficjalny opis ISO/IEC 27001 w IEC.
Załącznik A jest częścią ISO/IEC 27001. Pomaga porównać potrzebne zabezpieczenia z uporządkowanym katalogiem. Nie ogranicza organizacji do korzystania wyłącznie z tego katalogu.
ISO/IEC 27002 rozwija wskazówki dotyczące zabezpieczeń. Nie jest odrębnym standardem certyfikacji SZBI. Relację między dokumentami opisuje ISO.
W dokumentacji pilnuj pełnych oznaczeń. A.8.2 w Załączniku A odnosi się do uprawnień uprzywilejowanych. Rozdział 8.2 w głównej części ISO/IEC 27001 dotyczy innego zagadnienia. Pominięcie prefiksu i nazwy dokumentu może skierować zespół do niewłaściwego wymagania.
Podział i numerację można sprawdzić w publicznym podglądzie ISO/IEC 27002:2022. Przykłady zastosowania poniżej pokazują proponowany sposób pracy, nie pełną treść poszczególnych zabezpieczeń.
Zakres numeracji to A.5.1-A.5.37. Grupa obejmuje między innymi odpowiedzialność, zasady postępowania z informacją, dostawców, incydenty i ciągłość działania.
Przykład praktyczny: zanim firma kupi usługę chmurową, warto uzgodnić dopuszczalne dane, odpowiedzialność za dostęp i sposób zakończenia współpracy. Samo zatwierdzenie faktury nie dokumentuje tych ustaleń.
Pytanie do właściciela procesu: kto podejmuje decyzję i co potwierdza, że przyjęte zasady są realizowane?
Zakres numeracji to A.6.1-A.6.8. Grupa obejmuje relację organizacji z personelem, świadomość, pracę zdalną i zgłaszanie zdarzeń.
Przykład praktyczny: po szkoleniu pracownik powinien wiedzieć, jak zgłosić pomyłkowe wysłanie dokumentu. Lista obecności potwierdza udział, ale niekoniecznie umiejętność wykonania tej czynności.
Pytanie do HR i bezpieczeństwa: czy zasady są zrozumiałe także dla nowych osób i wykonawców zewnętrznych?
Zakres numeracji to A.7.1-A.7.14. Dotyczą miejsc, sprzętu, nośników i fizycznych warunków ochrony informacji.
Przykład praktyczny: przejście na pracę zdalną nie usuwa pytania o skradziony laptop, dokument pozostawiony w przestrzeni współdzielonej lub przekazanie nośnika do utylizacji.
Pytanie do organizacji: czy analizujemy rzeczywiste miejsca używania i przechowywania informacji, czy tylko adres siedziby?
Zakres numeracji to A.8.1-A.8.34. Grupa obejmuje między innymi dostęp, urządzenia, podatności, konfigurację, kopie, rejestrowanie zdarzeń, sieci i rozwój oprogramowania.
Przykład praktyczny: licencja na narzędzie ochronne nie mówi jeszcze, czy wszystkie istotne systemy są nim objęte i kto obsługuje wykryte problemy.
Pytanie do IT: jaki wynik techniczny i operacyjny potwierdzi, że zabezpieczenie działa w zadeklarowanym zakresie?
Materiał Copla wymaga korekty oznaczeń. Backup to A.8.13, a nie A.8.8. Z kolei A.6.8 dotyczy zgłaszania zdarzeń związanych z bezpieczeństwem informacji, nie uprawnień uprzywilejowanych. W dokumentacji roboczej sprawdzaj numer, nazwę i wydanie normy łącznie.
A.8.2 odnosi się do uprawnień uprzywilejowanych, a A.8.5 do bezpiecznego uwierzytelniania.
Nasza wskazówka: sprawdzaj osobno, czy użytkownik może potwierdzić swoją tożsamość i czy otrzymał właściwy zakres uprawnień. Poprawne logowanie nie uzasadnia nadania mu administracji całym środowiskiem.
A.8.8 dotyczy podatności technicznych, a A.8.9 zarządzania konfiguracją.
Nasza wskazówka: zestawiaj wyniki aktualizacji z przeglądem ustawień. Zainstalowana poprawka nie jest dowodem, że system ma właściwie ograniczony dostęp lub wyłączone zbędne funkcje.
A.8.15 dotyczy rejestrowania zdarzeń, a A.8.16 działań monitorujących.
Nasza wskazówka: potwierdź nie tylko istnienie zapisu, lecz także odbiorcę istotnego sygnału i sposób jego obsługi. Folder z logami nie odpowiada na pytanie, kto zauważy niepożądaną zmianę.
Szczegółowe przykłady pracy z kontami znajdziesz w kategorii Tożsamość, dostęp i bezpieczeństwo chmury.
Cel wyjaśnia, jaki efekt ma przynieść zabezpieczenie. Nie należy jednak traktować opisowej kolumny „Control Objective” z internetowego poradnika jako oficjalnego brzmienia normy.
IAF MD 26 wyjaśnia zmianę struktury: w ISO/IEC 27002:2022 cel opisuje się przy poszczególnym zabezpieczeniu, zamiast stosować wcześniejszy układ celów dla grup zabezpieczeń.
Rekomendujemy oddzielanie trzech pól: odwołania do normy, własnego sposobu realizacji i kryterium odbioru. Dzięki temu wewnętrzna procedura nie jest przedstawiana jako dosłowne wymaganie ISO.
Nie automatycznie, ale żadnej pozycji nie należy pominąć bez rozpatrzenia. Organizacja najpierw ustala potrzebne zabezpieczenia, a następnie porównuje je z Załącznikiem A, aby wychwycić ewentualne pominięcia. Rolę tego porównania potwierdza IAF.
Punktem wyjścia powinny być zakres SZBI, ryzyka i mające zastosowanie wymagania. Potrzebne mogą być również zabezpieczenia własne lub pochodzące z innych źródeł. Załącznik A nie jest maksymalnym dopuszczalnym zakresem ochrony.
Rekomendacja CCyber: nie używaj jednej kolumny do oznaczania, czy zabezpieczenie jest potrzebne i czy zostało wykonane. „Jeszcze nie wdrożyliśmy” nie znaczy „nie dotyczy”. Podobnie priorytet wdrożenia nie jest decyzją o wyłączeniu zabezpieczenia.
Wymaganie 6.1.3 d) ISO/IEC 27001 dotyczy dokumentu wskazującego potrzebne zabezpieczenia, powody ich uwzględnienia, stan wdrożenia oraz uzasadnienia wyłączeń z Załącznika A. Podstawę można sprawdzić w publicznym podglądzie tekstu normy.
SoA nie zastępuje planu postępowania z ryzykiem. Norma wymaga również zatwierdzenia tego planu i akceptacji ryzyk rezydualnych przez właścicieli ryzyka. Ryzyko rezydualne to ryzyko pozostające po uwzględnieniu przyjętego postępowania.
Poza wymaganym zakresem proponujemy powiązać rekord z właścicielem, systemami, procedurą, dowodami i otwartymi działaniami. Można prowadzić te dane w oddzielnych, połączonych rejestrach. Nie trzeba umieszczać całej dokumentacji w jednej komórce arkusza.
Ważne: szczegółowy opis wdrożenia, termin testu i odnośnik do zgłoszenia są praktycznymi rozszerzeniami proponowanego modelu. Nie przedstawiamy ich jako obowiązkowych nazw kolumn narzuconych przez ISO.
Uzasadnienie powinno wynikać z rzeczywistego zakresu i potrzeb ochrony. Nie wystarcza zdanie „nie mamy budżetu” albo „nikt dotychczas o to nie pytał”. Poniższe przykłady pokazują, jak weryfikować takie decyzje.
Sprawdź, co nadal pozostaje po stronie organizacji: urządzenia użytkowników, uprawnienia, konfiguracja usług i nadzór nad dostawcą. Zamiast wyłączać całą grupę, opisz podział wykonania i odpowiednie potwierdzenia.
Ustal, czy firma zamawia rozwój u dostawcy, utrzymuje własne integracje lub wprowadza istotne modyfikacje. Brak etatu programisty nie rozstrzyga jeszcze stosowalności zabezpieczeń związanych z wytwarzaniem.
Odróżnij brak zastosowania od realizacji zewnętrznej. W proponowanym rejestrze wskaż usługę, odpowiedzialność firmy oraz materiał potwierdzający zakres działania dostawcy. Nie zaznaczaj wdrożenia wyłącznie na podstawie ogólnego opisu marketingowego.
Przykład modelowy CCyber, nie opis konkretnego klienta. Firma korzysta z zewnętrznego serwisu aplikacji. Analiza wykazała, że uprawnienia serwisowe wymagają uporządkowania. Poniższy zapis pokazuje możliwy sposób połączenia SoA z wykonaniem.
Odwołanie: A.8.2, uprawnienia uprzywilejowane.
Uzasadnienie stosowania: serwisant może zmieniać konfigurację aplikacji i wpływać na dostępność usługi. Konieczne jest ograniczenie oraz nadzorowanie tego dostępu.
Zakres: wskazana aplikacja produkcyjna i konta zewnętrznych administratorów. Pozostałe systemy wymagają osobnej oceny.
Stan: zabezpieczenie potrzebne, wdrożenie częściowe. Uwierzytelnianie działa, lecz nie zakończono przeglądu zakresu uprawnień i zasad ich odbierania.
Proponowane działanie: ustalić potrzebne role, właściciela zatwierdzającego dostęp, warunki jego aktywacji i sposób zakończenia. Wykonać kontrolowane sprawdzenie na koncie testowym.
Kryterium odbioru: konto wykonuje uzgodnione zadania, nie może wykonać czynności poza zatwierdzonym zakresem, a po odebraniu uprawnień nie odzyskuje dostępu objętą testem ścieżką.
Dowody: decyzja właściciela, konfiguracja roli, zapis przeglądu i wynik testu. Materiały przechowuje się w zatwierdzonym repozytorium, bez haseł i sekretów.
Taki rekord może odwoływać się do działań dotyczących uwierzytelniania i logowania, ale nie oznacza automatycznego spełnienia wszystkich powiązanych zabezpieczeń.
Rekomendujemy rozdzielenie trzech perspektyw: zasad, konfiguracji i wykonanych czynności. Polityka pokazuje oczekiwany sposób działania. Konfiguracja pokazuje ustawienia. Raport z procesu lub testu pomaga potwierdzić wynik w określonym zakresie.
Przykład: zasada nakazuje przegląd uprawnień, system umożliwia wygenerowanie raportu, ale dopiero zakończony przegląd z decyzjami i wykonanymi zmianami pokazuje, że czynność rzeczywiście przeprowadzono.
Do projektowania sprawdzeń można pomocniczo wykorzystać NIST SP 800-53A. Jest to metodyka oceny zabezpieczeń, nie zamiennik wymagań ISO/IEC 27001 ani obowiązek przyjęcia całego katalogu NIST.
Każdy dowód powinien pozwalać ustalić zakres i datę. Nie przedstawiaj testu jednej aplikacji jako wyniku dla wszystkich systemów. Materiał zawierający wrażliwe konfiguracje udostępniaj wyłącznie uprawnionym odbiorcom.
Samo stwierdzenie „wdrożyliśmy 80 z 93 zabezpieczeń” nie wyjaśnia, czy dobór jest właściwy, które luki są istotne ani czy system zarządzania działa.
W raportowaniu proponujemy osobno pokazywać: decyzje o stosowalności wymagające uzupełnienia, potrzebne zabezpieczenia jeszcze niewdrożone, wdrożenia oczekujące na sprawdzenie i działania naprawcze po terminie.
Przy wskaźniku podaj jego znaczenie. „Udział sprawdzonych zabezpieczeń w wybranym zakresie” jest czymś innym niż „poziom zgodności całej firmy z ISO 27001”.
Najpierw uporządkuj podstawę: potwierdź wydanie normy, numery pozycji i zakres SZBI. Nie aktualizuj starego arkusza przez samą zmianę daty w nagłówku.
Następnie sprawdź uzasadnienia: wybierz kilka ryzyk i zobacz, czy prowadzą do konkretnych zabezpieczeń. Potem przejdź w drugą stronę i zapytaj, dlaczego dane zabezpieczenie jest potrzebne.
Na końcu zweryfikuj wykonanie: wybierz reprezentatywną usługę i porównaj deklaracje z jej rzeczywistym stanem. Zapisz braki, właścicieli i kryteria zamknięcia. Pilnych zagrożeń nie odkładaj do ukończenia całego rejestru.
W kategorii Regulacje cyber UE i zgodność rozwijamy zagadnienia wymagań i przygotowania dowodów. Przykłady dotyczące bezpieczeństwa produktów znajdziesz w obszarze Bezpieczne tworzenie oprogramowania i produktów cyfrowych.
Ten artykuł koncentruje się na doborze i realizacji zabezpieczeń Załącznika A. Nie jest pełnym harmonogramem certyfikacji ani oceną zgodności z konkretną ustawą.
Audyt gotowości do ISO/IEC 27001 w CCyber obejmuje identyfikację braków, priorytety, potrzebne polityki i procedury oraz etapowy plan wdrożenia.
Sprawdź, czy Twoja deklaracja stosowania odpowiada rzeczywistemu środowisku. Punktem wyjścia do ustalenia zakresu przeglądu mogą być obecna SoA, zakres SZBI i lista otwartych działań. Przegląd gotowości pomaga przygotować organizację, ale nie jest wydaniem certyfikatu przez jednostkę certyfikującą.
Nie. Jedna procedura może wspierać kilka zabezpieczeń, a pojedyncze zabezpieczenie może wymagać kilku procesów i konfiguracji. Dokumentację organizuj według sposobu działania firmy, zachowując możliwość wskazania właściwych odniesień.
Nie należy zaczynać od narzędzia. Do prowadzenia SoA można wykorzystać kontrolowany dokument lub rejestr. Ważne są spójność, wersjonowanie, uprawnienia i powiązanie z działaniami. Narzędzie nie podejmuje za organizację decyzji o stosowalności.
Nie, jeżeli zabezpieczenie jest potrzebne. Brak wdrożenia należy odzwierciedlić w jego statusie i planie działań. Uzasadnienie wyłączenia odpowiada na inne pytanie niż termin wykonania zadania.
Nie traktuj częstotliwości z internetowego poradnika jako automatycznego wymagania normy. Ustal potrzeby, role i sposób potwierdzania kompetencji oraz świadomości. Odrębny obowiązek częstotliwości może wynikać z innych wymagań dotyczących organizacji.
W Załączniku A ISO/IEC 27001:2022. Rozwinięcie wskazówek znajduje się w ISO/IEC 27002:2022. Korzystaj z właściwego wydania dostępnego przez ISO, IEC lub uprawnionego dystrybutora. Opisowe zestawienie z bloga nie zastępuje brzmienia normy.
Załącznik A pomaga uporządkować ochronę, ale wartość wdrożenia wynika z decyzji i działania. Poprawna numeracja to początek. Dalej potrzebne są uzasadnienie, właściwy zakres, odpowiedzialność i weryfikacja.
Dobra deklaracja stosowania łączy to, czego firma potrzebuje, z tym, co rzeczywiście robi. Nie ukrywa braków pod oznaczeniem „nie dotyczy” i nie przedstawia zakupionego narzędzia jako dowodu skuteczności.
Modelowanie zagrożeń w systemach wbudowanych: 5 kroków
Jak przeprowadzić modelowanie zagrożeń dla urządzenia, które łączy elektronikę, firmware i komunikację sieciową? Pokazujemy pięć etapów analizy, zastosowanie STRIDE oraz sposób zamiany zagrożeń w wymagania i testy. Przykład rejestratora temperatury obejmuje dostęp serwisowy, ochronę kluczy i aktualizacje oprogramowania. Wyjaśniamy również, dlaczego podpisany firmware nie rozwiązuje wszystkich problemów, CVSS nie zastępuje oceny ryzyka, a model zagrożeń trzeba aktualizować razem z produktem.
Opracowanie: Zespół redakcyjny CCyber
Modelowanie zagrożeń w systemach wbudowanych polega na analizie urządzenia i jego otoczenia z perspektywy możliwego nadużycia. Zespół ustala, co chroni, którędy można wpłynąć na działanie produktu, jakie skutki są istotne i które zabezpieczenia należy zaprojektować lub sprawdzić.
Nie wystarczy przeanalizować aplikacji komunikującej się z urządzeniem. W przykładzie embedded trzeba uwzględnić również firmware, pamięć, interfejsy serwisowe, aktualizacje i dostęp fizyczny. Wynikiem powinny być scenariusze zagrożeń, decyzje o ryzyku, wymagania oraz testy powiązane z konkretną wersją produktu.
19 września 2026 r.
Punktem wyjścia jest artykuł Sii o modelowaniu zagrożeń w systemach wbudowanych. Pięcioetapowy układ nawiązuje do tego materiału. Rozwinięcia techniczne oparto na wskazanych źródłach, a przykład urządzenia, pytania warsztatowe i karta zagrożenia są propozycją CCyber, nie opisem rzeczywistego klienta ani wykrytej podatności.
Dla producentów urządzeń, zespołów firmware i elektroniki, architektów, testerów oraz osób odpowiedzialnych za bezpieczeństwo produktu. Także dla integratorów i właścicieli rozwiązań przemysłowych, którzy chcą wiedzieć, o jakie założenia bezpieczeństwa zapytać dostawcę.
Artykuł koncentruje się na urządzeniu i jego cyklu życia. Ogólny poradnik „Threat modeling: praktyczny przewodnik dla zespołów produktowych” znajdziesz w kategorii Bezpieczne tworzenie oprogramowania i produktów cyfrowych.
Threat modeling to uporządkowana analiza tego, jak można naruszyć bezpieczeństwo systemu. Nie jest wyłącznie listą znanych błędów z baz podatności. Może dotyczyć projektu, który jeszcze nie został zaimplementowany.
OWASP opisuje modelowanie jako proces powtarzalny, obejmujący zrozumienie systemu, identyfikację zagrożeń, wybór reakcji i sprawdzenie wyników. Istotne są przepływy danych oraz granice zaufania, czyli miejsca, w których zmieniają się uprawnienia, kontrola lub założenia dotyczące źródła informacji.
Praktyczne rozróżnienie: zagrożeniem może być nieuprawniona zmiana konfiguracji urządzenia. Brak sprawdzenia uprawnień byłby możliwą słabością umożliwiającą taki scenariusz. To, czy słabość faktycznie występuje, wymaga sprawdzenia projektu lub implementacji.
W tym artykule systemem wbudowanym nazywamy elektronikę i oprogramowanie realizujące określoną funkcję urządzenia. Nie utożsamiamy automatycznie każdego takiego systemu z urządzeniem IoT albo elementem infrastruktury krytycznej.
W analizie urządzenia warto rozdzielić interfejsy sieciowe, lokalne i fizyczne. OWASP IoT Security Testing Guide uwzględnia osobno między innymi pamięć, firmware, mechanizm aktualizacji i różne rodzaje interfejsów. Sam przegląd panelu internetowego nie obejmuje całego tego zakresu.
Pytanie projektowe: czy zabezpieczenie nadal działa, gdy urządzenie trafia do serwisu, zostaje zresetowane albo pracuje bez połączenia z chmurą? Odpowiedź może wymagać zmian w sprzęcie, procedurze produkcji lub obsłudze, nie tylko poprawki w aplikacji.
Rekomendujemy wskazanie wersji sprzętu i firmware, funkcji urządzenia, sposobu użytkowania oraz analizowanego fragmentu. Przygotuj opis interfejsów, przechowywanych danych, aktualizacji i trybów serwisowych. Zapisz również rzeczywiste ograniczenia pamięci, zasilania i czasu reakcji.
Do pracy zaproś osoby znające elektronikę, oprogramowanie, testy i użytkowanie produktu. Właściciel produktu powinien uczestniczyć w ustalaniu priorytetów. Jeżeli urządzenie wpływa na bezpieczeństwo ludzi lub procesów, potrzebny jest również udział osoby odpowiedzialnej za ten obszar.
Takie podejście zespołowe i sprawdzanie założeń projektowych wspiera Microsoft w praktykach Secure by Design. Specjalista security może prowadzić analizę, ale nie zastąpi wiedzy konstruktorów o urządzeniu.
Przykładem będzie modelowy rejestrator temperatury, który zapisuje pomiary lokalnie, wysyła je do chmury i umożliwia aktualizację firmware. Ma również lokalny interfejs serwisowy. Zakładamy, że nie steruje maszyną i nie pełni funkcji zabezpieczenia bezpieczeństwa funkcjonalnego.
Wskaż funkcje, dane i właściwości produktu wymagające ochrony. W naszym przykładzie są to wiarygodność pomiarów, konfiguracja progów alarmowych, tożsamość urządzenia i możliwość bezpiecznego wznowienia pracy.
Uwzględnij otoczenie: operatora, serwisanta, usługę chmurową oraz system przygotowania i dostarczania aktualizacji. Nie każdy z tych elementów musi być szczegółowo analizowany podczas jednej sesji, ale zależności nie powinny znikać z modelu.
Rezultat etapu: uzgodniony zakres, lista chronionych elementów, wersje produktu i jawne wyłączenia. Zapis „analiza tylko komunikacji sieciowej” nie może później zostać przedstawiony jako pełny przegląd sprzętu.
Dla rejestratora opisz osobno przepływ pomiarów, zmian konfiguracji i aktualizacji. Wskaż procesy, pamięć trwałą, komponent startowy uruchamiający firmware oraz interfejs serwisowy.
Przykładowy przepływ danych: czujnik przekazuje pomiar do programu urządzenia, który zapisuje wynik i wysyła go do usługi chmurowej.
Przykładowy przepływ aktualizacji: pakiet z systemu dystrybucji trafia do urządzenia, przechodzi weryfikację i dopiero potem może zostać uruchomiony.
Przy każdym przejściu zapytaj, komu ufamy i co to zaufanie potwierdza. Fizyczne umieszczenie złącza wewnątrz obudowy nie jest samo w sobie mechanizmem sprawdzania uprawnień. Diagram powinien pokazywać także dostęp lokalny, a nie tylko połączenie z internetem.
Rezultat etapu: model przepływów z granicami zaufania i listą punktów wymagających sprawdzenia.
Rozdziel możliwości różnych osób: zdalnego użytkownika bez konta, serwisanta z ograniczonym dostępem i osoby mającej fizyczny dostęp do urządzenia. Nie zakładaj, że każdy atakujący od początku ma pełne uprawnienia.
W przykładzie można rozważyć podszycie się pod urządzenie, nieuprawnioną zmianę progów alarmowych albo instalację starszego firmware. Dla każdego scenariusza zapisz warunki, potrzebny dostęp i możliwy skutek.
Przykład zapisu: osoba mogąca rozpocząć aktualizację próbuje zainstalować wcześniej podpisaną wersję, która nie powinna być już dopuszczona do użycia. To hipoteza do sprawdzenia, nie stwierdzenie, że konkretny produkt jest podatny.
Rezultat etapu: scenariusze odnoszące się do modelu, a nie ogólna lista haseł takich jak „ransomware” lub „atak na sieć”.
Sprawdź wymagany dostęp, trudność wykonania, możliwość wykrycia oraz skutki dla pojedynczego urządzenia i całej grupy produktów. Zaznacz, które informacje są potwierdzone, a które pozostają założeniem.
W materiale Sii pojawia się CVSS. Doprecyzowanie z dokumentacji FIRST: wynik CVSS Base mierzy istotność podatności i nie powinien samodzielnie służyć do oceny ryzyka. Kontekst wdrożenia i zagrożeń wymaga dodatkowej analizy. Wyjaśnia to przewodnik CVSS v4.0.
W naszym przykładzie brak wpływu na sterowanie maszyną nie oznacza braku konsekwencji biznesowych. Nieprawidłowe pomiary mogą uniemożliwić wiarygodną ocenę warunków przechowywania. Tę konsekwencję należy ocenić w rzeczywistym zastosowaniu produktu.
Rezultat etapu: uzasadnione priorytety i wskazanie brakujących danych. Nie nadawaj pozornie precyzyjnej punktacji scenariuszowi, którego warunków nie rozumiesz.
Dla wybranych zagrożeń określ decyzję: zmiana projektu, ograniczenie funkcji, dodatkowe zabezpieczenie albo świadomie udokumentowane pozostawienie ryzyka przez uprawnionego właściciela. Każdej zmianie przypisz wykonawcę i kryterium odbioru.
W rejestratorze może to oznaczać ograniczenie interfejsu serwisowego, ochronę poświadczeń albo kontrolę wersji firmware. Dobór powinien wynikać ze scenariusza i możliwości platformy, nie z listy modnych technologii.
Przy firmware warto myśleć o ochronie przed nieuprawnioną zmianą, jej wykrywaniu oraz bezpiecznym odzyskiwaniu. Te trzy kierunki opisuje NIST SP 800-193.
Rezultat etapu: wymagania i testy powiązane z zagrożeniami. Sam wpis „zastosowano kryptografię” nie określa, co zostało zabezpieczone.
Sii wymienia STRIDE, DREAD, PASTA, TRIKE, VAST i OCTAVE. W naszym przykładzie wykorzystujemy STRIDE do porządkowania scenariuszy. Nie jest to wybór obowiązkowy dla każdego projektu.
Nazwy kategorii pochodzą z dokumentacji Microsoft. Poniższe pytania odnoszące je do rejestratora są propozycją CCyber.
Czy usługa chmurowa odróżni właściwy rejestrator od innego urządzenia przedstawiającego ten sam identyfikator? Jak potwierdzana jest tożsamość serwisanta i źródła aktualizacji?
Czy można zmienić zapisane pomiary, progi alarmowe lub pakiet firmware bez wykrycia? W którym miejscu kontrola integralności faktycznie wpływa na decyzję o przyjęciu danych?
Czy po zmianie konfiguracji można ustalić, kto ją wykonał i jaki był wynik? Co dzieje się z zapisem podczas pracy offline, resetu lub zapełnienia pamięci? Sam fakt istnienia logu nie rozstrzyga jego wiarygodności.
Czy diagnostyka albo odczyt pamięci ujawnia poświadczenia? Czy sekret uzyskany z jednego egzemplarza mógłby zostać wykorzystany wobec innych urządzeń?
Czy obsługa komunikacji może wyczerpać zasoby potrzebne do zbierania pomiarów? Jakie zachowanie ma być oczekiwane przy przeciążeniu lub utracie połączenia z chmurą?
Czy użytkownik uprawniony tylko do odczytu może zmieniać konfigurację albo instalować firmware? Czy tryb serwisowy pozwala ominąć ograniczenia stosowane podczas zwykłej pracy?
STRIDE nie daje gwarancji kompletności. Microsoft podkreśla potrzebę podważania założeń projektowych także poza samymi kategoriami. Dlatego pytanie „co się stanie, jeśli ta kontrola zawiedzie?” pozostaje częścią analizy.
Sprawdź, skąd pochodzą poświadczenia, kto nadaje je podczas produkcji i jak są zmieniane lub unieważniane. OWASP wskazuje ryzyka wynikające z sekretów zaszytych w firmware, w tym możliwość objęcia problemem wielu egzemplarzy i utrudnioną zmianę po ujawnieniu. Zobacz sekcję OWASP dotyczącą firmware.
W naszym przeglądzie warto dodać pytanie: co stanie się po wymianie urządzenia lub zmianie jego właściciela? Nie zakładaj, że reset zawsze usuwa wszystkie dane i uprawnienia.
Podpis pakietu, sprawdzenie podpisu i polityka dopuszczonych wersji rozwiązują różne problemy. Poprawnie podpisana starsza wersja nadal może być niepożądana. OWASP opisuje osobno weryfikację podpisu, autoryzację aktualizacji i ochronę przed cofnięciem wersji w katalogu testów mechanizmu aktualizacji.
W proponowanym projekcie trzeba też uzgodnić odzyskiwanie po przerwaniu aktualizacji. Ochrona przed powrotem do niebezpiecznej wersji nie powinna być projektowana bez analizy dostępnej, zaufanej ścieżki naprawy.
Przejrzyj osobno tryb produkcyjny, serwisowy i awaryjny. Dla każdego ustal dostępne funkcje, uprawnienia i możliwość zauważenia niepożądanej zmiany.
Katalog zdolności bezpieczeństwa urządzeń NIST rozdziela między innymi identyfikację, konfigurację, ochronę danych, kontrolę interfejsów i aktualizacje. To pomoc w doborze wymagań do urządzeń IoT, nie lista identycznych zabezpieczeń dla każdego produktu.
Przykład modelowy CCyber. Przyjmujemy, że zespół testuje rejestrator, a wcześniejsza wersja testowa zawiera znany błąd, którego nie wolno ponownie wprowadzić do urządzenia. Nie opisujemy rzeczywistej podatności konkretnego producenta.
Identyfikator i zakres: TM-UPDATE-01, wskazana rewizja sprzętu, wersja komponentu startowego i mechanizmu aktualizacji.
Chroniony element: integralność działającego oprogramowania oraz wiarygodność pomiarów.
Warunki scenariusza: osoba ma dostęp do funkcji aktualizacji oraz wcześniej podpisanego pakietu. Nie zakładamy przejęcia klucza podpisującego.
Niepożądany rezultat: uruchomienie wersji poniżej zatwierdzonego minimum bezpieczeństwa.
Proponowane wymaganie: standardowy mechanizm aktualizacji odrzuca taki pakiet także wtedy, gdy jego podpis jest poprawny. Zasady odzyskiwania awaryjnego są określone osobno i nie mogą stanowić niekontrolowanego obejścia.
Test: na egzemplarzu laboratoryjnym sprawdzić odrzucenie wycofanej wersji oraz poprawne przyjęcie wersji dopuszczonej. Zarejestrować wersję faktycznie uruchomioną po restarcie.
Dowód i odpowiedzialność: raport z identyfikatorem sprzętu i kompilacji, wynik testu, właściciel poprawki oraz osoba oceniająca pozostałe ryzyko.
To wzór do dopasowania. Testy naruszające normalne działanie wykonuj na uzgodnionym stanowisku, nie na urządzeniu obsługującym produkcję lub proces krytyczny.
Powiąż model z wersją architektury, sprzętu i oprogramowania. Przy zmianie sprawdź, czy powstał nowy interfejs, inny sposób uwierzytelniania, dodatkowy tryb serwisowy lub nowa zależność od dostawcy. Aktualizacji może wymagać również model po incydencie lub ujawnieniu istotnej podatności. Takie utrzymywanie analizy wraz z systemem opisuje OWASP.
Rekomendujemy rozdzielanie statusów: zidentyfikowane, zaplanowano zabezpieczenie, wdrożono oraz zweryfikowano. Dodatkowo oznaczaj scenariusze wymagające informacji i ryzyka formalnie pozostawione przez właściciela.
Przed wydaniem produktu sprawdź, czy istotne scenariusze mają decyzję i czy wymagane testy wykonano na właściwej konfiguracji. Nie uznawaj liczby zamkniętych wpisów za dowód pełnego bezpieczeństwa.
Do diagramów i rejestru można wykorzystać OWASP Threat Dragon. Narzędzie wspiera zapis modelu i zagrożeń, ale nie sprawdzi za zespół rzeczywistego działania interfejsu ani odporności elektroniki.
Weryfikację zakresu norm warto prowadzić oddzielnie od wyboru metody takiej jak STRIDE. Poniższe rozróżnienie opiera się na oficjalnych opisach, nie na analizie wszystkich wymagań norm.
IEC 62443-4-1 opisuje bezpieczny cykl rozwoju produktów dla automatyki i sterowania przemysłowego, w tym sprzętu, oprogramowania i firmware. Ta część dotyczy twórcy i podmiotu utrzymującego produkt. Nie należy automatycznie przenosić jej wszystkich wymagań na użytkownika urządzenia. Zakres podaje IEC.
ISO/SAE 21434 dotyczy inżynierii cyberbezpieczeństwa systemów elektrycznych i elektronicznych pojazdów drogowych. Nie jest uniwersalnym standardem dla każdego urządzenia embedded. Zakres wyjaśnia ISO.
CLC/TS 50701 odnosi się do cyberbezpieczeństwa zastosowań kolejowych i ich cyklu życia. Opis dostępny w BSI wskazuje również, że nie zastępuje wymagań bezpieczeństwa funkcjonalnego.
Sam diagram zagrożeń nie potwierdza zgodności z normą. Trzeba ustalić właściwy zakres, wymagane działania i dowody.
Model produktu warto połączyć z analizą środowiska, w którym urządzenie będzie pracować. Segmentację, zdalny serwis i zależności zakładu rozwijamy w kategorii Bezpieczeństwo OT, przemysłu i infrastruktury krytycznej.
Nie należy jednak traktować zabezpieczeń sieci klienta jako automatycznego zastępstwa dla ochrony samego urządzenia. Założenia dotyczące wdrożenia powinny być jawne i możliwe do sprawdzenia.
W ramach projektów i wdrożeń cyberbezpieczeństwa CCyber wspiera analizę ryzyka, bezpieczeństwo aplikacji, procesy bezpiecznego wytwarzania oraz środowiska OT.
Zacznij od jednej istotnej funkcji urządzenia. Do ustalenia zakresu wsparcia przygotuj opis produktu, interfejsów i zmian planowanych w najbliższym wydaniu. Pozwoli to określić potrzebny udział konstruktorów, zakres analizy i ewentualnych testów laboratoryjnych.
Brak internetu nie usuwa dostępu lokalnego, aktualizacji z nośnika ani interfejsów serwisowych. Zakres analizy może być inny, ale powinien wynikać z rzeczywistych możliwości oddziaływania na urządzenie.
Nie. Analiza pomaga zaplanować wymagania i scenariusze testowe. Nie dowodzi jednak, że implementacja działa zgodnie z projektem. Testy mogą ujawnić błędy lub założenia wymagające aktualizacji modelu.
Nie. STRIDE porządkuje rodzaje zagrożeń. Nadal trzeba ocenić warunki scenariusza, skutki i adekwatność zabezpieczeń. Liczba znalezionych kategorii nie jest miarą ryzyka.
Podpis pomaga sprawdzić pochodzenie i integralność pakietu, jeżeli jest poprawnie weryfikowany względem zaufanego klucza. Nie potwierdza braku błędów w kodzie ani dopuszczalności każdej starszej wersji.
Nie ma jednego czasu właściwego dla wszystkich urządzeń. Zależy on od zakresu, dokumentacji i złożoności. Zacznij od ograniczonej funkcji, a brakujące informacje potraktuj jako zadania. Jedno spotkanie nie musi zamknąć analizy całego produktu.
Modelowanie zagrożeń dla systemu wbudowanego powinno łączyć elektronikę, firmware, komunikację i sposób obsługi urządzenia. Pięć etapów prowadzi od zakresu i przepływów do scenariuszy, priorytetów oraz zabezpieczeń.
Najważniejszym wynikiem jest sprawdzalna decyzja projektowa. Zespół powinien wiedzieć, przed czym chroni produkt, jakie założenia przyjął i jak potwierdzi działanie zabezpieczeń. Taki model pozostaje użyteczny również przy kolejnej wersji urządzenia.
NIS2, DORA i RODO: jak połączyć wymagania bez dublowania pracy?
NIS2, DORA i RODO wymagają uporządkowanego podejścia do bezpieczeństwa, ale nie obejmują tych samych organizacji, danych i obowiązków. Wyjaśniamy, jak ustalić zakres regulacji, odróżnić obowiązek ustawowy od wymagania klienta i wykorzystać wspólne zabezpieczenia bez tworzenia trzech równoległych projektów. Pokazujemy również, czego nie wolno łączyć automatycznie: oceny ryzyka, rejestrów, terminów i zgłoszeń incydentów. Artykuł zawiera przykładową kartę wymagania oraz sposób uporządkowania odpowiedzialności i planu działań.
Opracowanie: Zespół redakcyjny CCyber
NIS2, DORA i RODO można obsługiwać w ramach spójnego programu bezpieczeństwa, ale nie za pomocą jednej, uniwersalnej deklaracji zgodności. Najpierw trzeba ustalić, które przepisy dotyczą organizacji i w jakiej roli. Następnie można połączyć pracę nad dostępem, odtwarzaniem, dostawcami, szkoleniami i reagowaniem na incydenty.
Osobno pozostają podstawy prawne, zakres poszczególnych obowiązków, wymagane rejestry i zasady przekazywania zgłoszeń. Raport z testu backupu może wspierać kilka ocen, lecz nie zastąpi analizy legalności przetwarzania danych ani rejestru informacji wymaganego przez DORA.
Praktyczny cel to jedno wykonanie właściwie zaprojektowanej czynności i wykorzystanie jej wyniku tam, gdzie rzeczywiście odpowiada wymaganiu. Nie chodzi o kopiowanie tego samego dokumentu do trzech folderów.
19 września 2026 r.
Artykuł rozwija temat wpływu regulacji unijnych na wymagania cyberbezpieczeństwa. Koncentruje się na ich wzajemnym uporządkowaniu, nie stanowi pełnego wykładu obowiązków RODO, DORA ani KSC. Proponowany model pracy i karta wymagania są rekomendacją CCyber, a nie urzędowym formularzem.
Dla zarządów, kierowników IT, CISO, osób odpowiedzialnych za zgodność, ochronę danych i zakupy. Szczególnie dla firm, w których różne zespoły zlecają podobne analizy, wysyłają dostawcom osobne ankiety i przygotowują raporty z tych samych zabezpieczeń.
Materiał przyda się także dostawcom IT i SaaS, którzy otrzymują od klientów wymagania opisane jako „NIS2”, „DORA” albo „RODO” i chcą poprawnie ustalić ich znaczenie.
NIS2 ustanawia wymagania dotyczące zarządzania ryzykiem cyberbezpieczeństwa w określonych sektorach. W Polsce praktyczną podstawą obowiązków jest ustawa o krajowym systemie cyberbezpieczeństwa, czyli KSC.
Podlegania nie ustala się wyłącznie na podstawie tego, czy firma korzysta z internetu lub przetwarza dane klientów. Znaczenie mają sektor, rodzaj działalności, wielkość i wyjątki. Zakres wyjaśniają Komisja Europejska oraz Ministerstwo Cyfryzacji w informacji o podmiotach objętych KSC.
Pytanie do organizacji: jakie usługi świadczymy i na jakiej podstawie uznajemy, że podlegamy określonym obowiązkom?
DORA dotyczy podmiotów finansowych określonych w rozporządzeniu, z uwzględnieniem wyłączeń i zasad proporcjonalności. Obejmuje między innymi zarządzanie ryzykiem ICT, incydenty, testowanie odporności i ryzyko związane z dostawcami technologii. ICT oznacza technologie informacyjno-komunikacyjne.
Odporność cyfrowa nie ogranicza się do ochrony przed hakerem. Istotne mogą być także awaria, błąd zmiany lub niedostępność dostawcy. Cel i obszary DORA opisuje Europejski Urząd Nadzoru Giełd i Papierów Wartościowych, ESMA.
Pytanie do organizacji: czy jesteśmy podmiotem finansowym objętym rozporządzeniem, czy dostawcą, wobec którego taki klient formułuje wymagania?
RODO, czyli GDPR, nie jest wyłącznie regulacją cyberbezpieczeństwa. Obejmuje również zasady przetwarzania danych i prawa osób. Firma powinna ustalić, czy dla konkretnego przetwarzania działa jako administrator, podmiot przetwarzający lub w innej właściwej roli.
Administrator określa cele i sposoby przetwarzania. Podmiot przetwarzający działa w jego imieniu. To nie jest to samo znaczenie słowa „administrator” co administrator systemów IT. Rozróżnienie wyjaśnia Europejska Rada Ochrony Danych.
Pytanie do organizacji: czyje dane przetwarzamy, w jakim celu i kto podejmuje decyzje o ich wykorzystaniu?
W określonym zakresie, ale nie jako uniwersalne wyłączenie z wszystkich przepisów KSC. Art. 4 NIS2 reguluje relację z sektorowymi aktami unijnymi. Art. 1 ust. 2 DORA wskazuje jego sektorowy charakter wobec NIS2 dla objętych nim podmiotów finansowych. Podstawę stanowią NIS2 oraz rozporządzenie DORA.
W Polsce trzeba dodatkowo odczytać art. 8i KSC, który przewiduje szczególne zasady dla sektora bankowości i infrastruktury rynków finansowych. Wyłącza stosowanie części przepisów, pozostawiając wskazane obowiązki.
W praktyce nie należy ani wdrażać dwóch identycznych programów bez sprawdzenia relacji przepisów, ani wpisywać „KSC nie dotyczy” wyłącznie dlatego, że organizacja realizuje DORA. Analiza powinna wskazywać konkretne obowiązki objęte wyłączeniem i te, które pozostają.
DORA wymaga określonych postanowień w umowach na usługi ICT. Obejmują one między innymi opis usługi, lokalizację przetwarzania, pomoc przy incydencie i możliwość odzyskania danych. Dla usług wspierających funkcje krytyczne lub istotne przewidziano dodatkowe wymagania. Wynikają one z art. 30 rozporządzenia.
Dlatego dostawca może otrzymać od banku wymagania dotyczące dostępności, testów, podwykonawców czy zakończenia współpracy. Nie czyni go to automatycznie podmiotem finansowym. Osobnym mechanizmem jest nadzór nad formalnie wyznaczonymi kluczowymi zewnętrznymi dostawcami ICT, opisany przez Europejski Urząd Nadzoru Bankowego.
Rekomendujemy oznaczanie wymagań w trzech kategoriach: obowiązek ustawowy firmy, zobowiązanie wobec klienta i dobrowolnie przyjęta praktyka. Każda kategoria może być ważna, ale wymaga innego uzasadnienia i sposobu zarządzania zmianą.
NIS2, DORA i art. 32 RODO mają obszary wspólne, takie jak zarządzanie ryzykiem, bezpieczeństwo dostępu, ciągłość i sprawdzanie zabezpieczeń. RODO wymaga jednak odniesienia ochrony do ryzyka dla osób. Ten kontekst podkreśla poradnik EROD o bezpieczeństwie danych osobowych.
Poniżej proponujemy model organizacyjny. Wspólne wykonanie nie oznacza, że każdy element ma identyczne wymagania we wszystkich trzech regulacjach.
Ustal wspólne identyfikatory usług, aplikacji, właścicieli i dostawców. Dzięki temu zespoły mogą pracować na tych samych informacjach zamiast ustalać od początku, kto utrzymuje daną aplikację.
Nie zastępuj jednak jednego rejestru drugim. Rejestr czynności przetwarzania, ewidencja zasobów i rejestr informacji DORA mają inne cele i zakres. EBA wyjaśnia, że rejestr informacji DORA obejmuje ustalenia umowne dotyczące usług ICT.
Rezultat: dane źródłowe są współdzielone, ale każde wymagane zestawienie zachowuje właściwą strukturę.
Przejęcie konta może jednocześnie zatrzymać usługę, ujawnić dane osób i naruszyć zobowiązanie wobec klienta. Opis zdarzenia może być wspólny, lecz jego konsekwencji nie należy sprowadzać do jednej kwoty utraconego przychodu.
Rekomendujemy osobno wskazywać wpływ na działalność, ciągłość usługi i prawa osób. Brak istotnej straty finansowej firmy nie przesądza o niskim ryzyku dla osoby, której dane ujawniono.
Rezultat: jedna analiza zdarzenia dostarcza informacji do kilku ocen, bez ukrywania różnic między nimi.
Kontrola dostępu, aktualizacje, backup i monitoring mogą wspierać różne wymagania. Dla każdego mechanizmu zapisz zakres systemów, właściciela, sposób działania i sposób weryfikacji.
Raportu potwierdzającego MFA dla pracowników biurowych nie przedstawiaj jako dowodu zabezpieczenia wszystkich kont administracyjnych. Podobnie test odtworzenia jednej aplikacji nie potwierdza automatycznie zdolności odzyskania całej usługi.
Rezultat: dowód jest używany wielokrotnie tylko tam, gdzie jego zakres odpowiada ocenianemu wymaganiu.
Rozmowę o bezpieczeństwie dostawcy można przeprowadzić wspólnie. Następnie oddziel ocenę techniczną od wymaganych klauzul umownych, zasad powierzenia danych i specyficznych wymagań klienta finansowego.
Podpisana umowa powierzenia nie potwierdza jakości odtwarzania. Raport z testu bezpieczeństwa nie zastępuje z kolei ustalenia, kto może korzystać z podwykonawców i co stanie się z danymi po zakończeniu usługi.
Rezultat: dostawca otrzymuje spójne pytania, a organizacja zachowuje odrębne decyzje wymagane dla poszczególnych obszarów.
Jeżeli kilka analiz wskazuje ten sam brak, utwórz jedno zadanie naprawcze i połącz je z odpowiednimi wymaganiami. Wskaż wykonawcę, termin, kryterium odbioru i osobę potwierdzającą wynik.
Szkolenia można organizować wspólnie na poziomie podstaw, a następnie uzupełniać modułami właściwymi dla ról. Osoba zgłaszająca podejrzaną wiadomość potrzebuje innego przygotowania niż osoba kwalifikująca naruszenie danych.
Rezultat: mniej podwójnego zlecania pracy, bez sztucznego zamykania kilku obowiązków jednym nieadekwatnym działaniem.
Dobrze zabezpieczona baza danych może nadal być wykorzystywana niezgodnie z prawem, na przykład poza właściwym celem lub bez odpowiedniej podstawy. Wspólny program cyber nie zastępuje realizacji praw osób i pozostałych obowiązków ochrony danych.
Zakres praw wyjaśnia poradnik EROD dotyczący praw osób. Nie każda taka sprawa wymaga zakupu narzędzia bezpieczeństwa. Często potrzebna jest poprawa procesu biznesowego.
Nie przechowuj wszystkich logów i kopii bezterminowo tylko dlatego, że kilka regulacji wymaga dokumentowania działań. Art. 5 RODO przewiduje minimalizację danych i ograniczenie przechowywania.
Okres ustal dla konkretnego rodzaju informacji, celu i mającego zastosowanie obowiązku. Wymaganie zachowania raportu z audytu nie oznacza automatycznie konieczności przechowywania bez końca wszystkich danych, które audyt obejmował.
Wpis do wykazu, raport dostawcy i certyfikat systemu zarządzania odpowiadają na różne pytania. Nie traktuj żadnego z nich jako automatycznego potwierdzenia pełnej zgodności z trzema regulacjami.
W rejestrze wymagań zachowaj również warunki, wyjątki i przepisy sektorowe. Samo zestawienie numerów artykułów obok nazwy zabezpieczenia nie potwierdza jeszcze ich spełnienia.
Rekomendujemy wspólny zapis zdarzenia i jedną oś czasu, ale odrębne decyzje o obowiązkach zgłoszeniowych. Nie oznacza to automatycznego wysyłania każdego incydentu do wszystkich instytucji.
Administrator zgłasza naruszenie właściwemu organowi bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin po jego stwierdzeniu, chyba że jest mało prawdopodobne, by skutkowało ryzykiem dla praw i wolności osób. Przy wysokim ryzyku należy ocenić również zawiadomienie osób.
Podmiot przetwarzający informuje administratora bez zbędnej zwłoki. Nie powinien zakładać, że zawsze ma na to własne 72 godziny. Dokumentować trzeba także naruszenia niewymagające zgłoszenia organowi. Zasady opisuje EROD w przewodniku o naruszeniach danych.
Trzeba sprawdzić wpływ zdarzenia na usługi, status podmiotu, właściwy reżim i okres przejściowy. Nowy model KSC przewiduje etapowe przekazywanie informacji, a nie jeden uniwersalny raport dla każdej organizacji.
Próg istotności incydentu nie powinien być automatycznie kopiowany z oceny ryzyka dla osób w RODO. Podstawę stanowią właściwe przepisy ustawy o KSC.
Podmiot finansowy ocenia poważny incydent związany z ICT według właściwych kryteriów DORA. Nie należy przenosić do jego procedury terminu 72 godzin z RODO jako jedynego obowiązku zgłoszeniowego.
Dla podmiotów raportujących do KNF urząd wskazuje System do Obsługi Incydentów DORA oraz tryb awaryjny. Aktualną instrukcję zawiera strona KNF dotycząca incydentów DORA.
Do każdej ścieżki przypisz przesłankę, moment rozpoczęcia biegu terminu, odbiorcę i osobę odpowiedzialną. Wspólne narzędzie do obsługi zdarzeń nie znosi różnic prawnych. Przykłady ćwiczeń rozwijamy w kategorii Reagowanie na incydenty i ciągłość działania.
Przykład modelowy, nie opis konkretnego klienta. Firma świadczy bankowi usługi administracji systemami. Przyjmijmy, że odrębna analiza potwierdziła jej status podmiotu ważnego KSC. W części operacji przetwarza dane osobowe w imieniu klienta.
Firma ma zatem własne obowiązki KSC, obowiązki podmiotu przetwarzającego i zobowiązania umowne wobec banku. Sam kontrakt nie zmienia jej w podmiot finansowy objęty pełnym zakresem DORA.
Po przejęciu konta serwisowego zespół może prowadzić jedno postępowanie techniczne: zabezpieczyć logi, ustalić zakres dostępu i ograniczyć skutki. Równolegle firma ocenia własne zgłoszenie KSC, informuje administratora danych i przekazuje bankowi informacje potrzebne do jego oceny DORA.
Wspólna jest analiza zdarzenia. Różne pozostają role i decyzje o zgłoszeniach. Nie należy ani czekać na zakończenie analizy banku, aby wykonać własny obowiązek, ani bez podstawy zgłaszać wszystko w imieniu klienta.
Poniższy wzór jest propozycją organizacyjną. Pomaga połączyć wymaganie z wykonaniem bez utraty informacji o jego źródle.
Podmiot i rola: której spółki, usługi i roli prawnej dotyczy zapis?
Źródło: konkretny przepis, postanowienie umowne albo zatwierdzona zasada wewnętrzna.
Wymagany rezultat: co musi być wykonane i w jakim zakresie?
Wspólne działanie: który proces lub mechanizm realizuje wymaganie i jakie inne obowiązki wspiera?
Odpowiedzialność: kto podejmuje decyzję, kto wykonuje pracę i kto sprawdza wynik?
Termin i dowód: od jakiego zdarzenia liczymy termin, gdzie znajduje się potwierdzenie i kiedy trzeba je odnowić?
Różnice i ograniczenia: czego dowód nie obejmuje, jakie wyjątki pozostają i które działania należy wykonać osobno?
Przykładowo jedno zadanie usunięcia zbędnego dostępu może wspierać kilka wymagań. Nie oznacza jednak, że zamknięcie tego zadania potwierdza całą zgodność aplikacji z RODO, KSC lub wymaganiami banku.
Przygotuj krótką analizę dla poszczególnych spółek, usług i ról. Zidentyfikuj również obowiązki już realizowane, a nie tylko te planowane na przyszłość.
RODO stosuje się od 25 maja 2018 r., a DORA od 17 stycznia 2025 r. Nie należy odkładać wynikających z nich działań do zakończenia projektu KSC.
Dla organizacji spełniających kryteria w dniu wejścia w życie nowelizacji KSC właściwy harmonogram przewiduje wdrożenie obowiązków do 3 kwietnia 2027 r. Podmioty zobowiązane do samorejestracji w okresie przejściowym mają termin 3 października 2026 r. Sprawdź harmonogram Ministerstwa Cyfryzacji oraz zasady samorejestracji.
Porównaj otwarte działania i sprawdź, czy dwa zespoły nie planują tej samej konfiguracji, ankiety albo testu. Uzgodnij jedno wykonanie oraz wymagania wszystkich odbiorców wyniku.
Nie łącz zadań, gdy mają różny zakres lub cel. Ocena skutków dla ochrony danych nie jest automatycznie tym samym co analiza wpływu przestoju na biznes.
Wybierz jedną ważną usługę i przejdź przez dostęp, dostawcę, odtwarzanie oraz incydent. Zweryfikuj, czy każdy zespół otrzymuje informacje potrzebne do wykonania swoich obowiązków.
Dopiero potem rozszerz model na kolejne usługi. Nie uznawaj pozytywnego wyniku pilotażu za potwierdzenie zgodności całej organizacji.
Rekomendujemy sponsora po stronie kierownictwa i koordynatora pracy między IT, bezpieczeństwem, zakupami oraz zgodnością. Właściciele usług powinni uczestniczyć w decyzjach o priorytetach i odbiorze wyników.
Inspektor ochrony danych, jeżeli został wyznaczony, doradza i monitoruje zgodność w zakresie swojej funkcji. Nie należy automatycznie czynić go właścicielem wszystkich decyzji o przetwarzaniu. Art. 38-39 RODO wymagają uwzględnienia niezależności i konfliktu interesów.
Nie utożsamiaj więc „jednego programu” z „jedną osobą odpowiedzialną za wszystko”. Model ma ułatwiać współpracę, a nie usuwać niezbędny podział ról.
Szczegółowe poradniki znajdziesz w kategorii Regulacje cyber UE i zgodność. Tematy odpowiedzialności i raportowania do kierownictwa rozwijamy w obszarze Ryzyko cyber, governance i vCISO.
Ten artykuł pomaga zaprojektować współpracę między obszarami. Nie zastępuje szczegółowej analizy konkretnego obowiązku.
W ramach wsparcia zgodności z regulacjami UE CCyber pomaga w analizie luk, przygotowaniu polityk i procedur, mapowaniu odpowiedzialności oraz planowaniu kontroli i dowodów.
Sprawdź, które prace można połączyć, a które wymagają osobnej realizacji. Punktem wyjścia może być obecny rejestr wymagań, lista usług i otwarte zadania. Celem jest jeden uzgodniony plan działań z zachowaniem właściwych różnic prawnych.
Nie. Zakres każdej regulacji ustala się osobno. Przetwarzanie danych osobowych nie oznacza automatycznie podlegania DORA lub KSC. Podobnie dostarczanie usług bankowi nie nadaje automatycznie statusu podmiotu finansowego.
Można przyjąć wspólną politykę nadrzędną, jeżeli jej zakres jest właściwy. Potrzebne mogą pozostać odrębne procedury i rejestry. Liczba dokumentów nie jest miarą zgodności, liczy się objęcie wszystkich właściwych obowiązków.
Nie. Wymagania mogą dotyczyć innych danych, podmiotów i celów. Dłuższa retencja nie zawsze jest prawidłowa, a bardziej restrykcyjny dostęp nie zastępuje podstawy przetwarzania. Najpierw trzeba ustalić, do czego odnosi się wymaganie.
Jeden projekt audytowy może obejmować kilka zestawów kryteriów, ale musi rozdzielać ich zakres i wyniki. Trzeba także spełnić właściwe wymagania dotyczące wykonawcy i niezależności. Ogólny raport techniczny nie staje się automatycznie audytem ustawowym.
Może ograniczyć powielanie analiz i zadań. Nie ma jednak gwarantowanego poziomu oszczędności. W pierwszej kolejności warto zmierzyć liczbę dublowanych prac, czas dostarczania dowodów i liczbę obowiązków bez właściciela.
NIS2, DORA i RODO wymagają spojrzenia na bezpieczeństwo z różnych perspektyw: działania usług, odporności podmiotów finansowych i ochrony osób. Wiele czynności można wykonywać wspólnie, ale ich znaczenie prawne trzeba oceniać osobno.
Najlepszy punkt wyjścia to nie trzy nowe projekty, lecz jedna mapa: podmiot, obowiązek, proces, właściciel i dowód. Dzięki niej organizacja może ograniczyć podwójną pracę bez pomijania wymagań, które rzeczywiście ją dotyczą.
Jak wejść do cyberbezpieczeństwa? Plan nauki i pierwszej pracy
Przebranżowienie do cyberbezpieczeństwa warto zacząć od wyboru konkretnych zadań, nie od kupowania kolejnych kursów. Pokazujemy trzy kierunki: GRC, zarządzanie dostępem oraz analizę zdarzeń w SOC. Artykuł zawiera plan nauki na sześć miesięcy, przykłady projektów do portfolio, wskazówki dotyczące certyfikatów i przygotowania CV. Wyjaśniamy również, jak wykorzystać wcześniejsze doświadczenie oraz czytać dane o zarobkach juniorów. To plan przygotowania do pierwszych rekrutacji, nie gwarancja zatrudnienia w określonym terminie.
Opracowanie: Zespół redakcyjny CCyber
Aby wejść do cyberbezpieczeństwa po zmianie branży, wybierz konkretny kierunek, opanuj podstawy IT i przygotuj przykłady pracy odpowiadające zadaniom na danym stanowisku. Następnie porównaj swoje umiejętności z ofertami i rozpocznij dopasowane rekrutacje. Samo ukończenie kursu lub zdanie egzaminu nie zastępuje umiejętności wyjaśnienia, co zrobiono, dlaczego i z jakim wynikiem.
Nie musisz od początku uczyć się wszystkich obszarów. Możesz sprawdzić, czy bliższa jest Ci analiza ryzyka i wymagań, zarządzanie dostępem czy badanie alertów bezpieczeństwa. Wcześniejsze doświadczenie w procesach, obsłudze użytkowników, finansach lub administracji IT może pomóc, ale wymaga uzupełnienia wiedzą właściwą dla wybranej roli.
19 września 2026 r.
Plan nauki i zadania do portfolio są autorską propozycją CCyber. Nie są wynikiem badania czasu potrzebnego do znalezienia pracy. Dane o wynagrodzeniach pochodzą z raportu Just Join IT 2026 dotyczącego ogłoszeń z 2025 r. Wymagania certyfikacyjne sprawdzono w źródłach organizacji wydających certyfikaty.
Dla osób zmieniających branżę, pracowników IT rozważających specjalizację w bezpieczeństwie oraz kandydatów, którzy rozpoczęli naukę, ale nie wiedzą, co umieścić w portfolio. Szczególnie dla osób uczących się obok obecnej pracy i potrzebujących planu z konkretnymi rezultatami.
Zamiast pytać wyłącznie „jak zostać specjalistą cyber?”, sprawdź, jakie problemy chcesz rozwiązywać. Czy interesuje Cię ocena ryzyka? Ustalanie, kto powinien mieć dostęp do danych? A może analiza zdarzenia i odróżnienie pomyłki użytkownika od podejrzanej aktywności?
Europejskie ramy kompetencji ENISA opisują różne profile zawodowe. Z kolei NIST NICE łączy role z zadaniami, wiedzą i umiejętnościami. Role w takim frameworku nie są jednak gotowym katalogiem stanowisk juniorskich.
Pierwsze ćwiczenie: zbierz około dziesięciu aktualnych ogłoszeń dla początkujących w interesującym Cię obszarze. Wypisz powtarzające się zadania, wymagania obowiązkowe i umiejętności dodatkowe. Sprawdź również język pracy, lokalizację, ewentualne dyżury oraz dostępność wsparcia bardziej doświadczonych osób.
To rozpoznanie na potrzeby własnego planu, nie reprezentatywne badanie rynku. Aktualizuj je podczas nauki.
Poniższe ścieżki są propozycją do sprawdzenia, a nie rankingiem łatwości wejścia. Dostępność stanowisk i zakres odpowiedzialności trzeba zweryfikować w konkretnych ofertach.
GRC oznacza governance, risk and compliance, czyli zarządzanie, ryzyko i zgodność. W tym kierunku warto rozwijać analizę procesów, ocenę ryzyka, pracę z wymaganiami oraz sprawdzanie dowodów wykonania zabezpieczeń.
Doświadczenie w audycie, jakości, finansach, zakupach lub analizie biznesowej może stanowić punkt zaczepienia. Nie oznacza to jednak, że GRC jest pracą bez wiedzy technicznej. Trzeba rozumieć systemy na tyle, aby nie pomylić deklaracji dostawcy z dowodem działania.
Sprawdź ten kierunek, przygotowując krótką ocenę ryzyka fikcyjnej usługi i uzasadniony plan działań. Nie zaczynaj od produkowania kilkudziesięciu polityk.
IAM, czyli identity and access management, dotyczy między innymi nadawania, zmiany i odbierania dostępu. Przykładowe zadania do poznania to obsługa wniosków, kontrola uprawnień po zmianie stanowiska i przegląd kont osób, które zakończyły współpracę.
To kierunek wart sprawdzenia przez osoby znające obsługę użytkowników, procesy HR, administrację aplikacjami lub analizę danych. Zakres stanowisk jest zróżnicowany: obsługa procesu dostępowego nie jest tym samym co projektowanie złożonej platformy IAM.
Sprawdź ten kierunek, analizując fikcyjny rejestr kont i przygotowując uzasadnione decyzje o uprawnieniach. Dalsze materiały znajdziesz w kategorii Tożsamość, dostęp i bezpieczeństwo chmury.
SOC to zespół operacji bezpieczeństwa. W przygotowaniu do roli analitycznej skup się na odczytywaniu logów, budowaniu osi czasu, weryfikowaniu hipotez i przekazywaniu spraw wymagających dalszej analizy.
Doświadczenie w rozwiązywaniu problemów technicznych i pracy ze zgłoszeniami może być przydatne. Sprawdź jednak, czy wybrane stanowisko obejmuje pracę zmianową i jakie decyzje początkujący analityk podejmuje samodzielnie.
Sprawdź ten kierunek, analizując treningowy zestaw zdarzeń i pisząc krótkie zgłoszenie do kolejnej linii wsparcia. Sam alert nie powinien automatycznie stawać się w Twoim raporcie potwierdzonym atakiem.
To nie wszystkie możliwości. Przy doświadczeniu programistycznym, chmurowym albo przemysłowym warto zbadać również bezpieczeństwo aplikacji, chmury lub OT. Nie trzeba jednak rozpoczynać nauki wszystkich tych specjalizacji jednocześnie.
W badaniu ISC2 opublikowanym w 2025 r. menedżerowie wskazywali pozyskiwanie kandydatów także spoza typowych kierunków IT oraz znaczenie myślenia analitycznego, współpracy i rozwiązywania problemów. Badanie objęło 929 menedżerów z sześciu krajów i nie obejmowało Polski. To kontekst dotyczący rekrutacji, nie dowód, że każda polska firma stosuje takie same kryteria. Szczegóły zawiera raport ISC2 o zatrudnianiu osób początkujących.
W CV pokaż związek doświadczenia z zadaniem. Przykładowo: analizowanie rozbieżności, prowadzenie dokumentacji, obsługa zgłoszeń, uzgadnianie odpowiedzialności lub sprawdzanie wykonania procedur.
Nie przemianowuj całego stażu zawodowego na doświadczenie w cyberbezpieczeństwie. Rozdziel dotychczasową pracę, nowe umiejętności i projekty edukacyjne.
Przygotuj się do wyjaśnienia, jak komputer łączy się z usługą, do czego służy DNS, czym różnią się konto użytkownika i administratora oraz gdzie można znaleźć zapis zdarzenia. Poznaj podstawy Windows i Linux, uprawnienia do plików oraz różnicę między usługą chmurową a własnym serwerem.
Nie chodzi o pamięciowe opanowanie wszystkich protokołów. Powinieneś umieć zastosować podstawy do prostego problemu i wskazać, czego jeszcze nie wiesz.
Rozróżniaj uwierzytelnianie od autoryzacji, zagrożenie od podatności i backup od synchronizacji. Ćwicz powiązanie braku zabezpieczenia ze skutkiem dla użytkownika lub firmy.
Jako punkt startowy do zrozumienia organizacyjnej strony bezpieczeństwa wykorzystaj przewodnik NIST CSF 2.0 dla małych organizacji. Nie musisz od razu projektować kompletnego systemu zarządzania.
Włącz do nauki czytanie krótkich fragmentów dokumentacji i opisywanie wyniku ćwiczenia po angielsku. Celem praktycznym może być zrozumienie instrukcji i napisanie zgłoszenia, a nie perfekcyjny akcent.
Przy każdym zadaniu zapisuj cel, źródła, wykonane kroki, wynik i ograniczenia. Ta dokumentacja później stanie się podstawą portfolio.
Założenie robocze: 6-8 godzin tygodniowo obok obecnej pracy. To propozycja organizacji nauki, nie potwierdzony czas osiągnięcia gotowości zawodowej. Osoba bez podstaw IT może potrzebować dłuższego etapu wstępnego. Administrator z doświadczeniem może przejść część materiału szybciej.
Przykładowy tydzień ośmiogodzinny to dwie godziny podstaw, cztery godziny ćwiczeń, godzina dokumentacji i godzina angielskiego lub przeglądu ofert. Proporcje dostosuj do największej luki.
Przejrzyj oferty, oceń podstawy i wykonaj dwa niewielkie zadania z różnych ścieżek. Zobacz, które sprawia Ci większą satysfakcję i gdzie potrafisz logicznie wyjaśnić wynik.
Rezultat: wybrany kierunek, lista brakujących umiejętności oraz realny tygodniowy plan. Przed większym wydatkiem na kurs sprawdź, czy odpowiada Ci sama praca nad zadaniami.
Pracuj na własnym, odizolowanym laboratorium lub przygotowanym środowisku szkoleniowym. Przećwicz konta, role, logi i odzyskiwanie testowych danych. Nie ograniczaj nauki do oglądania materiałów.
Rezultat: krótkie notatki z wykonanych ćwiczeń i możliwość odtworzenia podstawowego zadania bez kopiowania instrukcji krok po kroku.
Wybierz jeden z projektów opisanych poniżej. Ustal zakres, dane wejściowe i kryterium zakończenia. Przygotuj pierwszą wersję raportu i poproś kompetentną osobę o wskazanie błędów w rozumowaniu.
Rezultat: projekt z opisanymi decyzjami i ograniczeniami, nie tylko zrzutami ekranu.
Popraw pierwszy projekt i wykonaj drugi, powiązany z wybraną rolą. Dodaj trudniejszy wariant: brakujące dane, niejednoznaczne zdarzenie albo wyjątek wymagający decyzji.
Przygotuj CV pod konkretne zadania. Gdy potrafisz już wykonać podstawowe czynności i wyjaśnić projekty, rozpocznij dopasowane aplikacje. Nie musisz czekać do ostatniego miesiąca planu.
Przećwicz prezentację projektu, pytania o podstawy oraz odpowiedź „nie wiem, sprawdziłbym to w następujący sposób”. Analizuj otrzymany feedback i aktualizuj listę braków.
Rezultat: lepsze dopasowanie do wybranych stanowisk i plan dalszej nauki. Upływ sześciu miesięcy nie jest automatycznym potwierdzeniem gotowości ani terminem otrzymania oferty.
Wybierz jeden projekt główny i drugie, uzupełniające zadanie w tej samej ścieżce. Nie musisz realizować wszystkich trzech propozycji.
Opisz modelową firmę usługową korzystającą z poczty i aplikacji chmurowych. Przygotuj pięć scenariuszy ryzyka, wskaż istniejące zabezpieczenia, braki informacji i trzy działania priorytetowe.
Co pokazać: krótki rejestr ryzyk, uzasadnienie priorytetów i jednostronicową notatkę dla kierownictwa. Wyraźnie odróżnij przyjęte założenia od zweryfikowanych faktów.
Jak sprawdzić jakość: inna osoba powinna rozumieć, dlaczego dany problem jest ważny, kto powinien działać i jaki dowód potwierdziłby poprawę. Nie przedstawiaj ćwiczenia jako rzeczywistego audytu zgodności.
Przygotuj fikcyjny rejestr 20 użytkowników, kilku ról i dwóch aplikacji. Dodaj odejście pracownika, zmianę działu oraz konto bez właściciela. Zaproponuj, co należy utrzymać, zmienić lub przekazać do wyjaśnienia.
Co pokazać: reguły decyzyjne, listę rozbieżności, projekt procesu akceptacji i opis weryfikacji odebrania dostępu. Arkusz może wystarczyć do analizy, ale sam nie dowodzi wdrożenia technicznego.
Jak sprawdzić jakość: każda rekomendacja powinna mieć uzasadnienie. Nie usuwaj automatycznie konta tylko dlatego, że wygląda nietypowo. Najpierw ustal jego rolę i zależności.
Wykorzystaj syntetyczne logi albo materiały treningowe dopuszczone do takiego użycia. Zbuduj oś czasu, wskaż nietypowe zdarzenia i co najmniej dwie możliwe interpretacje. Określ, jakie dodatkowe informacje pomogłyby je rozstrzygnąć.
Co pokazać: krótkie zgłoszenie analityczne, wykorzystane filtry lub zapytania, rozdzielenie obserwacji od hipotez i uzasadnienie eskalacji.
Jak sprawdzić jakość: odbiorca powinien umieć odtworzyć tok analizy. Liczba alertów ani użycie znanego narzędzia nie zastępują poprawnego wniosku.
Do poznania zadań zawodowych można wykorzystać narzędzia i mikroćwiczenia opisane przez CISA w zasobach rozwoju kariery. Traktuj je jako okazję do sprawdzenia rodzaju pracy, nie jako pełne przygotowanie do stanowiska.
Do podstaw bezpieczeństwa, zgodności i tożsamości w środowisku Microsoft przyda się ścieżka szkoleniowa SC-900. Jest skoncentrowana na ekosystemie Microsoft i zakłada podstawową orientację w IT, sieciach i chmurze.
Zasada pracy: ćwicz wyłącznie w środowisku, do którego masz odpowiednie uprawnienia. Nie skanuj przypadkowych firm, nie używaj dokumentów obecnego pracodawcy i nie publikuj rzeczywistych danych dostępowych. Przy usługach chmurowych sprawdzaj również koszty laboratorium.
AI może pomagać tłumaczyć pojęcia i proponować pytania do powtórki. Wyniki sprawdzaj w dokumentacji i ćwiczeniach. Nie oddawaj jako własnej analizy materiału, którego nie potrafisz objaśnić.
ISC2 Certified in Cybersecurity, czyli CC, nie wymaga wcześniejszego doświadczenia zawodowego. Może być punktem odniesienia dla nauki podstaw. Warunki opisuje oficjalna strona certyfikacji CC.
Microsoft SC-900 dotyczy podstaw bezpieczeństwa, zgodności i tożsamości w usługach Microsoft. Ma sens jako opcja do rozważenia, gdy ten ekosystem pojawia się w Twoim planie nauki lub ofertach. Zakres określa oficjalny opis certyfikacji.
Nie musisz zdobywać obu certyfikatów. Przed zakupem sprawdź aktualny program, cenę w swoim regionie, zasady ponownego podejścia i utrzymania kwalifikacji. Odróżniaj potwierdzenie ukończenia kursu od uzyskania certyfikacji na zasadach jej wydawcy.
Certyfikat uzupełnia portfolio. Nie powinien być sposobem na odkładanie ćwiczeń i aplikowania.
W raporcie Just Join IT 2026, opartym na ogłoszeniach z 2025 r., dla poziomu junior w kategorii Security podano 7 500 zł miesięcznie brutto na umowie o pracę oraz 12 844 zł miesięcznie netto na fakturze B2B, bez VAT. Dane pochodzą z zestawienia kategorii Security.
Według metodologii raportu wartości dla poziomów doświadczenia są medianami środków widełek z analizowanych ogłoszeń. Nie są gwarantowaną wypłatą dla osoby bez doświadczenia. To dane historyczne z jednego portalu, nie bieżący cennik wszystkich polskich pracodawców.
Kwota netto na fakturze B2B nie jest wynagrodzeniem „na rękę”. Nie porównuj jej bezpośrednio z wypłatą pracownika. Są to również różne zbiory ofert, nie wycena tej samej pracy w dwóch formach zatrudnienia.
Planując zmianę branży, sprawdź aktualne oferty dla swojej roli, poziomu i lokalizacji. Nie opieraj decyzji o kosztownym szkoleniu na najwyższej stawce znalezionej w raporcie.
Wydziel sekcję „Projekty edukacyjne”. Przy każdym wpisz problem, zakres własnej pracy, rezultat i odnośnik do bezpiecznie opublikowanego materiału. Portfolio może mieć formę repozytorium albo uporządkowanych dokumentów. GRC nie wymaga udawania projektu programistycznego.
Przykładowy zapis: „Projekt edukacyjny IAM: przygotowanie modelowego rejestru 20 kont, identyfikacja rozbieżności po zmianach ról i opracowanie procesu odbierania dostępu. Dane syntetyczne, bez wdrożenia produkcyjnego”.
Na rozmowie wyjaśnij, jakich danych brakowało, co zmieniłbyś po dodatkowej informacji i które działania wymagałyby akceptacji. To pokazuje więcej niż samo odczytanie gotowego raportu.
Rozważ także staż, rolę asystencką lub uzgodnione zadania w obecnej organizacji. Przejście przez wsparcie IT albo obsługę dostępów może być elementem Twojego planu, ale nie daje automatycznego awansu do security. Sprawdzaj realny zakres nauki i opieki.
Dobrym punktem kontrolnym jest możliwość samodzielnego wyjaśnienia podstaw oraz wykonania i obrony prostego zadania właściwego dla stanowiska. Powinieneś rozumieć ograniczenia swojego rozwiązania i wiedzieć, kiedy potrzebujesz pomocy.
Nie czekaj na znajomość każdego narzędzia z ogłoszenia. Rozróżnij wymagania obowiązkowe od dodatkowych. Jednocześnie nie wpisuj umiejętności, których nie potrafisz zademonstrować.
Jeżeli aplikacje nie prowadzą do rozmów, sprawdź dopasowanie stanowisk i CV. Jeżeli trudność pojawia się w zadaniach, wróć do wskazanych podstaw. Traktuj to jako hipotezy do sprawdzenia, a nie automatyczną diagnozę przyczyny odrzucenia.
Przed zapisem zapytaj o wymagany poziom wejściowy, tygodniowy nakład pracy i konkretne zadania. Ustal, kto sprawdza projekty, jak wygląda informacja zwrotna i co dokładnie oznacza wsparcie rekrutacyjne.
Sprawdź całkowity koszt, ewentualne opłaty za egzaminy i laboratoria oraz zasady udziału. Jeżeli organizator podaje wskaźnik zatrudnienia absolwentów, zapytaj o okres pomiaru, liczbę uczestników i definicję zatrudnienia w branży.
Wybieraj program odpowiadający roli, do której się przygotowujesz. Duża liczba modułów nie pomoże, gdy zabraknie czasu na samodzielne ćwiczenia i poprawianie błędów.
Podstawy rozwijamy w kategorii Szkolenia i cyberświadomość. Materiał o kompetencjach przyszłości daje szerszy kontekst rozwoju, a artykuły o tożsamości i dostępie pomagają poznać przykłady praktycznych problemów.
Ten poradnik koncentruje się na indywidualnym planie przebranżowienia. Nie jest programem konkretnej edycji szkolenia.
Bootcamp cyberbezpieczeństwa CCyber jest kierowany do początkujących i specjalistów IT planujących zmianę specjalizacji. Opis programu obejmuje zadania do portfolio, przygotowanie CV, próbne rozmowy rekrutacyjne i plan certyfikacji.
Sprawdź program pod kątem swojego punktu startowego. Przed zapisem określ dotychczasowe doświadczenie, interesujący Cię kierunek i czas dostępny na naukę. To ułatwi ocenę, czy zakres i intensywność kursu odpowiadają Twoim potrzebom. Ukończenie szkolenia nie jest gwarancją otrzymania oferty pracy.
Istnieją ścieżki oparte na innych doświadczeniach i kwalifikacjach, ale konkretna oferta może wymagać określonego wykształcenia. Sprawdzaj wymagania wybranych pracodawców i rozwijaj umiejętności odpowiadające zadaniom.
Nie każda ścieżka wymaga programowania na starcie. Nie oznacza to braku wymagań technicznych. Analiza danych, rozumienie systemów i późniejsza automatyzacja mogą być ważne również poza rolami programistycznymi. Kieruj się zakresem stanowiska.
To zależy od punktu startowego, czasu i jakości nauki oraz rekrutacji. Przedstawiony plan organizuje przygotowanie. Nie ustala terminu zatrudnienia ani poziomu samodzielności po jego zakończeniu.
Nie oceniaj możliwości wyłącznie przez wiek. Sprawdź wymagane umiejętności, swój czas na naukę i warunki pierwszych stanowisk. Zacznij od ograniczonego etapu próbnego, zanim podejmiesz decyzje o dużych wydatkach lub odejściu z pracy.
Nie. Dla ścieżki GRC może to być uzasadniona analiza ryzyka, a dla IAM przegląd uprawnień i opis procesu. Forma powinna odpowiadać zadaniom, a projekt wyraźnie wskazywać Twój wkład i ograniczenia.
Przebranżowienie do cyberbezpieczeństwa warto budować wokół konkretnych umiejętności, nie samej nazwy zawodu. Wybierz kierunek, uzupełnij podstawy, wykonaj projekty i sprawdź, czy potrafisz objaśnić ich wyniki.
Najważniejsza zmiana brzmi: zamiast „skończyłem kurs” pokaż „potrafię wykonać to zadanie i wiem, gdzie kończy się moja wiedza”. Taki plan pomaga przygotować się do pierwszych rozmów i świadomie wybierać kolejne kroki.
Piszemy o regulacjach takich jak NIS2, DORA, CRA i ISO 27001, o bezpieczeństwie MŚP i infrastruktury krytycznej, a także o cyberhigienie, cyberzagrożeniach i budowaniu świadomości bezpieczeństwa w organizacji.
Każdy artykuł to praktyczna wiedza - bez żargonu i z konkretnymi wskazówkami do wdrożenia, które pomagają firmom skutecznie chronić dane, ludzi i ciągłość działania.
