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.
Czy moja firma podlega NIS2? Prosty przewodnik dla MŚP
MŚP nie powinno odpowiadać na pytanie o NIS2 wyłącznie na podstawie liczby pracowników albo kodu PKD. Trzeba sprawdzić pięć rzeczy: sektor działalności, wielkość firmy, wyjątki niezależne od wielkości, rolę w łańcuchu dostaw oraz aktualne przepisy krajowe wdrażające NIS2. Mała firma często nie będzie bezpośrednio podmiotem kluczowym lub ważnym, ale może być pośrednio objęta wymaganiami klientów, jeśli dostarcza IT, software, chmurę, usługi zarządzane, komponenty, serwis, dane albo procesy dla podmiotów regulowanych.
Opracowanie: Zespół redakcyjny CCyber
Nie każda mała lub średnia firma w Polsce podlega NIS2 bezpośrednio. Sama informacja, że firma jest MŚP, nie wystarczy. Trzeba sprawdzić sektor działalności, rodzaj świadczonych usług, wielkość przedsiębiorstwa, powiązania kapitałowe, wyjątki niezależne od wielkości oraz to, czy firma jest dostawcą dla podmiotu regulowanego. Co do zasady NIS2 obejmuje głównie średnie i duże podmioty z określonych sektorów. Małe i mikrofirmy mogą jednak zostać objęte w wyjątkowych przypadkach albo odczuć NIS2 pośrednio przez wymagania klientów, umowy, ankiety bezpieczeństwa i audyty dostawców. Najbezpieczniejszym podejściem jest przygotowanie krótkiej analizy podlegania z datą, źródłami, decyzją zarządu i planem minimum cyberbezpieczeństwa.
Lipiec 2026
NIS2 jest dyrektywą Unii Europejskiej. Oznacza to, że dla praktycznej odpowiedzi w Polsce trzeba patrzeć na dyrektywę, ale także na krajowe przepisy wdrażające, czyli przede wszystkim nowelizację przepisów dotyczących krajowego systemu cyberbezpieczeństwa. Dlatego odpowiedź na pytanie „czy moja firma podlega NIS2?” powinna mieć datę i wskazanie wersji przepisów, na której została oparta.
Ten przewodnik pomaga przygotować praktyczną analizę. Nie zastępuje indywidualnej opinii prawnej, ale pokazuje, jak zarząd MŚP powinien uporządkować temat przed rozmową z prawnikiem, audytorem, klientem lub dostawcą cyberbezpieczeństwa.
Jeżeli firma jest mikro lub mała, nie działa w szczególnym sektorze i nie świadczy usług krytycznych dla większych podmiotów, prawdopodobnie nie będzie bezpośrednio podmiotem kluczowym lub ważnym. Nie oznacza to jednak, że może zignorować temat.
Jeżeli firma jest średnia, działa w jednym z sektorów NIS2 albo obsługuje klientów z takich sektorów, powinna wykonać formalną analizę podlegania.
Jeżeli firma świadczy usługi IT, chmurowe, zarządzane, bezpieczeństwa, DNS, hostingowe, telekomunikacyjne, zaufania, rejestracji domen albo utrzymuje systemy klientów regulowanych, powinna potraktować NIS2 jako temat priorytetowy niezależnie od tego, czy finalnie będzie objęta bezpośrednio.
Dopiero odpowiedź na te pytania pozwala przygotować rozsądny wniosek. Sam kod PKD, sama liczba pracowników albo sama branżowa etykieta „IT” nie wystarczą.
NIS2 obejmuje sektory wysokiej krytyczności oraz pozostałe sektory krytyczne. Dla MŚP najważniejsze jest sprawdzenie, czy rzeczywista działalność firmy pasuje do jednego z tych sektorów lub czy firma świadczy usługi dla klientów z tych sektorów.
Mała firma produkcyjna może myśleć, że NIS2 jej nie dotyczy, ale jeśli produkuje komponenty dla sektora medycznego, transportowego, energetycznego lub technologicznego, może zostać objęta wymaganiami klientów. Software house może nie być oczywistym podmiotem kluczowym, ale jeśli utrzymuje system dla szpitala, operatora infrastruktury, banku albo dostawcy usług zarządzanych, może dostać wymagania NIS2 w umowie.
Co do zasady NIS2 obejmuje podmioty średnie i duże z sektorów wskazanych w dyrektywie. W praktyce trzeba sprawdzić liczbę pracowników, obrót, sumę bilansową oraz powiązania z innymi podmiotami.
W NIS2 szczególnie ważne jest to, czy firma kwalifikuje się jako średnie przedsiębiorstwo albo przekracza progi średniego przedsiębiorstwa. Trzeba też uważać na firmy partnerskie i powiązane, bo grupa kapitałowa może wpływać na kwalifikację.
Jeżeli firma ma mniej niż 50 pracowników i nie świadczy szczególnych usług, często będzie poza bezpośrednim zakresem NIS2. Jeżeli firma ma od 50 do 249 pracowników i działa w sektorze objętym NIS2, analiza podlegania jest obowiązkowym zadaniem zarządu.
Niektóre podmioty mogą być objęte NIS2 niezależnie od wielkości. To szczególnie ważne dla firm technologicznych, telekomunikacyjnych, domenowych, usług zaufania i podmiotów o szczególnym znaczeniu dla społeczeństwa lub gospodarki.
Mała firma nie powinna automatycznie uznawać, że jest poza zakresem. Jeżeli świadczy usługę o szczególnym znaczeniu, działa w obszarze infrastruktury cyfrowej albo jest niezbędna dla krytycznej usługi klienta, potrzebna jest dokładniejsza analiza.
NIS2 dzieli podmioty na kluczowe i ważne. Różnica ma znaczenie dla nadzoru i egzekwowania obowiązków. Dla MŚP najważniejsze jest jednak najpierw ustalić, czy firma w ogóle jest bezpośrednio w zakresie.
Podmiot kluczowy to zasadniczo organizacja o większym znaczeniu, często większa i działająca w sektorach wysokiej krytyczności albo spełniająca szczególne kryteria. Podmioty kluczowe są zwykle objęte silniejszym nadzorem.
Podmiot ważny to organizacja objęta NIS2, która nie kwalifikuje się jako podmiot kluczowy. Obowiązki zarządzania ryzykiem i zgłaszania incydentów nadal mają znaczenie, ale reżim nadzorczy może być inny.
Dla większości MŚP najpierw trzeba odpowiedzieć: czy jesteśmy bezpośrednio w zakresie. Dopiero później warto rozstrzygać, czy status będzie kluczowy czy ważny.
To najważniejsza część dla wielu MŚP. Firma może nie być bezpośrednio podmiotem kluczowym lub ważnym, ale może obsługiwać klientów, którzy podlegają NIS2. Wtedy wymagania pojawią się w umowach, ankietach bezpieczeństwa, audytach, postępowaniach zakupowych i wymaganiach dostępowych.
Nie. PKD może być pomocnym punktem startu, ale nie zastępuje analizy rzeczywistej działalności. NIS2 dotyczy typów usług, sektorów, znaczenia działalności, skali i roli organizacji. Firma może mieć kod PKD ogólny, ale w praktyce świadczyć usługę krytyczną dla klienta regulowanego. Może też mieć kod technologiczny, ale wykonywać działalność poza zakresem NIS2.
Firma działa w sektorze NIS2, spełnia próg wielkości albo wyjątek niezależny od wielkości. W takim przypadku trzeba przygotować pełniejszy program zgodności i dowodów.
Firma działa blisko sektora regulowanego, ma nietypową rolę, jest częścią grupy, świadczy usługę o szczególnym znaczeniu albo jej kwalifikacja zależy od krajowych przepisów.
To bardzo częsty scenariusz dla MŚP. Firma nie musi być formalnym podmiotem regulowanym, ale klienci będą wymagać konkretnych zabezpieczeń i dowodów.
Firma nie działa w sektorze objętym, nie spełnia progu wielkości i nie ma klientów regulowanych. Warto jednak monitorować zmiany przepisów, klientów i modelu działalności.
Software house może nie być bezpośrednio podmiotem kluczowym lub ważnym, jeśli nie spełnia kryteriów NIS2. Może jednak być ważnym dostawcą dla podmiotu z sektora zdrowia. Klient może wymagać bezpiecznego SDLC, testów, zarządzania podatnościami, SLA, zgłaszania incydentów i kontroli podwykonawców.
Jeżeli klient produkcyjny podlega NIS2, dostawca IT może zostać objęty wymaganiami umownymi. Szczególnie jeśli ma dostęp administratora, obsługuje backup, konta użytkowników, sieć lub systemy krytyczne.
Typowy mały sklep internetowy zwykle nie będzie bezpośrednio objęty tylko dlatego, że działa online. Trzeba jednak sprawdzić skalę, typ usługi, ewentualny status platformy, dane klientów, dostawców płatności i wymagania umów.
Taka firma powinna wykonać analizę podlegania. Może być średnim przedsiębiorstwem, dostawcą usług cyfrowych lub ICT, a jednocześnie dostawcą dla klientów regulowanych. Nawet jeśli ostateczna kwalifikacja wymaga analizy prawnej, wymagania klientów są bardzo prawdopodobne.
Sama wielkość może wskazywać na brak bezpośredniego podlegania. Jeżeli jednak firma dostarcza krytyczne komponenty do sektora medycznego, energetycznego, transportowego albo dla dużych klientów regulowanych, może odczuć NIS2 przez łańcuch dostaw.
Jeżeli analiza wskazuje, że firma może być bezpośrednio objęta NIS2, nie należy czekać na audyt albo pismo od klienta. Trzeba przygotować plan gotowości.
To najczęstszy scenariusz dla MŚP. Wtedy firma powinna przygotować „NIS2 supplier readiness”, czyli pakiet dowodów i kontroli, których będą oczekiwać klienci regulowani.
Dostawca, który potrafi szybko odpowiedzieć na ankietę NIS2, pokazać dowody i wyjaśnić swój model bezpieczeństwa, ma przewagę w sprzedaży do większych klientów.
Mała firma może być pośrednio objęta przez klientów albo bezpośrednio przez wyjątek. Najpierw trzeba sprawdzić fakty.
PKD nie pokazuje pełnego obrazu usług, klientów, dostępu do systemów i znaczenia firmy w łańcuchu dostaw.
Wielkość firmy może zależeć od spółek partnerskich i powiązanych. To może zmienić kwalifikację.
Firma może być poza bezpośrednim zakresem, ale klient z sektora regulowanego może narzucić wymagania umowne.
Ustna odpowiedź „NIS2 nas nie dotyczy” jest słaba. Potrzebna jest notatka lub analiza z uzasadnieniem.
Nawet jeśli kwalifikacja wymaga doprecyzowania, firma może już wdrożyć minimum: MFA, backup, incident response, access review i szkolenia.
NIS2 to nie tylko analiza prawna. To także ryzyko cyber, dostawcy, incydenty, ciągłość działania i dowody.
Większe firmy będą pytać dostawców o zabezpieczenia. MŚP powinno mieć gotowe odpowiedzi i dowody.
Nawet jeśli firma nie podlega bezpośrednio NIS2, podstawowe zabezpieczenia są potrzebne. Chronią przed ransomware, phishingiem, przejęciem poczty, utratą danych i problemami w relacjach z klientami.
Firma SaaS zatrudnia 42 osoby. Dostarcza platformę do obsługi dokumentów dla klientów z produkcji, ochrony zdrowia i administracji lokalnej. Zarząd pyta, czy firma podlega NIS2, bo sama firma jest mała i nie uważa się za podmiot krytyczny.
Analiza pokazuje, że bezpośrednie podleganie wymaga sprawdzenia szczegółów usługi, wielkości, klientów i przepisów krajowych. Jednocześnie widać, że firma jest pośrednio dotknięta NIS2, bo kilku klientów może być podmiotami regulowanymi. Klienci już pytają o MFA, backup, zgłaszanie incydentów, testy bezpieczeństwa i podwykonawców.
Firma nie czeka na ostateczną interpretację. W 90 dni przygotowuje analizę podlegania, pakiet dowodów dla klientów, MFA, test restore, incident response plan, procedurę zgłaszania incydentów klientom i ocenę dostawców. Dzięki temu jest gotowa zarówno na wymagania klientów, jak i na dalszą analizę prawną.
ccyber.io pomaga MŚP ustalić, czy NIS2 może dotyczyć firmy bezpośrednio lub pośrednio. Łączymy perspektywę prawną, techniczną, dostawczą i biznesową. Nie kończymy na odpowiedzi „tak” lub „nie”. Przygotowujemy praktyczny plan działań i pakiet dowodów, który pomaga w rozmowach z klientami, audytorami i ubezpieczycielami.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Applicability Workshop dla MŚP. W krótkim warsztacie można ustalić, czy firma może być bezpośrednio objęta, czy jest pośrednio dotknięta przez klientów i jakie minimum warto wdrożyć niezależnie od finalnej kwalifikacji.
Nie. Mała firma zwykle nie podlega bezpośrednio tylko dlatego, że prowadzi działalność gospodarczą. Trzeba jednak sprawdzić sektor, usługę, wyjątki i klientów.
Nie. Średnia firma podlega wtedy, gdy działa w sektorze lub świadczy usługę objętą NIS2 albo spełnia szczególne kryteria. Sama wielkość nie wystarczy.
Nie. PKD może pomóc, ale nie zastępuje analizy rzeczywistej działalności, klientów, usług, danych, dostępu do systemów i roli w łańcuchu dostaw.
Nie zawsze bezpośrednio. Może jednak zostać objęty wymaganiami klienta w umowie, audycie, ankiecie bezpieczeństwa i procedurach zgłaszania incydentów.
Tak, jeśli spełnia kryteria sektora, wielkości albo szczególnej usługi. Nawet jeśli nie jest objęty bezpośrednio, może być pośrednio dotknięty jako dostawca systemów dla podmiotów regulowanych.
Przygotuj analizę podlegania, zbierz dane o firmie, usługach i klientach, sprawdź sektory NIS2 i skonsultuj wynik z prawnikiem lub doradcą. Równolegle wdrażaj podstawowe zabezpieczenia.
Najczęściej: MFA, backup, test odtworzenia, incident response plan, access review, szkolenia, zarządzanie podatnościami, bezpieczeństwo dostawców i procedura zgłaszania incydentów.
Zacznij od pięciu rzeczy: lista usług, lista klientów z sektorów regulowanych, dane o wielkości firmy, analiza wyjątków niezależnych od wielkości i szybki przegląd podstawowych zabezpieczeń.
Pytanie „czy moja firma podlega NIS2?” wymaga praktycznej analizy. Nie wystarczy sprawdzić wielkości firmy albo kodu PKD. Trzeba ocenić sektor, usługę, wyjątki, klientów, powiązania kapitałowe, dostęp do danych i systemów oraz aktualne przepisy krajowe.
Dla wielu MŚP najważniejszy będzie wpływ pośredni. Firma może nie być formalnym podmiotem kluczowym lub ważnym, ale jako dostawca dla podmiotu regulowanego będzie musiała pokazać zabezpieczenia, procedury i dowody.
Najlepsza zasada brzmi: nie czekaj na ankietę klienta albo kontrolę. Przygotuj analizę podlegania, wdroż minimum cyberbezpieczeństwa i zbierz dowody, które pokażą, że firma zarządza ryzykiem w praktyce.
Finansowanie cyberbezpieczeństwa: na co powinny zwrócić uwagę polskie firmy w 2026 roku
W 2026 roku polskie firmy powinny patrzeć na finansowanie cyberbezpieczeństwa szerzej niż tylko na „dotację na firewall”. Największe szanse pojawiają się tam, gdzie cyberbezpieczeństwo jest częścią cyfryzacji, automatyzacji, Przemysłu 4.0, zgodności z NIS2, przygotowania produktów pod CRA, odporności operacyjnej, chmury, AI, backupu, zarządzania dostępem i testów bezpieczeństwa. Najlepiej przygotowane projekty mają diagnozę ryzyka, zakres techniczny, budżet, harmonogram, dowody potrzeby, powiązanie z regulacjami i mierzalne efekty biznesowe.
Opracowanie: Zespół redakcyjny CCyber
W 2026 roku polskie firmy powinny szukać finansowania cyberbezpieczeństwa nie tylko w programach nazwanych wprost „cyber”. W praktyce cyberbezpieczeństwo może być częścią projektów cyfryzacji, automatyzacji, transformacji cyfrowej, Przemysłu 4.0, rozwoju produktów cyfrowych, zgodności z NIS2, przygotowania pod Cyber Resilience Act, odporności operacyjnej, chmury, AI, backupu, zarządzania tożsamością, testów bezpieczeństwa i szkoleń. Najważniejsze jest dobre przygotowanie projektu: diagnoza ryzyka, lista systemów, uzasadnienie biznesowe, budżet, harmonogram, mierzalne efekty, powiązanie z regulacjami i dowody, że firma potrafi wdrożyć oraz utrzymać zakupione rozwiązania. Sama lista narzędzi rzadko wystarczy. Instytucje finansujące chcą widzieć cel, efekt i trwałość.
Lipiec 2026
Rok 2026 jest szczególny, bo firmy jednocześnie mierzą się z kilkoma trendami. Rosną wymagania klientów, ubezpieczycieli, audytorów i regulatorów. NIS2 zwiększa presję na zarządzanie ryzykiem cyber i dostawcami. Cyber Resilience Act wymaga przygotowania producentów software i hardware do bezpieczeństwa produktów cyfrowych. DORA wpływa na sektor finansowy i dostawców ICT. AI zwiększa tempo cyfryzacji, ale też tworzy nowe ryzyka. Ransomware i phishing nadal powodują realne przestoje oraz straty.
To oznacza, że cyberbezpieczeństwo przestaje być wyłącznie kosztem IT. Staje się elementem konkurencyjności, odporności operacyjnej, zgodności regulacyjnej i dostępu do większych klientów. Z tego powodu finansowanie cyberbezpieczeństwa warto planować nie jako „projekt bezpieczeństwa”, ale jako projekt rozwoju firmy.
Polskie firmy często szukają programów pod hasłem „dotacja na cyberbezpieczeństwo”. To zbyt wąskie podejście. W praktyce koszty cyber mogą pojawić się w projektach dotyczących cyfryzacji, automatyzacji, wdrożenia systemów IT, chmury, AI, Przemysłu 4.0, e-usług, bezpieczeństwa produktu, zgodności z regulacjami albo odporności operacyjnej.
Dlatego dobra strategia finansowania polega na znalezieniu właściwego celu programu, a dopiero potem pokazaniu, dlaczego cyberbezpieczeństwo jest niezbędnym elementem tego celu.
Portal Funduszy Europejskich wskazuje, że cyfryzacja firm może być wspierana przez dotacje, granty i preferencyjne pożyczki. W praktyce wsparcie może obejmować gotowe rozwiązania, licencje, technologie, prace programistyczne oraz doradztwo przedwdrożeniowe. To ważne, bo cyberbezpieczeństwo często jest częścią bezpiecznej cyfryzacji, a nie osobnym produktem.
Dig.IT jest przykładem instrumentu, w którym cyberbezpieczeństwo może pojawić się jako element wdrażania nowoczesnych technologii cyfrowych. Program jest skierowany do mikro, małych i średnich przedsiębiorstw z sektora przetwórstwa przemysłowego oraz usług produkcyjnych. W jego opisie pojawiają się między innymi big data, AI i cyberbezpieczeństwo.
Dla firm produkcyjnych cyberbezpieczeństwo często jest powiązane z automatyzacją, integracją systemów, danymi produkcyjnymi, chmurą, IoT, systemami klasy MES, ERP albo SCADA. Jeżeli projekt cyfryzacji zwiększa zależność firmy od systemów cyfrowych, to bezpieczeństwo powinno być częścią zakresu.
Instrumenty pożyczkowe mogą być dobrym rozwiązaniem dla większych projektów, w których cyberbezpieczeństwo jest częścią szerokiej modernizacji cyfrowej. Pożyczki na cyfrową i zieloną transformację przedsiębiorstw są kierowane do firm z całej Polski, a w części cyfrowej mogą dotyczyć między innymi transformacji w kierunku Przemysłu 4.0, automatyzacji, robotyzacji, chmury, analizy danych i systemów cyfrowych.
EDIH to szczególnie ważna ścieżka dla MŚP, które nie są jeszcze gotowe na duży projekt inwestycyjny. Centra EDIH oferują audyty, doradztwo, test before invest, szkolenia, rozwój kompetencji, wsparcie w pozyskaniu finansowania, networking i dostęp do ekosystemu innowacji. W polskiej ofercie EDIH pojawia się także cyberbezpieczeństwo.
W 2026 roku warto monitorować programy regionalne, bo część wsparcia na cyfryzację i rozwój MŚP jest dostępna na poziomie województw. Portal Funduszy Europejskich wskazuje przykłady pożyczek i instrumentów regionalnych na cyfryzację przedsiębiorstw.
Digital Europe Programme jest ważnym źródłem finansowania projektów dotyczących cyberbezpieczeństwa, AI, kompetencji cyfrowych i infrastruktury cyfrowej. Dla wielu firm będzie to ścieżka trudniejsza niż programy krajowe, bo często wymaga konsorcjum, partnerów międzynarodowych, większego zakresu i zgodności z celami programu.
Nie każdy projekt cyberbezpieczeństwa musi być finansowany dotacją. W większych projektach warto rozważyć finansowanie zwrotne, pożyczki preferencyjne, gwarancje, leasing technologiczny lub finansowanie inwestycyjne. W 2026 roku szczególnie istotne będzie łączenie cyberbezpieczeństwa z odpornością biznesu, technologią, automatyzacją i cyfrową suwerennością.
Wniosek nie powinien zaczynać się od „chcemy kupić narzędzie”. Powinien zaczynać się od problemu: firma ma ryzyko ransomware, brak testowanego backupu, zbyt szerokie dostępy, wymagania klienta, NIS2, CRA, ryzyko OT albo brak bezpiecznego procesu aktualizacji produktu.
Cyberbezpieczeństwo finansuje się łatwiej, gdy jest powiązane z konkretnym efektem biznesowym.
Nie każdy koszt cyber będzie kwalifikowany w każdym programie. Trzeba sprawdzić regulamin, katalog kosztów, pomoc publiczną, limity, wkład własny, terminy, sposób płatności i wymagania trwałości.
Instytucje finansujące chcą widzieć rezultat. Dla cyberbezpieczeństwa warto używać wskaźników praktycznych.
Jednorazowy zakup nie wystarczy. Trzeba pokazać, kto będzie utrzymywał rozwiązanie, kto będzie reagował na alerty, kto będzie aktualizował procedury, kto będzie wykonywał testy i jak firma utrzyma efekty po zakończeniu finansowania.
Jeżeli firma chce kupić narzędzie, ale nie pokazuje ryzyka, celu i efektu, projekt może wyglądać jak zwykły koszt operacyjny.
Sama wymiana jednego narzędzia na drugie może być trudna do uzasadnienia, jeśli nie pokazuje poprawy odporności, zgodności albo dojrzałości.
Cyberbezpieczeństwo finansowane z grantów powinno mieć właściciela po stronie firmy, nie tylko dostawcę technologii.
Jeżeli firma nie pokaże, kto będzie utrzymywał rozwiązanie po wdrożeniu, projekt może być oceniony słabiej.
Nie każdy program finansuje wszystko. Nawet dobry projekt cyber może nie pasować do programu, jeśli nie realizuje jego celu.
Najpierw trzeba sprawdzić cel programu, kwalifikowalność kosztów i wymagania. Dopiero potem dobierać zakres techniczny.
Bez audytu lub oceny ryzyka trudno uzasadnić, dlaczego projekt jest potrzebny.
Hasło „poprawa cyberbezpieczeństwa” jest za szerokie. Lepiej wskazać konkretne ryzyka, systemy, kontrole i efekty.
Projekt powinien pokazywać, jak firma zmierzy poprawę bezpieczeństwa.
Wdrożenie EDR, SIEM albo backupu bez ludzi, procesów i utrzymania może nie dać trwałego efektu.
Przygotowanie dobrego budżetu wymaga czasu, porównania opcji i dopasowania zakresu do programu.
NIS2, CRA, DORA, ISO 27001 i wymagania klientów mogą być silnym uzasadnieniem projektu. Warto je pokazać.
Wniosek cyberbezpieczeństwa wymaga perspektywy technicznej, finansowej i biznesowej. Jedna osoba rzadko ma pełny obraz.
Firma ma ryzyko ransomware, brak testowanego backupu, brak MFA na kontach krytycznych, wymagania klienta albo obowiązki regulacyjne.
Zwiększenie odporności cyfrowej, ograniczenie ryzyka przestoju, spełnienie wymagań NIS2 lub CRA, bezpieczne wdrożenie technologii cyfrowych.
Diagnoza, wdrożenie technologii, procedury, testy, szkolenia, dokumentacja i dowody.
MFA na systemach krytycznych, test restore, skrócony czas odtworzenia, zamknięte podatności, bezpieczniejszy produkt, przeszkolony zespół.
Właściciel kontroli, cykliczne testy, budżet utrzymaniowy, procedury, raportowanie do zarządu.
Dla firm objętych NIS2 lub współpracujących z podmiotami regulowanymi projekt może dotyczyć zarządzania ryzykiem, incident response, backupu, dostawców, szkoleń, logów, MFA, podatności i dowodów zgodności.
Dla producentów oprogramowania i hardware projekt może dotyczyć bezpieczeństwa produktu: SBOM, secure SDLC, testów, zarządzania podatnościami, procesu aktualizacji, obsługi zgłoszeń i dokumentacji technicznej.
Dla firm finansowych i dostawców ICT projekt może dotyczyć odporności cyfrowej, testów, rejestru dostawców, umów ICT, incident reporting, backupu, ciągłości działania i audytowalności.
Dla firm przygotowujących się do certyfikacji projekt może dotyczyć rejestru ryzyk, polityk, kontroli, audytów, szkoleń, zarządzania dostawcami i repozytorium dowodów.
Firma produkcyjna zatrudnia 120 osób. Planuje wdrożyć system MES, integrację z ERP, automatyczne zbieranie danych produkcyjnych i panel klienta B2B. Początkowo projekt jest opisany jako cyfryzacja produkcji. Po analizie okazuje się jednak, że nowe rozwiązanie zwiększy zależność firmy od chmury, sieci przemysłowej, kont użytkowników, integracji API i danych produkcyjnych.
Firma rozszerza projekt o cyberbezpieczeństwo: segmentację sieci, MFA dla kont krytycznych, backup konfiguracji, test odtworzenia, monitoring, szkolenie administratorów i procedurę incydentową. Wniosek nie opisuje cyber jako dodatku, ale jako warunek bezpiecznej transformacji cyfrowej.
Dzięki temu projekt jest spójny: automatyzacja poprawia efektywność, a cyberbezpieczeństwo ogranicza ryzyko przestoju, utraty danych i błędów operacyjnych. Firma przygotowuje też wskaźniki: liczba systemów objętych MFA, czas odtworzenia, liczba przeszkolonych osób i test restore po wdrożeniu.
ccyber.io pomaga firmom przygotować projekty cyberbezpieczeństwa do finansowania z dotacji, grantów, pożyczek i programów cyfryzacji. Łączymy perspektywę bezpieczeństwa, regulacji, finansowania, technologii i biznesu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Funding Readiness Workshop. W krótkim warsztacie można ustalić, co firma chce sfinansować, które źródła finansowania pasują do projektu, jakie koszty mogą być problematyczne i jak przygotować projekt, który ma sens biznesowo oraz technicznie.
To zależy od naboru. Często cyberbezpieczeństwo nie występuje jako osobny cel, ale może być częścią cyfryzacji, transformacji cyfrowej, Przemysłu 4.0, zgodności regulacyjnej albo rozwoju produktu cyfrowego.
Może, ale tylko wtedy, gdy pasuje do zasad konkretnego programu i jest uzasadniony w projekcie. Sam zakup narzędzia bez diagnozy i efektu może być trudniejszy do obrony.
Tak. EDIH oferują MŚP usługi związane z transformacją cyfrową, w tym audyty, doradztwo, test before invest, szkolenia, wsparcie w pozyskaniu finansowania oraz usługi dotyczące cyberbezpieczeństwa.
Tak. Wdrożenia ERP, MES, SCADA, IoT, AI, chmury i automatyzacji powinny zawierać element bezpieczeństwa, bo zwiększają zależność firmy od technologii cyfrowych.
W wielu przypadkach elementy przygotowania pod NIS2 mogą być częścią projektu cyfryzacji, odporności, zarządzania ryzykiem, szkoleń, backupu, incydentów albo dostawców. Trzeba sprawdzić zasady konkretnego programu.
Najważniejsze jest dopasowanie projektu do celu programu, jasne uzasadnienie ryzyka, mierzalne efekty, realistyczny budżet, harmonogram i trwałość rezultatów.
Zacznij od diagnozy cyberbezpieczeństwa, listy ryzyk, mapy systemów krytycznych i sprawdzenia aktualnych naborów. Potem dopasuj projekt do źródła finansowania, a nie odwrotnie.
Tak. Nabory są konkurencyjne, a terminy się zmieniają. Firma powinna mieć plan minimum do wdrożenia z własnych środków, pożyczki albo etapowego finansowania.
Finansowanie cyberbezpieczeństwa w 2026 roku wymaga szerokiego spojrzenia. Polskie firmy powinny szukać nie tylko programów nazwanych „cyber”, ale też instrumentów cyfryzacji, transformacji, Przemysłu 4.0, EDIH, FENG, programów regionalnych, Digital Europe, pożyczek i finansowania zwrotnego.
Najlepsze projekty cyber są konkretne: wynikają z diagnozy, odpowiadają na realne ryzyko, są powiązane z biznesem, regulacjami i technologią, mają mierzalne efekty oraz plan utrzymania. Najsłabsze projekty są listą zakupów bez uzasadnienia.
Najlepsza zasada brzmi: nie pytaj najpierw „na co jest dotacja?”. Zapytaj, jakie ryzyko cyber ograniczasz, jaki efekt biznesowy osiągasz i które źródło finansowania najlepiej pasuje do tego celu.
10 błędów pracowników, które najczęściej prowadzą do incydentów
Najczęstsze incydenty nie zaczynają się od spektakularnego włamania, ale od małych błędów: kliknięcia w phishing, podania kodu MFA, użycia tego samego hasła, wysłania danych do złego odbiorcy, zatwierdzenia fałszywej płatności, zignorowania aktualizacji albo niezgłoszenia podejrzanego zdarzenia. Celem szkolenia nie powinno być straszenie pracowników, ale nauczenie prostych zachowań: zatrzymaj się, sprawdź drugim kanałem, nie podawaj kodów, zgłaszaj szybko, używaj zatwierdzonych narzędzi i pytaj, gdy coś wygląda nietypowo.
Opracowanie: Zespół redakcyjny CCyber
Najczęstsze błędy pracowników prowadzące do incydentów to kliknięcie w phishing, podanie hasła lub kodu MFA, ponowne używanie haseł, korzystanie z niezatwierdzonych narzędzi, wysyłanie danych do złych odbiorców, ignorowanie aktualizacji i alertów, obchodzenie procedur płatności, praca na prywatnych urządzeniach bez zasad, brak zgłaszania podejrzanych zdarzeń oraz zbyt duże zaufanie do wiadomości, telefonów i poleceń wyglądających „normalnie”. Nie chodzi o obwinianie ludzi. Większość takich błędów wynika z presji czasu, słabych procesów, braku jasnych zasad, źle zaprojektowanych narzędzi i szkolenia, które uczy teorii zamiast zachowań. Dobra cyberświadomość polega na tym, że pracownik wie, kiedy się zatrzymać, jak zweryfikować prośbę, czego nie podawać, gdzie zgłosić problem i że szybkie zgłoszenie błędu jest lepsze niż milczenie.
Lipiec 2026
Większość pracowników nie popełnia błędów dlatego, że ignoruje bezpieczeństwo. Błędy pojawiają się, bo codzienna praca wymaga szybkości, reagowania na wiadomości, obsługi klientów, akceptowania płatności, pracy z dokumentami, korzystania z wielu systemów i podejmowania decyzji pod presją.
Atakujący to wykorzystują. Nie zawsze próbują „zhakować system”. Często próbują przekonać człowieka, aby zrobił coś za nich: kliknął link, podał kod, otworzył załącznik, zatwierdził płatność, udostępnił plik, zresetował hasło albo zignorował nietypowy sygnał.
Dlatego program szkoleń powinien być projektowany jak system bezpieczeństwa, a nie jak jednorazowa prezentacja.
Phishing nadal jest jednym z najczęstszych sposobów rozpoczęcia incydentu. Wiadomość może udawać bank, dostawcę, klienta, kuriera, urząd, dział IT, zarząd albo znaną platformę. Coraz częściej nie wygląda już jak klasyczny podejrzany e-mail z literówkami. Może być poprawna językowo, dopasowana do kontekstu i wysłana z przejętego konta prawdziwej osoby.
Jeżeli wiadomość wymaga logowania, płatności, pobrania pliku, podania danych albo szybkiej reakcji, zatrzymaj się i sprawdź ją drugim kanałem.
Hasło nie jest już jedynym celem atakującego. Coraz częściej celem jest kod MFA, zatwierdzenie powiadomienia w aplikacji lub przekonanie pracownika, że „dział IT” potrzebuje kodu do rozwiązania problemu.
Nigdy nie podawaj kodu MFA i nigdy nie zatwierdzaj logowania, którego sam nie rozpocząłeś.
Ponowne używanie haseł sprawia, że wyciek z jednego serwisu może otworzyć dostęp do innych kont. Problem rośnie, gdy pracownik używa tego samego hasła w pracy i prywatnie.
Jedno konto, jedno hasło. Hasła firmowe przechowuj tylko w zatwierdzonym menedżerze haseł.
Incydent nie zawsze zaczyna się od ataku. Czasem jest to omyłkowe wysłanie pliku, nieuważne użycie autouzupełniania adresu, dodanie złej osoby do wątku, udostępnienie folderu zbyt szeroko albo wklejenie danych do publicznego narzędzia AI.
Przed wysłaniem danych klienta sprawdź odbiorcę, załącznik, zakres udostępnienia i kanał komunikacji.
Ataki na płatności często nie wymagają malware. Wystarczy fałszywy e-mail od dostawcy, przejęta skrzynka klienta, telefon od osoby podszywającej się pod zarząd albo wiadomość z prośbą o „pilny przelew”.
Nowy rachunek, pilny przelew albo nietypowa prośba o płatność zawsze wymagają drugiego kanału i drugiej osoby.
Pracownicy często odkładają aktualizacje, bo przeszkadzają w pracy. Czasem ignorują komunikaty o podejrzanym logowaniu, blokadzie konta, ryzyku pliku lub ostrzeżeniu przeglądarki. To może otwierać drogę do wykorzystania znanych podatności lub utraty konta.
Nie wyłączaj zabezpieczeń i nie ignoruj ostrzeżeń. Jeśli komunikat przeszkadza w pracy, zgłoś go zamiast omijać.
Pracownik może używać prywatnej poczty, prywatnego dysku, komunikatora, telefonu albo niezatwierdzonego narzędzia, bo chce szybciej wykonać zadanie. To często tworzy Shadow IT i Shadow AI, czyli obszar poza kontrolą organizacji.
Dane firmowe i dane klientów przetwarzaj tylko w zatwierdzonych narzędziach i na urządzeniach zgodnych z zasadami firmy.
Ten błąd często nie jest spektakularny, ale jest bardzo częsty. Pracownik zmienia rolę, projekt się kończy, dostawca zakończył usługę, ale dostęp zostaje. Były pracownik nadal ma konto, a osoba z poprzedniego projektu nadal widzi dane klienta.
Dostęp jest potrzebny tylko tak długo, jak istnieje realna potrzeba biznesowa.
To jeden z najgroźniejszych błędów, bo zamienia mały incydent w duży. Pracownik kliknął link, podał hasło, wysłał plik do złego odbiorcy albo zatwierdził podejrzane MFA, ale boi się konsekwencji i milczy.
Szybkie zgłoszenie błędu chroni firmę. Ukrycie błędu pomaga atakującemu.
Ataki socjotechniczne nie kończą się na e-mailu. Pracownik może dostać telefon od „prezesa”, wiadomość od „dostawcy”, nagranie głosowe, prośbę w komunikatorze, zaproszenie do spotkania albo materiał wyglądający jak prawdziwy. AI i deepfake zwiększają wiarygodność takich prób.
Nietypowa prośba od ważnej osoby nadal wymaga weryfikacji. Autorytet nie znosi procedury.
Skuteczne szkolenie nie powinno zaczynać się od slajdu „czym jest phishing”. Powinno zaczynać się od realnych sytuacji z pracy. Pracownik musi ćwiczyć decyzje, które podejmuje w codziennych procesach.
Wiele firm mierzy tylko, ile osób kliknęło w symulację phishingu. To za mało. Celem jest zmiana zachowania, a nie samo obniżenie procentu kliknięć.
Pracownik po szkoleniu powinien wiedzieć, co zrobić, a nie tylko czego się bać.
Finanse, HR, sprzedaż, IT i zarząd mają różne ryzyka. Szkolenie powinno uwzględniać role.
Publiczne zawstydzanie zmniejsza zgłaszanie błędów. A szybkie zgłoszenie jest kluczowe.
Ważniejsze jest, czy pracownicy zgłaszają podejrzane sytuacje i czy procedury działają.
Jeżeli zgłoszenie jest trudne, pracownik odłoży je na później albo nie zgłosi wcale.
Jeżeli manager wymaga szybkości kosztem procedury, szkolenie nie zadziała.
Ataki zmieniają się. Szkolenia muszą obejmować SMS-y, telefony, QR kody, deepfake, AI i przejęte konta dostawców.
Szkolenie bez procedury phishingu, płatności, MFA i zgłaszania incydentów zostaje teorią.
Firma usługowa zatrudnia 60 osób. Ma Microsoft 365, CRM, system fakturowania, chmurę plików i zewnętrzną księgowość. Po dwóch incydentach: kliknięciu w fałszywy link do logowania i próbie zmiany rachunku dostawcy, zarząd prosi o „szkolenie z phishingu”.
Krótki przegląd pokazuje jednak, że problem nie dotyczy samego phishingu. Pracownicy nie wiedzą, gdzie zgłaszać podejrzane wiadomości. Finanse nie mają procedury drugiego kanału. MFA jest włączone, ale pracownicy nie wiedzą, co zrobić przy nieoczekiwanym powiadomieniu. Hasła do niektórych kont marketingowych są współdzielone. Managerowie naciskają na szybkie wykonanie zadań, nawet gdy prośba jest nietypowa.
Firma przygotowuje program na 90 dni. Wprowadza kanał zgłoszeń, szkoli pracowników na scenariuszach, wdraża procedurę płatności, ćwiczy podejrzane MFA, ogranicza konta współdzielone i raportuje do zarządu nie tylko kliknięcia, ale też zgłoszenia i czas reakcji. Po trzech miesiącach liczba zgłoszeń rośnie, co początkowo wygląda jak więcej problemów. W praktyce firma widzi więcej ryzyk wcześniej i może szybciej reagować.
ccyber.io pomaga firmom budować programy cyberświadomości, które zmieniają zachowania, a nie tylko odhaczają szkolenie. Łączymy szkolenia, procedury, symulacje, metryki i raportowanie dla zarządu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Awareness Risk Workshop. W krótkim warsztacie można ustalić, które błędy są najgroźniejsze dla firmy, które działy wymagają szkoleń rolowych i jakie procedury trzeba poprawić, aby pracownicy mogli działać bezpiecznie.
Nie warto tak tego ujmować. Pracownicy są częścią systemu bezpieczeństwa. Jeżeli nie mają jasnych zasad, prostych narzędzi i kultury zgłaszania, będą popełniać błędy częściej.
Najgroźniejsze jest szybkie wykonanie nietypowej prośby bez weryfikacji: kliknięcie linku, podanie kodu MFA, zmiana rachunku dostawcy albo wysłanie danych do niewłaściwej osoby.
Działają najlepiej wtedy, gdy są połączone z omówieniem, procedurą zgłaszania i szkoleniem. Sama symulacja bez nauki zachowań może tylko stresować pracowników.
Najlepiej krócej, ale częściej. Szkolenie startowe przy onboardingu, krótkie przypomnienia kwartalne i szkolenia rolowe dla działów wysokiego ryzyka są praktyczniejsze niż jedna długa prezentacja rocznie.
Powinien zgłosić zdarzenie natychmiast, bez obawy przed karą. Firma powinna zmienić hasło, sprawdzić sesje, MFA, logowania, reguły poczty i zakres ewentualnego dostępu atakującego.
Karanie zwykle zmniejsza zgłaszanie. Lepsze są jasne zasady, szybka reakcja, szkolenie i konsekwencje tylko dla świadomego, powtarzalnego obchodzenia procedur.
Mierz zgłoszenia, czas reakcji, liczbę zgłoszonych podejrzanych MFA, skuteczność drugiego kanału, błędy wysyłki danych, wyniki ćwiczeń i działania naprawcze.
Zacznij od trzech rzeczy: prosty kanał zgłaszania, szkolenie z phishingu i MFA oraz procedura drugiego kanału dla płatności, danych i zmian dostępu.
Najczęstsze incydenty często zaczynają się od codziennych decyzji pracowników: kliknięcia linku, podania kodu, wysłania pliku, zatwierdzenia płatności, użycia prywatnego narzędzia albo zignorowania nietypowego sygnału. To nie oznacza, że winny jest tylko człowiek. Oznacza, że firma musi projektować procesy tak, aby bezpieczne zachowanie było proste.
Najważniejsze działania to szkolenia rolowe, procedura zgłaszania, MFA, menedżer haseł, drugi kanał weryfikacji, jasne zasady dla danych i narzędzi, bezpieczny offboarding oraz kultura, w której szybkie zgłoszenie błędu jest doceniane.
Najlepsza zasada brzmi: nie oczekuj od pracowników doskonałości. Daj im jasne zasady, proste narzędzia, możliwość zatrzymania procesu i bezpieczną ścieżkę zgłaszania, zanim mały błąd stanie się dużym incydentem.
Ubezpieczenie cybernetyczne: co trzeba mieć wdrożone, zanim ubezpieczyciel zada pytania
Cyberubezpieczenie nie zastępuje cyberbezpieczeństwa. Zanim ubezpieczyciel zada pytania, firma powinna mieć wdrożone i udokumentowane minimum: MFA, backup z testem odtworzenia, ochronę poczty, aktualizacje, EDR lub ochronę urządzeń, kontrolę kont administratorów, przegląd uprawnień, szkolenia, procedurę incident response, plan ciągłości działania, rejestr dostawców, procedurę płatności i pakiet dowodów. Najważniejsze jest, aby odpowiedzi w ankiecie ubezpieczeniowej były zgodne z rzeczywistością, bo deklaracje bez dowodów mogą być problemem przy odnowieniu polisy albo przy likwidacji szkody.
Opracowanie: Zespół redakcyjny CCyber
Przed rozmową z ubezpieczycielem firma powinna mieć wdrożone podstawowe zabezpieczenia i dowody ich działania. Najważniejsze są: MFA dla poczty, kont administratorów, chmury i dostępu zdalnego, testowane kopie zapasowe, ochrona urządzeń, aktualizacje, zarządzanie podatnościami, procedura reagowania na incydenty, plan ciągłości działania, szkolenia pracowników, przegląd uprawnień, kontrola dostawców, procedura płatności oraz uporządkowany pakiet dowodów. Cyberubezpieczenie może pomóc pokryć część kosztów incydentu, ale nie zapobiega atakowi i nie zastępuje obowiązku wdrożenia rozsądnych zabezpieczeń. Największym błędem jest wpisanie w ankiecie ubezpieczeniowej, że kontrola działa, jeśli w praktyce nie jest wdrożona albo nie ma na nią dowodu.
Lipiec 2026
Cyberubezpieczenie ma pomóc firmie ograniczyć finansowe skutki cyberincydentu. Może obejmować koszty reakcji, usług ekspertów, prawników, odzyskiwania danych, komunikacji kryzysowej, przestoju, roszczeń osób trzecich albo innych kosztów wskazanych w polisie. Zakres zależy od umowy, wyłączeń, limitów, udziałów własnych i warunków spełnionych przez firmę.
Cyberubezpieczenie może być szczególnie przydatne, gdy firma nie ma wewnętrznego zespołu reagowania, nie ma dużego działu prawnego albo chce mieć dostęp do sprawdzonych dostawców po incydencie. Nie oznacza to jednak, że polisa rozwiązuje problem bezpieczeństwa.
Ubezpieczyciel ocenia ryzyko. Tak jak przy ubezpieczeniu budynku może pytać o alarm, zabezpieczenia przeciwpożarowe i stan instalacji, tak przy cyberubezpieczeniu pyta o zabezpieczenia systemów, danych i procesów. Celem jest ustalenie, czy firma jest narażona na wysokie ryzyko i czy potrafi ograniczyć skutki incydentu.
Pytania techniczne nie są tylko formalnością. Odpowiedzi mogą wpływać na:
Dlatego ankietę ubezpieczeniową powinny wypełniać wspólnie: zarząd, IT, security, legal, finanse i osoba odpowiedzialna za ryzyko. Nie powinna robić tego jedna osoba na podstawie przypuszczeń.
Największe ryzyko przy cyberubezpieczeniu to rozjazd między deklaracją a rzeczywistością. Firma może napisać, że ma MFA, backup, EDR i incident response plan, ale po incydencie okazuje się, że MFA nie obejmuje administratorów, backup nie był testowany, EDR nie działa na wszystkich urządzeniach, a plan incydentu nigdy nie był ćwiczony.
„Mamy MFA”.
„MFA jest włączone dla Microsoft 365, kont administratorów, VPN, systemu finansowego i menedżera haseł. Wyjątki są opisane w rejestrze. Ostatni raport MFA pochodzi z 15 czerwca 2026 r.”.
Zakres ankiety zależy od ubezpieczyciela, branży, wielkości firmy, przychodów, danych i historii incydentów. W praktyce większość pytań dotyczy kilkunastu powtarzalnych obszarów.
MFA jest jedną z pierwszych kontroli, o które pyta ubezpieczyciel. Szczególnie ważne są konta poczty, administratorów, VPN, chmury, bankowości, CRM, systemów finansowych, backupu i dostępu zdalnego.
Dowód: raport MFA z systemu tożsamości, lista wyjątków i decyzje o ich akceptacji.
Ubezpieczyciel będzie chciał wiedzieć nie tylko, czy backup istnieje, ale czy firma potrafi odzyskać dane. Test restore jest ważniejszy niż sama deklaracja, że kopie się wykonują.
Dowód: raport backupu, raport testu odtworzenia i lista działań naprawczych.
Ransomware to jeden z najważniejszych scenariuszy dla ubezpieczycieli. Firma powinna umieć pokazać, że ogranicza prawdopodobieństwo ataku i wpływ ewentualnego incydentu.
Dowód: plan ransomware, raport ćwiczenia, raport EDR i test restore.
Ubezpieczyciel może pytać, czy firma ma ochronę urządzeń końcowych, kto monitoruje alerty i czy ochrona działa na wszystkich laptopach, serwerach i stacjach roboczych.
Dowód: raport pokrycia EDR lub antywirusa, lista wyjątków i raport alertów.
Pytania o aktualizacje dotyczą systemów operacyjnych, aplikacji, urządzeń sieciowych, serwerów, VPN, firewalla, chmury i systemów internetowych. Firma powinna mieć proces, a nie tylko deklarację.
Dowód: raport podatności, raport patch management i lista wyjątków.
Konta administratorów są szczególnie interesujące dla ubezpieczycieli, bo ich przejęcie może prowadzić do szerokiego incydentu.
Dowód: raport kont administratorów i raport przeglądu uprawnień.
Access review pokazuje, że firma kontroluje, kto ma dostęp do danych i systemów. To dobry dowód do ankiety, audytu i likwidacji szkody.
Dowód: raport access review i lista odebranych uprawnień.
Dostęp zdalny jest częstą drogą wejścia atakujących. Ubezpieczyciel może pytać o VPN, RDP, narzędzia zdalnego wsparcia i dostęp dostawców.
Dowód: opis modelu dostępu zdalnego, raport MFA, lista dostawców z dostępem i logi sesji.
Poczta jest jednym z najważniejszych punktów ryzyka. Ubezpieczyciel może pytać o MFA, zabezpieczenia antyphishingowe, SPF, DKIM, DMARC i szkolenia.
Dowód: raport konfiguracji poczty, status SPF/DKIM/DMARC, raport szkoleń i rejestr zgłoszeń.
Nie każda polisa obejmuje straty z oszustw płatniczych. Dlatego firma powinna mieć procedurę ograniczającą ryzyko fałszywego przelewu i zmiany rachunku dostawcy.
Dowód: procedura płatności, rejestr zmian rachunków i potwierdzenia drugim kanałem.
Ubezpieczyciel może pytać, czy firma ma plan reagowania, kto go uruchamia i czy był testowany. Plan powinien być prosty, aktualny i znany osobom decyzyjnym.
Dowód: incident response plan i raport z ćwiczenia tabletop.
Cyberubezpieczenie często dotyczy kosztów przestoju, ale firma musi umieć pokazać, że ogranicza jego długość i wpływ.
Dowód: BCP, DRP, raport testu odtworzenia i lista działań po teście.
Ubezpieczyciel może pytać, co firma chroni, jakie dane przetwarza, gdzie są systemy i które są krytyczne. Bez inwentaryzacji odpowiedzi są zgadywaniem.
Dowód: rejestr aktywów, systemów i danych.
Jeśli firma przetwarza dane osobowe, dane klientów, informacje finansowe albo tajemnice przedsiębiorstwa, ubezpieczyciel może pytać o szyfrowanie i kontrolę dostępu do danych.
Dowód: polityka klasyfikacji danych, raport szyfrowania urządzeń i raport dostępu do danych.
Ubezpieczyciel może pytać o szkolenia z phishingu, MFA, ransomware, haseł i procedur płatności. Sama prezentacja nie wystarczy. Potrzebne są dowody udziału i skuteczności.
Dowód: lista uczestników, materiały, wyniki testu i raport zgłoszeń phishingu.
Atak lub awaria dostawcy może być źródłem szkody. Ubezpieczyciel może pytać o dostawców IT, chmury, hostingu, backupu, systemów finansowych i usług zarządzanych.
Dowód: rejestr dostawców, oceny ryzyka i klauzule bezpieczeństwa w umowach.
Ubezpieczyciel może pytać o wcześniejsze incydenty, zgłoszenia, szkody, ransomware, naruszenia danych, fałszywe przelewy i działania naprawcze.
Dowód: rejestr incydentów i raport działań po incydencie.
Firma powinna wiedzieć, czy podlega NIS2, DORA, KSC, RODO, wymaganiom klientów albo standardom branżowym. Ubezpieczyciel może pytać o obowiązki prawne i potencjalne kary.
Dowód: analiza podlegania, rejestr wymagań i procedury zgłoszeniowe.
Cyberubezpieczenie jest decyzją zarządczą. Zarząd powinien znać ryzyka, zakres polisy, wyłączenia, limity, wymagania ubezpieczyciela i luki, które mogą wpływać na ochronę.
Dowód: raport dla zarządu i decyzje budżetowe.
Przy ubezpieczeniu liczy się czas i spójność. Firma powinna mieć jedno miejsce, w którym trzyma dowody dla brokera, ubezpieczyciela, audytora i zespołu likwidacji szkody.
Dowód: macierz dowodów z właścicielami, datami i statusem aktualności.
Przy cyberubezpieczeniu nie wystarczy spojrzeć na cenę i limit. Trzeba zrozumieć, co jest objęte ochroną, co jest wyłączone, jakie są warunki wypłaty i jakie obowiązki ma firma przed oraz po incydencie.
W ankiecie powinny uczestniczyć osoby od IT, bezpieczeństwa, finansów, legal, ryzyka, HR i zarządu. Jedna osoba zwykle nie zna pełnego obrazu.
Nie wpisuj „tak”, jeśli kontrola działa tylko częściowo. Lepiej wskazać zakres, wyjątki i plan naprawczy.
Każda odpowiedź „tak” powinna mieć dowód. Każda odpowiedź „częściowo” powinna mieć plan poprawy.
Wyjątki nie muszą przekreślać polisy, ale muszą być jawne, uzasadnione i zarządzane.
Zmiana dostawcy, systemu, backupu, incydent albo istotna zmiana zakresu działania może wymagać rozmowy z brokerem lub ubezpieczycielem.
Ankieta ubezpieczeniowa jest dokumentem ryzyka. Odpowiedzi powinny być sprawdzone i zgodne z rzeczywistością.
MFA może działać dla użytkowników, ale nie dla administratorów, VPN, dostawców albo kont awaryjnych. To duża różnica.
Ubezpieczyciel może pytać o backup, ale po incydencie ważne będzie, czy firma potrafi odtworzyć dane i systemy.
Po ataku firma dopiero szuka numeru do ubezpieczyciela, prawnika i dostawcy reagowania. To wydłuża chaos.
Nie każda polisa cyber obejmuje fałszywe przelewy. Trzeba to sprawdzić osobno.
Dostawca może mieć dostęp administratora, backupu albo danych klientów. Ubezpieczyciel może pytać, czy firma zarządza tym ryzykiem.
Zarząd kupuje polisę, ale nie zna wyłączeń, luk, wymagań i działań potrzebnych do odnowienia.
Firma zmienia chmurę, dostawcę, backup albo model pracy, ale nie aktualizuje informacji przekazanych brokerowi lub ubezpieczycielowi.
Firma usługowa zatrudnia 80 osób i chce wykupić cyberubezpieczenie. W ankiecie pojawiają się pytania o MFA, backup, EDR, ransomware, szkolenia, incydenty, dostawców i plan reagowania. Zarząd początkowo zakłada, że większość odpowiedzi brzmi „tak”, bo firma ma zewnętrznego dostawcę IT.
Po krótkim przeglądzie okazuje się, że MFA działa w Microsoft 365, ale nie obejmuje kont administratorów dostawcy. Backup istnieje, ale nie był testowany od ponad roku. EDR nie obejmuje wszystkich laptopów. Przegląd uprawnień nie był robiony. Procedura płatności nie istnieje, a szkolenia phishingowe odbyły się tylko raz.
Firma nie wpisuje niepewnych odpowiedzi do ankiety. W ciągu 60 dni poprawia MFA, wykonuje test odtworzenia, przygotowuje access review, uzupełnia EDR, tworzy procedurę płatności i szkoli pracowników. Do ankiety dołącza plan działań naprawczych i dowody. Efekt: rozmowa z brokerem i ubezpieczycielem jest oparta na faktach, a nie na przypuszczeniach.
ccyber.io pomaga firmom przygotować się do cyberubezpieczenia w sposób praktyczny, oparty na ryzyku i dowodach. Nie zaczynamy od samej ankiety. Zaczynamy od sprawdzenia, czy firma ma wdrożone zabezpieczenia, które deklaruje, i czy potrafi je udowodnić.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Insurance Readiness Workshop. W krótkim warsztacie można sprawdzić, które odpowiedzi w ankiecie są pewne, gdzie brakuje dowodów, które luki mogą wpływać na polisę i co wdrożyć przed rozmową z ubezpieczycielem.
Nie. Cyberubezpieczenie może pomóc po incydencie, ale nie zapobiega atakowi. Firma nadal musi mieć podstawowe zabezpieczenia, procedury, testy i dowody.
MFA, backup, test odtworzenia, EDR, aktualizacje, konta administratorów, dostęp zdalny, szkolenia, incident response, historię incydentów, dostawców i ochronę danych.
W praktyce MFA jest jednym z najważniejszych oczekiwań. Powinno obejmować pocztę, konta administratorów, chmurę, dostęp zdalny i systemy krytyczne.
Nie. Trzeba mieć test odtworzenia, ochronę kont backupu, kopie odseparowane od produkcji i plan przywrócenia systemów krytycznych.
Nie należy udawać, że są wdrożone. Trzeba wskazać stan faktyczny, wyjątki, plan naprawczy i terminy. To lepsze niż deklaracje bez pokrycia.
Nie zawsze. Business email compromise, social engineering fraud i fałszywe przelewy mogą wymagać osobnego zakresu lub mieć szczególne warunki. Trzeba to sprawdzić w polisie.
Raport MFA, raport backupu, test restore, raport EDR, access review, listę kont administratorów, plan incident response, szkolenia, rejestr dostawców i raport działań naprawczych.
Zacznij od porównania ankiety ubezpieczeniowej z rzeczywistym stanem zabezpieczeń. Oznacz odpowiedzi pewne, częściowe i bez dowodów, a potem zamknij najważniejsze luki.
Cyberubezpieczenie jest ważnym elementem zarządzania ryzykiem, ale działa najlepiej wtedy, gdy firma ma realne zabezpieczenia i dowody. Polisa nie zastąpi MFA, backupu, EDR, szkoleń, procedur, kontroli dostępu i planu reagowania.
Zanim ubezpieczyciel zada pytania, firma powinna przygotować minimum: MFA, testowany backup, ochronę urządzeń, aktualizacje, kontrolę administratorów, access review, ochronę poczty, procedurę płatności, incident response, BCP, szkolenia, dostawców i repozytorium dowodów.
Najlepsza zasada brzmi: nie kupuj polisy na podstawie życzeniowych odpowiedzi. Najpierw sprawdź stan faktyczny, zbierz dowody i pokaż ubezpieczycielowi, że firma realnie zarządza ryzykiem cyber.
DORA w praktyce: co oznacza odporność cyfrowa dla firm finansowych i dostawców ICT
DORA oznacza, że firmy finansowe muszą udowodnić, że potrafią działać mimo awarii, cyberataku, błędu dostawcy ICT albo niedostępności kluczowego systemu. Odporność cyfrowa nie polega tylko na posiadaniu zabezpieczeń technicznych. Obejmuje zarządzanie ryzykiem ICT, ciągłość działania, testy odporności, zgłaszanie incydentów, kontrolę dostawców, rejestr umów ICT, nadzór zarządu i dowody działania. Dla dostawców ICT DORA oznacza większe wymagania umowne, audyty, obowiązki informacyjne, kontrolę podwykonawców i w wybranych przypadkach bezpośredni nadzór jako krytyczny dostawca ICT.
Opracowanie: Zespół redakcyjny CCyber
DORA, czyli Digital Operational Resilience Act, to unijne rozporządzenie dotyczące cyfrowej odporności operacyjnej sektora finansowego. W praktyce oznacza, że banki, ubezpieczyciele, firmy inwestycyjne, instytucje płatnicze, dostawcy usług związanych z kryptoaktywami i inne podmioty finansowe muszą zarządzać ryzykiem ICT w sposób udokumentowany, testowany i nadzorowany. Firma finansowa musi wiedzieć, które usługi i systemy są krytyczne, jak reaguje na incydent, jak odtwarza działanie, jak kontroluje dostawców ICT i jak raportuje poważne incydenty. Dla dostawców ICT DORA oznacza, że klienci z sektora finansowego będą wymagać większej przejrzystości, lepszych umów, audytowalności, raportowania incydentów, kontroli podwykonawców i dowodów odporności.
Lipiec 2026
DORA zmienia sposób myślenia o cyberbezpieczeństwie w sektorze finansowym. Nie wystarczy powiedzieć, że firma ma zabezpieczenia, polityki i dostawcę IT. Trzeba pokazać, że organizacja potrafi utrzymać lub odtworzyć działanie usług finansowych po zakłóceniu cyfrowym.
W praktyce DORA wymaga, aby firma finansowa:
Najprościej: DORA wymaga, aby sektor finansowy był odporny nie tylko na typowy cyberatak, ale też na awarię dostawcy, błąd operacyjny, niedostępność chmury, problemy z centrum danych, utratę łączności, błędną zmianę, ransomware i inne zakłócenia ICT.
Odporność cyfrowa to zdolność organizacji do utrzymania, ochrony, wykrywania, reagowania, odtwarzania i uczenia się po zakłóceniu cyfrowym. W sektorze finansowym chodzi o to, aby incydent ICT nie zatrzymał świadczenia usług, które są ważne dla klientów, rynku i stabilności systemu finansowego.
To oznacza, że odporność cyfrowa nie jest jednym narzędziem. To system zarządzania ryzykiem, ciągłością działania, dostawcami i dowodami.
DORA dotyczy szerokiego katalogu podmiotów finansowych działających w Unii Europejskiej oraz wpływa na dostawców usług ICT obsługujących sektor finansowy. Dokładną kwalifikację zawsze trzeba sprawdzić na podstawie rozporządzenia, przepisów wykonawczych i stanowisk właściwych organów.
DORA wpływa także na dostawców ICT, czyli firmy dostarczające technologie informacyjno-komunikacyjne dla sektora finansowego. Nie każdy dostawca ICT staje się automatycznie podmiotem bezpośrednio nadzorowanym przez unijne organy. Większość dostawców odczuje DORA przez wymagania umowne klientów finansowych. Dostawcy uznani za krytycznych mogą podlegać szczególnemu nadzorowi na poziomie europejskim.
Firma finansowa musi mieć ramy zarządzania ryzykiem ICT. Nie chodzi tylko o dokument, ale o działający proces: identyfikację aktywów, ocenę ryzyka, zabezpieczenia, monitoring, reagowanie, odtwarzanie i raportowanie.
DORA wymaga zarządzania incydentami ICT, ich klasyfikacji i raportowania poważnych incydentów do właściwych organów. Firma musi mieć procedurę, role, szablony, ścieżkę eskalacji i dowody reakcji.
DORA wymaga testowania odporności cyfrowej. Testy nie powinny ograniczać się do jednego testu technicznego. Powinny obejmować procedury, systemy, dostawców, odtwarzanie i scenariusze kryzysowe.
To jeden z najważniejszych obszarów DORA. Sektor finansowy jest silnie zależny od dostawców technologii. DORA wymaga, aby te zależności były widoczne, kontrolowane i opisane w umowach.
DORA przewiduje możliwość wymiany informacji i wiedzy o cyberzagrożeniach między podmiotami finansowymi. W praktyce firmy powinny rozważyć, jak korzystają z informacji o zagrożeniach, ostrzeżeń sektorowych i współpracy branżowej.
DORA przewiduje szczególny nadzór nad dostawcami ICT uznanymi za krytycznych dla sektora finansowego. Dla takich dostawców oznacza to wyższe oczekiwania dotyczące ryzyka, kontroli, przejrzystości i współpracy z organami nadzoru.
DORA wymaga, aby odporność cyfrowa była tematem zarządczym, a nie wyłącznie technicznym. Zarząd powinien rozumieć, które funkcje są krytyczne, jakie ryzyka ICT im zagrażają, jakie działania ograniczające ryzyko są wdrożone i jakie są największe zależności od dostawców.
Dla firm finansowych DORA oznacza konieczność przejścia od podejścia „mamy IT i bezpieczeństwo” do podejścia „umiemy udowodnić odporność cyfrową”. To duża różnica.
Dostawcy ICT obsługujący sektor finansowy powinni traktować DORA jako istotną zmianę oczekiwań klientów. Nawet jeśli dostawca nie jest bezpośrednio nadzorowany jako krytyczny dostawca ICT, jego klienci finansowi będą musieli wykazać, że kontrolują ryzyko dostawców.
W DORA bardzo ważne jest rozróżnienie funkcji krytycznych lub istotnych. To one wskazują, które procesy, systemy i dostawcy mają największe znaczenie dla odporności firmy finansowej.
Jednym z praktycznych wymagań DORA jest rejestr informacji o umowach z dostawcami ICT. To nie jest zwykła lista dostawców. To uporządkowany zestaw danych o tym, jakie usługi ICT wspierają firmę, które funkcje są nimi objęte i jakie ryzyko wynika z tych zależności.
Dowód do przygotowania: aktualny rejestr informacji o umowach ICT, powiązany z funkcjami krytycznymi lub istotnymi.
DORA sprawia, że umowy z dostawcami ICT muszą być bardziej precyzyjne. Szczególnie wtedy, gdy dostawca wspiera funkcję krytyczną lub istotną.
Testowanie w DORA powinno odpowiadać na pytanie: czy firma potrafi działać, gdy coś pójdzie źle? Nie chodzi tylko o test techniczny. Chodzi o sprawdzenie ludzi, procesów, dostawców, kopii, komunikacji i decyzji zarządu.
DORA wymaga, aby firma potrafiła identyfikować, klasyfikować i raportować incydenty ICT. To wymaga wcześniejszego przygotowania, bo w trakcie incydentu nie ma czasu na tworzenie procesu od zera.
Firma ma plan reagowania na incydenty, ale nie ma procedury klasyfikacji i raportowania zgodnej z DORA. Wtedy w kryzysie ludzie wiedzą, że „coś się stało”, ale nie wiedzą, czy i jak raportować.
DORA i NIS2 mają wspólny cel: większą odporność cyfrową i cyberbezpieczeństwo. Różnią się jednak zakresem. DORA jest szczególną regulacją dla sektora finansowego i ryzyka ICT. NIS2 dotyczy szerokiego katalogu sektorów krytycznych i ważnych.
Jeżeli firma finansowa podlega DORA, wymagania DORA będą podstawową regulacją dla obszaru cyfrowej odporności operacyjnej. Nie oznacza to, że można ignorować inne regulacje, ale dla ryzyka ICT w sektorze finansowym DORA jest kluczowym punktem odniesienia.
Dostawca ICT może jednocześnie odczuwać wymagania DORA od klientów finansowych i wymagania NIS2, jeśli sam jest objęty NIS2 albo obsługuje podmioty z innych sektorów regulowanych. Dlatego dostawcy powinni budować jeden program bezpieczeństwa, który obsłuży wiele regulacji i audytów.
ISO 27001 może bardzo pomóc w przygotowaniu do DORA, ale nie zastępuje DORA. ISO 27001 daje system zarządzania bezpieczeństwem informacji, rejestr ryzyk, kontrole, audyty, przeglądy zarządzania i działania korygujące. DORA dodaje szczegółowe wymagania sektora finansowego, zwłaszcza w zakresie ryzyka ICT, incydentów, testów odporności i dostawców ICT.
Najpierw trzeba ustalić, które podmioty, usługi, systemy, lokalizacje, dostawcy i funkcje są objęte DORA.
Wynik: zakres DORA i mapa funkcji krytycznych lub istotnych.
Porównaj obecny stan z wymaganiami DORA. Sprawdź nie tylko dokumenty, ale też dowody działania.
Wynik: DORA gap analysis z właścicielami i priorytetami.
Rejestr ryzyk powinien łączyć ryzyka technologiczne z usługami finansowymi, klientami, dostawcami i ciągłością działania.
Wynik: rejestr ryzyk ICT zatwierdzony przez właściwe forum zarządcze.
Przygotuj procedury klasyfikacji, eskalacji i raportowania poważnych incydentów ICT.
Wynik: procedura incydentów ICT, szablony i test ścieżki zgłoszeniowej.
Testuj nie tylko technologię, ale także ludzi, dostawców, odtwarzanie i komunikację.
Wynik: harmonogram testów, raporty i lista działań naprawczych.
Rejestr powinien pokazywać pełny obraz zależności od dostawców ICT.
Wynik: rejestr informacji gotowy do raportowania i przeglądu.
Najpierw skup się na dostawcach wspierających funkcje krytyczne lub istotne.
Wynik: plan aneksowania umów, nowe klauzule i oceny ryzyka.
Zarząd powinien rozumieć DORA, ryzyka ICT, funkcje krytyczne, dostawców i scenariusze zakłóceń.
Wynik: szkolenie zarządu, raport ryzyka i decyzje budżetowe.
DORA wymaga dowodów. Dowody powinny być uporządkowane i aktualne.
Wynik: macierz dowodów DORA z właścicielami, datami i statusem.
Próbny audyt pokazuje, czy firma ma realną gotowość, czy tylko dokumenty.
Wynik: raport audytu, lista luk i plan działań korygujących.
DORA wymaga realnej odporności i dowodów działania. Sama dokumentacja bez testów, rejestrów i decyzji nie wystarczy.
Firma nie wie, które procesy są najważniejsze, więc nie potrafi dobrze ustalić priorytetów testów, dostawców i odtwarzania.
Lista dostawców nie wystarczy. Trzeba wiedzieć, który dostawca wspiera którą funkcję i jaki wpływ ma jego awaria.
To duże ryzyko, szczególnie dla usług wspierających funkcje krytyczne lub istotne.
Odporność cyfrowa wymaga testowania także decyzji zarządu, komunikacji, dostawców i pracy w trybie awaryjnym.
Plan reagowania na incydenty nie wystarczy, jeśli nie ma klasyfikacji, szablonów i ścieżki raportowania zgodnej z DORA.
Dostawca może technicznie świadczyć dobrą usługę, ale nie być gotowy na raportowanie, audyt, podwykonawstwo i dowody wymagane przez klientów finansowych.
Zarząd widzi projekty IT, ale nie widzi realnej odporności: testów, RTO, RPO, dostawców krytycznych, incydentów i ryzyk po terminie.
Firma finansowa korzysta z kilku kluczowych usług ICT: chmury, systemu transakcyjnego, systemu obsługi klienta, usługi SOC, backupu i zewnętrznego dostawcy oprogramowania. Przed DORA traktowała te umowy głównie jako temat zakupów i IT. Po analizie okazuje się, że część dostawców wspiera funkcje krytyczne lub istotne, a umowy nie zawierają jasnych zasad audytu, zgłaszania incydentów, podwykonawstwa i planu wyjścia.
Firma uruchamia program DORA. Tworzy mapę funkcji krytycznych, rejestr ryzyk ICT, rejestr informacji o umowach ICT i plan testów. Przeprowadza test odtworzenia, ćwiczenie poważnego incydentu ICT i przegląd dostawców. Zarząd otrzymuje pierwszy raport z metrykami odporności, a dostawcy dostają wymagania do aneksów.
Największa zmiana nie polega na stworzeniu nowej polityki. Polega na tym, że firma zaczyna widzieć zależności technologiczne jako ryzyko biznesowe i potrafi pokazać dowody odporności.
ccyber.io pomaga firmom finansowym i dostawcom ICT przygotować się do DORA w sposób praktyczny, oparty na ryzyku i dowodach. Nie zaczynamy od dokumentacji dla dokumentacji. Zaczynamy od funkcji krytycznych, dostawców, incydentów, testów, zarządu i realnej zdolności do działania po zakłóceniu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest DORA Operational Resilience Workshop. W krótkim warsztacie można ustalić, które funkcje są krytyczne, którzy dostawcy są najważniejsi, jakie umowy wymagają zmian, które testy trzeba wykonać i jakie dowody przygotować przed audytem.
DORA to unijne rozporządzenie o cyfrowej odporności operacyjnej sektora finansowego. Dotyczy zarządzania ryzykiem ICT, incydentów, testów odporności, dostawców ICT i nadzoru nad krytycznymi dostawcami.
DORA stosuje się od 17 stycznia 2025 r. Firmy finansowe powinny już działać według jej wymagań i posiadać dowody przygotowania.
Tak, ale w różny sposób. Większość dostawców ICT odczuwa DORA przez wymagania klientów finansowych w umowach, audytach i raportowaniu. Krytyczni dostawcy ICT mogą podlegać szczególnemu nadzorowi.
To zdolność firmy do utrzymania lub odtworzenia działania usług mimo incydentu ICT, awarii, cyberataku, błędu dostawcy albo zakłócenia technologicznego.
Najważniejsze są funkcje krytyczne lub istotne, ryzyko ICT, incydenty, testy odporności, dostawcy ICT, rejestr informacji i dowody działania.
Nie automatycznie. ISO 27001 bardzo pomaga, ale DORA ma szczegółowe wymagania sektorowe dotyczące incydentów ICT, testowania odporności, dostawców, rejestru informacji i nadzoru zarządu.
Opis usługi, granice odpowiedzialności, dowody bezpieczeństwa, procedurę incydentową, plan ciągłości, testy odtwarzania, listę podwykonawców, zasady audytu i plan wyjścia.
Zacznij od mapy funkcji krytycznych lub istotnych, rejestru ryzyk ICT, rejestru dostawców ICT i przeglądu umów z dostawcami wspierającymi najważniejsze usługi.
DORA w praktyce oznacza przejście od ochrony IT do odporności cyfrowej całej organizacji finansowej. Firma musi wiedzieć, które usługi są krytyczne, jakie systemy je wspierają, którzy dostawcy są niezbędni, jak działają kopie, jak raportowane są incydenty i czy zarząd widzi realny poziom ryzyka.
Dla firm finansowych DORA oznacza zarządzanie ryzykiem ICT, testowanie odporności, raportowanie incydentów, kontrolę dostawców i dowody. Dla dostawców ICT oznacza większą przejrzystość, silniejsze umowy, audyty, raportowanie, kontrolę podwykonawców i konieczność pokazania, że usługa jest odporna.
Najlepsza zasada brzmi: odporności cyfrowej nie da się udowodnić samą polityką. Trzeba mieć testy, raporty, metryki, decyzje zarządu, rejestr dostawców i dowody, że firma potrafi działać mimo zakłócenia.
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.