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.
Cyberubezpieczenie w firmie: dlaczego jest ważne i gdzie kończy się jego rola?
Cyberubezpieczenie jest ważne, bo cyberatak może oznaczać nie tylko koszt technicznej naprawy, ale też przestój, utratę danych, obsługę prawną, komunikację z klientami, roszczenia, działania forensics, PR, koszty odtworzenia i utratę przychodów. Polisa może pomóc sfinansować reakcję i ograniczyć skutki finansowe incydentu, ale nie zapobiega atakom i nie zastępuje cyberbezpieczeństwa. Firma powinna traktować cyberubezpieczenie jako element zarządzania ryzykiem: obok MFA, backupu, EDR, aktualizacji, kontroli dostępu, szkoleń, incident response, BCP, testów i zarządzania dostawcami.
Opracowanie: Zespół redakcyjny CCyber
Cyberubezpieczenie jest ważne, ponieważ cyberatak może bardzo szybko stać się problemem finansowym, prawnym, operacyjnym i reputacyjnym. Ransomware, przejęcie poczty, wyciek danych, fałszywy przelew, awaria dostawcy albo atak na sklep internetowy mogą wygenerować koszty, których firma nie planowała: forensics, prawnicy, komunikacja z klientami, odtworzenie systemów, utrata przychodów, wsparcie PR, obsługa roszczeń i dodatkowe zasoby IT. Dobra polisa może pomóc w sfinansowaniu części tych kosztów i dać dostęp do ekspertów po incydencie. Nie zastępuje jednak MFA, backupu, aktualizacji, EDR, szkoleń, planu reagowania, BCP i dobrego zarządzania ryzykiem. Cyberubezpieczenie nie jest tarczą przed atakiem. Jest mechanizmem transferu części skutków finansowych, gdy mimo zabezpieczeń coś pójdzie nie tak.
Lipiec 2026
Większość firm działa dziś cyfrowo. Poczta, płatności, CRM, system finansowy, pliki, chmura, faktury, produkcja, obsługa klienta, sklep internetowy, logistyka i dane pracowników są zależne od systemów IT lub dostawców cyfrowych. To oznacza, że cyberincydent nie jest już tylko problemem technicznym.
Cyberatak może zatrzymać sprzedaż, zablokować dostęp do danych, wywołać roszczenia klientów, uruchomić obowiązki zgłoszeniowe, zakłócić produkcję, opóźnić płatności i zaangażować zarząd na wiele dni. Właśnie dlatego cyberubezpieczenie jest coraz częściej traktowane jako element zarządzania ryzykiem biznesowym.
Co zrobimy finansowo i organizacyjnie, jeśli mimo zabezpieczeń dojdzie do incydentu?
Cyberubezpieczenie to polisa, która może pokrywać wybrane koszty związane z cyberincydentem. Zakres zależy od konkretnej oferty, warunków, wyłączeń, limitów, podlimitów i odpowiedzi firmy w ankiecie ubezpieczeniowej.
Nie każda polisa obejmuje wszystko. Dlatego firma nie powinna kupować polisy tylko na podstawie ceny. Trzeba sprawdzić zakres, wyłączenia, podlimity, udział własny, obowiązki po incydencie i warunki wypłaty.
Cyberubezpieczenie nie jest zabezpieczeniem technicznym. Nie zatrzyma phishingu, nie załata podatności, nie włączy MFA, nie zrobi backupu i nie przeszkoli pracowników. Polisa zaczyna działać dopiero wtedy, gdy dojdzie do zdarzenia objętego ochroną i gdy firma spełnia warunki polisy.
Najlepsze podejście to traktować cyberubezpieczenie jako trzecią warstwę: po prewencji i gotowości operacyjnej.
To zabezpieczenia, które mają zmniejszyć prawdopodobieństwo incydentu. Przykłady: MFA, aktualizacje, EDR, ograniczanie uprawnień, szkolenia, ochrona poczty i bezpieczny dostęp zdalny.
To zdolność firmy do działania, gdy incydent się wydarzy. Przykłady: backup, test restore, incident response plan, tabletop, BCP, DRP, lista kontaktów awaryjnych i komunikacja kryzysowa.
To cyberubezpieczenie. Może pomóc pokryć część kosztów, ale działa najlepiej wtedy, gdy dwie pierwsze warstwy są wdrożone i udokumentowane.
Po cyberataku firma często potrzebuje ekspertów natychmiast: forensics, incident response, prawnika, specjalisty od komunikacji, dostawcy odzyskiwania danych i wsparcia IT. Bez polisy koszty te trzeba pokryć z bieżącego budżetu.
Firma traci dostęp do poczty i systemu plików. Potrzebuje zespołu forensic, wsparcia przy odtworzeniu danych, prawników i komunikacji do klientów. Polisa może pomóc pokryć część takich kosztów, jeśli są objęte zakresem.
Dla wielu firm największym kosztem nie jest sama naprawa techniczna, ale przerwa w działalności. Sklep nie sprzedaje. Produkcja stoi. Konsultanci nie obsługują klientów. System fakturowania nie działa. Przychody spadają, a koszty stałe zostają.
Wyciek danych, utrata dostępności usługi lub incydent u dostawcy może uruchomić obowiązki wobec klientów, regulatorów, organów ochrony danych, partnerów i ubezpieczyciela. Firmie często potrzebny jest prawnik, który rozumie cyberincydenty i obowiązki zgłoszeniowe.
Jeżeli firma przechowuje dane klientów, dostarcza usługę cyfrową, obsługuje płatności lub utrzymuje system klienta, incydent może spowodować roszczenia. Cyberubezpieczenie może obejmować odpowiedzialność wobec osób trzecich, ale zakres trzeba sprawdzić bardzo dokładnie.
Niektóre polisy zapewniają dostęp do hotline, forensic experts, prawników, PR i zespołów incident response. To może być szczególnie ważne dla MŚP, które nie mają własnego zespołu security ani stałej umowy z firmą reagowania.
Ankieta ubezpieczeniowa bywa niewygodna, ale jest użyteczna. Broker lub ubezpieczyciel zapyta o MFA, backup, EDR, dostęp zdalny, szkolenia, incydenty, dostawców i procedury. Dzięki temu zarząd widzi, gdzie firma ma luki.
Coraz więcej klientów, szczególnie większe firmy i organizacje regulowane, wymaga od dostawców potwierdzenia cyberubezpieczenia. Dotyczy to zwłaszcza firm IT, SaaS, software house’ów, MSP, dostawców usług cyfrowych i podmiotów przetwarzających dane klientów.
Cyberbezpieczeństwo często jest opisywane technicznie. Cyberubezpieczenie zmusza do rozmowy o scenariuszach finansowych: ile kosztuje dzień przestoju, ile kosztuje wyciek danych, jakie limity są potrzebne, jaki udział własny jest akceptowalny i co firma może finansować sama.
Rozmowa o polisie powinna łączyć się z BCP i DRP. Polisa może pokrywać wybrane koszty, ale firma nadal musi wiedzieć, które systemy przywraca jako pierwsze, kto podejmuje decyzje i jak działa bez poczty, CRM lub systemu finansowego.
Dobra polisa i dobrze przygotowany plan incident response wskazują, kogo kontaktować, kiedy zgłosić szkodę, z których dostawców można korzystać i jakie informacje trzeba zebrać. To zmniejsza chaos w pierwszych godzinach kryzysu.
Każdy z tych elementów trzeba sprawdzić w OWU, ofercie, warunkach szczególnych i wyłączeniach. Nazwa „cyber” na polisie nie oznacza automatycznie pełnej ochrony przed każdym scenariuszem.
Największe rozczarowania pojawiają się wtedy, gdy firma zakłada, że polisa obejmuje wszystko. Nie obejmuje. Wyłączenia są równie ważne jak zakres ochrony.
Im więcej danych klientów, tym większe ryzyko kosztów notyfikacji, roszczeń, utraty zaufania i obsługi prawnej.
E-commerce, marketplace, platformy SaaS i usługi online mogą tracić przychody już po kilku godzinach niedostępności.
Incydent u dostawcy IT może dotknąć klientów. Często pojawiają się wymagania kontraktowe dotyczące cyberubezpieczenia.
MSP, MSSP, integratorzy, administratorzy i dostawcy utrzymania mają ryzyko odpowiedzialności za szkody po stronie klienta.
Te sektory przetwarzają dane wrażliwe, finansowe lub poufne, co zwiększa potencjalne skutki incydentu.
Dla mniejszych firm dostęp do ekspertów po incydencie może być jedną z największych praktycznych wartości polisy.
Decyzja o cyberubezpieczeniu powinna wynikać z oceny ryzyka, a nie z presji marketingowej. Zarząd powinien zobaczyć scenariusze, koszty, luki i zakres transferu ryzyka.
Firma powinna wiedzieć, co jest najważniejsze: poczta, system finansowy, CRM, ERP, sklep, produkcja, dane klientów, backup, system tożsamości i dostawcy.
MFA powinno obejmować pocztę, administratorów, VPN, chmurę, system finansowy, backup i dostawców z dostępem zdalnym.
Backup bez testu restore jest słabym dowodem odporności. Raport z testu jest jednym z najważniejszych dokumentów dla brokera i zarządu.
Zbyt wielu administratorów, konta współdzielone i brak access review zwiększają ryzyko oraz utrudniają rozmowę z ubezpieczycielem.
Publiczne RDP, stare VPN, konta dostawców bez MFA i niekontrolowane narzędzia zdalnego pulpitu są poważnym sygnałem ryzyka.
Firma powinna wiedzieć, kto działa w pierwszej godzinie, kto kontaktuje brokera, kto kontaktuje prawnika, kto decyduje o komunikacji i gdzie są kontakty awaryjne.
Business email compromise i fałszywe przelewy wymagają weryfikacji drugim kanałem, zasady dwóch osób i szkolenia finansów.
Dostawcy chmury, hostingu, IT, backupu, SOC, SaaS i systemów krytycznych mogą być źródłem incydentu lub przestoju.
Najlepsza odpowiedź w ankiecie to odpowiedź z dowodem: raport MFA, raport backupu, test restore, EDR, access review, szkolenia, IR plan, BCP, rejestr dostawców i decyzje zarządu.
Sprawdź, jakie typy incydentów są objęte. Nie zakładaj, że ransomware, BEC, social engineering fraud, incydent u dostawcy i przerwa w działalności są zawsze w standardzie.
Polisa może mieć ogólny limit, ale konkretne scenariusze mogą mieć niższe podlimity. To szczególnie ważne przy BEC, cyber extortion, PR, forensics i incydentach u dostawców.
Niski koszt polisy może wiązać się z większym udziałem własnym. Zarząd powinien wiedzieć, jaki koszt firma poniesie samodzielnie.
Sprawdź, jakie zabezpieczenia firma musi mieć i utrzymywać. Deklaracje z ankiety powinny być zgodne z rzeczywistością.
Polisa może wymagać określonego sposobu zgłoszenia szkody, kontaktu z hotline, użycia wskazanych dostawców albo uzyskania zgody przed poniesieniem części kosztów.
To najważniejsza część. Wyłączenie może sprawić, że scenariusz najbardziej realny dla firmy nie będzie objęty ochroną.
Cyberubezpieczenie powinno być widoczne w modelu zarządzania ryzykiem. Nie powinno być tylko dokumentem w dziale finansów.
Polisa nie zatrzyma ataku. Ubezpieczyciel może oczekiwać, że firma utrzymuje podstawowe zabezpieczenia.
Firma patrzy na cenę i limit, ale nie sprawdza, czy polisa obejmuje BEC, dostawców, ransomware, PR i przerwę w działalności.
Odpowiedź „mamy MFA” jest za słaba, jeśli firma nie wie, czy MFA obejmuje administratorów, VPN, dostawców i backup.
Ankieta wymaga wiedzy IT, finansów, legal, DPO, zarządu, HR, dostawców i właścicieli procesów.
Backup bez testu odtworzenia nie daje pewności, że firma wróci do działania po ransomware.
W kryzysie firma nie powinna dopiero szukać numeru do brokera, ubezpieczyciela, prawnika i dostawcy incident response.
Zmiana chmury, dostawcy, systemu, zakresu danych albo modelu pracy może wpływać na ryzyko i warunki polisy.
Najtańsza polisa może mieć mniejszy zakres, wysokie podlimity, duże wyłączenia lub brak ochrony dla najważniejszych scenariuszy.
Firma SaaS zatrudnia 60 osób i obsługuje klientów B2B. Korzysta z Microsoft 365, chmury, repozytorium kodu, systemu ticketowego, CRM i zewnętrznego dostawcy DevOps. Jeden z większych klientów wymaga potwierdzenia cyberubezpieczenia przed przedłużeniem umowy.
Zarząd początkowo traktuje polisę jako formalność. Broker przesyła ankietę. Okazuje się, że firma ma MFA tylko dla części kont, backup nie był testowany od roku, konta administratorów nie były przeglądane, a incident response plan jest nieaktualny. Polisa jest dostępna, ale warunki są słabsze niż oczekiwano.
Firma przez 60 dni poprawia najważniejsze elementy: włącza MFA dla administratorów i dostawców, wykonuje test restore, porządkuje konta DevOps, aktualizuje incident response plan, szkoli zespół i przygotowuje pakiet dowodów. Po ponownej rozmowie z brokerem firma ma lepszą pozycję negocjacyjną i przede wszystkim lepiej rozumie własne ryzyko.
ccyber.io pomaga firmom traktować cyberubezpieczenie jako element zarządzania ryzykiem, a nie tylko zakup polisy. Pomagamy przygotować organizację do rozmowy z brokerem, ocenić luki, zebrać dowody i sprawdzić, czy zakres polisy odpowiada realnym scenariuszom incydentów.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Insurance Risk Workshop. W krótkim warsztacie można ustalić, czy firma potrzebuje cyberubezpieczenia, jakie scenariusze powinna objąć polisa, gdzie są luki w zabezpieczeniach i jakie dowody przygotować przed rozmową z brokerem.
Nie każda firma potrzebuje takiej samej polisy, ale każda firma zależna od danych, systemów, poczty, płatności, chmury lub klientów cyfrowych powinna przynajmniej przeanalizować scenariusze cyberfinansowe i koszt incydentu.
Nie. Polisa nie zapobiega atakom. Firma nadal musi mieć podstawowe zabezpieczenia, takie jak MFA, backup, EDR, aktualizacje, szkolenia i incident response.
Najważniejsze jest zrozumienie ryzyk, przygotowanie dowodów zabezpieczeń, sprawdzenie wyłączeń i upewnienie się, że odpowiedzi w ankiecie są zgodne z rzeczywistością.
Może obejmować, ale zależy to od warunków polisy. Trzeba sprawdzić limity, podlimity, warunki, wyłączenia i wymagane zabezpieczenia.
Nie zawsze. Business email compromise i social engineering fraud często wymagają dodatkowego zakresu albo mają podlimity.
Może dojść do sporu, jeśli firma podała nieprawdziwe informacje, nie spełniała warunków polisy, naruszyła obowiązki po incydencie albo szkoda jest objęta wyłączeniem.
Najlepiej, aby właścicielem biznesowym był CFO, risk lub zarząd, ale z aktywnym udziałem IT, security, legal, DPO, compliance i właścicieli procesów.
Zacznij od scenariuszy: ransomware, przejęcie poczty, wyciek danych, fałszywy przelew, awaria dostawcy i przestój systemu krytycznego. Następnie sprawdź, czy polisa i zabezpieczenia odpowiadają tym scenariuszom.
Cyberubezpieczenie jest ważne, ponieważ pomaga firmie przygotować się finansowo i organizacyjnie na skutki cyberincydentu. Może wspierać reakcję, odtwarzanie, obsługę prawną, komunikację, roszczenia i przerwę w działalności.
Nie jest jednak magiczną ochroną przed atakiem. Największą wartość daje jako część modelu zarządzania ryzykiem: obok podstawowych zabezpieczeń, planów reakcji, ciągłości działania, testów i dowodów.
Najlepsza zasada brzmi: nie kupuj cyberubezpieczenia po to, żeby nie zajmować się cyberbezpieczeństwem. Kupuj je po to, żeby świadomie przenieść część ryzyka, którego nie da się całkowicie wyeliminować, i mieć wsparcie wtedy, gdy mimo zabezpieczeń wydarzy się incydent.
Czy NIS2 obejmuje ewidencję zasobów i ich widoczność? Zakres i konkretne wymagania
Tak, NIS2 obejmuje ewidencję zasobów i ich widoczność, choć nie zawsze używa potocznego języka „CMDB” albo „asset inventory”. W art. 21 dyrektywa wskazuje asset management, polityki kontroli dostępu, bezpieczeństwo systemów, ciągłość działania, supply chain security i ocenę skuteczności środków. W praktyce oznacza to, że firma powinna wiedzieć, jakie ma systemy, urządzenia, aplikacje, konta, dane, usługi chmurowe, dostawców i zasoby publiczne, kto jest ich właścicielem, jaką mają krytyczność, jakie dane przetwarzają, kto ma dostęp, czy są objęte backupem, aktualizacjami, monitoringiem i kontrolami bezpieczeństwa. Dla części podmiotów cyfrowych i usług zarządzanych rozporządzenie wykonawcze 2024/2690 doprecyzowuje wymóg kompletnej, dokładnej, aktualnej i spójnej ewidencji aktywów.
Opracowanie: Zespół redakcyjny CCyber
Tak, NIS2 obejmuje ewidencję zasobów i ich widoczność. Nie oznacza to, że każda firma musi mieć od razu drogi system CMDB, CAASM, EASM albo narzędzie klasy enterprise. Oznacza to jednak, że organizacja objęta NIS2 powinna potrafić wykazać, jakie ma zasoby, które z nich są krytyczne, kto jest ich właścicielem, jakie dane przetwarzają, kto ma do nich dostęp, czy są chronione, czy są monitorowane i jak wpływają na ciągłość działania. Ewidencja zasobów jest potrzebna do analizy ryzyka, kontroli dostępu, zarządzania podatnościami, backupu, incident response, supply chain security, testów skuteczności i raportowania do zarządu. Bez widoczności zasobów zgodność z NIS2 będzie deklaracją, a nie działającym systemem zarządzania ryzykiem.
Lipiec 2026
Tak. NIS2 w art. 21 wskazuje między innymi bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i asset management. To oznacza, że zarządzanie zasobami jest częścią obowiązkowych środków zarządzania ryzykiem cyber dla podmiotów objętych dyrektywą.
Jednocześnie ewidencja zasobów wynika też pośrednio z innych wymagań. Nie da się prowadzić analizy ryzyka, zarządzać incydentami, planować backupu, oceniać dostawców, kontrolować dostępu i testować skuteczności zabezpieczeń bez wiedzy o tym, jakie zasoby firma posiada.
Widoczność zasobów to zdolność organizacji do szybkiego ustalenia, jakie zasoby istnieją, gdzie się znajdują, kto za nie odpowiada, jaki mają status bezpieczeństwa i jaki wpływ mają na usługę lub proces biznesowy. Sama lista sprzętu nie wystarczy.
Ewidencja to rejestr. Pokazuje, co firma ma. Może być prowadzona w arkuszu, CMDB, narzędziu ITSM, systemie asset management albo platformie GRC.
Widoczność to zdolność do wykrywania i potwierdzania stanu zasobów. Pokazuje, czy rejestr odzwierciedla rzeczywistość. Widoczność pochodzi z katalogu użytkowników, EDR, MDM, DHCP, DNS, firewalla, chmury, backupu, skanerów, faktur, umów i rozmów z właścicielami procesów.
Firma ma w arkuszu 120 laptopów. To jest ewidencja. Ale EDR pokazuje 138 urządzeń, DHCP pokazuje 151 nazw hostów, a księgowość pokazuje faktury za 9 narzędzi SaaS poza listą IT. To jest widoczność. Dopiero połączenie obu warstw daje realną kontrolę.
Rozporządzenie wykonawcze 2024/2690 doprecyzowuje techniczne i metodologiczne wymagania NIS2 dla wybranych podmiotów cyfrowych i usług zaufania, między innymi dostawców DNS, rejestrów TLD, chmury, data center, CDN, usług zarządzanych, usług bezpieczeństwa zarządzanego, marketplace, wyszukiwarek, platform społecznościowych i usług zaufania.
To rozporządzenie nie jest automatycznie szczegółowym katalogiem wymagań dla każdego podmiotu NIS2 w każdym sektorze, ale jest bardzo dobrym punktem odniesienia. Pokazuje, jak regulator rozumie asset management: klasyfikację zasobów, ewidencję, aktualność, spójność, historię zmian i zarządzanie cyklem życia.
Dla podmiotów objętych rozporządzeniem 2024/2690 wymagania są znacznie bardziej konkretne niż ogólne brzmienie NIS2. W praktyce warto wykorzystać je jako benchmark także w innych organizacjach.
Organizacja powinna określić poziomy klasyfikacji zasobów, w tym informacji, objętych zakresem jej systemów sieciowych i informacyjnych. Klasyfikacja powinna odpowiadać potrzebnemu poziomowi ochrony.
Organizacja powinna utrzymywać ewidencję zasobów, która jest kompletna, dokładna, aktualna i spójna. Zmiany w ewidencji powinny być śledzone w sposób umożliwiający odtworzenie historii.
Rejestr nie musi być przesadnie szczegółowy dla każdego drobnego elementu, ale musi być wystarczający do ryzyka, ochrony, monitorowania, odtwarzania i audytu.
Rejestr powinien obejmować operacje i usługi oraz systemy sieciowe, informacyjne i inne zasoby wspierające te operacje oraz usługi.
Rejestr powinien być regularnie przeglądany i aktualizowany. Historia zmian powinna być dokumentowana.
Rejestr powinien być prosty, ale użyteczny. Jego celem nie jest tworzenie archiwum, którego nikt nie czyta. Celem jest zarządzanie ryzykiem.
Może to być arkusz lub lekka baza. Ważne, aby miał właściciela, wersję, pola obowiązkowe i cykl przeglądu.
Jeżeli EDR pokazuje 80 laptopów, katalog użytkowników 95 urządzeń, a DHCP 120 hostów, to nie jest problem do ukrycia. To jest materiał do wyjaśnienia. Różnice pokazują, gdzie brakuje widoczności.
Nieznany zasób nie powinien znikać z raportu. Powinien mieć status „do wyjaśnienia”, właściciela działań i termin.
Nowy system, nowy dostawca, nowa aplikacja SaaS, nowa integracja, nowa domena i nowe konto administratora powinny uruchamiać aktualizację ewidencji.
Ewidencja bez działań naprawczych jest tylko katalogiem. NIS2 wymaga zarządzania ryzykiem, dlatego wynik przeglądu powinien prowadzić do decyzji.
NIS2 nie dotyczy tylko laptopów. Największe ryzyko może być w SaaS, kontach administratorów, publicznych zasobach, danych i dostawcach.
Lista systemów bez informacji, które usługi wspierają, nie pomaga w ocenie wpływu incydentu.
IT może znać nazwę systemu, ale biznes wie, jak bardzo awaria uderzy w klientów, przychody i operacje.
Nowy dostawca, nowa aplikacja, nowa integracja lub nowe konto administratora powinny aktualizować rejestr.
Porzucone subdomeny, stare VPN, publiczne panele i zapomniane serwery testowe są częstym źródłem ryzyka.
Rejestr bez informacji o MFA, backupie, EDR, aktualizacjach i monitoringu nie wspiera realnego zarządzania ryzykiem.
Audytor może zapytać, kiedy zasób został dodany, kto zmienił krytyczność i dlaczego system został wycofany.
Nawet najlepsze narzędzie nie pomoże, jeśli nikt nie potwierdza właścicieli, nie zamyka luk i nie raportuje ryzyka.
Firma usługowa zatrudnia 110 osób i przygotowuje się do audytu klienta objętego NIS2. Firma ma Microsoft 365, CRM, system fakturowania, repozytorium plików, kilka aplikacji SaaS, dostawcę IT i zewnętrzny backup. IT ma listę laptopów, ale nie ma pełnej listy aplikacji, usług chmurowych, kont administratorów i publicznych zasobów.
Podczas pierwszego przeglądu firma tworzy rejestr zasobów. Eksportuje użytkowników i administratorów z Microsoft Entra ID, urządzenia z EDR, aplikacje z faktur, domeny z DNS, publiczne IP z hostingu i systemy objęte backupem. Okazuje się, że firma używa 18 usług SaaS, z czego 7 nie było znanych IT. Trzy systemy krytyczne nie mają potwierdzonego testu restore. Dwa konta dostawcy mają dostęp administratora bez formalnego właściciela. Jedna stara subdomena prowadzi do nieużywanego panelu testowego.
Firma nie kupuje od razu drogiego narzędzia. Najpierw porządkuje właścicieli, krytyczność, MFA, backup, publiczną ekspozycję i dostęp dostawców. Po 90 dniach ma rejestr zasobów, raport braków, plan naprawczy i dowód przeglądu dla audytora. To nie jest idealny model enterprise, ale jest to działający system widoczności, który wspiera zgodność z NIS2.
ccyber.io pomaga firmom przygotować ewidencję zasobów i model widoczności zgodny z NIS2 bez nadmiernych kosztów i bez zaczynania od drogich narzędzi enterprise. Budujemy proces, rejestr, źródła danych, metryki, dowody i plan poprawy.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Asset Visibility Workshop. W krótkim warsztacie można ustalić, jakie zasoby firma już widzi, gdzie są największe luki, jakie źródła danych można wykorzystać bez nowych kosztów i jaki rejestr wystarczy na pierwszym etapie zgodności.
Tak. NIS2 wskazuje asset management jako element środków zarządzania ryzykiem cyber. Ewidencja zasobów jest także niezbędna do ryzyka, dostępu, backupu, incydentów, dostawców i ciągłości działania.
Nie. NIS2 nie wskazuje konkretnego narzędzia. Liczy się to, czy firma potrafi wykazać aktualną ewidencję, właścicieli, krytyczność, status zabezpieczeń i regularny przegląd.
Na początku tak, jeśli ma właściciela, wersję, obowiązkowe pola, historię zmian, cykliczny przegląd i jest porównywany z danymi technicznymi. Dla większych organizacji arkusz może szybko przestać wystarczać.
Widoczność oznacza, że firma nie tylko ma rejestr, ale potrafi wykrywać zasoby z różnych źródeł, porównywać je z rejestrem, identyfikować braki i uruchamiać działania naprawcze.
Systemy krytyczne, dane klientów, tożsamość, poczta, backup, systemy finansowe, publiczne zasoby, konta administratorów, usługi SaaS, chmura i dostawcy z dostępem.
Nie. Dotyczy wybranych kategorii podmiotów cyfrowych i usług zaufania. Jest jednak bardzo dobrym praktycznym punktem odniesienia dla asset management także w innych organizacjach.
Zasoby krytyczne warto przeglądać co najmniej kwartalnie oraz po każdej istotnej zmianie. Pełny przegląd można robić raz w roku lub częściej, jeśli organizacja szybko się zmienia.
Zacznij od listy usług krytycznych, systemów, użytkowników, administratorów, urządzeń, aplikacji SaaS, dostawców, domen, publicznych IP i backupu. Następnie przypisz właścicieli, krytyczność i status zabezpieczeń.
NIS2 obejmuje ewidencję zasobów i ich widoczność, bo bez nich nie da się zarządzać ryzykiem cyber. Asset management jest wskazany wprost w art. 21, a konkretne wymagania dla części podmiotów cyfrowych i usług zarządzanych zostały doprecyzowane w rozporządzeniu wykonawczym 2024/2690.
W praktyce ewidencja zgodna z NIS2 powinna obejmować nie tylko sprzęt, ale także usługi biznesowe, systemy ICT, aplikacje, dane, konta, dostawców, chmurę, zasoby publiczne, backup, monitoring i zależności. Każdy zasób powinien mieć właściciela, krytyczność, status zabezpieczeń i datę przeglądu.
Najlepsza zasada brzmi: nie pytaj tylko, czy mamy listę zasobów. Zapytaj, czy ta lista pozwala zarządzać ryzykiem, odtworzyć działanie po incydencie, wykryć zasoby nieznane i pokazać audytorowi, że organizacja wie, co chroni.
Integracja zarządzania ryzykiem stron trzecich i zarządzania ryzykiem ICT w jeden model operacyjny
Zarządzanie ryzykiem stron trzecich i zarządzanie ryzykiem ICT nie powinny działać jako dwa osobne światy. Dostawca ICT, chmura, SaaS, SOC, backup, system finansowy, integrator OT albo software house są jednocześnie stroną trzecią, elementem środowiska ICT, zależnością operacyjną i potencjalnym źródłem incydentu. Jeden model operacyjny powinien łączyć rejestr dostawców, rejestr usług ICT, rejestr aktywów, rejestr ryzyk, umowy, dostęp dostawców, incydenty, BCP, DRP, testy, monitoring, exit plany i raportowanie do zarządu. Najważniejsze pytanie brzmi: czy w razie incydentu u dostawcy firma potrafi szybko ustalić wpływ, właściciela, dane, systemy, klientów, obowiązki zgłoszeniowe i plan odtworzenia?
Opracowanie: Zespół redakcyjny CCyber
Integracja zarządzania ryzykiem stron trzecich i zarządzania ryzykiem ICT oznacza, że firma nie prowadzi osobno rejestru dostawców, osobno rejestru systemów, osobno rejestru ryzyk i osobno planów ciągłości działania. Wszystkie te elementy są połączone jednym modelem operacyjnym. Każdy dostawca ICT powinien być powiązany z usługą biznesową, systemem, danymi, właścicielem, umową, poziomem krytyczności, dostępem, ryzykiem, kontrolami, incydentami, testami i planem wyjścia. Dzięki temu incydent u dostawcy nie jest zaskoczeniem organizacyjnym. Firma wie, kogo powiadomić, które systemy mogą ucierpieć, jakie dane są zagrożone, jakie obowiązki zgłoszeniowe mogą się uruchomić i jak utrzymać działanie.
Lipiec 2026
W wielu firmach ryzyko stron trzecich jest prowadzone przez zakupy, legal lub compliance, a ryzyko ICT przez IT lub security. Obie funkcje używają innych rejestrów, innych właścicieli, innych ankiet i innych raportów. Problem pojawia się wtedy, gdy dostawca ma incydent.
Jeden model operacyjny ma usunąć ten problem. Dostawca nie jest tylko rekordem w zakupach. Jest zależnością operacyjną, elementem ICT, częścią łańcucha dostaw i potencjalnym scenariuszem incydentowym.
TPRM koncentruje się na ryzyku wynikającym z relacji z podmiotami zewnętrznymi. Obejmuje dostawców, podwykonawców, partnerów, outsourcing, chmurę, SaaS, usługi zarządzane, biura rachunkowe, operatorów płatności i inne zależności.
Zarządzanie ryzykiem ICT koncentruje się na systemach, usługach, infrastrukturze, danych, aplikacjach, dostępach, incydentach, ciągłości działania, podatnościach, zmianach i odporności cyfrowej.
W tych przypadkach nie da się oddzielić pytania „czy dostawca jest bezpieczny?” od pytania „czy nasze ICT jest odporne?”. To jest ten sam problem widziany z dwóch stron.
Jeden model operacyjny to wspólny sposób pracy dla ryzyka stron trzecich, ryzyka ICT, incydentów i ciągłości działania. Nie oznacza jednej aplikacji. Oznacza wspólne role, dane, procesy, decyzje, metryki i dowody.
Największy błąd polega na tym, że firma ma listę dostawców, ale nie wie, jak ich awaria wpłynie na usługi biznesowe. Dostawca powinien być połączony z konkretną usługą, systemem, procesem i właścicielem.
Dostawca „CloudHost X” nie powinien być tylko rekordem w rejestrze zakupowym. Powinien być powiązany z:
Dopiero wtedy firma wie, co oznacza incydent u tego dostawcy.
TPRM i ICT risk powinny używać tych samych pojęć: krytyczność, wpływ, prawdopodobieństwo, kontrola, właściciel, ryzyko rezydualne, wyjątek, działanie naprawcze i akceptacja ryzyka.
Dostawca, system i usługa powinny być oceniane według wspólnej skali. Jeżeli system jest krytyczny, a dostawca go utrzymuje, dostawca automatycznie powinien być oceniany jako wysoki lub krytyczny.
Firma powinna widzieć zależności między dostawcą, usługą ICT, systemem, danymi, lokalizacją, podwykonawcą i klientem.
Ryzyko dostawcy nie powinno być akceptowane tylko przez zakupy. Ryzyko ICT nie powinno być akceptowane tylko przez IT. Akceptacja powinna mieć właściciela biznesowego i widoczność zarządu dla ryzyk wysokich.
Incydent u dostawcy powinien trafiać do tego samego procesu incident response, co incydent wewnętrzny. Różni się źródło, ale wpływ na firmę może być taki sam.
Zarząd powinien widzieć jeden obraz: top ryzyka ICT, top dostawcy, zależności krytyczne, incydenty, testy, luki, wyjątki i działania naprawcze.
Zanim firma wybierze dostawcę, powinna ustalić, jaką usługę biznesową będzie wspierał, jakie dane będzie przetwarzał i jaki wpływ będzie miała jego awaria.
Ocena dostawcy powinna obejmować cyberbezpieczeństwo, odporność, ciągłość działania, podwykonawców, lokalizację danych, zgodność, testy, incydenty i plan wyjścia.
Równolegle trzeba ocenić ryzyko usługi ICT: krytyczność, dostęp, integracje, dane, podatności, monitoring, backup i wpływ na proces biznesowy.
Wymagania bezpieczeństwa, incydentów, audytu, podwykonawstwa, SLA, backupu, testów i wyjścia muszą trafić do umowy albo załącznika bezpieczeństwa.
Dostawca otrzymuje tylko wymagany dostęp. Powstaje rekord w rejestrze dostawców, usług ICT, dostępów, ryzyk i BCP.
Firma monitoruje SLA, incydenty, podatności, zmiany usługi, zmiany podwykonawców, wyniki testów, access review i działania naprawcze.
Okresowy przegląd powinien jednocześnie obejmować dostawcę, usługę ICT, ryzyka, umowę, dostęp, incydenty i plan wyjścia.
Incydent u dostawcy uruchamia wspólny proces: ocena wpływu, eskalacja, komunikacja, zgłoszenia, praca awaryjna, odtworzenie, raport i działania naprawcze.
Wyjście z dostawcy powinno obejmować migrację danych, odebranie dostępów, usunięcie integracji, potwierdzenie usunięcia danych, zmianę dokumentacji, test nowego modelu i zamknięcie ryzyk.
Dostawca lub usługa, których awaria zatrzyma funkcję krytyczną, produkcję, płatności, obsługę klientów, bezpieczeństwo, dostęp do danych albo odtworzenie działania.
Dostawca lub usługa mają istotny wpływ na procesy, dane, klientów lub systemy, ale istnieje ograniczone obejście krótkoterminowe.
Dostawca wspiera proces, ale jego awaria nie zatrzyma firmy i można działać ręcznie przez pewien czas.
Dostawca nie ma dostępu do danych wrażliwych, systemów krytycznych ani procesów istotnych dla ciągłości działania.
Kategoria tego artykułu nie jest przypadkowa. Zintegrowany model ryzyka dostawców i ICT ma największą wartość wtedy, gdy wydarzy się incydent. Firma nie ma wtedy czasu na ręczne łączenie faktów.
W praktyce wiele planów BCP opisuje awarię systemu, ale nie opisuje awarii dostawcy, podwykonawcy, chmury, SaaS, operatora płatności albo dostawcy backupu. To luka.
Exit plan to operacyjny plan odejścia od dostawcy. Powinien obejmować dane, systemy, integracje, konta, podwykonawców, licencje, terminy, koszty, testy i komunikację.
Nie trzeba zaczynać od dużej platformy GRC. Na start wystarczy dobrze zaprojektowany rejestr w arkuszu, lekkim narzędziu ITSM, systemie ticketowym albo prostym GRC. Ważne, aby dane były spójne.
Jednorazowa ankieta nie daje modelu operacyjnego. Dostawca musi być monitorowany przez cały okres współpracy.
Rejestr ryzyk mówi o systemie, ale nie pokazuje, że system jest utrzymywany przez dostawcę albo zależy od chmury.
IT i zakupy nie powinny samodzielnie akceptować ryzyka dla usługi biznesowej. Właściciel procesu musi brać udział w decyzji.
Umowa opisuje usługę i cenę, ale nie opisuje zgłaszania incydentów, podwykonawców, audytu, testów i wyjścia.
Plan ciągłości zakłada awarię systemu, ale nie zakłada awarii dostawcy, który ten system utrzymuje.
Dostawca ma konto administratora, ale nikt nie wykonuje access review, nie wymusza MFA i nie loguje działań.
Firma ma exit plan lub DRP, ale nigdy nie sprawdziła, czy można go wykonać w praktyce.
Zarząd dostaje osobno raport zakupów, IT i security, ale nie widzi jednej mapy zależności i ryzyk.
Firma e-commerce korzysta z platformy sklepowej, dostawcy płatności, hostingu, Microsoft 365, CRM, dostawcy IT, narzędzia marketing automation i zewnętrznego backupu. Zakupy mają listę umów. IT ma listę systemów. Security ma rejestr ryzyk. BCP opisuje awarię sklepu, ale nie opisuje awarii dostawcy płatności ani hostingu.
Podczas incydentu u dostawcy płatności zarząd pyta, ilu klientów jest dotkniętych, czy można przełączyć płatności, czy trzeba informować klientów i jaki jest wpływ finansowy. Zespół potrzebuje kilku godzin, aby połączyć dane z umów, systemów i ryzyk.
Firma wdraża jeden model operacyjny. Każdy dostawca jest powiązany z usługą, systemem, danymi, właścicielem i BCP. Dostawca płatności dostaje status krytyczny. Umowa zostaje uzupełniona o incydenty, SLA i plan wyjścia. Firma robi tabletop awarii dostawcy płatności. Po trzech miesiącach zarząd ma raport pokazujący najważniejsze zależności, single points of failure i działania naprawcze.
ccyber.io pomaga organizacjom połączyć zarządzanie ryzykiem stron trzecich i zarządzanie ryzykiem ICT w jeden model operacyjny, który działa w audycie i w realnym incydencie. Łączymy perspektywę cyberbezpieczeństwa, dostawców, umów, ciągłości działania, DORA, NIS2, ISO 27001 i zarządzania kryzysowego.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Integrated TPRM and ICT Risk Workshop. W krótkim warsztacie można ustalić, które dostawcy są krytyczni, które usługi ICT są najbardziej wrażliwe, gdzie brakuje powiązań między rejestrami i jak przygotować model działania na incydent u dostawcy.
Można, ale jest to ryzykowne. W praktyce dostawca ICT jest jednocześnie stroną trzecią, zasobem operacyjnym, ryzykiem technologicznym i potencjalnym źródłem incydentu.
Najlepszym punktem integracji jest usługa biznesowa lub usługa ICT. Do niej można podłączyć dostawcę, system, dane, właściciela, umowę, ryzyka, incydenty, BCP i exit plan.
Nie na początku. Można zacząć od dobrze zaprojektowanych rejestrów, wspólnego modelu danych i regularnych przeglądów. Narzędzie GRC pomaga później, gdy proces jest już zdefiniowany.
DORA mocno formalizuje ryzyko ICT i dostawców ICT. NIS2 wymaga zarządzania ryzykiem cyber i bezpieczeństwem łańcucha dostaw. ISO 27001 i NIST pomagają uporządkować model kontroli i ryzyka.
Najlepiej, aby właścicielem operacyjnym był risk, CISO, vCISO lub funkcja governance, ale decyzje muszą angażować biznes, IT, legal, compliance, zakupy i zarząd.
Zacznij od mapy zależności: dostawca, usługa ICT, system, dane, właściciel, krytyczność, umowa, dostęp, BCP i exit plan. To szybko pokazuje największe luki.
Najlepszy test to tabletop incydentu u dostawcy krytycznego. Sprawdź, czy firma potrafi w godzinę ustalić wpływ, dane, klientów, obowiązki zgłoszeniowe i plan działania.
Rejestr dostawców ICT, mapa usług i zależności, oceny ryzyka, umowy z klauzulami bezpieczeństwa, access review dostawców, BCP, DRP, exit plany, tabletop i raport dla zarządu.
Integracja TPRM i zarządzania ryzykiem ICT w jeden model operacyjny jest potrzebna, ponieważ współczesne incydenty rzadko mieszczą się w jednym silosie. Awaria lub atak u dostawcy może jednocześnie dotknąć danych, systemów, klientów, ciągłości działania, obowiązków zgłoszeniowych i reputacji.
Dobry model łączy dostawców, usługi ICT, aktywa, dane, ryzyka, dostęp, umowy, incydenty, testy, BCP, DRP i exit plany. Nie chodzi o stworzenie kolejnego rejestru, ale o to, aby firma mogła działać szybciej i mądrzej, gdy zależność od dostawcy staje się problemem operacyjnym.
Najlepsza zasada brzmi: nie pytaj tylko, czy dostawca przeszedł ankietę. Zapytaj, jak jego awaria zatrzyma Twoją usługę, jakie dane są zagrożone, kto podejmuje decyzję, jaki plan obejścia istnieje i czy ten plan był testowany.
Jak zapewnić pełną ewidencję i widoczność zasobów zgodną z NIS2 bez drogich narzędzi enterprise?
Pełna ewidencja zasobów zgodna z NIS2 nie musi oznaczać drogiego systemu klasy enterprise. Dla MŚP najważniejsze jest, aby firma wiedziała, jakie ma urządzenia, konta, aplikacje, usługi chmurowe, dane, dostawców, systemy krytyczne i publicznie dostępne zasoby. Można zacząć od arkusza, eksportów z Microsoft 365 lub Google Workspace, danych z routera, DHCP, DNS, EDR, antywirusa, backupu, faktur, umów, systemu księgowego i prostych skanów sieci. Kluczowe nie jest narzędzie, ale proces: właściciel zasobu, krytyczność, dane, dostęp, backup, aktualizacje, dostawca, status zabezpieczeń i regularny przegląd.
Opracowanie: Zespół redakcyjny CCyber
Pełna ewidencja i widoczność zasobów zgodna z NIS2 nie musi zaczynać się od zakupu drogiego CMDB, EASM, CAASM albo platformy klasy enterprise. Dla MŚP najważniejsze jest zbudowanie wiarygodnego, regularnie aktualizowanego rejestru zasobów i połączenie go z prostymi źródłami danych: katalogiem użytkowników, systemem poczty, MDM lub EDR, routerem, DHCP, DNS, firewallem, backupem, chmurą, fakturami, umowami i systemem księgowym. Firma powinna wiedzieć, jakie ma urządzenia, aplikacje, systemy, konta, dane, usługi chmurowe, dostawców i zasoby wystawione do internetu. Pełna widoczność nie oznacza idealnej automatyzacji od pierwszego dnia. Oznacza, że firma potrafi odpowiedzieć: co mamy, kto jest właścicielem, jak krytyczne to jest, jakie dane tam są, kto ma dostęp, czy jest backup, czy są aktualizacje i czy zasób jest monitorowany.
Lipiec 2026
NIS2 nie mówi, że każda firma musi kupić konkretny system do inwentaryzacji. Wymaga jednak zarządzania ryzykiem cyber, a tego nie da się zrobić bez wiedzy o zasobach. Jeżeli firma nie wie, jakie systemy posiada, kto ma do nich dostęp, gdzie są dane i które usługi są krytyczne, nie jest w stanie rzetelnie ocenić ryzyka, przygotować planu ciągłości działania ani wykazać zgodności.
Najprościej: ewidencja zasobów to fundament dla ryzyka, MFA, backupu, podatności, incydentów, dostawców, ciągłości działania i audytu.
Nie. W małej lub średniej firmie pełna ewidencja nie oznacza, że od pierwszego dnia każdy kabel, każde urządzenie i każda aplikacja są automatycznie widoczne w jednej konsoli. Oznacza, że firma ma proces, który pozwala stale zbliżać się do kompletności i szybko wykrywać braki.
Audytor lub klient rzadko oczekuje od MŚP idealnego systemu klasy globalnej korporacji. Będzie jednak oczekiwać, że firma ma jasny rejestr, właścicieli, daty, krytyczność, status zabezpieczeń i dowody cyklicznego przeglądu.
Drogie narzędzia mogą być bardzo pomocne, ale nie rozwiążą problemu, jeśli firma nie ma procesu. Narzędzie bez właścicieli, klasyfikacji, przeglądu i decyzji biznesowych stanie się kolejną nieaktualną bazą danych.
Najważniejsze jest, aby rejestr był używany w decyzjach. Jeżeli z rejestru wynika, że system nie ma właściciela, nie ma backupu albo ma publiczny dostęp, musi powstać działanie naprawcze.
Rejestr nie musi być skomplikowany. Musi jednak zawierać pola, które pozwalają podejmować decyzje o ryzyku.
To arkusz, prosta baza, system ticketowy albo lekkie narzędzie IT asset management. Rejestr główny jest miejscem, w którym firma podejmuje decyzje. Nie musi automatycznie odkrywać wszystkiego, ale musi zbierać wynik z wielu źródeł.
To systemy, z których zbierasz dane: Microsoft 365, Google Workspace, katalog użytkowników, MDM, EDR, antywirus, firewall, DHCP, DNS, backup, chmura, hosting, repozytorium kodu i skaner sieciowy.
Automatyka nie wie wszystkiego. Właściciel biznesowy musi potwierdzić, czy system nadal jest używany, czy jest krytyczny, jakie dane zawiera i czy dostawca nadal ma dostęp.
Widoczność ma prowadzić do działań. Nieznane urządzenie, brak MFA, brak backupu, publiczny port, nieużywana aplikacja albo konto byłego pracownika powinny trafić do planu naprawczego.
Microsoft Entra ID, Active Directory, Google Workspace albo inny katalog tożsamości pokazuje użytkowników, grupy, konta administratorów, urządzenia, aplikacje i logowania.
Panel administracyjny pokazuje licencje, użytkowników, grupy, urządzenia, usługi, aplikacje i część ustawień bezpieczeństwa.
Nawet prosty router, serwer DHCP albo DNS daje dużo informacji o urządzeniach widzianych w sieci.
Firewall pokazuje publiczne usługi, połączenia zdalne, reguły NAT, VPN i ruch do internetu. To bardzo ważne dla widoczności powierzchni ataku.
Jeżeli firma ma ochronę urządzeń, konsola zwykle pokazuje laptopy, serwery, wersje systemu, status agenta i brakujące aktualizacje.
Backup pokazuje, które systemy są objęte kopią, które nie są, które kopie się nie udały i kiedy był test odtworzenia.
AWS, Azure, Google Cloud, hosting, VPS i platformy PaaS pokazują zasoby, które mogą być niewidoczne w lokalnej sieci.
Część najważniejszych zasobów ukrywa się w kosztach. Faktura za narzędzie SaaS może ujawnić usługę, o której IT nie wiedziało.
Okresowy skan wewnętrznej sieci może pokazać urządzenia, otwarte usługi i niespodziewane systemy. Trzeba wykonywać go ostrożnie, szczególnie w środowiskach OT.
Nie wszystko znajdziesz technicznie. Marketing, sprzedaż, finanse, HR i produkcja mogą używać narzędzi, których nie widać w centralnym IT.
Shadow IT to narzędzia, konta, aplikacje, urządzenia i usługi używane poza formalną kontrolą organizacji. W MŚP często powstaje bez złych intencji. Ktoś kupuje narzędzie do marketingu, zakłada konto testowe, używa prywatnego dysku albo zamawia małą aplikację u dostawcy.
Nie każdy zasób wymaga takiej samej uwagi. Krytyczność pomaga ustalić priorytety zabezpieczeń i działań naprawczych.
Zasób, którego awaria zatrzymuje sprzedaż, produkcję, płatności, obsługę klientów, bezpieczeństwo, dostęp do danych lub odtwarzanie działania.
Zasób ważny dla wielu użytkowników, danych klientów, finansów, procesów operacyjnych albo dostawców, ale z możliwym obejściem krótkoterminowym.
Zasób wspiera dział lub proces, ale jego awaria nie zatrzymuje całej firmy i można działać ręcznie przez pewien czas.
Zasób pomocniczy, testowy albo mało istotny, bez danych wrażliwych i bez wpływu na usługi krytyczne.
Bez właściciela rejestr umrze po pierwszym eksporcie. Właściciel procesu nie musi sam znać każdego systemu, ale odpowiada za kompletność, cykl przeglądu i raportowanie.
Ustal, czy ewidencja obejmuje całą firmę, jedną spółkę, jeden oddział, jeden system, środowisko produkcyjne albo zakres audytu klienta.
Na start wystarczy arkusz, ale powinien mieć kontrolę wersji, właściciela i jasne pola obowiązkowe. W późniejszym etapie można przenieść go do lekkiego narzędzia ITSM lub asset management.
Zacznij od katalogu użytkowników, panelu Microsoft 365 lub Google Workspace, EDR, backupu, DHCP, firewalli i faktur. Nie czekaj na idealny zestaw danych.
Ten sam laptop może pojawić się w EDR, DHCP, katalogu użytkowników i fakturze. Ustal regułę łączenia rekordów, na przykład po numerze seryjnym, nazwie urządzenia, użytkowniku i adresie MAC.
Każdy zasób krytyczny musi mieć właściciela biznesowego i technicznego. „IT” jako właściciel wszystkiego to słaby dowód.
Właściciel procesu powinien wskazać, czy zasób wspiera usługę krytyczną i jakie dane przetwarza.
Dla każdego zasobu krytycznego sprawdź MFA, backup, EDR, aktualizacje, logi, dostawców i publiczną ekspozycję.
Brak właściciela, brak backupu, brak MFA, brak EDR, brak testu restore albo publiczny port powinny mieć status i działanie naprawcze.
Rejestr musi być aktualizowany cyklicznie i po zmianach. Minimum dla MŚP to kwartalny przegląd zasobów krytycznych i roczny przegląd pełny.
Firma tworzy arkusz przed audytem, a potem nikt go nie aktualizuje. Po trzech miesiącach rejestr nie odzwierciedla rzeczywistości.
Współczesne MŚP często ma więcej ryzyka w usługach SaaS niż w laptopach. Rejestr musi obejmować narzędzia chmurowe i aplikacje biznesowe.
IT wie, że system istnieje, ale nie wie, jak ważny jest dla procesu i jakie dane są w środku.
Firma zna laptopy, ale nie wie, jakie domeny, subdomeny, porty i panele administracyjne są dostępne z internetu.
Dostawca IT, backupu, hostingu albo SaaS może mieć większy wpływ na ciągłość działania niż wewnętrzny laptop.
Sama nazwa systemu to za mało. Rejestr powinien pokazywać MFA, backup, EDR, logi, aktualizacje i test restore.
Stare systemy, nieużywane konta, porzucone subdomeny i zapomniane środowiska testowe często są najłatwiejszym celem.
Narzędzie pomaga, ale nie zastąpi decyzji: kto jest właścicielem, co jest krytyczne, co trzeba poprawić i kto zamyka luki.
Zarząd nie potrzebuje listy każdego laptopa. Potrzebuje widzieć ryzyko, braki i decyzje.
Firma usługowa zatrudnia 85 osób. Korzysta z Microsoft 365, CRM, systemu fakturowania, repozytorium plików, narzędzi marketingowych, zewnętrznego dostawcy IT i kilku aplikacji SaaS kupowanych przez działy biznesowe. Zarząd pyta, czy firma jest gotowa na wymagania NIS2, ale IT nie ma pełnej listy zasobów.
Firma zaczyna bez drogiego narzędzia enterprise. Tworzy arkusz rejestru, eksportuje użytkowników i urządzenia z Microsoft 365 oraz EDR, pobiera listę faktur za SaaS, sprawdza backup, spisuje domeny, publiczne IP i dostawców. Po miesiącu okazuje się, że istnieje 14 narzędzi SaaS poza wiedzą IT, 6 kont administratorów bez formalnego właściciela, 3 systemy krytyczne bez potwierdzonego testu restore i 2 stare subdomeny prowadzące do nieużywanych usług.
Po 90 dniach firma ma rejestr zasobów, właścicieli, krytyczność, status MFA, backupu i dostawców. Nie jest to jeszcze platforma enterprise, ale firma potrafi pokazać zarządowi i audytorowi, co ma, co jest krytyczne, gdzie są luki i jakie działania są w toku.
ccyber.io pomaga MŚP zbudować ewidencję i widoczność zasobów zgodną z wymaganiami NIS2 bez niepotrzebnego przeciążania firmy narzędziami enterprise. Zaczynamy od procesu, źródeł danych i praktycznego rejestru, a dopiero potem dobieramy automatyzację.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Asset Visibility for NIS2 Workshop. W krótkim warsztacie można ustalić, jakie zasoby firma już widzi, jakie są ukryte, które źródła danych można wykorzystać bez nowych kosztów i jaki rejestr będzie wystarczający na pierwszym etapie.
Nie. NIS2 wymaga zarządzania ryzykiem i asset management jako elementu środków bezpieczeństwa, ale nie wskazuje konkretnego narzędzia. Dla MŚP ważniejszy jest działający proces i dowody.
Na start tak, jeśli ma właściciela, wersję, pola obowiązkowe, cykliczny przegląd i jest porównywany z danymi technicznymi. Długoterminowo można go zastąpić lżejszym narzędziem ITSM lub asset management.
Zasoby krytyczne warto przeglądać co najmniej kwartalnie oraz po każdej istotnej zmianie. Pełny przegląd całej ewidencji można robić raz w roku lub częściej, jeśli firma szybko się zmienia.
Oba obszary są ważne. W wielu MŚP największe ryzyko jest dziś w SaaS, kontach administratorów, usługach chmurowych, publicznych zasobach i dostawcach, nie tylko w laptopach.
Sprawdź faktury, płatności kartą, aplikacje OAuth, logowania SSO, DNS, ankiety do działów, repozytoria projektów i listę dostawców. To często ujawnia Shadow IT.
Warto, ale ostrożnie. Skan sieci pomaga wykryć urządzenia i usługi, ale w środowiskach produkcyjnych i OT powinien być zaplanowany z odpowiedzialnymi osobami.
Systemy wspierające usługi krytyczne, tożsamość, poczta, backup, systemy finansowe, systemy produkcyjne, dane klientów, dostawcy krytyczni i zasoby wystawione do internetu.
Zacznij od listy systemów krytycznych, użytkowników, administratorów, urządzeń, SaaS, backupu, publicznych adresów IP, domen i dostawców. Następnie przypisz właścicieli i status zabezpieczeń.
Pełna ewidencja i widoczność zasobów zgodna z NIS2 nie musi zaczynać się od drogich narzędzi enterprise. Dla MŚP najważniejsze jest, aby zbudować realny, aktualny i używany rejestr zasobów, który łączy urządzenia, aplikacje, dane, konta, chmurę, dostawców, backup, publiczną ekspozycję i krytyczność biznesową.
Największą wartość daje prosty proces: zbierz dane z istniejących źródeł, przypisz właścicieli, oznacz krytyczność, sprawdź podstawowe zabezpieczenia, porównuj rejestr z rzeczywistością i regularnie raportuj braki zarządowi.
Najlepsza zasada brzmi: nie pytaj najpierw, jakie narzędzie kupić. Zapytaj, czy firma potrafi dziś powiedzieć, co ma, co jest krytyczne, gdzie są dane, kto ma dostęp, co jest wystawione do internetu i czego nie umie jeszcze zobaczyć.
Jakie firmy obecnie dotyczą regulacje takie jak NIS2, CRA czy DORA - zestawienie dla krajów UE
NIS2, CRA i DORA dotyczą różnych typów firm i nie należy ich wrzucać do jednego worka. NIS2 obejmuje przede wszystkim średnie i duże podmioty z wybranych sektorów krytycznych, ale szczegóły zależą od krajowej transpozycji w danym państwie UE. DORA dotyczy sektora finansowego i ryzyka ICT, a dostawców ICT obejmuje przede wszystkim przez umowy, nadzór nad krytycznymi dostawcami i wymagania klientów finansowych. CRA dotyczy producentów, importerów, dystrybutorów i innych operatorów gospodarczych udostępniających na rynku UE produkty z elementami cyfrowymi. Dla firm działających w wielu krajach kluczowe jest osobne sprawdzenie: kraju działalności, sektora, wielkości firmy, typu produktu, relacji z klientem finansowym i roli w łańcuchu dostaw.
Opracowanie: Zespół redakcyjny CCyber
NIS2, CRA i DORA dotyczą różnych firm. NIS2 dotyczy przede wszystkim średnich i dużych podmiotów z sektorów krytycznych i wybranych mniejszych podmiotów o szczególnym znaczeniu, ale szczegóły zależą od prawa krajowego w danym państwie UE. CRA dotyczy produktów z elementami cyfrowymi, czyli producentów, importerów, dystrybutorów, upoważnionych przedstawicieli i części podmiotów open source działających komercyjnie. DORA dotyczy podmiotów finansowych oraz zarządzania ryzykiem ICT, a dostawców ICT obejmuje głównie przez umowy, wymagania klientów finansowych i nadzór nad dostawcami krytycznymi. Firma działająca w kilku krajach UE powinna sprawdzić osobno: kraj, sektor, wielkość, rolę prawną, typ usługi, produkt, klientów oraz dostawców.
Lipiec 2026
To zestawienie nie jest indywidualną opinią prawną. W regulacjach cyber UE bardzo ważne są definicje, wyjątki, progi, akty krajowe, sektor działalności i konkretna rola firmy. Dwie firmy z tej samej branży mogą mieć różny status, jeśli jedna jest średnim podmiotem, a druga mikrofirmą, jeśli jedna działa jako producent produktu cyfrowego, a druga tylko jako integrator, albo jeśli jedna obsługuje banki, a druga nie.
Najważniejsza praktyczna zasada brzmi: nie pytaj tylko „czy moja branża jest objęta?”. Zapytaj: w jakim kraju działamy, jaką usługę świadczymy, jak duża jest firma, jakie dane przetwarzamy, czy jesteśmy dostawcą dla sektora regulowanego i czy wprowadzamy produkt cyfrowy na rynek UE.
| Regulacja | Najprostsze pytanie | Kogo dotyczy | Co jest najważniejsze |
|---|---|---|---|
| NIS2 | Czy firma działa w sektorze krytycznym i spełnia próg lub wyjątek? | Głównie średnie i duże podmioty w sektorach z załączników NIS2 oraz wybrane podmioty niezależnie od wielkości | Zarządzanie ryzykiem cyber, incydenty, łańcuch dostaw, ciągłość działania, odpowiedzialność kierownictwa |
| DORA | Czy firma jest podmiotem finansowym albo dostawcą ICT dla sektora finansowego? | Podmioty finansowe, a dostawcy ICT głównie przez umowy, wymagania klientów i nadzór nad dostawcami krytycznymi | Ryzyko ICT, incydenty ICT, testy odporności cyfrowej, dostawcy ICT, rejestr informacji, umowy i exit plany |
| CRA | Czy firma udostępnia na rynku UE produkt z elementami cyfrowymi? | Producenci, importerzy, dystrybutorzy, upoważnieni przedstawiciele, wybrane role open source | Bezpieczeństwo produktu, podatności, aktualizacje, dokumentacja techniczna, ocena zgodności, CE, raportowanie |
NIS2 obejmuje podmioty z sektorów wysokiej krytyczności i pozostałych sektorów krytycznych. Co do zasady chodzi o średnie i duże firmy, ale dyrektywa przewiduje też przypadki objęcia mniejszych podmiotów, jeśli mają szczególny charakter lub znaczenie.
DORA dotyczy sektora finansowego. Obowiązki bezpośrednie spoczywają przede wszystkim na podmiotach finansowych. Dostawcy ICT są jednak bardzo mocno dotknięci pośrednio, ponieważ ich klienci finansowi muszą oceniać ryzyko, mieć odpowiednie umowy, rejestry, prawa audytu, plany wyjścia i monitorować usługi ICT.
CRA dotyczy produktów z elementami cyfrowymi udostępnianych na rynku UE. To oznacza, że nie dotyczy tylko klasycznych urządzeń IoT. Może obejmować oprogramowanie, sprzęt, firmware, aplikacje, komponenty, produkty bezpieczeństwa, urządzenia sieciowe i produkty połączone z urządzeniem lub siecią.
W tabeli przyjęto praktyczną perspektywę firmy. DORA i CRA jako rozporządzenia mają zasadniczo wspólny zakres w całej UE. NIS2 wymaga natomiast sprawdzenia krajowej transpozycji, krajowych organów, procedur rejestracji i ewentualnych lokalnych rozszerzeń. Szczególną uwagę zaznaczono przy państwach, które według komunikatu Komisji z lipca 2026 r. nie notyfikowały pełnej transpozycji i zostały skierowane do TSUE.
| Kraj UE | NIS2 - kogo sprawdzić | DORA - kogo sprawdzić | CRA - kogo sprawdzić | Uwaga praktyczna |
|---|---|---|---|---|
| Austria | Średnie i duże podmioty w sektorach NIS2 oraz wybrane podmioty szczególne według prawa krajowego | Podmioty finansowe działające w Austrii oraz ich dostawcy ICT | Operatorzy gospodarczy udostępniający produkty z elementami cyfrowymi na rynku UE | Sprawdź lokalny akt wdrażający NIS2, organ właściwy i obowiązki rejestracyjne |
| Belgia | Średnie i duże podmioty w sektorach NIS2 oraz dostawcy usług cyfrowych i zarządzanych | Banki, ubezpieczyciele, fintechy i inni uczestnicy rynku finansowego oraz dostawcy ICT | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Sprawdź lokalne progi, rejestrację i wymagania organów |
| Bułgaria | Podmioty w sektorach NIS2, szczególnie energia, transport, zdrowie, cyfrowa infrastruktura i usługi ICT | Podmioty finansowe i dostawcy ICT obsługujący funkcje finansowe | Firmy wprowadzające software, hardware lub komponenty na rynek UE | Sprawdź status krajowej transpozycji i lokalne terminy |
| Chorwacja | Podmioty średnie i duże w sektorach NIS2 oraz dostawcy dla takich podmiotów | Sektor finansowy i jego dostawcy ICT | Operatorzy gospodarczy produktu cyfrowego | Sprawdź obowiązki krajowe, organ i procedurę zgłoszeń |
| Cypr | Podmioty w sektorach NIS2, zwłaszcza cyfrowe, finansowe, zdrowotne i usługowe | Podmioty finansowe z działalnością na Cyprze i ich dostawcy ICT | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Sprawdź lokalną transpozycję NIS2 i właściwy CSIRT |
| Czechy | Średnie i duże podmioty w sektorach NIS2 oraz podmioty wskazane krajowo | Podmioty finansowe, fintech, krypto, ubezpieczenia i dostawcy ICT | Firmy udostępniające produkty z elementami cyfrowymi na rynku UE | Sprawdź czeską ustawę i akty wykonawcze do NIS2 |
| Dania | Podmioty w sektorach NIS2, w tym energia, transport, zdrowie, cyfrowa infrastruktura i administracja | Podmioty finansowe i dostawcy ICT | Operatorzy gospodarczy produktów cyfrowych | Sprawdź lokalne organy sektorowe i wymogi rejestracyjne |
| Estonia | Podmioty w sektorach NIS2, szczególnie cyfrowa infrastruktura, administracja, zdrowie i usługi ICT | Podmioty finansowe oraz dostawcy ICT dla finansów | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Sprawdź lokalne zasady nadzoru i zgłaszania incydentów |
| Finlandia | Średnie i duże podmioty w sektorach NIS2 oraz wybrane podmioty mniejsze o szczególnym znaczeniu | Sektor finansowy i dostawcy ICT | Operatorzy gospodarczy produktu z elementami cyfrowymi | Sprawdź fińskie akty wdrożeniowe i organ właściwy dla sektora |
| Francja | Podmioty w sektorach NIS2, ale należy szczególnie sprawdzić status pełnej transpozycji | Podmioty finansowe i dostawcy ICT obsługujący francuski rynek finansowy | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Szczególna uwaga: Komisja skierowała Francję do TSUE za brak notyfikacji pełnej transpozycji NIS2 |
| Niemcy | Podmioty w sektorach NIS2, w praktyce także firmy szczególnie ważne i ważne według prawa krajowego | Podmioty finansowe i dostawcy ICT | Firmy wprowadzające produkty cyfrowe na rynek UE | Sprawdź lokalne progi, rejestrację i wymagania BSI |
| Grecja | Podmioty w sektorach NIS2, szczególnie energia, transport, zdrowie, cyfrowa infrastruktura i administracja | Podmioty finansowe i dostawcy ICT | Operatorzy gospodarczy produktów cyfrowych | Sprawdź krajowe przepisy i krajowy punkt kontaktowy |
| Węgry | Średnie i duże podmioty w sektorach NIS2 oraz wybrane podmioty według prawa krajowego | Podmioty finansowe i dostawcy ICT | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Sprawdź lokalne wymogi rejestracji i nadzoru |
| Irlandia | Podmioty w sektorach NIS2, ale należy szczególnie sprawdzić status pełnej transpozycji | Podmioty finansowe, fintechy, dostawcy ICT i centra usług dla finansów | Firmy produktowe i dystrybutorzy produktów cyfrowych na rynku UE | Szczególna uwaga: Komisja skierowała Irlandię do TSUE za brak notyfikacji pełnej transpozycji NIS2 |
| Włochy | Podmioty w sektorach NIS2 i dostawcy usług zarządzanych oraz cyfrowych | Podmioty finansowe i dostawcy ICT | Operatorzy gospodarczy produktów cyfrowych | Sprawdź włoskie przepisy wdrożeniowe i lokalne procedury |
| Łotwa | Podmioty średnie i duże w sektorach NIS2 oraz wybrane podmioty szczególne | Podmioty finansowe i dostawcy ICT | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Sprawdź lokalne organy i terminy obowiązków |
| Litwa | Podmioty z sektorów NIS2, w tym infrastruktura cyfrowa, zdrowie, energia, transport i administracja | Podmioty finansowe i dostawcy ICT | Operatorzy gospodarczy produktów cyfrowych | Sprawdź krajowe obowiązki rejestracji i zgłaszania |
| Luksemburg | Podmioty w sektorach NIS2, zwłaszcza finansowe, cyfrowe, zarządzania ICT i administracji | Silnie istotne dla sektora finansowego oraz dostawców ICT | Firmy udostępniające produkty z elementami cyfrowymi | Sprawdź relację NIS2 z lokalnym nadzorem finansowym i DORA |
| Malta | Podmioty w sektorach NIS2 oraz dostawcy usług cyfrowych i zarządzanych | Podmioty finansowe i dostawcy ICT | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Sprawdź lokalną ścieżkę rejestracji i organ właściwy |
| Niderlandy | Podmioty w sektorach NIS2, ale należy szczególnie sprawdzić status pełnej transpozycji | Podmioty finansowe i dostawcy ICT na rynku niderlandzkim | Operatorzy gospodarczy produktów cyfrowych | Szczególna uwaga: Komisja skierowała Niderlandy do TSUE za brak notyfikacji pełnej transpozycji NIS2 |
| Polska | Podmioty w sektorach NIS2 i podmioty wskazane przez krajową nowelizację KSC | Podmioty finansowe i dostawcy ICT obsługujący sektor finansowy | Firmy produktowe wprowadzające software, hardware lub komponenty na rynek UE | Sprawdź aktualny stan KSC i przepisy sektorowe, bo to one przesądzają szczegóły krajowe |
| Portugalia | Podmioty średnie i duże w sektorach NIS2 oraz wybrane podmioty według prawa krajowego | Podmioty finansowe i dostawcy ICT | Operatorzy gospodarczy produktów cyfrowych | Sprawdź lokalną transpozycję i właściwe organy |
| Rumunia | Podmioty w sektorach NIS2, w tym energia, transport, zdrowie, cyfrowa infrastruktura i administracja | Podmioty finansowe i dostawcy ICT | Firmy udostępniające produkty z elementami cyfrowymi | Sprawdź rumuńskie przepisy i procedury rejestracyjne |
| Słowacja | Podmioty w sektorach NIS2 oraz dostawcy usług istotnych dla takich podmiotów | Podmioty finansowe i dostawcy ICT | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Sprawdź krajowe wymogi i klasyfikację podmiotów |
| Słowenia | Średnie i duże podmioty w sektorach NIS2 oraz podmioty szczególne według prawa krajowego | Podmioty finansowe i dostawcy ICT | Operatorzy gospodarczy produktów cyfrowych | Sprawdź lokalny stan wdrożenia i organy nadzoru |
| Hiszpania | Podmioty w sektorach NIS2, ale należy szczególnie sprawdzić status pełnej transpozycji | Podmioty finansowe i dostawcy ICT obsługujący rynek hiszpański | Producenci, importerzy i dystrybutorzy produktów cyfrowych | Szczególna uwaga: Komisja skierowała Hiszpanię do TSUE za brak notyfikacji pełnej transpozycji NIS2 |
| Szwecja | Podmioty w sektorach NIS2, zwłaszcza infrastruktura, administracja, zdrowie, transport, energia i cyfrowe usługi | Podmioty finansowe i dostawcy ICT | Operatorzy gospodarczy produktów cyfrowych | Sprawdź lokalne przepisy i właściwy organ sektorowy |
Firma działająca w wielu krajach UE nie powinna robić jednej ogólnej analizy dla całej grupy. Powinna przygotować matrycę: kraj, spółka, sektor, produkt, usługa, klient i dostawca.
Może nie być bezpośrednio podmiotem finansowym pod DORA, ale będzie dostawcą ICT dla klienta finansowego. Jeśli rozwija własny produkt cyfrowy, może też przygotowywać się do CRA. Jeśli spełnia kryteria NIS2 jako dostawca usług zarządzanych, dostawca cyfrowy lub podmiot z sektora ICT service management, musi sprawdzić także NIS2.
Może być objęty CRA jako producent produktu z elementami cyfrowymi. Jeśli obsługuje klientów z energetyki, transportu, zdrowia lub produkcji krytycznej, może dostać wymagania NIS2 w umowach. Jeśli dostarcza urządzenia do sektora finansowego, klient może wymagać elementów zgodności z DORA.
Może być dostawcą usług cyfrowych lub ICT. Jeśli oferuje produkt z elementami cyfrowymi, komponent lub agenta instalowanego u klienta, powinna sprawdzić CRA. Jeśli obsługuje klientów finansowych, powinna przygotować pakiet dostawcy ICT pod DORA.
Najważniejsza regulacja to DORA. NIS2 może mieć znaczenie sektorowo i dla relacji z krajowymi organami, ale DORA działa jako sektorowe prawo UE dla wielu obowiązków cyber i ICT w sektorze finansowym. CRA może pojawić się, jeśli bank lub fintech jest producentem produktu cyfrowego, a nie tylko użytkownikiem.
Może podlegać NIS2, jeśli działa w jednym z objętych sektorów produkcji i spełnia kryteria. Może być pośrednio dotknięta CRA jako nabywca produktów cyfrowych albo bezpośrednio, jeśli produkuje sprzęt lub oprogramowanie z elementami cyfrowymi.
To trzy różne mechanizmy. NIS2 dotyczy sektorów i podmiotów, DORA sektora finansowego i ICT, a CRA produktów cyfrowych.
Firma działająca w wielu państwach UE musi sprawdzić lokalne przepisy NIS2, organy i obowiązki rejestracyjne w każdym właściwym kraju.
Firma może nie podlegać bezpośrednio DORA lub NIS2, ale dostać wymagania w umowie od banku, operatora infrastruktury albo klienta objętego NIS2.
Bez rejestru produktów trudno ustalić, które produkty mają elementy cyfrowe, kto jest producentem i jaka ścieżka zgodności jest potrzebna.
Firma używająca narzędzia AI lub aplikacji nie zawsze jest producentem pod CRA. Firma sprzedająca produkt pod własną marką może nim być.
Małe firmy mogą być pośrednio dotknięte przez wymagania klientów albo bezpośrednio objęte wybranymi wyjątkami.
Status krajowej transpozycji NIS2, wytyczne CRA, standardy, akty wykonawcze i praktyka organów mogą się zmieniać.
Firma SaaS z Polski sprzedaje platformę klientom w Niemczech, Francji, Hiszpanii i Niderlandach. Część klientów to banki i ubezpieczyciele. Platforma ma agenta instalowanego u klienta, API, panel administracyjny i moduł integracji z danymi klientów.
Analiza pokazuje trzy równoległe ścieżki. Po pierwsze, klienci finansowi wymagają od firmy pakietu dostawcy ICT pod DORA: SLA, incydenty, testy, exit plan, podwykonawcy i dowody bezpieczeństwa. Po drugie, w zależności od wielkości firmy i rodzaju usługi trzeba sprawdzić NIS2 w krajach działania oraz w Polsce. Po trzecie, agent instalowany u klienta może być produktem z elementami cyfrowymi, więc firma musi przygotować analizę CRA, SBOM, proces podatności i plan zgodności produktu.
Najważniejszy wniosek dla zarządu: firma nie powinna pytać „czy podlegamy jednej regulacji?”. Powinna zbudować matrycę: NIS2 dla sektorów i krajów, DORA dla klientów finansowych, CRA dla produktów cyfrowych.
ccyber.io pomaga firmom ustalić, które regulacje cyber UE dotyczą ich bezpośrednio lub pośrednio. Łączymy perspektywę NIS2, KSC, DORA, CRA, AI Act, ISO 27001, cyberubezpieczenia i wymagań klientów.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest EU Cyber Regulations Applicability Workshop. W krótkim warsztacie można ustalić, które spółki, kraje, produkty, usługi i klienci uruchamiają obowiązki pod NIS2, DORA lub CRA.
Nie w pełni. NIS2 jest dyrektywą i wymaga krajowej transpozycji. Główne sektory i założenia są unijne, ale szczegóły, organy, rejestracja i praktyka nadzoru są krajowe.
Nie. DORA dotyczy szerokiego katalogu podmiotów finansowych, w tym m.in. instytucji płatniczych, firm inwestycyjnych, ubezpieczycieli, podmiotów krypto i innych uczestników rynku finansowego.
Dostawca ICT zwykle jest dotknięty DORA przez wymagania klientów finansowych, umowy, audyty, rejestr informacji, testy i plany wyjścia. Krytyczni dostawcy ICT mogą podlegać dodatkowym ramom nadzoru.
Nie. CRA dotyczy także oprogramowania, komponentów, firmware, aplikacji i produktów z elementami cyfrowymi udostępnianych na rynku UE.
Tak. Może być poza bezpośrednim zakresem NIS2, ale być dostawcą podmiotu regulowanego. Może też być producentem produktu cyfrowego pod CRA albo dostawcą ICT dla podmiotu finansowego pod DORA.
Najważniejsza jest matryca krajów i spółek. Dla NIS2 trzeba sprawdzić każde państwo. Dla DORA trzeba sprawdzić klientów finansowych i usługi ICT. Dla CRA trzeba sprawdzić produkty i role w łańcuchu dostaw.
Tak. Przykład to dostawca SaaS dla banków, który spełnia progi NIS2 i sprzedaje produkt z elementami cyfrowymi na rynku UE.
Zacznij od listy krajów, spółek, produktów, usług, klientów regulowanych i dostawców. Potem zrób matrycę podlegania: NIS2, DORA, CRA i wymagania krajowe.
NIS2, CRA i DORA nie odpowiadają na to samo pytanie. NIS2 pyta o sektor, wielkość i znaczenie podmiotu. DORA pyta o sektor finansowy, ryzyko ICT, dostawców i funkcje krytyczne. CRA pyta o produkt z elementami cyfrowymi i rolę firmy w łańcuchu dostaw produktu.
W całej UE zakres DORA i CRA jest zasadniczo wspólny, bo są to rozporządzenia. NIS2 wymaga krajowej transpozycji, dlatego firmy muszą śledzić przepisy państw, w których działają. Szczególnie firmy wielonarodowe nie powinny opierać się na jednej ogólnej analizie.
Najlepsza zasada brzmi: przygotuj jedną matrycę podlegania dla całej grupy, ale decyzje podejmuj osobno dla kraju, spółki, sektora, produktu, usługi i relacji z klientem regulowanym.
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.