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.
Bezpieczny zdalny dostęp do OT: najczęstsze błędy i dobre praktyki
Bezpieczny zdalny dostęp do OT nie polega na prostym włączeniu VPN, RDP albo narzędzia dostawcy. W środowisku przemysłowym zdalny dostęp musi być uzasadniony, czasowy, kontrolowany, monitorowany i możliwy do natychmiastowego odłączenia. Najczęstsze błędy to stały dostęp dostawców, brak MFA, współdzielone konta, bezpośredni dostęp z internetu do HMI, PLC lub stacji inżynierskich, brak segmentacji, brak logów, brak procedury akceptacji i brak testu awaryjnego odcięcia dostępu. Dobra praktyka to dostęp przez strefę pośrednią, jump server, MFA, konta imienne, least privilege, zatwierdzenie operacyjne, okno serwisowe, nagrywanie sesji, pełne logowanie i regularny przegląd uprawnień.
Opracowanie: Zespół redakcyjny CCyber
Bezpieczny zdalny dostęp do OT powinien być wyjątkiem kontrolowanym przez proces, a nie stałą furtką do zakładu. Firma powinna wiedzieć, kto łączy się do środowiska OT, po co, na jak długo, z jakiego urządzenia, przez jaki kanał, do jakiego systemu i kto zatwierdził tę sesję. Największe ryzyka pojawiają się wtedy, gdy dostawcy mają stały VPN, RDP jest wystawione do internetu, konta są współdzielone, nie ma MFA, dostęp prowadzi bezpośrednio do HMI, PLC lub stacji inżynierskiej, a nikt nie monitoruje sesji. Dobra praktyka to model: brak bezpośredniego dostępu z internetu do OT, segmentacja IT i OT, strefa pośrednia, jump server, MFA, konta imienne, dostęp czasowy, zatwierdzenie przez właściciela procesu, logowanie, nagrywanie sesji i możliwość szybkiego odłączenia zdalnego dostępu bez zatrzymania produkcji.
Lipiec 2026
Zdalny dostęp do OT to możliwość połączenia się spoza lokalnej strefy przemysłowej z systemami, które wspierają produkcję, automatykę, proces technologiczny, infrastrukturę techniczną lub bezpieczeństwo obiektu. Może to być dostęp pracownika firmy, dostawcy IT, integratora automatyki, producenta maszyny, serwisanta, operatora SOC albo inżyniera pracującego z innej lokalizacji.
Problem polega na tym, że zdalny dostęp może być bardzo użyteczny i bardzo ryzykowny jednocześnie. Ułatwia serwis, diagnostykę, wsparcie dostawcy, szybsze usuwanie awarii i pracę w wielu lokalizacjach. Ale jeśli jest źle zaprojektowany, staje się najkrótszą drogą do systemów, które mogą zatrzymać produkcję lub wpłynąć na bezpieczeństwo ludzi.
W IT skutkiem incydentu może być utrata danych, przestój systemu, wyciek informacji lub ransomware. W OT skutkiem może być także zatrzymanie linii, uszkodzenie maszyny, błędny parametr procesu, utrata widoczności, utrata kontroli, zagrożenie jakości produktu lub ryzyko dla bezpieczeństwa ludzi.
Dlatego w OT nie wystarczy przenieść zasad z biurowego IT. Zdalny dostęp musi być projektowany z udziałem automatyki, utrzymania ruchu, IT, bezpieczeństwa, produkcji i dostawcy technologii.
Producent maszyny łączy się, aby sprawdzić alarmy, parametry, konfigurację, błędy napędu, logi lub wersję oprogramowania.
Integrator łączy się z systemem SCADA, PLC, HMI lub stacją inżynierską, aby wykonać zmianę, diagnostykę albo poprawkę.
Inżynier zakładu lub centralny zespół techniczny łączy się z wielu lokalizacji, aby analizować stan instalacji.
Dane z historian, MES, BMS lub systemów monitoringu są przeglądane zdalnie przez wybrane osoby lub systemy analityczne.
Zespół serwisowy potrzebuje pilnego dostępu w nocy, w weekend albo podczas przestoju produkcji.
SOC, MDR lub dostawca monitoringu OT potrzebuje dostępu do logów, sensorów, konsol lub danych telemetrycznych.
Najczęstszy problem to dostęp, który kiedyś został uruchomiony dla serwisu i nigdy nie został wyłączony. Dostawca ma konto, VPN, router LTE albo narzędzie zdalnego pulpitu, a zakład nie wie, kiedy i po co ktoś się łączy.
Bezpośrednie wystawienie systemu OT do internetu jest bardzo wysokim ryzykiem. Nawet jeśli dostęp jest chroniony hasłem, takie rozwiązanie zwiększa powierzchnię ataku.
RDP, VNC i narzędzia zdalnego pulpitu bywają wygodne, ale w OT mogą dawać zbyt szeroki dostęp. Jeśli użytkownik dostaje pulpit stacji inżynierskiej, może wykonać znacznie więcej niż tylko diagnostykę.
Hasło nie wystarcza. W środowiskach dostawców i serwisów hasła mogą być współdzielone, używane przez wiele osób lub zapisane w niebezpiecznych miejscach. Bez MFA przejęcie hasła może oznaczać wejście do OT.
Konto „serwis”, „vendor”, „automatyk” albo „support” jest wygodne, ale niszczy rozliczalność. Po incydencie firma nie wie, kto wykonał zmianę.
VPN często daje dostęp do całej podsieci. W OT to zbyt szerokie uprawnienie. Serwisant jednej maszyny nie powinien widzieć całej sieci produkcyjnej.
Zdalny użytkownik nie powinien trafiać bezpośrednio do sterowania. Strefa pośrednia, DMZ lub jump server ogranicza ryzyko i daje miejsce na logowanie, kontrolę, skanowanie oraz egzekwowanie polityki.
W wielu zakładach istnieją różne kanały zdalnego dostępu: VPN IT, router producenta maszyny, modem 4G, laptop serwisowy, TeamViewer, AnyDesk, portal chmurowy dostawcy i tunel do diagnostyki. Bez rejestru nikt nie widzi pełnego ryzyka.
Jeżeli ktoś wykona zmianę w OT, firma powinna wiedzieć, kto, kiedy, z jakiego adresu, do jakiego systemu i co zrobił. Bez logów nie ma rozliczalności.
W sytuacji incydentu zakład musi umieć szybko zablokować zdalny dostęp. To nie może wymagać kilku godzin szukania administratora, dostawcy lub hasła do routera.
Każdy kanał zdalnego dostępu powinien mieć uzasadnienie. Pytanie nie brzmi „czy da się połączyć?”, ale „czy naprawdę musimy utrzymywać ten dostęp i jaki problem biznesowy rozwiązuje?”.
Dostęp powinien przechodzić przez kontrolowaną strefę pośrednią. Użytkownik zdalny nie powinien łączyć się bezpośrednio z PLC, HMI ani stacją inżynierską.
Każda osoba powinna mieć konto imienne, MFA i przypisaną rolę. Konta dostawców powinny być oddzielone od kont pracowników zakładu.
Dostęp powinien być ograniczony do konkretnej maszyny, systemu, aplikacji lub strefy. Nie do całej sieci OT.
Dostęp powinien być aktywny tylko w zatwierdzonym oknie serwisowym. Po zakończeniu prac powinien zostać wyłączony.
Firma powinna mieć logi, alerty i w przypadku działań wysokiego ryzyka nagranie sesji.
Zakład powinien potrafić odłączyć zdalny dostęp bez chaosu, bez zatrzymania niepotrzebnych systemów i bez ryzyka dla bezpieczeństwa ludzi.
HMI, PLC, SCADA, stacje inżynierskie i routery przemysłowe nie powinny być dostępne bezpośrednio z internetu. Każde takie wystawienie wymaga pilnej analizy i zwykle usunięcia.
MFA powinno obejmować VPN, jump server, portal dostępu, konta dostawców i dostęp administratorów. Wyjątki powinny być opisane i zaakceptowane przez właściciela ryzyka.
Jump server pozwala ograniczyć dostęp, logować sesje, nagrywać działania i odseparować użytkownika zdalnego od bezpośredniego dostępu do systemów przemysłowych.
Segmentuj OT według funkcji, linii, procesu, lokalizacji lub krytyczności. Dostęp dostawcy jednej maszyny nie powinien otwierać drogi do całego zakładu.
Zezwalaj tylko na komunikację potrzebną do konkretnej pracy. Blokuj niepotrzebne RDP, VNC, SSH, SMB, FTP, web management i inne usługi.
Każda sesja serwisowa powinna mieć zgłoszenie, właściciela, cel, czas, zakres i potwierdzenie zakończenia. W przypadku działań wysokiego ryzyka wymagaj zgody utrzymania ruchu lub produkcji.
Nie każda praca może być wykonywana w dowolnym czasie. Zmiany w systemach OT powinny być uzgodnione z produkcją i ocenione pod kątem wpływu na bezpieczeństwo procesu.
Logi powinny obejmować użytkownika, czas, źródło, cel, długość sesji, użyty protokół i wykonane działania. Dla dostępu dostawców i stacji inżynierskich warto nagrywać sesje.
Co najmniej raz w roku sprawdź, czy firma potrafi szybko wyłączyć zdalny dostęp dostawcy, VPN lub router przemysłowy. Test nie powinien zagrażać produkcji.
Umowy z dostawcami powinny opisywać MFA, konta imienne, zakres dostępu, logowanie, zgłaszanie incydentów, podwykonawców, aktualizacje narzędzi zdalnych i możliwość audytu.
Sesje nocne, weekendowe, długie, z nietypowej lokalizacji albo do nietypowego systemu powinny generować alert.
Komputer, z którego odbywa się dostęp do OT, powinien być kontrolowany, aktualny, chroniony, bez malware i zgodny z wymaganiami firmy. Prywatny laptop dostawcy nie powinien mieć swobodnego dostępu do OT bez kontroli.
Jeśli dostawca potrzebuje tylko odczytu alarmów lub danych, nie dawaj dostępu do funkcji zapisu, zmiany programu albo modyfikacji parametrów.
Co najmniej kwartalnie sprawdzaj, kto ma zdalny dostęp do OT. Usuwaj konta byłych pracowników, byłych serwisantów, nieaktywnych dostawców i stare tunele.
Dostawca automatyki ma stały dostęp VPN do sieci zakładowej. Jedno z jego kont zostaje przejęte. Atakujący loguje się wieczorem, skanuje sieć OT, znajduje stację inżynierską i próbuje pobrać pliki projektu. Następnie pojawiają się błędy na HMI i nietypowe połączenia do kilku sterowników.
Umowa opisuje serwis, ale nie opisuje MFA, kont imiennych, logów, nagrywania sesji, incydentów ani podwykonawców.
Zakład nie może sprawdzić, czy dostawca zarządza kontami, urządzeniami serwisowymi i podwykonawcami.
Dostawca może mieć incydent, ale klient nie dowie się o tym na czas.
Po zakończeniu umowy konto, router lub tunel dostawcy nadal istnieje.
Dostawca dopuszcza kolejną firmę do zdalnego serwisu, ale zakład nie wie, kto realnie ma dostęp.
Firma produkcyjna ma 6 linii technologicznych. Każda linia ma innego dostawcę maszyn. Przez lata dostawcy uruchamiali własne formy zdalnego dostępu: jeden ma VPN, drugi router LTE, trzeci TeamViewer na stacji HMI, a czwarty modem do diagnostyki. Zakład wie, że „dostawcy jakoś się łączą”, ale nie ma pełnej listy.
Audyt pokazuje 11 kanałów zdalnego dostępu, 4 stałe tunele, 3 konta współdzielone, 2 narzędzia bez MFA i jeden router, którego właściciel nie jest znany. Jeden dostawca ma dostęp do całej podsieci OT, mimo że serwisuje tylko jedną maszynę.
Firma wprowadza rejestr dostępów, zamyka nieużywane tunele, przenosi dostawców przez jump server, włącza MFA, ustala okna serwisowe i nagrywa sesje wysokiego ryzyka. Po 90 dniach zdalny dostęp nadal działa, ale jest widoczny, kontrolowany i możliwy do odcięcia. Produkcja nie traci wsparcia dostawców, a zarząd dostaje realny raport ryzyka.
ccyber.io pomaga firmom przemysłowym uporządkować i zabezpieczyć zdalny dostęp do OT bez paraliżowania serwisu i utrzymania ruchu. Łączymy perspektywę automatyki, IT, bezpieczeństwa, produkcji, dostawców i zarządu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest OT Remote Access Readiness Workshop. W krótkim warsztacie można ustalić, kto ma dziś dostęp do OT, które kanały są najgroźniejsze, co trzeba wyłączyć natychmiast, a co przenieść do bezpieczniejszego modelu.
Nie. VPN może być częścią rozwiązania, ale sam VPN nie wystarczy. Potrzebne są MFA, ograniczenie zakresu, segmentacja, logowanie, kontrola dostawców i możliwość odcięcia dostępu.
Stały dostęp powinien być wyjątkiem, dobrze uzasadnionym i kontrolowanym. Bezpieczniejszy model to dostęp czasowy, aktywowany na okno serwisowe i zatwierdzany przez właściciela OT.
Może być bardzo ryzykowne, jeśli jest dostępne bezpośrednio lub bez kontroli. Lepiej używać jump servera, MFA, kont imiennych, nagrywania sesji i ograniczeń funkcji.
Może, ale tylko jeśli jest wpisany do rejestru, zatwierdzony, skonfigurowany zgodnie z wymaganiami bezpieczeństwa, objęty MFA, logowaniem i procedurą odcięcia.
Minimum kwartalnie oraz po każdej zmianie dostawcy, linii produkcyjnej, systemu, integratora lub incydencie.
Właściciel procesu lub systemu OT, najczęściej utrzymanie ruchu, automatyka lub produkcja, we współpracy z IT i bezpieczeństwem.
Dla działań wysokiego ryzyka warto. Nagrania pomagają w rozliczalności, analizie zmian, audycie i wyjaśnianiu incydentów.
Zacznij od rejestru: kto ma zdalny dostęp do OT, przez co się łączy, do czego ma dostęp, czy działa MFA, czy sesja jest logowana i kto jest właścicielem dostępu.
Bezpieczny zdalny dostęp do OT jest potrzebny, ale musi być kontrolowany. Największym ryzykiem nie jest sam fakt zdalnego dostępu, tylko brak widoczności, brak MFA, stałe tunele, współdzielone konta, bezpośredni dostęp do systemów OT i brak procedury odcięcia.
Dobra architektura opiera się na segmentacji, strefie pośredniej, jump serverze, kontach imiennych, MFA, dostępie czasowym, logowaniu, nagrywaniu sesji i regularnym przeglądzie uprawnień.
Najlepsza zasada brzmi: zdalny dostęp do OT powinien być jak praca serwisowa w zakładzie. Musi mieć cel, zgodę, czas, zakres, nadzór, zapis działań i bezpieczne zakończenie.
Czy tabletop to cyberatak „na sucho”? Jak sprawdzić, czy firma jest gotowa na cyberatak?
Tabletop to kontrolowane ćwiczenie scenariuszowe, w którym firma sprawdza, jak zareagowałaby na cyberatak bez realnego wyłączania systemów. To cyberatak „na sucho”, ale nie test techniczny typu pentest. Tabletop sprawdza decyzje, role, komunikację, eskalację, priorytety odtworzenia, zgłaszanie incydentów, współpracę z dostawcami i gotowość zarządu. Dobrze przeprowadzone ćwiczenie kończy się raportem, listą luk, właścicielami działań i terminami. Najważniejsze pytanie brzmi nie „czy mamy plan?”, ale „czy ludzie potrafią go użyć pod presją?”.
Opracowanie: Zespół redakcyjny CCyber
Tabletop to ćwiczenie cyberataku „na sucho”. Firma nie wyłącza systemów, nie szyfruje danych i nie prowadzi realnego ataku, ale przechodzi przez realistyczny scenariusz incydentu krok po kroku. Celem jest sprawdzenie, czy zarząd, IT, security, prawnik, DPO, HR, komunikacja, finanse, operacje i dostawcy wiedzą, co zrobić w pierwszych godzinach cyberataku. Tabletop nie zastępuje testów technicznych, takich jak pentest, test restore albo test SOC. Sprawdza coś innego: decyzje, role, komunikację, eskalację, priorytety, dokumenty, kontakty, dowody i zdolność do działania pod presją. Dobre ćwiczenie kończy się raportem, listą luk i planem naprawczym.
Lipiec 2026
Tabletop to ćwiczenie scenariuszowe prowadzone w kontrolowanych warunkach. Uczestnicy siedzą przy stole lub spotykają się online i przechodzą przez symulowany cyberincydent. Moderator podaje kolejne informacje, tak zwane „injects”, a zespół decyduje, co robi.
W ćwiczeniu nie chodzi o udowodnienie, że ktoś zna definicję ransomware. Chodzi o sprawdzenie praktyki:
Tabletop jest bezpieczny, bo nie ingeruje w produkcję. Jednocześnie może ujawnić bardzo realne problemy: brak numerów telefonów, niejasne role, nieaktualny plan, brak decyzji zarządu, niewiadome RTO, nietestowany backup, brak procedury zgłoszenia incydentu i sprzeczne oczekiwania między IT a biznesem.
Tak, ale z ważnym zastrzeżeniem. Tabletop jest cyberatakiem „na sucho” w sensie organizacyjnym. Firma ćwiczy reakcję na atak, ale bez realnego atakowania systemów. To próba generalna decyzji, komunikacji i procesu.
Nie jest to jednak:
Tabletop odpowiada na pytanie: czy wiemy, co zrobić, gdy atak już trwa? Test techniczny odpowiada na pytanie: czy technologia działa tak, jak powinna? Firma potrzebuje obu typów sprawdzeń.
Cyberatak szybko staje się problemem zarządczym. Trzeba decydować o przestoju, komunikacji, priorytetach klientów, zgłoszeniach, kosztach, pracy ręcznej i odtwarzaniu. Tabletop pokazuje, czy zarząd ma dane potrzebne do decyzji.
W planie może być zapisane, że „IT reaguje na incydent”. To za mało. Ćwiczenie pokazuje, kto konkretnie odbiera telefon, kto zatwierdza komunikat, kto kontaktuje prawnika i kto prowadzi log działań.
Podczas incydentu poczta może nie działać. Telefon może być przeciążony. Komunikaty mogą wyciekać do klientów lub mediów. Tabletop sprawdza, czy firma ma alternatywne kanały i zasady komunikacji.
Wiele incydentów zaczyna się mało widocznie: podejrzane MFA, dziwne reguły poczty, alert EDR, problem z plikami. Ćwiczenie pokazuje, kiedy sprawa trafia do zarządu i kiedy uruchamia się formalny tryb incydentowy.
Nie da się odtworzyć wszystkiego naraz. Tabletop zmusza firmę do ustalenia, które usługi wracają pierwsze: poczta, ERP, CRM, produkcja, system finansowy, sklep internetowy, panel klienta albo backup.
Wiele firm zależy od zewnętrznego IT, SOC, chmury, hostingu, backupu, dostawcy systemu albo integratora OT. Tabletop pokazuje, czy dostawcy mają kontakt awaryjny, SLA, dostęp, role i procedury.
Po incydencie firma musi odtworzyć oś czasu, decyzje, kontakty, logi, zakres danych i działania naprawcze. Tabletop pokazuje, czy ktoś prowadzi dokumentację w trakcie kryzysu.
Tabletop nie pokaże wszystkiego. Jeżeli firma chce sprawdzić techniczną skuteczność zabezpieczeń, potrzebuje dodatkowych testów.
Dlatego po tabletop często warto zaplanować testy techniczne: restore test, test detekcji, pentest, purple team, przegląd Microsoft 365, test procedury phishingu albo test przełączenia na środowisko awaryjne.
Najlepszy moment jest przed incydentem. Wtedy błędy są tanie, a stres jest kontrolowany.
Plan bez ćwiczenia jest hipotezą. Tabletop sprawdza, czy plan jest zrozumiały i użyteczny.
Ćwiczenie daje dobry dowód gotowości dla NIS2, DORA, ISO 27001, klientów i cyberubezpieczenia.
Zmiana chmury, dostawcy IT, systemu ERP, struktury organizacyjnej, modelu pracy albo procesu backupu powinna uruchomić aktualizację scenariuszy.
Jeżeli firma miała phishing, przejęcie konta, fałszywy przelew, awarię backupu albo incydent u dostawcy, warto przećwiczyć podobny scenariusz.
Najczęstszy błąd to zaproszenie tylko IT. Cyberatak nie jest tylko problemem IT. Tabletop powinien obejmować osoby, które realnie podejmują decyzje i wykonują działania w kryzysie.
W małej firmie jedna osoba może pełnić kilka ról. Ważne, aby role były nazwane i sprawdzone.
Nie ćwicz wszystkiego naraz. Dobrze zaprojektowany tabletop ma jasny cel.
Scenariusz powinien pasować do firmy. Dla e-commerce dobry będzie atak na sklep i płatności. Dla produkcji ransomware w systemie magazynowym. Dla kancelarii wyciek dokumentów. Dla SaaS incydent w chmurze i utrata zaufania klientów.
Nie trzeba zdradzać całego scenariusza, ale uczestnicy powinni znać cel, czas trwania, zasady i dokumenty, z których mogą korzystać.
Injects to kolejne informacje w scenariuszu. Na przykład: klient zgłasza niedostępność, EDR generuje alert, dostawca nie odbiera telefonu, media pytają o wyciek danych, backup nie działa zgodnie z planem.
W ćwiczeniu nie chodzi o idealne odpowiedzi. Chodzi o obserwację, gdzie firma ma luki.
Bezpośrednio po ćwiczeniu zbierz wnioski: co działało, co nie działało, czego brakowało, kto nie znał roli, które decyzje były opóźnione.
Najważniejszym efektem jest improvement plan, czyli lista działań naprawczych z właścicielami i terminami.
Firma rano odkrywa, że część plików ma dziwne rozszerzenia. Poczta działa niestabilnie, a pracownicy widzą komunikat o okupie. Dostawca IT sugeruje odłączenie części sieci.
Pracownik zgłasza nieoczekiwane powiadomienia MFA. Kilka godzin później klienci dostają fałszywe faktury z jego konta. W skrzynce pojawiają się reguły przekazywania poczty.
Finanse dostają wiadomość od dostawcy o zmianie rachunku. Wiadomość wygląda wiarygodnie, bo pochodzi z prawdziwego wątku. Przelew ma być wykonany pilnie.
Klient informuje, że znalazł swoje dane w publicznym miejscu. Zespół podejrzewa błędne udostępnienie folderu albo przejęcie konta.
Dostawca chmury, hostingu, systemu ERP albo usług IT informuje o incydencie. Nie wiadomo, czy dane firmy są zagrożone. Usługa działa niestabilnie.
System magazynowy, produkcyjny albo operatorski przestaje działać. Integrator OT nie jest dostępny od razu. Produkcja pyta, czy może pracować ręcznie.
Nie ma jasnych ról, dokumentów, kontaktów ani decyzji. Firma działa intuicyjnie.
Dokumenty są, ale ludzie ich nie znają. Kontakty są nieaktualne. Nie wiadomo, kto decyduje.
Role są znane, plan działa częściowo, ale brakuje testów, szablonów, dostawców albo priorytetów odtworzenia.
Zespół zna role, decyzje są szybkie, komunikacja działa, a większość luk ma plan naprawczy.
Firma potrafi działać w trybie awaryjnym, odtwarzać usługi według priorytetów, komunikować z klientami i dokumentować decyzje.
Najważniejsza jest lista działań naprawczych. Bez niej tabletop staje się rozmową, a nie narzędziem poprawy odporności.
Dla większości firm dobrym minimum jest jedno większe ćwiczenie tabletop rocznie i jedno krótsze ćwiczenie kwartalne dla wybranego scenariusza. Firmy regulowane, dostawcy usług krytycznych, firmy finansowe, produkcyjne i technologiczne powinny ćwiczyć częściej.
Jeżeli ćwiczenie jest pełne technicznych szczegółów, zarząd i biznes przestają uczestniczyć. Tabletop powinien sprawdzać decyzje, nie tylko narzędzia.
Cyberatak dotyka klientów, finansów, prawników, DPO, PR, HR i zarząd. Bez tych osób ćwiczenie jest niepełne.
Bez dobrego moderatora ćwiczenie zamienia się w luźną rozmowę albo spór techniczny.
Jeżeli nikt nie zapisuje decyzji, pytań i luk, firma traci najważniejszą wartość ćwiczenia.
Ćwiczenie bez raportu i planu działań nie poprawia odporności.
Scenariusz powinien być realistyczny i niewygodny. Ma pokazać luki, nie tylko potwierdzić, że wszystko jest dobrze.
Tabletop ma znaleźć luki w systemie, nie winnych ludzi. Kultura obwiniania zmniejsza szczerość.
Największą wartość daje zamknięcie działań naprawczych i ponowne ćwiczenie wybranego fragmentu.
Firma usługowa zatrudnia 90 osób. Ma Microsoft 365, CRM, system fakturowania, chmurę plików, zewnętrznego dostawcę IT i backup. Zarząd uważa, że firma jest przygotowana, bo ma plan incident response i backup.
Podczas tabletop scenariusz zaczyna się od podejrzanych powiadomień MFA. Po godzinie pojawiają się reguły przekazywania poczty, a klienci otrzymują fałszywe faktury. Zespół IT wie, jak zablokować konto, ale nie wiadomo, kto informuje klientów, kto kontaktuje bank, kto sprawdza zakres danych i kto decyduje o komunikacie zarządu. Lista kontaktów do dostawcy IT zawiera numer do osoby, która już nie pracuje. Backup jest dostępny, ale nikt nie pamięta daty ostatniego testu restore.
Ćwiczenie trwa dwie godziny i ujawnia 14 luk. Firma nie traktuje tego jako porażki. W ciągu 60 dni aktualizuje kontakty, ćwiczy procedurę przejęcia konta, robi test restore, przygotowuje szablon komunikatu do klientów i ustala właściciela incydentu. Po trzech miesiącach robi krótkie ćwiczenie follow-up. Tym razem eskalacja jest szybsza, a decyzje są dużo bardziej uporządkowane.
ccyber.io pomaga firmom projektować i prowadzić ćwiczenia tabletop, które realnie sprawdzają gotowość na cyberatak. Nie robimy ćwiczeń dla samego odhaczenia. Budujemy scenariusze dopasowane do biznesu, systemów, dostawców, regulacji i ryzyk firmy.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Tabletop Readiness Workshop. W krótkim warsztacie można ustalić, który scenariusz jest najważniejszy dla firmy, kto powinien uczestniczyć, jakie dokumenty trzeba przygotować i jakie decyzje zarząd powinien przećwiczyć przed realnym atakiem.
Nie. Pentest sprawdza techniczne podatności. Tabletop sprawdza decyzje, role, komunikację, eskalację i zdolność firmy do działania podczas incydentu.
Nie. To ćwiczenie kontrolowane. Systemy produkcyjne nie są celowo wyłączane ani atakowane.
Małe ćwiczenie może trwać 90 minut. Typowe ćwiczenie trwa 2 do 4 godzin. Rozbudowane ćwiczenia dla firm regulowanych mogą trwać cały dzień.
Nie tylko IT. Powinien uczestniczyć zarząd, legal, DPO, komunikacja, operacje, finanse, HR, osoby od klientów i kluczowi dostawcy.
Najczęściej najlepszy jest ransomware, przejęcie poczty lub fałszywy przelew. Wybór zależy od profilu firmy i największego ryzyka biznesowego.
Tak, jeśli powstaje raport, lista uczestników, cele, scenariusz, wnioski i plan działań naprawczych. Samo spotkanie bez dokumentacji jest słabym dowodem.
Minimum raz w roku. Firmy o większym ryzyku powinny robić krótsze ćwiczenia kwartalne i ćwiczenia po dużych zmianach lub incydentach.
Zacznij od jednego scenariusza, który realnie może zatrzymać firmę. Ustal cele, zaproś właściwe osoby, przygotuj dokumenty i zadbaj o raport po ćwiczeniu.
Tabletop to cyberatak „na sucho”, który pozwala sprawdzić, czy firma umie działać pod presją bez realnego wyłączania systemów. Nie zastępuje testów technicznych, ale pokazuje luki w decyzjach, komunikacji, rolach, eskalacji, dostawcach i odtwarzaniu działania.
Największą wartością tabletop jest to, że ujawnia problemy przed prawdziwym incydentem. Firma może poprawić kontakty, playbooki, backup, komunikację, zgłoszenia, role i priorytety odtworzenia wtedy, gdy nie płaci jeszcze kosztu realnego kryzysu.
Najlepsza zasada brzmi: nie pytaj tylko, czy firma ma plan incident response. Sprawdź, czy ludzie potrafią go użyć, gdy poczta nie działa, klient dzwoni, zarząd czeka na decyzję, a zegar incydentu już tyka.
Cyberhigiena w firmie: program szkoleniowy na 12 miesięcy
Program cyberhigieny na 12 miesięcy powinien być krótkim, regularnym i praktycznym cyklem działań, a nie jedną prezentacją raz w roku. Każdy miesiąc powinien wzmacniać inne zachowanie: phishing, MFA, hasła, dane, urządzenia, płatności, AI, dostęp, dostawców, ransomware, zgłaszanie incydentów i pracę z klientami. Celem nie jest straszenie pracowników, ale zbudowanie prostych nawyków: zatrzymaj się, sprawdź drugim kanałem, nie podawaj kodów, używaj zatwierdzonych narzędzi, zgłaszaj szybko i nie obchodź procedur pod presją.
Opracowanie: Zespół redakcyjny CCyber
Cyberhigiena w firmie to zestaw prostych, powtarzalnych zachowań, które zmniejszają ryzyko codziennych incydentów. Program szkoleniowy na 12 miesięcy powinien obejmować krótkie lekcje, ćwiczenia scenariuszowe, komunikaty przypominające, szkolenia rolowe, symulacje phishingu, testy wiedzy i mierzenie zachowań. Najważniejsze tematy to phishing, MFA, hasła, menedżer haseł, ochrona danych, bezpieczne udostępnianie plików, urządzenia, aktualizacje, praca zdalna, fałszywe płatności, AI, zgłaszanie incydentów, ransomware, backup, dostęp i dostawcy. Celem programu nie jest odhaczenie szkolenia, ale zmiana zachowań pracowników przez cały rok.
Lipiec 2026
Cyberhigiena to codzienne nawyki, które ograniczają ryzyko cyberincydentu. Tak jak higiena osobista nie polega na jednorazowym działaniu, tak cyberhigiena nie polega na jednej prezentacji szkoleniowej. To regularne zachowania, które powinny być proste, zrozumiałe i powtarzalne.
Dobra cyberhigiena nie wymaga od pracownika bycia ekspertem. Wymaga jasnych zasad, prostych narzędzi i kultury, w której zgłoszenie problemu jest normalne.
Ludzie zapominają. Procesy się zmieniają. Pojawiają się nowe narzędzia, nowi pracownicy, nowe oszustwa i nowe presje biznesowe. Dlatego cyberświadomość nie może być jednorazowym wydarzeniem.
Najlepiej działa rytm: raz w miesiącu krótki temat, raz na kwartał ćwiczenie, raz na pół roku głębsza symulacja, raz w roku podsumowanie i plan na kolejny cykl.
Lepiej zrobić 12 krótkich lekcji po 10 minut niż jedną dwugodzinną prezentację raz w roku. Cyberhigiena działa wtedy, gdy jest obecna w codziennej pracy.
Pracownik powinien ćwiczyć realne sytuacje: fałszywa faktura, prośba o kod MFA, link do logowania, błędny odbiorca, telefon od „prezesa”, plik klienta w niezatwierdzonym narzędziu AI.
Finanse potrzebują ćwiczeń z płatności. HR potrzebuje ochrony danych kandydatów i pracowników. Sprzedaż potrzebuje bezpiecznej pracy z klientami. IT potrzebuje kont administratorów, logów i podatności. Zarząd potrzebuje decyzji, ryzyka i incydentów.
Publiczne zawstydzanie pracowników zmniejsza liczbę zgłoszeń. Program powinien wzmacniać szybkie zgłaszanie, nawet jeśli ktoś kliknął, podał hasło albo wysłał plik do złego odbiorcy.
Najważniejsze pytanie nie brzmi „czy ludzie obejrzeli szkolenie?”. Ważniejsze jest, czy zgłaszają phishing, czy używają drugiego kanału, czy nie podają kodów MFA i czy managerowie nie naciskają na obchodzenie procedur.
Zanim firma uruchomi 12-miesięczny program, powinna przygotować podstawy organizacyjne. Bez nich szkolenie będzie oderwane od rzeczywistości.
Pierwszy miesiąc powinien wyjaśnić, dlaczego program istnieje, czego firma oczekuje od pracowników i jak zgłaszać podejrzane sytuacje.
Krótki quiz: „co robisz w tej sytuacji?” z przykładami phishingu, fałszywej płatności, podejrzanego MFA i błędnego odbiorcy wiadomości.
Drugi miesiąc skupia się na rozpoznawaniu wiadomości, które próbują wymusić kliknięcie, logowanie, pobranie pliku, podanie danych lub wykonanie płatności.
Pracownicy oceniają 5 wiadomości i decydują: zgłosić, zweryfikować drugim kanałem, usunąć, otworzyć albo eskalować.
Trzeci miesiąc powinien zmniejszyć ryzyko przejęcia kont. Najważniejsze komunikaty: nie podawaj kodów MFA, nie zatwierdzaj nieoczekiwanych logowań, nie używaj tych samych haseł, korzystaj z menedżera haseł.
Symulacja telefonu od „IT” z prośbą o kod MFA oraz ćwiczenie tworzenia bezpiecznego wpisu w menedżerze haseł.
Czwarty miesiąc dotyczy błędów, które nie zawsze wyglądają jak atak: zły odbiorca, zły załącznik, zbyt szeroki link, dane w prywatnym narzędziu lub dokument z ukrytymi kolumnami.
Scenariusz: pracownik wysłał plik klienta do złego odbiorcy. Zespół ćwiczy zgłoszenie, ograniczenie skutków i komunikację wewnętrzną.
Piąty miesiąc wzmacnia podstawy pracy na laptopach, telefonach i zdalnych połączeniach. Pracownik powinien wiedzieć, że aktualizacja, blokada ekranu i zgłoszenie zgubionego urządzenia są elementem bezpieczeństwa firmy.
Checklista pracownika zdalnego: urządzenie, sieć, dane, rozmowy, ekran, dokumenty i zgłoszenia.
Szósty miesiąc powinien być szczególnie praktyczny dla finansów, zarządu, administracji i osób zatwierdzających zamówienia. Celem jest ograniczenie ryzyka fałszywego przelewu i zmiany rachunku dostawcy.
Symulacja: dostawca wysyła nowy numer rachunku. Zespół finansów ćwiczy weryfikację, dokumentowanie i decyzję.
Siódmy miesiąc uczy zachowań po zauważeniu zaszyfrowanych plików, dziwnego komunikatu, niedostępności systemów lub podejrzanego działania urządzenia.
Tabletop dla pracowników i managerów: „rano nie działa poczta, pliki mają dziwne rozszerzenia, a na ekranie jest żądanie okupu”.
Ósmy miesiąc skupia się na używaniu narzędzi poza kontrolą organizacji. To obejmuje prywatny dysk, prywatną pocztę, niezatwierdzone aplikacje, transkrypcje spotkań i publiczne narzędzia AI.
Pracownicy oceniają 6 przypadków użycia AI i decydują, czy są dozwolone, ograniczone, zakazane lub wymagają zgody.
Dziewiąty miesiąc jest szczególnie ważny dla managerów. Uczy, że zmiana roli, projekt, odejście pracownika i zakończenie współpracy z dostawcą muszą oznaczać przegląd dostępów.
Managerowie analizują listę dostępów przykładowego pracownika po zmianie roli i wskazują, co zostaje, co trzeba odebrać, a co wymaga wyjaśnienia.
Dziesiąty miesiąc pokazuje pracownikom i managerom, że cyberbezpieczeństwo dotyczy także relacji z dostawcami oraz klientami. Szczególnie ważne są firmy obsługujące klientów regulowanych lub przetwarzające dane klientów.
Scenariusz: nowy dostawca SaaS ma przetwarzać dane klientów. Zespół ocenia ryzyko, umowę, MFA, lokalizację danych, podwykonawców i plan wyjścia.
Jedenasty miesiąc wzmacnia najważniejszy nawyk: zgłaszaj szybko. Pracownik musi wiedzieć, że szybkie zgłoszenie kliknięcia, podania hasła, utraty telefonu albo błędnej wysyłki pliku chroni firmę.
Ćwiczenie „kliknąłem, co dalej?”. Pracownicy przechodzą przez pierwsze 15 minut po błędzie.
Ostatni miesiąc powinien zamknąć cykl. Firma podsumowuje metryki, najczęstsze błędy, skuteczność zgłoszeń, luki procesowe i potrzeby na kolejny rok.
Roczna symulacja mieszana: phishing, MFA, fałszywy przelew, błędna wysyłka danych i incydent u dostawcy.
Nie wystarczy mierzyć obecności na szkoleniu. Firma powinna mierzyć zmianę zachowań i jakość procesów.
Jednorazowe szkolenie daje dokument do audytu, ale rzadko zmienia nawyki. Cyberhigiena wymaga powtarzania.
Definicje phishingu i ransomware są mniej ważne niż decyzja, co zrobić po otrzymaniu podejrzanej wiadomości.
Finanse, HR, sprzedaż, IT i zarząd mają inne ryzyka. Jeden materiał dla wszystkich pomija realne scenariusze.
Strach przed karą powoduje opóźnione zgłoszenia. A w incydencie czas jest kluczowy.
Kliknięcia w symulację phishingu są tylko jedną metryką. Ważniejsze jest szybkie zgłaszanie i poprawa procesów.
Jeżeli zgłoszenie jest trudne, pracownik odłoży je na później albo nie zgłosi problemu.
Jeżeli manager wymaga szybkiego działania mimo ryzyka, szkolenie nie zadziała. Procedury muszą obowiązywać także pod presją.
Program musi reagować na nowe ryzyka: deepfake, AI, QR phishing, przejęte konta dostawców i nowe narzędzia pracy.
Firma usługowa zatrudnia 75 osób. Ma Microsoft 365, CRM, system fakturowania, chmurę plików, zewnętrzną księgowość i kilku dostawców IT. Zarząd chce „szkolenie z phishingu”, bo pracownicy dostają coraz więcej podejrzanych wiadomości.
Krótki przegląd pokazuje, że problem jest szerszy. Pracownicy nie wiedzą, gdzie zgłaszać phishing. Finanse nie mają procedury zmiany rachunku dostawcy. MFA działa, ale pracownicy nie wiedzą, co zrobić przy nieoczekiwanym powiadomieniu. HR wysyła dane kandydatów przez zbyt szerokie linki. Część zespołu używa prywatnych narzędzi AI do podsumowań dokumentów.
Firma uruchamia program 12-miesięczny. Każdy miesiąc ma jeden temat, jedno krótkie ćwiczenie i jedną metrykę. Po pół roku rośnie liczba zgłoszeń phishingu, spada liczba niezweryfikowanych próśb o płatność, a managerowie zaczynają pytać o access review przy zmianie roli pracownika. Firma nie tylko szkoli ludzi, ale zmienia sposób pracy.
ccyber.io pomaga firmom budować programy cyberhigieny, które zmieniają zachowania i dają dowody do audytu, NIS2, ISO 27001, cyberubezpieczenia oraz wymagań klientów. Nie tworzymy szkolenia dla odhaczenia. Budujemy roczny program oparty na realnych scenariuszach, rolach, procedurach i metrykach.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Hygiene Programme Workshop. W krótkim warsztacie można ustalić, jakie zachowania są najważniejsze dla firmy, które działy mają największe ryzyko i jak zaplanować 12 miesięcy szkoleń bez przeciążania pracowników.
Nie musi, ale powinien być cykliczny. 12 miesięcy to praktyczny rytm, który pozwala utrwalać zachowania, mierzyć efekty i dopasować szkolenia do sezonu biznesowego.
Nie. Phishing jest ważny, ale cyberhigiena obejmuje też MFA, hasła, dane, płatności, urządzenia, AI, dostęp, dostawców i zgłaszanie incydentów.
Mikro-lekcja może trwać 5 do 15 minut. Szkolenia rolowe i ćwiczenia scenariuszowe zwykle trwają dłużej, ale powinny być konkretne i praktyczne.
Tak, jeśli są połączone z omówieniem, procedurą zgłaszania i poprawą procesów. Symulacja bez nauki może tylko stresować ludzi.
Zarząd powinien ćwiczyć decyzje: ransomware, zgłoszenie incydentu, komunikacja z klientami, koszt przestoju, priorytety odtworzenia i akceptacja ryzyka.
Mierz frekwencję, wyniki quizów, zgłoszenia phishingu, czas zgłoszenia, liczbę zgłoszonych podejrzanych MFA, potwierdzenia drugim kanałem i działania naprawcze po ćwiczeniach.
Nie powinno się budować programu na karaniu. Ważniejsze jest szybkie zgłaszanie, nauka i poprawa procesu. Konsekwencje powinny dotyczyć świadomego, powtarzalnego obchodzenia zasad.
Zacznij od właściciela programu, kanału zgłaszania, krótkiego szkolenia z minimum cyberhigieny i planu 12 miesięcy z tematami, ćwiczeniami i metrykami.
Cyberhigiena w firmie nie jest jednorazowym szkoleniem. To roczny rytm krótkich działań, które budują nawyki pracowników i zmniejszają ryzyko codziennych incydentów.
Dobry program 12-miesięczny obejmuje phishing, MFA, hasła, dane, urządzenia, płatności, ransomware, AI, dostęp, dostawców, zgłaszanie incydentów i podsumowanie efektów. Powinien być rolowy, praktyczny, mierzony i wspierany przez managerów.
Najlepsza zasada brzmi: nie oczekuj od pracowników perfekcji. Daj im jasne zasady, proste narzędzia, regularne ćwiczenia i bezpieczną ścieżkę zgłaszania, zanim mały błąd stanie się dużym incydentem.
Jak przygotować firmę na pytania brokera ds. ubezpieczenia cybernetycznego?
Broker ds. ubezpieczenia cybernetycznego będzie pytał nie tylko o polisę, ale przede wszystkim o realny stan cyberbezpieczeństwa firmy. Przed rozmową warto przygotować odpowiedzi i dowody dotyczące MFA, backupu, testu odtworzenia, EDR, aktualizacji, kont administratorów, dostępu zdalnego, phishingu, procedury płatności, incident response, BCP, dostawców, historii incydentów, regulacji i zakresu oczekiwanej ochrony. Najważniejsze jest, aby nie odpowiadać „tak” na podstawie założeń. Każda deklaracja powinna mieć zakres, właściciela i dowód.
Opracowanie: Zespół redakcyjny CCyber
Firmę do rozmowy z brokerem ds. ubezpieczenia cybernetycznego trzeba przygotować tak samo jak do mini-audytu cyberbezpieczeństwa. Broker będzie chciał zrozumieć, jakie ryzyka ma firma, jakie dane i systemy są krytyczne, czy działają podstawowe zabezpieczenia, czy firma potrafi odtworzyć dane po ransomware i czy odpowiedzi w ankiecie ubezpieczeniowej są zgodne z rzeczywistością. Najważniejsze obszary to MFA, backup i test restore, ochrona urządzeń, aktualizacje, konta administratorów, dostęp zdalny, ochrona poczty, szkolenia, procedura płatności, dostawcy, incident response, ciągłość działania, historia incydentów i zgodność z regulacjami. Dobrze przygotowana firma nie zgaduje odpowiedzi. Pokazuje dowody.
Lipiec 2026
Broker pomaga dobrać polisę do ryzyka firmy. Żeby to zrobić, musi zrozumieć, co firma robi, jakie dane przetwarza, od jakich systemów zależy, jakie ma przychody, jakich ma klientów, czy była już po incydencie i czy ma podstawowe zabezpieczenia.
W praktyce broker może pełnić rolę tłumacza między firmą a ubezpieczycielem. Firma mówi językiem biznesu i IT. Ubezpieczyciel mówi językiem ryzyka, limitów, wyłączeń, ankiet i wymogów ochrony. Dobry broker pomaga przygotować odpowiedzi, ale nie powinien zgadywać stanu zabezpieczeń za firmę.
Największym problemem przy cyberubezpieczeniu nie jest brak idealnych zabezpieczeń. Problemem jest deklarowanie czegoś, czego firma nie potrafi udowodnić. Jeżeli firma odpowie, że ma MFA, a MFA działa tylko dla części użytkowników, odpowiedź jest niepełna. Jeżeli firma odpowie, że ma backup, ale nigdy nie wykonała testu odtworzenia, to odpowiedź też może być myląca.
Słaba odpowiedź: „Mamy MFA”.
Dobra odpowiedź: „MFA działa dla Microsoft 365, VPN, kont administratorów i systemu finansowego. Nie obejmuje dwóch kont technicznych opisanych w rejestrze wyjątków. Ostatni raport MFA pochodzi z czerwca 2026 r.”.
Broker będzie potrzebował podstawowego obrazu firmy. To nie jest formalność, bo branża, przychody, liczba pracowników i rodzaj danych wpływają na ocenę ryzyka.
Ubezpieczyciel chce wiedzieć, co może zostać utracone, zaszyfrowane, skradzione albo zatrzymane.
Broker prawdopodobnie zapyta o wcześniejsze incydenty, roszczenia, ransomware, naruszenia danych, przejęcia kont, fałszywe przelewy i near miss. Warto przygotować uczciwy opis oraz działania naprawcze.
To jedno z najczęściej pojawiających się pytań. Broker może zapytać, czy MFA działa na poczcie, VPN, kontach administratorów, chmurze, systemach finansowych, backupie i dostępie dostawców.
Dowód: raport MFA, lista wyjątków i decyzje akceptujące ryzyko.
Broker może zapytać, czy firma wykonuje kopie zapasowe, ale ważniejsze jest pytanie, czy firma potrafi odtworzyć dane i systemy. Backup bez testu restore jest słabym dowodem odporności.
Dowód: raport backupu, raport testu odtworzenia i lista działań naprawczych.
Ransomware jest jednym z najważniejszych scenariuszy ubezpieczeniowych. Broker może pytać, jak firma wykrywa, izoluje, odtwarza i komunikuje incydent ransomware.
Dowód: ransomware playbook i raport z ćwiczenia tabletop.
Broker może pytać, czy urządzenia są chronione, kto widzi alerty i czy ochrona obejmuje wszystkie laptopy, serwery i stacje robocze.
Dowód: raport pokrycia EDR lub antywirusa, raport alertów i lista wyjątków.
Ubezpieczyciele interesują się podatnościami, bo wiele incydentów zaczyna się od niezałatanych systemów, VPN, serwerów, urządzeń sieciowych lub aplikacji internetowych.
Dowód: raport podatności, raport aktualizacji i rejestr wyjątków.
Konta administratorów są jednym z największych źródeł ryzyka. Broker może pytać, ilu jest administratorów, czy mają MFA, czy używają kont imiennych i czy dostęp jest przeglądany.
Dowód: raport kont administratorów i raport access review.
Dostęp zdalny, VPN, RDP i narzędzia wsparcia technicznego są częstym przedmiotem pytań brokera. Szczególnie ważny jest dostęp dostawców.
Dowód: opis dostępu zdalnego, raport MFA, lista dostawców z dostępem i logi administracyjne.
Poczta jest jednym z głównych wektorów ataku. Broker może pytać o ochronę antyphishingową, filtrowanie malware, reguły przekazywania poczty, SPF, DKIM, DMARC i szkolenia.
Dowód: raport konfiguracji poczty, raport phishingu i status SPF, DKIM oraz DMARC.
Broker powinien wiedzieć, czy firma ma ryzyko business email compromise i fałszywych przelewów. Nie każda polisa obejmuje taki scenariusz, więc trzeba omówić to wprost.
Dowód: procedura płatności, rejestr zmian rachunków i potwierdzenia drugim kanałem.
Broker może pytać, co firma zrobi w pierwszej godzinie po incydencie. Plan reagowania nie musi mieć 100 stron, ale musi być aktualny i znany osobom decyzyjnym.
Dowód: incident response plan, lista kontaktów awaryjnych i raport ćwiczenia.
Polisa może obejmować przerwy w działalności, ale broker musi rozumieć, ile kosztuje przestój i czy firma umie ograniczyć jego czas.
Dowód: BCP, DRP, test restore i analiza kosztu przestoju.
Broker może zapytać, jakie dane firma przetwarza i czy są one zabezpieczone. Im więcej danych osobowych, finansowych, medycznych, klientów lub tajemnic przedsiębiorstwa, tym ważniejsze są kontrole dostępu i szyfrowanie.
Dowód: klasyfikacja danych, raport szyfrowania i raport dostępu do danych.
Broker może pytać o szkolenia z phishingu, haseł, MFA, ransomware, ochrony danych i płatności. Dla działów finansów, HR i zarządu warto mieć szkolenia rolowe.
Dowód: lista uczestników, materiały, wyniki testów i plan szkoleń.
Broker może zapytać o chmurę, hosting, IT, backup, SOC, MDR, księgowość, CRM, ERP i innych dostawców, którzy mają dostęp do danych lub systemów.
Dowód: rejestr dostawców, oceny ryzyka i klauzule bezpieczeństwa w umowach.
Broker nie powinien dobierać zakresu w ciemno. Firma powinna wiedzieć, jakie scenariusze chce objąć ochroną.
Dowód: lista scenariuszy ryzyka i rekomendowany zakres ochrony.
Nie wystarczy wiedzieć, co polisa obejmuje. Trzeba też wiedzieć, czego nie obejmuje. To często najważniejszy element rozmowy z brokerem.
Dowód: notatka z analizy warunków polisy i lista pytań do brokera.
W wielu polisach ważne są procedury zgłaszania szkody i korzystania z zatwierdzonych dostawców. Firma powinna wiedzieć, kto dzwoni, kiedy i pod jaki numer.
Dowód: karta kontaktu ubezpieczeniowego w planie incident response.
Ankieta ubezpieczeniowa nie powinna być wypełniana przez jedną osobę z pamięci. Każdy obszar powinien mieć właściciela, który potwierdza odpowiedź.
Dowód: macierz odpowiedzialności do ankiety.
Nie każda luka musi blokować polisę. Ważne, aby była znana, opisana, priorytetyzowana i miała właściciela oraz termin.
Dowód: plan działań naprawczych do polisy lub odnowienia.
Cyberubezpieczenie jest decyzją zarządczą. Zarząd powinien znać ryzyka, limity, wyłączenia, wymagane zabezpieczenia i działania, które trzeba wykonać po zakupie polisy.
Dowód: raport dla zarządu i decyzje budżetowe.
Jeżeli MFA działa tylko dla poczty, ale nie działa dla VPN i administratorów, odpowiedź powinna wskazywać zakres. „Częściowo” z planem naprawczym jest bezpieczniejsze niż „tak” bez pokrycia.
Firma może mieć EDR, ale nikt nie reaguje na alerty. Może mieć backup, ale nikt go nie testuje. Może mieć plan incydentu, ale nikt go nie zna.
Wyjątki powinny być opisane i zaakceptowane. Ukryte wyjątki mogą wrócić jako problem po incydencie.
Dostawca IT może znać konfigurację, ale nie zna wszystkich procesów biznesowych, historii incydentów, płatności, danych, umów i ryzyk zarządczych.
Broker może pomóc w pytaniach i rynku polis, ale firma powinna sama potwierdzić stan zabezpieczeń albo skorzystać z niezależnego przeglądu.
Najtańsza polisa może mieć wyłączenia, podlimity i warunki, które nie pasują do realnego ryzyka firmy.
Ankietę wypełnia jedna osoba, chociaż odpowiedzi wymagają wiedzy IT, finansów, legal, zarządu i dostawców.
Firma deklaruje MFA, backup, EDR i szkolenia, ale nie ma raportów ani testów.
Incydent u dostawcy IT, chmury albo backupu może zatrzymać firmę, a polisa może mieć szczególne warunki dotyczące dostawców.
Fałszywe przelewy i social engineering fraud nie zawsze są objęte standardową polisą cyber. Trzeba zapytać o to wprost.
Backup jest wpisany w ankiecie jako działający, ale firma nie wie, czy potrafi odtworzyć dane po ransomware.
Po incydencie firma dopiero szuka numeru do brokera, ubezpieczyciela, prawnika i dostawcy reagowania.
Firma zmienia chmurę, dostawcę, model pracy albo zakres systemów, ale nie aktualizuje informacji przekazanych brokerowi.
Firma e-commerce zatrudnia 55 osób. Korzysta z platformy sklepowej, systemu płatności, magazynu, Microsoft 365, CRM, narzędzi marketingowych i zewnętrznego dostawcy IT. Zarząd chce kupić cyberubezpieczenie, bo rosną wymagania klientów i pojawiły się próby phishingu.
Broker przesyła ankietę. Firma początkowo odpowiada „tak” na większość pytań, bo ma dostawcę IT i backup. Po wewnętrznym przeglądzie okazuje się, że MFA działa tylko w Microsoft 365, ale nie obejmuje panelu sklepu i kont dostawcy IT. Backup sklepu istnieje, ale test restore nie był wykonany od ponad roku. Nie ma formalnej procedury zmiany rachunku dostawcy. EDR obejmuje tylko laptopy, a nie serwer aplikacyjny. Incident response plan jest w wersji roboczej.
Firma nie wysyła ankiety od razu. W ciągu 60 dni uzupełnia MFA, wykonuje test restore, porządkuje konta administratorów, wdraża procedurę płatności, szkoli finanse i przygotowuje pakiet dowodów. Rozmowa z brokerem zmienia się z negocjacji ceny w rozmowę o realnym ryzyku, zakresie polisy i warunkach, które firma potrafi spełnić.
ccyber.io pomaga firmom przygotować się do rozmowy z brokerem ds. ubezpieczenia cybernetycznego w sposób praktyczny, oparty na ryzyku i dowodach. Sprawdzamy, czy odpowiedzi w ankiecie są zgodne z rzeczywistością, gdzie są luki i jakie działania warto wykonać przed zakupem lub odnowieniem polisy.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Insurance Broker Readiness Workshop. W krótkim warsztacie można sprawdzić, które odpowiedzi są pewne, gdzie brakuje dowodów, które luki mogą wpływać na polisę i jakie pytania trzeba zadać brokerowi przed wyborem ochrony.
Broker może pytać o techniczne zabezpieczenia, ale zwykle nie wykonuje pełnego audytu technicznego. Firma powinna sama przygotować dowody albo wykonać niezależny przegląd przed złożeniem ankiety.
Profil firmy, listę systemów i danych krytycznych, historię incydentów, obecne zabezpieczenia, raport MFA, informacje o backupie, dostawcach, incident response i oczekiwanym zakresie polisy.
Nie powinno się tak robić. Lepiej opisać zakres, wyjątki i plan naprawczy. Odpowiedź „tak” bez doprecyzowania może być myląca.
Najczęściej kluczowe są pytania o MFA, backup i ransomware. W praktyce bardzo ważne są też EDR, dostęp zdalny, konta administratorów, aktualizacje, dostawcy i incident response.
Nie zawsze. Business email compromise, social engineering fraud i fałszywe przelewy mogą wymagać osobnego zakresu lub mieć podlimity oraz szczególne warunki.
Tak, warto go mieć. Backup bez testu odtworzenia jest słabym dowodem. Broker i ubezpieczyciel mogą pytać nie tylko o kopie, ale też o zdolność odzyskania danych.
IT, security, finanse, legal, risk, HR, zarząd i kluczowi dostawcy IT. Jedna osoba rzadko zna pełny obraz zabezpieczeń i ryzyk.
Zacznij od porównania pytań brokera z faktami: co jest wdrożone, co działa częściowo, czego nie ma i jakie dowody potwierdzają odpowiedzi.
Przygotowanie do rozmowy z brokerem ds. ubezpieczenia cybernetycznego powinno być krótkim, praktycznym przeglądem cyberodporności firmy. Broker będzie pytał o ryzyka, zabezpieczenia, dowody, dostawców, incydenty i oczekiwany zakres ochrony.
Najważniejsze obszary to MFA, backup z testem odtworzenia, EDR, aktualizacje, administratorzy, dostęp zdalny, poczta, phishing, płatności, incident response, ciągłość działania, dostawcy i historia incydentów.
Najlepsza zasada brzmi: nie przygotowuj się do polisy przez zgadywanie odpowiedzi. Przygotuj fakty, dowody i plan zamknięcia luk. Wtedy rozmowa z brokerem staje się elementem zarządzania ryzykiem, a nie tylko zakupem kolejnej usługi.
Cyber Resilience Act: co producenci produktów cyfrowych muszą przygotować w 2026 i 2027
Cyber Resilience Act oznacza, że producenci oprogramowania, sprzętu i produktów z elementami cyfrowymi muszą przygotować bezpieczeństwo produktu jako proces, a nie jednorazowy test. W 2026 roku kluczowe jest przygotowanie obsługi podatności, raportowania aktywnie wykorzystywanych podatności i poważnych incydentów, rejestru produktów, klasyfikacji produktów, SBOM, procesu aktualizacji, kontaktu do zgłoszeń i dowodów. W 2027 roku trzeba domknąć ocenę ryzyka, dokumentację techniczną, ocenę zgodności, instrukcje dla użytkowników, okres wsparcia, oznakowanie CE i gotowość do kontroli rynku.
Opracowanie: Zespół redakcyjny CCyber
Cyber Resilience Act, czyli CRA, zmienia podejście do bezpieczeństwa produktów cyfrowych w Unii Europejskiej. Producent oprogramowania, sprzętu, aplikacji, komponentu albo produktu połączonego z siecią musi przygotować nie tylko bezpieczny produkt na dzień sprzedaży, ale też proces utrzymania bezpieczeństwa w całym okresie wsparcia. W 2026 roku najważniejsze jest przygotowanie obsługi podatności i raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu. W 2027 roku producenci muszą domknąć pełną gotowość: ocenę ryzyka cyberbezpieczeństwa, zasadnicze wymagania, dokumentację techniczną, ocenę zgodności, deklarację zgodności UE, oznakowanie CE, instrukcje dla użytkowników, okres wsparcia, SBOM, aktualizacje bezpieczeństwa i dowody na wypadek kontroli rynku.
Lipiec 2026
Cyber Resilience Act to unijne rozporządzenie, które wprowadza horyzontalne wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi. Jego celem jest ograniczenie liczby podatnych produktów na rynku, poprawa przejrzystości dla użytkowników oraz zobowiązanie producentów do dbania o bezpieczeństwo produktu przez cały okres jego przewidywanego użycia.
W praktyce CRA oznacza, że bezpieczeństwo produktu staje się warunkiem wejścia na rynek UE. Producent nie powinien myśleć tylko o funkcjonalności, sprzedaży i UX. Musi także pokazać, że produkt został zaprojektowany, rozwinięty, udokumentowany, oceniony i utrzymywany zgodnie z wymaganiami cyberbezpieczeństwa.
Od 11 września 2026 r. zaczną być stosowane obowiązki raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu z elementami cyfrowymi. To oznacza, że producent powinien mieć już działający proces wykrywania, kwalifikacji, eskalacji i zgłaszania zdarzeń.
Od 11 grudnia 2027 r. będą stosowane główne obowiązki CRA. Nowe produkty z elementami cyfrowymi udostępniane na rynku UE będą musiały spełniać zasadnicze wymagania cyberbezpieczeństwa. Producent będzie musiał mieć gotową dokumentację techniczną, ocenę ryzyka, ocenę zgodności, instrukcje, okres wsparcia i deklarację zgodności.
Firmy, które zaczną przygotowania dopiero pod koniec 2027 roku, będą spóźnione. Proces CRA wymaga zmian w produkcie, kodzie, architekturze, dokumentacji, umowach z dostawcami, procesie aktualizacji, obsłudze podatności i pracy zespołów produktowych.
CRA dotyczy produktów z elementami cyfrowymi udostępnianych na rynku UE. To obejmuje zarówno produkty końcowe, jak i komponenty udostępniane osobno. Produkt z elementami cyfrowymi może być sprzętem, oprogramowaniem albo połączeniem sprzętu i oprogramowania.
To wymaga ostrożnej analizy. CRA dotyczy produktów z elementami cyfrowymi, a definicja obejmuje także rozwiązania zdalnego przetwarzania danych, jeśli są projektowane lub rozwijane przez producenta albo pod jego odpowiedzialnością i jeśli bez nich produkt nie wykonywałby jednej ze swoich funkcji. Dlatego firma SaaS powinna sprawdzić, czy oferuje produkt z elementami cyfrowymi, komponent, aplikację kliencką, agent, oprogramowanie instalowane, urządzenie lub usługę zdalnego przetwarzania niezbędną do funkcji produktu.
Software house nie zawsze będzie producentem w rozumieniu CRA. Jeżeli tworzy oprogramowanie na zamówienie i klient wprowadza produkt na rynek pod własną marką, trzeba ustalić role w umowie. Jeżeli software house rozwija i sprzedaje produkt pod własną nazwą lub znakiem towarowym, może być producentem i powinien przygotować się do obowiązków CRA.
Najważniejszą rolą z perspektywy tego artykułu jest producent. To podmiot, który rozwija lub produkuje produkt z elementami cyfrowymi albo zleca jego projektowanie, rozwój lub produkcję i wprowadza go na rynek pod swoją nazwą lub znakiem towarowym.
Producent odpowiada za bezpieczeństwo produktu, ocenę ryzyka, spełnienie wymagań, dokumentację techniczną, ocenę zgodności, deklarację zgodności, CE, okres wsparcia, aktualizacje i obsługę podatności.
Importer wprowadza na rynek UE produkt producenta spoza UE. Musi upewnić się, że produkt spełnia wymagania i że producent wykonał wymagane działania.
Dystrybutor udostępnia produkt na rynku bez wpływania na jego właściwości. Musi działać z należytą starannością i sprawdzać podstawowe elementy zgodności.
Jeżeli firma zmienia produkt, sprzedaje go pod własną marką, integruje go w większe rozwiązanie albo dokonuje istotnej modyfikacji, powinna sprawdzić, czy nie przejmuje obowiązków producenta.
Producent powinien zacząć od pełnej listy produktów z elementami cyfrowymi. Bez rejestru nie da się ocenić zakresu CRA, klasy produktu, okresu wsparcia, podatności, komponentów i dokumentacji.
Dowód do przygotowania: rejestr produktów CRA z właścicielami i klasyfikacją.
Nie każdy produkt będzie miał taką samą ścieżkę oceny zgodności. Wiele produktów będzie mogło korzystać z samooceny producenta, ale produkty ważne i krytyczne mogą wymagać surowszej procedury, w tym udziału jednostki notyfikowanej.
Dowód do przygotowania: karta klasyfikacji produktu z uzasadnieniem.
To najważniejszy obszar na 2026 rok. Producent musi wiedzieć, jak przyjmuje zgłoszenia podatności, jak je kwalifikuje, jak eskaluje, jak naprawia, jak informuje użytkowników i jak raportuje aktywnie wykorzystywane podatności.
Dowód do przygotowania: procedura vulnerability handling i rejestr podatności.
Od 11 września 2026 r. producent powinien być gotowy do raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu. Trzeba przygotować role, ścieżkę eskalacji, szablony i decyzje, zanim pojawi się incydent.
Dowód do przygotowania: playbook raportowania CRA, szablony zgłoszeń i ćwiczenie ścieżki eskalacji.
CRA wymaga identyfikacji i dokumentowania podatności oraz komponentów zawartych w produktach, w tym przygotowania software bill of materials w powszechnie używanym i maszynowo czytelnym formacie, co najmniej dla zależności najwyższego poziomu.
Dowód do przygotowania: SBOM, polityka komponentów i raport podatności zależności.
Producent powinien pokazać, że bezpieczeństwo jest częścią rozwoju produktu, a nie testem na końcu. Secure SDLC powinien obejmować wymagania bezpieczeństwa, architekturę, kod, testy, przeglądy i aktualizacje.
Dowód do przygotowania: polityka secure SDLC, wyniki testów i dowody przeglądów.
CRA wymaga skutecznych mechanizmów dystrybucji aktualizacji, tak aby podatności były naprawiane lub łagodzone terminowo. Dla wielu produktów aktualizacje bezpieczeństwa powinny być łatwe dla użytkownika, bezpieczne i oddzielone od aktualizacji funkcjonalnych, jeśli to technicznie możliwe.
Dowód do przygotowania: procedura aktualizacji bezpieczeństwa i raport testu procesu aktualizacji.
Każdy produkt w zakresie CRA powinien mieć ocenę ryzyka cyberbezpieczeństwa. Ocena powinna wskazywać ryzyka, środowisko użycia, użytkowników, interfejsy, dane, możliwe nadużycia, podatności, komponenty i wymagania, które są stosowane.
Dowód do przygotowania: product cybersecurity risk assessment.
Producent musi pokazać, jak produkt spełnia zasadnicze wymagania cyberbezpieczeństwa z załącznika I. W praktyce chodzi o to, aby produkt był projektowany bez znanych możliwych do wykorzystania podatności, miał bezpieczne ustawienia domyślne, ograniczoną powierzchnię ataku, kontrolę dostępu, ochronę danych, aktualizacje bezpieczeństwa i obsługę podatności.
Dowód do przygotowania: matryca wymagań CRA z kontrolami, testami i dowodami.
Dokumentacja techniczna będzie jednym z najważniejszych dowodów zgodności. Powinna umożliwiać wykazanie, że produkt spełnia wymagania CRA i że producent prowadzi procesy bezpieczeństwa produktu.
Dowód do przygotowania: komplet dokumentacji technicznej zgodnej z CRA.
Producent musi dobrać właściwą procedurę oceny zgodności. Dla wielu produktów możliwa będzie samoocena. Dla produktów ważnych lub krytycznych może być wymagana surowsza procedura lub udział jednostki notyfikowanej.
Dowód do przygotowania: decyzja o ścieżce oceny zgodności i komplet dowodów.
Po pozytywnej ocenie zgodności producent będzie mógł wystawić deklarację zgodności UE i oznaczyć produkt CE. To nie jest tylko formalność. CE oznacza, że producent deklaruje spełnienie wymagań mających zastosowanie do produktu.
Dowód do przygotowania: deklaracja zgodności UE i procedura oznakowania CE.
CRA wymaga, aby użytkownik dostał informacje potrzebne do bezpiecznego użycia produktu. Chodzi między innymi o kontakt do zgłaszania podatności, przeznaczenie produktu, właściwości bezpieczeństwa, okres wsparcia, aktualizacje bezpieczeństwa, bezpieczne uruchomienie i bezpieczne wycofanie z użycia.
Dowód do przygotowania: instrukcja bezpieczeństwa produktu i publiczne informacje o wsparciu.
CRA ma skutki prawne, ale jego wdrożenie jest głównie zadaniem produktowym, inżynieryjnym i operacyjnym. Bez zmian w procesie rozwoju produktu sama analiza prawna nie wystarczy.
Firma nie wie, które produkty są w zakresie, które są komponentami, które są ważne lub krytyczne i które wersje są nadal wspierane.
Od 2026 roku raportowanie aktywnie wykorzystywanych podatności wymaga szybkiej ścieżki decyzyjnej. Bez procesu firma może nie zdążyć z oceną i zgłoszeniem.
Lista komponentów nie wystarczy. Trzeba mieć proces aktualizacji, monitorowania podatności i powiązania komponentów z wersjami produktu.
CRA wymaga bezpieczeństwa w cyklu życia produktu. Test na końcu nie zastąpi secure SDLC, threat modeling i kontroli zależności.
Użytkownik musi wiedzieć, jak długo będzie otrzymywał wsparcie bezpieczeństwa. Producent musi to uzasadnić i udokumentować.
Jeżeli produkt okaże się ważny lub krytyczny, producent może potrzebować udziału jednostki notyfikowanej. To wymaga czasu i planowania.
Dokumentacja, testy, aktualizacje, decyzje ryzyka i obsługa podatności muszą zostawiać ślad. Bez dowodów trudno wykazać zgodność.
Firma SaaS i software house rozwija produkt do zarządzania dostępem dla klientów B2B. Produkt składa się z aplikacji webowej, agenta instalowanego u klienta, API, komponentów open source, modułu logowania i integracji z usługami chmurowymi. Firma początkowo zakłada, że CRA dotyczy głównie urządzeń IoT, więc odkłada temat.
Po analizie okazuje się, że agent instalowany u klienta i produkt zarządzania dostępem mogą być produktem z elementami cyfrowymi w zakresie CRA. Firma musi przygotować rejestr produktu, ocenę ryzyka, SBOM, proces zgłaszania podatności, obsługę aktualizacji bezpieczeństwa, instrukcje dla klientów i analizę ścieżki oceny zgodności.
W 2026 roku firma uruchamia kontakt do podatności, CVD, rejestr podatności, SBOM i playbook raportowania. W 2027 roku domyka dokumentację techniczną, testy, ocenę zgodności, instrukcje i proces CE. Dzięki temu CRA staje się elementem dojrzałości produktu, a nie panicznym projektem pod koniec 2027 roku.
ccyber.io pomaga producentom produktów cyfrowych przygotować się do Cyber Resilience Act w sposób praktyczny, produktowy i dowodowy. Łączymy perspektywę regulacyjną, security engineering, secure SDLC, testów bezpieczeństwa, SBOM, podatności, aktualizacji i dokumentacji zgodności.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest CRA Product Readiness Workshop. W krótkim warsztacie można ustalić, które produkty są w zakresie, które obowiązki są najpilniejsze w 2026 roku, jaka ścieżka oceny zgodności może być potrzebna i jakie dowody trzeba przygotować przed 2027 rokiem.
Nie. CRA dotyczy produktów z elementami cyfrowymi, czyli wielu produktów hardware i software, w tym aplikacji, komponentów, firmware, urządzeń sieciowych, produktów bezpieczeństwa, systemów wbudowanych i produktów połączonych z siecią.
Najważniejsze jest przygotowanie procesu obsługi podatności i raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu.
Najważniejsze jest pełne przygotowanie produktu do wymagań CRA: ocena ryzyka, zasadnicze wymagania, dokumentacja techniczna, ocena zgodności, instrukcje, okres wsparcia, CE i repozytorium dowodów.
Nie. Wiele produktów będzie mogło przejść samoocenę zgodności. Produkty ważne lub krytyczne mogą wymagać surowszej ścieżki, a w określonych przypadkach udziału jednostki notyfikowanej.
Produkty wprowadzone na rynek przed 11 grudnia 2027 r. co do zasady będą podlegały wymaganiom tylko wtedy, gdy od tej daty zostaną istotnie zmodyfikowane. Obowiązki raportowania z art. 14 mają jednak zastosowanie do produktów w zakresie CRA także wtedy, gdy były wprowadzone przed tą datą.
CRA wymaga przygotowania SBOM jako elementu identyfikacji komponentów i podatności. Publiczne udostępnienie użytkownikom to osobny temat. Producent powinien przygotować SBOM oraz procedury udostępniania właściwym podmiotom, jeśli będzie to wymagane.
Okres wsparcia powinien być określony przez producenta i co do zasady wynosić co najmniej 5 lat, chyba że przewidywany czas użycia produktu jest krótszy. Trzeba go jasno wskazać użytkownikowi i uzasadnić w dokumentacji.
Zacznij od rejestru produktów, klasyfikacji CRA, oceny, czy produkt jest w zakresie, procesu obsługi podatności, SBOM i roadmapy działań przed 11 września 2026 r. oraz 11 grudnia 2027 r.
Cyber Resilience Act wymaga od producentów produktów cyfrowych przejścia od myślenia „wydaliśmy produkt” do myślenia „utrzymujemy bezpieczny produkt przez cały okres wsparcia”. To oznacza zmiany w procesach produktowych, inżynieryjnych, prawnych, jakościowych i operacyjnych.
W 2026 roku producent powinien skupić się na raportowaniu, obsłudze podatności, SBOM, aktualizacjach i podstawach secure SDLC. W 2027 roku musi domknąć pełną gotowość: ocenę ryzyka, wymagania, dokumentację, ocenę zgodności, deklarację zgodności, CE i informacje dla użytkowników.
Najlepsza zasada brzmi: nie czekaj na 2027 rok. Produkt, którego architektura, komponenty, aktualizacje i dokumentacja nie są przygotowane już dziś, może wymagać znacznie więcej pracy niż sama formalna deklaracja zgodności.
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.