Praktyczne przewodniki po regulacjach cyberbezpieczeństwa i wymaganiach zgodności dla firm działających w Polsce i Unii Europejskiej. Wyjaśniamy NIS2, ustawę o KSC, DORA, Cyber Resilience Act, ISO/IEC 27001, NIST Cybersecurity Framework oraz powiązane obowiązki w prosty, biznesowy sposób.
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.
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.
Jakie dowody zgodności przygotować pod DORA, NIS2, KSC i ISO/IEC 27001?
Dowody zgodności pod DORA, NIS2, KSC i ISO/IEC 27001 to nie tylko polityki i procedury. Audytor, regulator, klient albo zarząd będą chcieli zobaczyć, że firma realnie zarządza ryzykiem cyber: ma analizę podlegania, zakres systemu, rejestr ryzyk, rejestr aktywów, decyzje zarządu, polityki, wyniki testów, logi, raporty backupu, access review, szkolenia, rejestr incydentów, ocenę dostawców, plan ciągłości działania, raporty z ćwiczeń, działania naprawcze i dowody przeglądów. Najlepszym podejściem jest jedna macierz dowodów, która mapuje te same artefakty do wielu wymagań, zamiast budowania osobnych segregatorów dla każdej regulacji.
Opracowanie: Zespół redakcyjny CCyber
Dowody zgodności pod DORA, NIS2, KSC i ISO/IEC 27001 powinny pokazywać nie tylko to, że firma ma dokumenty, ale że realnie zarządza ryzykiem cyber i odpornością cyfrową. Minimalny pakiet dowodów obejmuje analizę podlegania, zakres organizacji i systemów, rejestr aktywów, rejestr ryzyk, plan postępowania z ryzykiem, polityki bezpieczeństwa, zatwierdzenia zarządu, role i odpowiedzialności, MFA, backup, test odtworzenia, incident response plan, rejestr incydentów, procedury zgłaszania, BCP, DRP, testy odporności, access review, rejestr dostawców, oceny dostawców, umowy z klauzulami bezpieczeństwa, szkolenia, logi, monitoring, audyty wewnętrzne, przeglądy zarządzania i działania korygujące. Najlepiej przygotować jedną macierz dowodów, która mapuje te same artefakty do DORA, NIS2, KSC i ISO/IEC 27001.
Lipiec 2026
W wielu firmach słowo „dowód” oznacza plik PDF z polityką. To za mało. W audycie zgodności liczy się ciąg dowodowy: co firma zaplanowała, co wdrożyła, kto zatwierdził, kiedy sprawdzono skuteczność i co poprawiono po wykryciu luki.
Dokument opisuje zasadę lub proces. Przykład: polityka zarządzania dostępem, procedura incydentowa, BCP albo polityka dostawców.
Dowód pokazuje, że dokument działa w praktyce. Przykład: raport access review, log aktywacji roli administratora, raport testu restore, protokół tabletop albo lista odebranych uprawnień.
Artefakt to każdy element, który może być pokazany jako dowód: plik, raport, log, zrzut konfiguracji, ticket, protokół, decyzja zarządu, nagranie sesji, export z systemu lub wpis w rejestrze.
Te ramy nie są identyczne, ale wszystkie wymagają pokazania, że organizacja zarządza bezpieczeństwem w sposób uporządkowany. Audytor nie będzie zadowolony z odpowiedzi „mamy to wdrożone”. Będzie chciał zobaczyć dowody.
DORA jest najbardziej szczegółowa dla sektora finansowego i ryzyka ICT. Dowody powinny pokazywać zarządzanie ryzykiem ICT, incydenty ICT, testowanie odporności cyfrowej, ryzyko ICT stron trzecich, rejestr informacji, umowy, podwykonawców, testy i raportowanie.
NIS2 koncentruje się na środkach zarządzania ryzykiem cyber, raportowaniu istotnych incydentów, odpowiedzialności kierownictwa i bezpieczeństwie łańcucha dostaw. Dowody powinny pokazywać, że firma ma polityki, procesy, środki techniczne, szkolenia i nadzór nad ryzykiem.
KSC to krajowy kontekst dla polskich organizacji. Trzeba pracować na aktualnym obowiązującym brzmieniu ustawy oraz na aktualnym stanie krajowego wdrożenia NIS2. Dowody powinny być przygotowane tak, aby wspierały obowiązki krajowe: analiza podlegania, odpowiedzialności, kontakty, zgłoszenia, współpraca z właściwymi organami, zarządzanie ryzykiem i dokumentowanie działań.
ISO/IEC 27001 wymaga systemowego zarządzania bezpieczeństwem informacji. Dowody powinny pokazywać ISMS: zakres, kontekst, ryzyka, cele, Statement of Applicability, plan postępowania z ryzykiem, audyt wewnętrzny, przegląd zarządzania, działania korygujące i skuteczność kontroli.
Budowanie osobnego repozytorium dla DORA, osobnego dla NIS2, osobnego dla KSC i osobnego dla ISO/IEC 27001 szybko prowadzi do chaosu. Te same dowody mogą odpowiadać na wiele wymagań.
Raport testu odtworzenia danych może być dowodem dla:
To pierwszy dowód, o który warto zadbać. Organizacja musi wiedzieć, czy i dlaczego podlega DORA, NIS2, KSC albo ISO/IEC 27001, a także jaki zakres systemów, usług, spółek i lokalizacji obejmuje.
Dokument z datą, właścicielem, wersją, podstawą prawną lub standardową, decyzją zarządu i planem ponownego przeglądu.
Regulacje i standardy coraz mocniej wymagają widocznej roli kierownictwa. Zarząd powinien zatwierdzać ryzyka, środki zarządzania ryzykiem, budżet, priorytety i przeglądy.
Protokół lub decyzja, która pokazuje, że zarząd nie tylko otrzymał informację, ale też podjął decyzję, zaakceptował ryzyko lub zlecił działania.
Nie da się chronić, testować ani audytować czegoś, czego firma nie widzi. Rejestr aktywów jest podstawą zgodności.
Rejestr aktualizowany cyklicznie, z właścicielami, krytycznością, powiązaniem z procesami i historią zmian.
Dowody zgodności muszą pokazywać, że ryzyko jest oceniane, priorytetyzowane i zarządzane, a nie tylko wpisane do dokumentu.
Ryzyko ma właściciela, ocenę, plan działania, termin, status i dowód zamknięcia lub świadomej akceptacji.
Dla ISO/IEC 27001 kluczowym dowodem jest Statement of Applicability. Przy DORA, NIS2 i KSC warto przygotować analogiczną mapę kontroli.
Jedna mapa, która pokazuje, jakie kontrole spełniają konkretne wymagania i gdzie znajdują się dowody ich działania.
Polityki są potrzebne, ale tylko jako fundament. Same polityki bez dowodów wykonania nie wystarczą.
Dokument zatwierdzony, aktualny, znany właścicielom procesów i powiązany z realnymi zapisami z wykonania.
Dostęp do systemów jest jednym z najważniejszych obszarów audytu. Dowody powinny pokazywać, kto ma dostęp, dlaczego, kto zatwierdził i kiedy dostęp był przeglądany.
Raport pokazujący konkretne konta, systemy, role, decyzje, daty przeglądów i działania po przeglądzie.
Dowody zgodności muszą pozwalać odtworzyć, co się stało. Logi są potrzebne nie tylko do bezpieczeństwa, ale też do audytu i incydentów.
Przykładowa rekonstrukcja zdarzenia: logowanie, aktywacja roli, wykonana zmiana, ticket, zatwierdzenie, alert i zamknięcie sprawy.
Audytor będzie chciał wiedzieć, czy firma potrafi wykrywać, klasyfikować, eskalować, obsługiwać, zgłaszać i dokumentować incydenty.
Rejestr incydentu z osią czasu, decyzjami, komunikacją, wpływem, klasyfikacją, dowodami technicznymi i zamkniętymi działaniami naprawczymi.
DORA, NIS2 i KSC kładą nacisk na raportowanie incydentów. ISO/IEC 27001 wymaga systemowego zarządzania incydentami. Firma musi mieć dowody, że potrafi dotrzymać terminów i kryteriów zgłoszeń.
Tabletop lub test, w którym firma pokazuje, że potrafi sklasyfikować incydent, zebrać informacje, zatwierdzić komunikat i wykonać zgłoszenie w wymaganym czasie.
Jednym z najważniejszych dowodów jest test odtworzenia. Backup bez testu jest deklaracją, nie dowodem odporności.
Raport testu odtworzenia z datą, zakresem, wynikiem, czasem odtworzenia, problemami i działaniami naprawczymi.
DORA wymaga programu testowania odporności cyfrowej. NIS2 i ISO/IEC 27001 także oczekują sprawdzania skuteczności środków. Dowodem nie jest plan testów, ale wyniki i działania po testach.
Test ma zakres, metodykę, wynik, właściciela luk, priorytety, terminy i potwierdzenie zamknięcia.
Regulacje i standardy oczekują, że firma zna podatności, umie je priorytetyzować i kontroluje zmiany w środowisku.
Przykład podatności od wykrycia do zamknięcia: skan, ocena ryzyka, ticket, poprawka, retest i zatwierdzenie zamknięcia.
Dowody dotyczące dostawców są szczególnie ważne pod DORA i NIS2. W ISO/IEC 27001 również są istotnym elementem kontroli bezpieczeństwa informacji.
Pełna karta dostawcy: usługa, dane, dostęp, krytyczność, ryzyko, umowa, podwykonawcy, incydenty, SLA, plan wyjścia i ostatni review.
Szkolenia nie mogą być tylko podpisaną listą obecności. Dowód powinien pokazywać, kto został przeszkolony, z czego, kiedy i czy szkolenie było skuteczne.
Raport szkoleniowy z zakresem, frekwencją, wynikiem testów, wnioskami i działaniami poprawiającymi.
Dowody powinny pokazywać, że firma wie, jakie dane przetwarza, jak je klasyfikuje, kto ma do nich dostęp i jak są chronione.
Mapa danych z lokalizacją, właścicielem, klasyfikacją, podstawowymi kontrolami i ostatnim przeglądem dostępu.
Jeżeli firma tworzy lub utrzymuje aplikacje, audyt będzie pytał o security by design, testy i obsługę podatności.
Raport z wydania aplikacji pokazujący wymagania bezpieczeństwa, testy, wyniki, wyjątki, akceptacje i działania naprawcze.
ISO/IEC 27001 wymaga audytów wewnętrznych ISMS, ale audyty są też bardzo dobrym dowodem dla DORA, NIS2 i KSC.
Raport audytu, który nie tylko opisuje luki, ale pokazuje właścicieli, terminy i dowody zamknięcia działań.
Przegląd zarządzania pokazuje, że kierownictwo nadzoruje system, ryzyka, incydenty, wyniki audytów, skuteczność działań i potrzeby zasobowe.
Protokół przeglądu z decyzjami, właścicielami działań i terminami, a nie tylko prezentacja bez śladu decyzyjnego.
Audytorzy wiedzą, że nikt nie ma idealnego systemu. Ważne jest, czy firma znajduje luki i zamyka je w kontrolowany sposób.
Jedno zamknięte działanie korygujące pokazane od wykrycia luki do potwierdzenia skuteczności po wdrożeniu poprawki.
Firmy mają część procedur IT, ale nie mają rejestru informacji DORA, mapowania usług ICT do funkcji krytycznych lub istotnych, kontroli podwykonawców i gotowych planów wyjścia.
Firmy mają procedury IT, ale nie mają formalnej decyzji zarządu, dowodu szkolenia kierownictwa, mapy usług objętych wymaganiami i dowodów oceny skuteczności środków.
Organizacja przygotowuje polityki, ale nie ma dobrego powiązania między ryzykami, kontrolami, SoA, dowodami działania kontroli, audytem i przeglądem zarządzania.
Ktoś musi odpowiadać za strukturę, aktualność, dostęp, nazewnictwo i kompletność dowodów.
Lepsza struktura to: ryzyko, dostęp, incydenty, backup, dostawcy, szkolenia, audyty. Dopiero macierz pokazuje mapowanie do regulacji.
Audytor musi wiedzieć, czy dowód jest aktualny i kto może go wyjaśnić.
Polityki, procedury i raporty powinny mieć wersję, datę zatwierdzenia i historię zmian.
Zrzut ekranu bywa pomocny, ale lepszy jest raport eksportowany z systemu, log, ticket albo automatyczny raport cykliczny.
Jeżeli dowody powstają tydzień przed audytem, zwykle są niespójne, niepełne albo oderwane od rzeczywistego procesu.
Polityka backupu nie zastępuje raportu backupu i testu restore. Procedura access review nie zastępuje wykonanego przeglądu.
To prowadzi do duplikacji i sprzeczności. Lepsza jest jedna macierz dowodów z mapowaniem do wymagań.
Dowód bez właściciela szybko traci aktualność. Audytor pyta, a nikt nie wie, kto może wyjaśnić dokument.
Nie wiadomo, czy dowód jest aktualny. To szczególnie groźne przy politykach, rejestrach ryzyk i raportach technicznych.
Deklaracje nie wystarczą. Potrzebne są raporty z systemów, logi, tickety, wyniki testów i potwierdzenia zmian.
Test bez planu naprawczego nie poprawia zgodności. Audytor zapyta, co zrobiono z wynikami.
Zarząd może rozmawiać o cyberbezpieczeństwie, ale bez protokołu, decyzji i działań trudno to udowodnić.
Firma technologiczna dostarczająca usługi dla sektora finansowego przygotowuje się jednocześnie do audytu klienta, ISO/IEC 27001 i wymagań DORA jako dostawca ICT. Zespół ma wiele dokumentów: polityki, procedury, raporty backupu, wyniki skanów i umowy. Problem polega na tym, że nikt nie wie, który dokument odpowiada na które wymaganie.
Firma tworzy macierz dowodów. Ten sam raport testu restore mapuje do ciągłości działania w ISO/IEC 27001, odporności cyfrowej w DORA i wymagań klienta. Ten sam rejestr dostawców mapuje do DORA, NIS2 i ISO/IEC 27001. Ten sam access review mapuje do kontroli dostępu, PAM, audytu i cyberubezpieczenia.
Po 90 dniach firma nie ma więcej dokumentów niż wcześniej. Ma lepiej uporządkowane dowody. Audyt klienta przebiega szybciej, bo zespół potrafi pokazać wymaganie, dowód, właściciela, datę i status działań naprawczych.
ccyber.io pomaga firmom przygotować praktyczny pakiet dowodów zgodności pod DORA, NIS2, KSC i ISO/IEC 27001. Nie budujemy dokumentów dla samego audytu. Pomagamy połączyć regulacje, ryzyka, kontrole, dowody techniczne i decyzje zarządu w jeden spójny system.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Compliance Evidence Workshop. W krótkim warsztacie można ustalić, które wymagania dotyczą firmy, jakie dowody już istnieją, które są słabe, gdzie brakuje właścicieli i jak zbudować jedną macierz dowodów pod kilka regulacji jednocześnie.
Nie. Polityka jest potrzebna, ale trzeba pokazać wykonanie: raporty, logi, testy, przeglądy, decyzje, szkolenia i działania naprawcze.
Tak. Wiele dowodów jest wspólnych, na przykład rejestr ryzyk, rejestr aktywów, backup, test restore, access review, rejestr incydentów, ocena dostawców i raport audytu.
Ramy zarządzania ryzykiem ICT, rejestr informacji, incydenty ICT, testowanie odporności cyfrowej, zarządzanie dostawcami ICT, umowy, podwykonawcy i plany wyjścia.
Analiza podlegania, zarządzanie ryzykiem, zatwierdzenie przez kierownictwo, incident handling, ciągłość działania, supply chain security, cyberhigiena, szkolenia i procedury zgłaszania.
Zakres ISMS, ocena ryzyka, plan postępowania z ryzykiem, Statement of Applicability, cele bezpieczeństwa, audyt wewnętrzny, przegląd zarządzania i działania korygujące.
To zależy od ryzyka i procesu. Rejestry ryzyk, dostawców, aktywów i dostępów powinny mieć cykliczny przegląd. Dowody incydentów, testów i zmian powinny powstawać po każdym zdarzeniu.
Mogą być pomocnicze, ale lepsze są raporty systemowe, logi, tickety, protokoły, eksporty danych i dowody zatwierdzeń. Zrzut ekranu łatwo traci kontekst.
Zacznij od analizy podlegania, zakresu, rejestru aktywów, rejestru ryzyk, mapy wymagań i listy istniejących dowodów. Potem zbuduj macierz dowodów.
Dowody zgodności pod DORA, NIS2, KSC i ISO/IEC 27001 powinny pokazywać działający system zarządzania bezpieczeństwem i odpornością, nie tylko zestaw dokumentów. Audytor będzie pytał o ryzyko, decyzje, wdrożenie, testy, incydenty, dostawców, ciągłość działania i działania naprawcze.
Najlepszym podejściem jest jedna macierz dowodów, która mapuje wspólne artefakty do wielu wymagań. Dzięki temu firma nie tworzy czterech równoległych systemów zgodności, ale jeden spójny model dowodowy.
Najlepsza zasada brzmi: nie pytaj tylko, czy mamy dokument. Zapytaj, czy potrafimy pokazać, że proces działa, był testowany, jest nadzorowany przez zarząd i prowadzi do realnej poprawy bezpieczeństwa.
Cyber Resilience Act: co producenci produktów cyfrowych muszą przygotować w 2026 i 2027
Cyber Resilience Act oznacza, że producenci oprogramowania, sprzętu i produktów z elementami cyfrowymi muszą przygotować bezpieczeństwo produktu jako proces, a nie jednorazowy test. W 2026 roku kluczowe jest przygotowanie obsługi podatności, raportowania aktywnie wykorzystywanych podatności i poważnych incydentów, rejestru produktów, klasyfikacji produktów, SBOM, procesu aktualizacji, kontaktu do zgłoszeń i dowodów. W 2027 roku trzeba domknąć ocenę ryzyka, dokumentację techniczną, ocenę zgodności, instrukcje dla użytkowników, okres wsparcia, oznakowanie CE i gotowość do kontroli rynku.
Opracowanie: Zespół redakcyjny CCyber
Cyber Resilience Act, czyli CRA, zmienia podejście do bezpieczeństwa produktów cyfrowych w Unii Europejskiej. Producent oprogramowania, sprzętu, aplikacji, komponentu albo produktu połączonego z siecią musi przygotować nie tylko bezpieczny produkt na dzień sprzedaży, ale też proces utrzymania bezpieczeństwa w całym okresie wsparcia. W 2026 roku najważniejsze jest przygotowanie obsługi podatności i raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu. W 2027 roku producenci muszą domknąć pełną gotowość: ocenę ryzyka cyberbezpieczeństwa, zasadnicze wymagania, dokumentację techniczną, ocenę zgodności, deklarację zgodności UE, oznakowanie CE, instrukcje dla użytkowników, okres wsparcia, SBOM, aktualizacje bezpieczeństwa i dowody na wypadek kontroli rynku.
Lipiec 2026
Cyber Resilience Act to unijne rozporządzenie, które wprowadza horyzontalne wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi. Jego celem jest ograniczenie liczby podatnych produktów na rynku, poprawa przejrzystości dla użytkowników oraz zobowiązanie producentów do dbania o bezpieczeństwo produktu przez cały okres jego przewidywanego użycia.
W praktyce CRA oznacza, że bezpieczeństwo produktu staje się warunkiem wejścia na rynek UE. Producent nie powinien myśleć tylko o funkcjonalności, sprzedaży i UX. Musi także pokazać, że produkt został zaprojektowany, rozwinięty, udokumentowany, oceniony i utrzymywany zgodnie z wymaganiami cyberbezpieczeństwa.
Od 11 września 2026 r. zaczną być stosowane obowiązki raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu z elementami cyfrowymi. To oznacza, że producent powinien mieć już działający proces wykrywania, kwalifikacji, eskalacji i zgłaszania zdarzeń.
Od 11 grudnia 2027 r. będą stosowane główne obowiązki CRA. Nowe produkty z elementami cyfrowymi udostępniane na rynku UE będą musiały spełniać zasadnicze wymagania cyberbezpieczeństwa. Producent będzie musiał mieć gotową dokumentację techniczną, ocenę ryzyka, ocenę zgodności, instrukcje, okres wsparcia i deklarację zgodności.
Firmy, które zaczną przygotowania dopiero pod koniec 2027 roku, będą spóźnione. Proces CRA wymaga zmian w produkcie, kodzie, architekturze, dokumentacji, umowach z dostawcami, procesie aktualizacji, obsłudze podatności i pracy zespołów produktowych.
CRA dotyczy produktów z elementami cyfrowymi udostępnianych na rynku UE. To obejmuje zarówno produkty końcowe, jak i komponenty udostępniane osobno. Produkt z elementami cyfrowymi może być sprzętem, oprogramowaniem albo połączeniem sprzętu i oprogramowania.
To wymaga ostrożnej analizy. CRA dotyczy produktów z elementami cyfrowymi, a definicja obejmuje także rozwiązania zdalnego przetwarzania danych, jeśli są projektowane lub rozwijane przez producenta albo pod jego odpowiedzialnością i jeśli bez nich produkt nie wykonywałby jednej ze swoich funkcji. Dlatego firma SaaS powinna sprawdzić, czy oferuje produkt z elementami cyfrowymi, komponent, aplikację kliencką, agent, oprogramowanie instalowane, urządzenie lub usługę zdalnego przetwarzania niezbędną do funkcji produktu.
Software house nie zawsze będzie producentem w rozumieniu CRA. Jeżeli tworzy oprogramowanie na zamówienie i klient wprowadza produkt na rynek pod własną marką, trzeba ustalić role w umowie. Jeżeli software house rozwija i sprzedaje produkt pod własną nazwą lub znakiem towarowym, może być producentem i powinien przygotować się do obowiązków CRA.
Najważniejszą rolą z perspektywy tego artykułu jest producent. To podmiot, który rozwija lub produkuje produkt z elementami cyfrowymi albo zleca jego projektowanie, rozwój lub produkcję i wprowadza go na rynek pod swoją nazwą lub znakiem towarowym.
Producent odpowiada za bezpieczeństwo produktu, ocenę ryzyka, spełnienie wymagań, dokumentację techniczną, ocenę zgodności, deklarację zgodności, CE, okres wsparcia, aktualizacje i obsługę podatności.
Importer wprowadza na rynek UE produkt producenta spoza UE. Musi upewnić się, że produkt spełnia wymagania i że producent wykonał wymagane działania.
Dystrybutor udostępnia produkt na rynku bez wpływania na jego właściwości. Musi działać z należytą starannością i sprawdzać podstawowe elementy zgodności.
Jeżeli firma zmienia produkt, sprzedaje go pod własną marką, integruje go w większe rozwiązanie albo dokonuje istotnej modyfikacji, powinna sprawdzić, czy nie przejmuje obowiązków producenta.
Producent powinien zacząć od pełnej listy produktów z elementami cyfrowymi. Bez rejestru nie da się ocenić zakresu CRA, klasy produktu, okresu wsparcia, podatności, komponentów i dokumentacji.
Dowód do przygotowania: rejestr produktów CRA z właścicielami i klasyfikacją.
Nie każdy produkt będzie miał taką samą ścieżkę oceny zgodności. Wiele produktów będzie mogło korzystać z samooceny producenta, ale produkty ważne i krytyczne mogą wymagać surowszej procedury, w tym udziału jednostki notyfikowanej.
Dowód do przygotowania: karta klasyfikacji produktu z uzasadnieniem.
To najważniejszy obszar na 2026 rok. Producent musi wiedzieć, jak przyjmuje zgłoszenia podatności, jak je kwalifikuje, jak eskaluje, jak naprawia, jak informuje użytkowników i jak raportuje aktywnie wykorzystywane podatności.
Dowód do przygotowania: procedura vulnerability handling i rejestr podatności.
Od 11 września 2026 r. producent powinien być gotowy do raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu. Trzeba przygotować role, ścieżkę eskalacji, szablony i decyzje, zanim pojawi się incydent.
Dowód do przygotowania: playbook raportowania CRA, szablony zgłoszeń i ćwiczenie ścieżki eskalacji.
CRA wymaga identyfikacji i dokumentowania podatności oraz komponentów zawartych w produktach, w tym przygotowania software bill of materials w powszechnie używanym i maszynowo czytelnym formacie, co najmniej dla zależności najwyższego poziomu.
Dowód do przygotowania: SBOM, polityka komponentów i raport podatności zależności.
Producent powinien pokazać, że bezpieczeństwo jest częścią rozwoju produktu, a nie testem na końcu. Secure SDLC powinien obejmować wymagania bezpieczeństwa, architekturę, kod, testy, przeglądy i aktualizacje.
Dowód do przygotowania: polityka secure SDLC, wyniki testów i dowody przeglądów.
CRA wymaga skutecznych mechanizmów dystrybucji aktualizacji, tak aby podatności były naprawiane lub łagodzone terminowo. Dla wielu produktów aktualizacje bezpieczeństwa powinny być łatwe dla użytkownika, bezpieczne i oddzielone od aktualizacji funkcjonalnych, jeśli to technicznie możliwe.
Dowód do przygotowania: procedura aktualizacji bezpieczeństwa i raport testu procesu aktualizacji.
Każdy produkt w zakresie CRA powinien mieć ocenę ryzyka cyberbezpieczeństwa. Ocena powinna wskazywać ryzyka, środowisko użycia, użytkowników, interfejsy, dane, możliwe nadużycia, podatności, komponenty i wymagania, które są stosowane.
Dowód do przygotowania: product cybersecurity risk assessment.
Producent musi pokazać, jak produkt spełnia zasadnicze wymagania cyberbezpieczeństwa z załącznika I. W praktyce chodzi o to, aby produkt był projektowany bez znanych możliwych do wykorzystania podatności, miał bezpieczne ustawienia domyślne, ograniczoną powierzchnię ataku, kontrolę dostępu, ochronę danych, aktualizacje bezpieczeństwa i obsługę podatności.
Dowód do przygotowania: matryca wymagań CRA z kontrolami, testami i dowodami.
Dokumentacja techniczna będzie jednym z najważniejszych dowodów zgodności. Powinna umożliwiać wykazanie, że produkt spełnia wymagania CRA i że producent prowadzi procesy bezpieczeństwa produktu.
Dowód do przygotowania: komplet dokumentacji technicznej zgodnej z CRA.
Producent musi dobrać właściwą procedurę oceny zgodności. Dla wielu produktów możliwa będzie samoocena. Dla produktów ważnych lub krytycznych może być wymagana surowsza procedura lub udział jednostki notyfikowanej.
Dowód do przygotowania: decyzja o ścieżce oceny zgodności i komplet dowodów.
Po pozytywnej ocenie zgodności producent będzie mógł wystawić deklarację zgodności UE i oznaczyć produkt CE. To nie jest tylko formalność. CE oznacza, że producent deklaruje spełnienie wymagań mających zastosowanie do produktu.
Dowód do przygotowania: deklaracja zgodności UE i procedura oznakowania CE.
CRA wymaga, aby użytkownik dostał informacje potrzebne do bezpiecznego użycia produktu. Chodzi między innymi o kontakt do zgłaszania podatności, przeznaczenie produktu, właściwości bezpieczeństwa, okres wsparcia, aktualizacje bezpieczeństwa, bezpieczne uruchomienie i bezpieczne wycofanie z użycia.
Dowód do przygotowania: instrukcja bezpieczeństwa produktu i publiczne informacje o wsparciu.
CRA ma skutki prawne, ale jego wdrożenie jest głównie zadaniem produktowym, inżynieryjnym i operacyjnym. Bez zmian w procesie rozwoju produktu sama analiza prawna nie wystarczy.
Firma nie wie, które produkty są w zakresie, które są komponentami, które są ważne lub krytyczne i które wersje są nadal wspierane.
Od 2026 roku raportowanie aktywnie wykorzystywanych podatności wymaga szybkiej ścieżki decyzyjnej. Bez procesu firma może nie zdążyć z oceną i zgłoszeniem.
Lista komponentów nie wystarczy. Trzeba mieć proces aktualizacji, monitorowania podatności i powiązania komponentów z wersjami produktu.
CRA wymaga bezpieczeństwa w cyklu życia produktu. Test na końcu nie zastąpi secure SDLC, threat modeling i kontroli zależności.
Użytkownik musi wiedzieć, jak długo będzie otrzymywał wsparcie bezpieczeństwa. Producent musi to uzasadnić i udokumentować.
Jeżeli produkt okaże się ważny lub krytyczny, producent może potrzebować udziału jednostki notyfikowanej. To wymaga czasu i planowania.
Dokumentacja, testy, aktualizacje, decyzje ryzyka i obsługa podatności muszą zostawiać ślad. Bez dowodów trudno wykazać zgodność.
Firma SaaS i software house rozwija produkt do zarządzania dostępem dla klientów B2B. Produkt składa się z aplikacji webowej, agenta instalowanego u klienta, API, komponentów open source, modułu logowania i integracji z usługami chmurowymi. Firma początkowo zakłada, że CRA dotyczy głównie urządzeń IoT, więc odkłada temat.
Po analizie okazuje się, że agent instalowany u klienta i produkt zarządzania dostępem mogą być produktem z elementami cyfrowymi w zakresie CRA. Firma musi przygotować rejestr produktu, ocenę ryzyka, SBOM, proces zgłaszania podatności, obsługę aktualizacji bezpieczeństwa, instrukcje dla klientów i analizę ścieżki oceny zgodności.
W 2026 roku firma uruchamia kontakt do podatności, CVD, rejestr podatności, SBOM i playbook raportowania. W 2027 roku domyka dokumentację techniczną, testy, ocenę zgodności, instrukcje i proces CE. Dzięki temu CRA staje się elementem dojrzałości produktu, a nie panicznym projektem pod koniec 2027 roku.
ccyber.io pomaga producentom produktów cyfrowych przygotować się do Cyber Resilience Act w sposób praktyczny, produktowy i dowodowy. Łączymy perspektywę regulacyjną, security engineering, secure SDLC, testów bezpieczeństwa, SBOM, podatności, aktualizacji i dokumentacji zgodności.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest CRA Product Readiness Workshop. W krótkim warsztacie można ustalić, które produkty są w zakresie, które obowiązki są najpilniejsze w 2026 roku, jaka ścieżka oceny zgodności może być potrzebna i jakie dowody trzeba przygotować przed 2027 rokiem.
Nie. CRA dotyczy produktów z elementami cyfrowymi, czyli wielu produktów hardware i software, w tym aplikacji, komponentów, firmware, urządzeń sieciowych, produktów bezpieczeństwa, systemów wbudowanych i produktów połączonych z siecią.
Najważniejsze jest przygotowanie procesu obsługi podatności i raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu.
Najważniejsze jest pełne przygotowanie produktu do wymagań CRA: ocena ryzyka, zasadnicze wymagania, dokumentacja techniczna, ocena zgodności, instrukcje, okres wsparcia, CE i repozytorium dowodów.
Nie. Wiele produktów będzie mogło przejść samoocenę zgodności. Produkty ważne lub krytyczne mogą wymagać surowszej ścieżki, a w określonych przypadkach udziału jednostki notyfikowanej.
Produkty wprowadzone na rynek przed 11 grudnia 2027 r. co do zasady będą podlegały wymaganiom tylko wtedy, gdy od tej daty zostaną istotnie zmodyfikowane. Obowiązki raportowania z art. 14 mają jednak zastosowanie do produktów w zakresie CRA także wtedy, gdy były wprowadzone przed tą datą.
CRA wymaga przygotowania SBOM jako elementu identyfikacji komponentów i podatności. Publiczne udostępnienie użytkownikom to osobny temat. Producent powinien przygotować SBOM oraz procedury udostępniania właściwym podmiotom, jeśli będzie to wymagane.
Okres wsparcia powinien być określony przez producenta i co do zasady wynosić co najmniej 5 lat, chyba że przewidywany czas użycia produktu jest krótszy. Trzeba go jasno wskazać użytkownikowi i uzasadnić w dokumentacji.
Zacznij od rejestru produktów, klasyfikacji CRA, oceny, czy produkt jest w zakresie, procesu obsługi podatności, SBOM i roadmapy działań przed 11 września 2026 r. oraz 11 grudnia 2027 r.
Cyber Resilience Act wymaga od producentów produktów cyfrowych przejścia od myślenia „wydaliśmy produkt” do myślenia „utrzymujemy bezpieczny produkt przez cały okres wsparcia”. To oznacza zmiany w procesach produktowych, inżynieryjnych, prawnych, jakościowych i operacyjnych.
W 2026 roku producent powinien skupić się na raportowaniu, obsłudze podatności, SBOM, aktualizacjach i podstawach secure SDLC. W 2027 roku musi domknąć pełną gotowość: ocenę ryzyka, wymagania, dokumentację, ocenę zgodności, deklarację zgodności, CE i informacje dla użytkowników.
Najlepsza zasada brzmi: nie czekaj na 2027 rok. Produkt, którego architektura, komponenty, aktualizacje i dokumentacja nie są przygotowane już dziś, może wymagać znacznie więcej pracy niż sama formalna deklaracja zgodności.
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.