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.
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.
Jak zdobyć tańsze cyberubezpieczenie? Wdróż te rozwiązania już teraz
Tańsze cyberubezpieczenie nie wynika z samej deklaracji, że firma „dba o bezpieczeństwo”. Ubezpieczyciel patrzy na realne kontrole, historię incydentów, branżę, przychody, dane, dostawców i zdolność firmy do odtworzenia działania po ataku. Największy wpływ na ubezpieczalność i warunki polisy mają zwykle: MFA, testowany backup, EDR, aktualizacje, kontrola kont administratorów, bezpieczny dostęp zdalny, ochrona poczty, szkolenia, procedura płatności, plan reagowania, BCP, kontrola dostawców i pakiet dowodów. Nie ma gwarancji niższej składki, ale dobrze udokumentowane zabezpieczenia mogą pomóc uzyskać lepsze warunki, wyższe limity, mniejsze wyłączenia lub łatwiejsze odnowienie polisy.
Opracowanie: Zespół redakcyjny CCyber
Żeby zwiększyć szansę na tańsze cyberubezpieczenie, firma powinna poprawić to, co ubezpieczyciel widzi jako największe źródła ryzyka: brak MFA, nietestowany backup, słabą ochronę urządzeń, nieaktualne systemy, zbyt szerokie uprawnienia administratorów, niekontrolowany dostęp zdalny, słabą ochronę poczty, brak szkoleń, brak procedury płatności, brak incident response planu i brak dowodów. Nie da się zagwarantować niższej składki, bo cena zależy od branży, przychodów, historii szkód, zakresu polisy, limitów i rynku ubezpieczeniowego. Można jednak zwiększyć ubezpieczalność firmy i poprawić pozycję w rozmowie z brokerem oraz ubezpieczycielem. Najważniejsze jest, aby nie deklarować zabezpieczeń na słowo. Każda odpowiedź w ankiecie powinna mieć zakres, właściciela i dowód.
Lipiec 2026
Tak, ale trzeba dobrze rozumieć słowo „tańsze”. Ubezpieczyciel nie sprzedaje zniżki za samą nazwę narzędzia. Ocenia ryzyko. Jeżeli firma potrafi pokazać, że ograniczyła prawdopodobieństwo incydentu i umie zmniejszyć jego skutki, może mieć lepszą pozycję w rozmowie o składce, limitach, wyłączeniach i odnowieniu polisy.
Lepsze przygotowanie może pomóc w kilku obszarach:
Ważne: cyberubezpieczenie nie jest nagrodą za posiadanie narzędzi. Jest mechanizmem transferu części ryzyka. Firma nadal musi zarządzać ryzykiem, utrzymywać zabezpieczenia i aktualizować informacje przekazywane brokerowi oraz ubezpieczycielowi.
Ubezpieczyciel chce odpowiedzieć na proste pytanie: jak prawdopodobne jest, że ta firma będzie miała kosztowny incydent i jak duży może być ten koszt?
Nie wszystkie czynniki możesz zmienić. Nie zmienisz łatwo branży ani historii incydentów. Możesz jednak poprawić zabezpieczenia, przygotować dowody, uporządkować procesy i pokazać, że firma ma realną kontrolę nad ryzykiem.
Jeżeli broker lub ubezpieczyciel zapyta, czy firma ma MFA, backup, EDR i szkolenia, odpowiedź „tak” jest za słaba. Trzeba pokazać, gdzie dokładnie kontrola działa, kogo obejmuje, jakie są wyjątki i kiedy była ostatnio sprawdzana.
Słabo: „Mamy backup”.
Dobrze: „Backup obejmuje Microsoft 365, serwer plików, system finansowy i CRM. Kopie są odseparowane od produkcji. Ostatni test odtworzenia wykonano 12 czerwca 2026 r. Wynik testu i działania naprawcze są w raporcie”.
MFA to jedna z najważniejszych kontroli z perspektywy ubezpieczyciela. Chroni przed przejęciem kont po kradzieży hasła, phishingu albo wycieku danych logowania.
Dowód dla ubezpieczyciela: raport MFA, lista kont objętych MFA, lista wyjątków i decyzje o akceptacji ryzyka.
Backup bez testu jest obietnicą, a nie dowodem. Ubezpieczyciel chce wiedzieć, czy firma potrafi wrócić do działania po ransomware, awarii, błędzie człowieka albo utracie danych.
Dowód dla ubezpieczyciela: raport backupu, raport testu odtworzenia, RTO, RPO i lista działań naprawczych.
Ubezpieczyciel będzie pytał, czy laptopy, serwery i stacje robocze są chronione. Sama obecność antywirusa może nie wystarczyć, jeśli nikt nie monitoruje alertów albo ochrona nie obejmuje wszystkich urządzeń.
Dowód dla ubezpieczyciela: raport pokrycia EDR lub antywirusa, lista wyjątków, raport alertów i procedura reakcji.
Niezałatane systemy, VPN, firewalle, serwery i aplikacje internetowe są częstą drogą wejścia. Ubezpieczyciel może pytać, jak szybko firma łata podatności krytyczne.
Dowód dla ubezpieczyciela: raport podatności, raport patch management i lista podatności po terminie.
Konta administratorów są dla atakującego skrótem do całej firmy. Dlatego ubezpieczyciele zwracają uwagę na MFA, liczbę administratorów, konta imienne i przeglądy uprawnień.
Dowód dla ubezpieczyciela: raport kont administratorów, raport PIM lub PAM, access review i lista odebranych uprawnień.
Zdalny dostęp jest wygodny, ale jest też jednym z najważniejszych punktów ryzyka. Szczególnie groźne są publiczne RDP, stare VPN, konta dostawców bez MFA i stały dostęp serwisowy.
Dowód dla ubezpieczyciela: opis modelu dostępu zdalnego, raport MFA, lista dostawców z dostępem i logi sesji.
Poczta jest najczęstszym miejscem rozpoczęcia oszustw, przejęć kont i fałszywych płatności. Ubezpieczyciel może pytać o MFA, filtrację, SPF, DKIM, DMARC i szkolenia.
Dowód dla ubezpieczyciela: raport konfiguracji poczty, status SPF/DKIM/DMARC, raport szkoleń i rejestr zgłoszeń phishingu.
Szkolenia nie powinny być jedną prezentacją raz w roku. Dla ubezpieczyciela ważniejsze jest, czy firma uczy pracowników rozpoznawania phishingu, zgłaszania błędów, używania MFA i weryfikowania płatności.
Dowód dla ubezpieczyciela: plan szkoleń, lista uczestników, materiały, wyniki testów i raport zgłoszeń.
Business email compromise i fałszywe przelewy mogą nie być objęte standardową polisą albo mogą mieć podlimity. Niezależnie od polisy firma powinna ograniczyć ryzyko fałszywej płatności.
Dowód dla ubezpieczyciela: procedura płatności, rejestr potwierdzeń drugim kanałem i raport szkolenia finansów.
Polisa może dawać dostęp do ekspertów, ale firma nadal musi wiedzieć, co robi w pierwszej godzinie incydentu. Plan reagowania powinien być krótki, aktualny i ćwiczony.
Dowód dla ubezpieczyciela: incident response plan, lista kontaktów, raport tabletop i lista działań naprawczych.
Cyberubezpieczenie może dotyczyć kosztów przestoju, ale ubezpieczyciel będzie chciał wiedzieć, czy firma umie ograniczyć czas niedostępności i działać awaryjnie.
Dowód dla ubezpieczyciela: BCP, DRP, raport testu restore, analiza kosztu przestoju i decyzje zarządu.
Jeżeli firma nie wie, jakie systemy i dane posiada, nie odpowie dobrze na pytania ubezpieczyciela. Inwentaryzacja jest fundamentem ryzyka i zakresu polisy.
Dowód dla ubezpieczyciela: rejestr aktywów, mapa systemów krytycznych i klasyfikacja danych.
Incydent u dostawcy IT, chmury, hostingu, backupu albo systemu finansowego może zatrzymać firmę. Ubezpieczyciel może pytać, czy firma zarządza ryzykiem stron trzecich.
Dowód dla ubezpieczyciela: rejestr dostawców, oceny ryzyka, klauzule bezpieczeństwa i lista dostawców z dostępem.
Po incydencie firma musi odtworzyć, co się stało. Brak logów utrudnia reakcję, dochodzenie, zgłoszenia i likwidację szkody.
Dowód dla ubezpieczyciela: raport źródeł logów, konfiguracja SIEM lub log management, przykładowe alerty i polityka retencji.
Najlepsze zabezpieczenia niewiele pomogą w rozmowie z brokerem, jeśli firma nie ma dowodów. Pakiet dowodów skraca rozmowę, zmniejsza liczbę niejasności i ułatwia odnowienie polisy.
Dowód dla ubezpieczyciela: uporządkowane repozytorium dowodów z datami, właścicielami i statusem aktualności.
Każdy ubezpieczyciel ma własny model oceny, ale w praktyce największą wagę często mają kontrole, które ograniczają ransomware, przejęcie konta i przestój.
Odpowiedź „mamy MFA” jest ryzykowna, jeśli MFA nie obejmuje administratorów, VPN albo dostawców.
Wyjątki są normalne, ale muszą być znane, opisane i zaakceptowane. Ukryty wyjątek może być problemem po incydencie.
Firma może mieć EDR, ale nikt nie reaguje na alerty. Może mieć backup, ale nikt go nie testuje. Może mieć plan incydentu, ale nikt go nie zna.
Ankieta ubezpieczeniowa powinna być sprawdzona przez IT, security, zarząd, finanse, legal i właścicieli procesów.
Tańsza polisa z dużymi wyłączeniami może nie chronić przed scenariuszem, który jest najbardziej realny dla firmy.
Broker może porównać oferty, ale jeżeli ryzyko firmy jest wysokie, konkurencja cenowa ma ograniczone znaczenie.
Backup wpisany w ankiecie jako „działa” bez testu odtworzenia jest słabym dowodem.
MFA na zwykłych kontach nie wystarczy, jeśli administratorzy, VPN, dostawcy i system finansowy są poza zakresem.
Dostawca IT zna część techniczną, ale zwykle nie zna pełnego obrazu danych, finansów, historii incydentów, dostawców i decyzji zarządu.
Fałszywe przelewy mogą być wyłączone lub limitowane. Procedura drugiego kanału jest tania i bardzo ważna.
Szkolenia bez listy uczestników, programu i wyników testu są trudne do pokazania w audycie.
Firma zmienia chmurę, dostawcę, system albo zakres danych, ale nie aktualizuje informacji dla brokera i ubezpieczyciela.
Najważniejsze nie jest tylko „ile kosztuje polisa”, ale co realnie obejmuje i czego nie obejmuje.
Firma usługowa zatrudnia 70 osób i chce kupić cyberubezpieczenie. Pierwsza oferta jest droga, a broker wskazuje, że problemem są odpowiedzi w ankiecie: MFA działa tylko w Microsoft 365, backup nie był testowany od roku, nie ma formalnego incident response planu, EDR nie obejmuje wszystkich urządzeń, a procedura płatności nie istnieje.
Firma nie szuka od razu kolejnej, tańszej oferty. Najpierw przez 60 dni zamyka najważniejsze luki. Włącza MFA dla administratorów i VPN, wykonuje test restore, uzupełnia EDR, przygotowuje incident response plan, szkoli pracowników, wdraża drugi kanał dla zmian rachunków i zbiera dowody.
Po aktualizacji ankiety broker ma lepszy materiał do rozmowy z ubezpieczycielem. Firma nie dostaje gwarancji najniższej składki, ale uzyskuje lepszą pozycję negocjacyjną, mniej niejasności i większą szansę na polisę, która odpowiada realnym scenariuszom ryzyka.
ccyber.io pomaga MŚP przygotować się do cyberubezpieczenia w sposób praktyczny, oparty na ryzyku i dowodach. Nie obiecujemy automatycznej obniżki składki, bo decyzja należy do ubezpieczyciela. Pomagamy jednak poprawić ubezpieczalność firmy, zamknąć najważniejsze luki i przygotować pakiet dowodów dla brokera.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Insurance Cost Reduction Readiness Workshop. W krótkim warsztacie można sprawdzić, które zabezpieczenia są już wdrożone, gdzie brakuje dowodów, które luki najbardziej wpływają na rozmowę z brokerem i co warto zrobić przed wysłaniem ankiety.
Nie ma gwarancji, ale MFA jest jedną z najważniejszych kontroli ocenianych przez ubezpieczycieli. Brak MFA może utrudnić uzyskanie dobrych warunków.
Nie sam backup. Ważny jest test odtworzenia, odseparowanie kopii, ochrona kont backupu i plan przywracania usług krytycznych.
To zależy od ubezpieczyciela, branży i wielkości firmy. W praktyce ochrona urządzeń, monitoring alertów i reakcja na incydenty są bardzo często oceniane.
Może pomóc jako dowód dojrzałości, ale ubezpieczyciel nadal może pytać o konkretne kontrole, takie jak MFA, backup, EDR, incident response i dostawcy.
Tak, przez brokera można rozmawiać o zakresie, limitach, wyłączeniach, podlimitach i wymaganiach. Lepsze dowody zabezpieczeń mogą ułatwić rozmowę.
Nie. Tańsza polisa może mieć niższe limity, większy udział własny, więcej wyłączeń lub brak ochrony dla ważnych scenariuszy, takich jak BEC albo incydent u dostawcy.
Nie ukrywaj ich. Opisz stan faktyczny, zakres, plan naprawczy i terminy. Odpowiedź „częściowo wdrożone” z dowodami jest lepsza niż deklaracja bez pokrycia.
Zacznij od MFA, testu backupu, ochrony urządzeń, przeglądu administratorów, bezpiecznego dostępu zdalnego, incident response planu i pakietu dowodów dla brokera.
Tańsze cyberubezpieczenie nie zaczyna się od negocjacji ceny, tylko od obniżenia realnego ryzyka. Ubezpieczyciel będzie patrzył na to, czy firma ma podstawowe zabezpieczenia i czy potrafi je udowodnić.
Najważniejsze rozwiązania to MFA, testowany backup, EDR, aktualizacje, kontrola administratorów, bezpieczny dostęp zdalny, ochrona poczty, szkolenia, procedura płatności, incident response, BCP, kontrola dostawców, logi i repozytorium dowodów.
Najlepsza zasada brzmi: nie próbuj kupić tańszej polisy na podstawie życzeniowych odpowiedzi. Wdróż podstawowe kontrole, przetestuj je, zbierz dowody i dopiero wtedy rozmawiaj z brokerem o warunkach.
Zarządzanie ryzykiem stron trzecich: jak sprawdzać dostawców pod NIS2 i DORA
Zarządzanie ryzykiem stron trzecich pod NIS2 i DORA nie polega na wysłaniu jednej ankiety do dostawcy raz w roku. Firma musi wiedzieć, którzy dostawcy są krytyczni, jakie dane i systemy obsługują, czy mają dostęp uprzywilejowany, czy wspierają funkcje krytyczne lub istotne, gdzie przetwarzają dane, z jakich podwykonawców korzystają, jak zgłaszają incydenty, jak testują ciągłość działania i czy można od nich bezpiecznie odejść. Najlepszy model to cykl życia dostawcy: klasyfikacja, due diligence, ocena ryzyka, wymagania umowne, onboarding, monitoring, testy, incident response, review i exit plan.
Opracowanie: Zespół redakcyjny CCyber
Zarządzanie ryzykiem stron trzecich pod NIS2 i DORA powinno zaczynać się od mapy dostawców, a nie od ankiety. Firma musi wiedzieć, którzy dostawcy wspierają usługi krytyczne, mają dostęp do danych, mają konta administratorów, utrzymują systemy, dostarczają chmurę, software, monitoring, backup, OT, SOC, MDR albo procesy biznesowe. NIS2 wymaga uwzględnienia bezpieczeństwa łańcucha dostaw i relacji z dostawcami w zarządzaniu ryzykiem cyber. DORA idzie dalej dla sektora finansowego i wymaga formalnego zarządzania ryzykiem ICT stron trzecich, rejestru informacji, oceny usług wspierających funkcje krytyczne lub istotne, due diligence, monitoringu, klauzul umownych, kontroli podwykonawstwa, prawa audytu i planów wyjścia. Dobre sprawdzanie dostawców to proces przez cały cykl współpracy, nie jednorazowy formularz.
Lipiec 2026
Ryzyko stron trzecich to ryzyko, które firma przejmuje przez relacje z dostawcami, usługodawcami, partnerami, podwykonawcami, integratorami, grupą kapitałową albo narzędziami zewnętrznymi. W cyberbezpieczeństwie chodzi o to, że incydent u dostawcy może stać się incydentem firmy.
NIS2 dotyczy szerokiego katalogu sektorów i podmiotów kluczowych oraz ważnych. W kontekście dostawców najważniejsze jest to, że firma ma uwzględniać bezpieczeństwo łańcucha dostaw i relacji z dostawcami w środkach zarządzania ryzykiem cyber. Oznacza to, że organizacja musi wiedzieć, którzy dostawcy są istotni, jakie ryzyka tworzą i jakie zabezpieczenia są wymagane.
DORA jest regulacją dla sektora finansowego i ryzyka ICT. W zakresie dostawców jest bardziej szczegółowa. Wymaga rejestru informacji o umowach ICT, strategii zarządzania ryzykiem ICT stron trzecich, oceny funkcji krytycznych lub istotnych, due diligence, monitoringu, praw audytu, wymagań umownych, kontroli podwykonawców, oceny koncentracji i strategii wyjścia.
NIS2 mówi: zarządzaj ryzykiem dostawców jako częścią cyberbezpieczeństwa. DORA mówi: pokaż dokładnie, którzy dostawcy ICT wspierają funkcje krytyczne lub istotne, jakie umowy ich dotyczą, gdzie są dane, jacy są podwykonawcy, jakie masz prawa audytu, jak monitorujesz ryzyko i jak odejdziesz od dostawcy bez utraty odporności.
Najlepiej zacząć od prostej mapy dostawców. Bez niej firma nie wie, kogo ma sprawdzać, z jaką intensywnością i według jakiego zakresu.
Nie da się oceniać wszystkich dostawców tak samo. Dostawca kawy, dostawca systemu ERP i dostawca backupu nie tworzą takiego samego ryzyka. Klasyfikacja pozwala dobrać właściwą głębokość due diligence.
Dostawca wspiera usługę krytyczną, funkcję krytyczną lub istotną, produkcję, płatności, dane klientów, bezpieczeństwo, backup, chmurę albo system, którego awaria poważnie wpływa na firmę.
Dostawca nie zatrzymuje całej firmy, ale ma dostęp do danych wrażliwych, kont uprzywilejowanych, systemów klientów, środowiska produkcyjnego albo ważnych integracji.
Dostawca przetwarza ograniczone dane lub wspiera mniej krytyczny proces, ale nadal wymaga podstawowej oceny i wymagań umownych.
Dostawca nie ma dostępu do danych, systemów ani procesów krytycznych. Wystarczy lekka ocena, podstawowe zapisy umowne i okresowy przegląd.
Przed zakupem lub podpisaniem umowy firma powinna ocenić, czy dostawca w ogóle może być dopuszczony do danego typu danych lub usługi.
W tej fazie firma zbiera informacje o zabezpieczeniach, certyfikatach, procesach, podwykonawcach, ciągłości działania, incydentach i zgodności dostawcy.
Nie chodzi tylko o listę odpowiedzi. Trzeba ocenić wpływ, prawdopodobieństwo, luki, wyjątki, ryzyko rezydualne i decyzję biznesową.
Wymagania bezpieczeństwa powinny trafić do umowy, aneksu, SLA, DPA, regulaminu usługi albo załącznika bezpieczeństwa. Ankieta bez umowy ma ograniczoną wartość.
Dostawca powinien dostać tylko taki dostęp, jaki jest potrzebny. Trzeba ustalić właściciela, kontakty, ścieżkę incydentu i wymagania operacyjne.
Ryzyko dostawcy zmienia się. Trzeba monitorować incydenty, wyniki audytów, SLA, zmiany podwykonawców, podatności, lokalizację danych i zmiany usługi.
Dostawcy krytyczni wymagają regularnego przeglądu. Częstotliwość powinna zależeć od ryzyka.
Firma musi wiedzieć, jak odejdzie od dostawcy, odzyska dane, usunie konta, zamknie integracje i utrzyma ciągłość działania.
Najpierw ustal, czy dostawca ma wpływ na usługę, która może być objęta wymaganiami NIS2. Chodzi o realny wpływ, a nie tylko formalną nazwę dostawcy.
NIS2 skupia się między innymi na relacjach z bezpośrednimi dostawcami. Firma powinna znać ich podatności, jakość praktyk cyberbezpieczeństwa i podejście do bezpiecznego rozwoju produktów oraz usług.
Dostawca powinien spełniać wymagania adekwatne do ryzyka. Inne wymagania będą dla firmy sprzątającej, inne dla dostawcy SOC, inne dla software house’u utrzymującego aplikację klientów.
Jeżeli incydent u dostawcy może wpłynąć na Twoją usługę, klienta lub termin zgłoszenia regulacyjnego, umowa musi określać czas, kanał i zakres zgłoszenia.
Dostawca, którego awaria zatrzyma Twoją firmę, powinien pokazać plan ciągłości, testy odtwarzania i sposób komunikacji kryzysowej.
Na potrzeby audytu NIS2 firma powinna mieć dowody: rejestr dostawców, oceny ryzyka, wymagania umowne, review i plan działań naprawczych.
DORA dotyczy usług ICT świadczonych przez strony trzecie. Trzeba ustalić, które umowy dotyczą usług ICT, które są poza zakresem i które wspierają funkcje krytyczne lub istotne.
Rejestr informacji to podstawowy dowód zarządzania dostawcami ICT pod DORA. Powinien obejmować umowy, usługi, funkcje, dostawców, podwykonawców, lokalizacje, identyfikatory, powiązania i ocenę usług.
Największy nacisk DORA kładzie na usługi wspierające funkcje krytyczne lub istotne. To one wymagają najdokładniejszej oceny, umów, monitoringu, testów, praw audytu i planów wyjścia.
Przed podpisaniem umowy z dostawcą ICT firma powinna ocenić ryzyka, zdolność dostawcy, bezpieczeństwo, zasoby, podwykonawców, lokalizację danych, ciągłość działania i ryzyko koncentracji.
Umowy powinny opisywać usługę, SLA, lokalizację danych, bezpieczeństwo, incydenty, współpracę z organami, audyty, podwykonawstwo, ciągłość działania, testy i exit.
Jeżeli dostawca ICT korzysta z podwykonawców dla usług wspierających funkcje krytyczne lub istotne, firma musi rozumieć łańcuch podwykonawstwa, ryzyko lokalizacji, koncentrację, prawo audytu i możliwość sprzeciwu wobec istotnych zmian.
DORA nie kończy się na due diligence. Dostawca musi być monitorowany, a ryzyka, SLA, incydenty, zmiany, podwykonawcy i testy powinny być regularnie przeglądane.
Ankieta jest tylko początkiem. Odpowiedzi trzeba ocenić, udokumentować i powiązać z decyzją ryzyka.
Ten sam formularz dla dostawcy krytycznego i niskiego ryzyka prowadzi do zmęczenia, słabych odpowiedzi i braku realnych decyzji.
Firma nie wie, ilu ma dostawców, które umowy są ICT i kto wspiera procesy krytyczne.
Najlepszy moment na due diligence jest przed umową. Po podpisaniu negocjowanie wymagań jest trudniejsze.
Dostawca może działać bezpiecznie, ale ryzyko może pochodzić z jego podwykonawcy, lokalizacji danych albo dalszego łańcucha usług.
Firma wie, jak kupić usługę, ale nie wie, jak odzyska dane, przełączyć proces i odebrać dostępy po zakończeniu współpracy.
Bez prawa audytu lub alternatywnego assurance firma musi polegać wyłącznie na deklaracjach dostawcy.
Dostawca może mieć incydent, ale klient dowie się o nim za późno, aby spełnić własne obowiązki regulacyjne.
IT lub zakupy zbierają ankiety, ale nikt w biznesie nie bierze odpowiedzialności za ryzyko dostawcy.
Firma finansowa korzysta z 180 dostawców, w tym 45 dostawców ICT. Początkowo prowadzi jedną listę w arkuszu zakupowym. Nie ma jasnego podziału na usługi wspierające funkcje krytyczne lub istotne. Umowy z częścią dostawców nie zawierają klauzul audytu, podwykonawstwa, incydentów ani exit planu.
Po analizie firma tworzy rejestr informacji DORA, klasyfikuje dostawców według krytyczności, identyfikuje 12 usług ICT wspierających funkcje krytyczne, ocenia podwykonawców i przygotowuje aneksy bezpieczeństwa. Równolegle wdraża proces oceny nowych dostawców przed podpisaniem umowy.
Po 90 dniach zarząd widzi po raz pierwszy realny obraz zależności: którzy dostawcy są krytyczni, gdzie są dane, gdzie brakuje prawa audytu, gdzie istnieje ryzyko koncentracji i które plany wyjścia trzeba przygotować jako pierwsze.
ccyber.io pomaga firmom budować praktyczny program zarządzania ryzykiem stron trzecich pod NIS2, DORA, ISO 27001, cyberubezpieczenie i wymagania klientów. Łączymy perspektywę cyberbezpieczeństwa, regulacji, zakupów, prawa, danych i ciągłości działania.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest TPRM and Supplier Risk Workshop. W krótkim warsztacie można ustalić, którzy dostawcy są najważniejsi, jakie wymagania wynikają z NIS2 lub DORA, czego brakuje w umowach i jakie działania trzeba wykonać przed audytem albo kontrolą.
Tak. NIS2 wskazuje bezpieczeństwo łańcucha dostaw i relacji z dostawcami jako element środków zarządzania ryzykiem cyber. Zakres kontroli powinien zależeć od ryzyka i znaczenia dostawcy.
Nie. DORA dotyczy usług ICT świadczonych przez strony trzecie. Chmura jest ważnym przykładem, ale w zakresie mogą być też SaaS, hosting, systemy biznesowe, SOC, backup, IT outsourcing i inne usługi ICT.
To funkcja, której zakłócenie mogłoby istotnie wpłynąć na ciągłość działalności, klientów, obowiązki regulacyjne lub stabilność operacyjną podmiotu finansowego.
Nie. Ankieta musi prowadzić do oceny ryzyka, decyzji, wymagań umownych, działań naprawczych i monitoringu. Sama odpowiedź dostawcy bez dowodów jest słaba.
Rejestr dostawców, klasyfikacja krytyczności, ocena ryzyka, umowa z klauzulami bezpieczeństwa, raporty testów, plan ciągłości, procedura incydentów, lista podwykonawców i plan wyjścia.
Można rozważyć alternatywne assurance, na przykład certyfikaty, raporty niezależne, SOC 2, ISO 27001, raporty testów, dokumentację bezpieczeństwa albo audyt przez niezależną stronę. Dla dostawców krytycznych odmowa musi być oceniona jako ryzyko.
Dostawców krytycznych co najmniej raz w roku i po każdej istotnej zmianie. Dostawców średniego i niskiego ryzyka rzadziej, zgodnie z klasyfikacją.
Zacznij od rejestru dostawców, klasyfikacji krytyczności, identyfikacji dostawców ICT, sprawdzenia umów i oceny 10 najważniejszych dostawców.
Zarządzanie ryzykiem stron trzecich pod NIS2 i DORA wymaga widoczności, klasyfikacji, due diligence, umów, monitoringu i dowodów. Nie da się zarządzać ryzykiem dostawców, jeśli firma nie wie, kto ma dostęp do danych, kto wspiera usługi krytyczne i kto korzysta z dalszych podwykonawców.
NIS2 wymaga uwzględnienia dostawców w zarządzaniu ryzykiem cyber. DORA wymaga bardziej szczegółowego systemu dla dostawców ICT w sektorze finansowym: rejestru informacji, oceny funkcji krytycznych lub istotnych, kontroli podwykonawców, praw audytu, monitoringu i planów wyjścia.
Najlepsza zasada brzmi: nie pytaj tylko, czy dostawca ma certyfikat. Zapytaj, jak jego awaria wpłynie na Twoją firmę, jakie dane przetwarza, kto ma dostęp, kto jest jego podwykonawcą, jak zgłosi incydent i czy potrafisz bezpiecznie zakończyć współpracę.
Jak przygotować audit trail dla dostępu uprzywilejowanego?
Audit trail dla dostępu uprzywilejowanego to nie tylko log z systemu. To kompletna ścieżka dowodowa pokazująca, kto miał uprawnienia, kto je zatwierdził, kiedy zostały aktywowane, z jakiego powodu, z jakiego urządzenia, jakie działania wykonano, czy sesja była monitorowana, czy dostęp został odebrany i czy logi są chronione przed zmianą. Dobrze przygotowany audit trail łączy IAM, PAM, PIM, SIEM, logi systemowe, logi chmurowe, ticketing, access review, nagrania sesji i decyzje właścicieli biznesowych. Najważniejsze pytanie brzmi: czy po incydencie potrafimy odtworzyć pełną historię użycia konta uprzywilejowanego?
Opracowanie: Zespół redakcyjny CCyber
Audit trail dla dostępu uprzywilejowanego powinien odpowiadać na sześć pytań: kto miał dostęp, kto go zatwierdził, kiedy go użył, po co go użył, co zrobił i czy dostęp został później odebrany. Sama informacja, że „administrator się zalogował”, nie wystarczy. Trzeba połączyć dane z IAM, PAM, PIM, systemu ticketowego, SIEM, logów chmurowych, logów systemowych, logów aplikacji, nagrań sesji i przeglądów uprawnień. Dobra ścieżka audytu obejmuje pełny cykl życia dostępu: nadanie, aktywację, zatwierdzenie, użycie, działania w sesji, zmianę konfiguracji, pobranie danych, zakończenie sesji, wygaśnięcie uprawnień, review i ewentualne działania naprawcze.
Lipiec 2026
Audit trail to ścieżka dowodowa. W kontekście dostępu uprzywilejowanego pokazuje, jak powstało uprawnienie, kto je zatwierdził, kiedy zostało użyte, jakie działania wykonano i czy cały proces był zgodny z zasadami firmy.
Dostęp uprzywilejowany obejmuje konta, role i uprawnienia, które mogą zmieniać konfigurację, nadawać prawa innym osobom, czytać dane wrażliwe, usuwać dane, wyłączać zabezpieczenia, zarządzać chmurą, wykonywać komendy na serwerach albo wpływać na ciągłość działania.
Audit trail powinien udowodnić, że ten dostęp był przyznany świadomie, użyty zgodnie z celem, monitorowany i później ograniczony lub odebrany.
Konto uprzywilejowane może zmienić wszystko. Może dodać użytkownika, wyłączyć MFA, zmienić politykę dostępu, skasować backup, pobrać dane, otworzyć zasób publicznie, wyłączyć logowanie albo nadać dostęp atakującemu. Dlatego po incydencie najważniejsze pytanie brzmi: co zrobiło konto uprzywilejowane?
Bez audit trail firma często wie tylko, że „coś się stało”. Nie wie, kto wykonał zmianę, czy miał do niej prawo, czy działanie było częścią planu, czy oznaką ataku.
Logowanie to element audit trail, ale nie cały audit trail. Sam log typu „użytkownik X zalogował się o 10:14” nie wystarczy. Audytor, klient lub zespół incident response zapyta o znacznie więcej.
Każdy dostęp uprzywilejowany powinien mieć powód. Może to być ticket serwisowy, zgłoszenie zmiany, awaria, wdrożenie, incydent albo zaplanowane okno administracyjne.
Dostęp uprzywilejowany nie powinien wynikać wyłącznie z decyzji administratora. Powinien być zatwierdzony przez właściwą osobę: właściciela systemu, managera, security, właściciela procesu lub osobę dyżurną w trybie awaryjnym.
Najlepsza praktyka to dostęp just-in-time. Użytkownik jest eligible, czyli może aktywować rolę po spełnieniu warunków, ale nie ma stałego aktywnego dostępu.
Audit trail powinien pokazywać kontekst. To pomaga odróżnić normalną pracę administratora od podejrzanej aktywności.
Najważniejsze jest to, co administrator zrobił po uzyskaniu uprawnień. Logowanie bez logów działań jest za słabym dowodem.
Dla działań wysokiego ryzyka warto mieć nagranie sesji, zapis komend lub pełny zapis działań w PAM. Dotyczy to zwłaszcza dostawców, administratorów systemów krytycznych i stacji jump server.
Audit trail powinien pokazywać, że dostęp nie został pozostawiony na stałe. Jeżeli był czasowy, powinien wygasnąć. Jeżeli był awaryjny, powinien zostać formalnie zamknięty.
Najlepszy audit trail nie kończy się na logach. Powinien być okresowo przeglądany. Ktoś musi sprawdzić, czy role nadal są potrzebne i czy użycie uprawnień było zgodne z zasadami.
Każde zdarzenie związane z dostępem uprzywilejowanym powinno zawierać zestaw pól, które pozwalają je powiązać z osobą, procesem i działaniem.
Jeżeli logi są przechowywane tylko na systemie, którym zarządza administrator, mogą zostać zmienione lub usunięte przez tę samą osobę albo przez atakującego z jej uprawnieniami.
Audytor widzi aktywację roli, ale nie widzi, dlaczego była potrzebna. Bez ticketu trudno odróżnić zaplanowaną zmianę od nadużycia.
Logowanie administratora jest widoczne, ale nie widać wykonanych zmian. To zbyt mało do wyjaśnienia incydentu.
Konto „admin”, „root”, „serwis” albo „vendor” utrudnia rozliczalność. Po incydencie firma nie wie, która osoba użyła konta.
Konta serwisowe, service principals, managed identities i klucze API często mają szerokie uprawnienia, a jednocześnie są słabo monitorowane.
Logi są zbierane, ale nikt ich nie czyta. Firma dowiaduje się o problemie dopiero po incydencie.
Incydent może zostać wykryty po tygodniach lub miesiącach. Jeżeli logi są przechowywane tylko 7 lub 30 dni, firma może stracić możliwość odtworzenia zdarzeń.
Najgorszy scenariusz to administrator lub atakujący z jego kontem, który może wyłączyć logowanie albo usunąć logi.
Firma powinna mieć jasną definicję. Bez niej jedni uznają za uprzywilejowane tylko konta global admin, a inni także konta serwisowe, właścicieli subskrypcji, administratorów aplikacji i dostawców.
Nie da się audytować czegoś, czego firma nie widzi. Rejestr powinien obejmować ludzi, dostawców, konta techniczne, aplikacje i role w chmurze.
Dla każdego systemu ustal, skąd będą pochodzić logi: IAM, PAM, PIM, system operacyjny, aplikacja, chmura, baza danych, ticketing i SIEM.
Każda aktywacja wysokiego ryzyka powinna mieć uzasadnienie i numer zgłoszenia. To ułatwia audyt i analizę incydentów.
Stały dostęp uprzywilejowany zwiększa ryzyko. Dostęp czasowy daje lepszy audit trail, bo wymusza moment aktywacji, uzasadnienie i często zatwierdzenie.
Logi muszą być odporne na zmianę i usunięcie. Dostęp do logów powinien być ograniczony, a zmiany konfiguracji logowania powinny generować alert.
Audit trail nie powinien być tylko archiwum. Powinien wspierać wykrywanie zdarzeń, które wymagają reakcji.
Audit trail pokazuje, kto używa uprawnień. Access review pokazuje, czy nadal powinien je mieć.
Nie ma jednej uniwersalnej odpowiedzi. Retencja zależy od ryzyka, regulacji, umów, branży, kosztu przechowywania i czasu wykrywania incydentów. Dla dostępu uprzywilejowanego warto stosować dłuższą retencję niż dla zwykłych logów diagnostycznych.
Retencja powinna być zatwierdzona formalnie. Firma powinna wiedzieć, które logi są potrzebne do audytu, które do incident response, a które do wymagań klientów.
Najlepszy sposób to ćwiczenie odtworzenia historii. Wybierz jedno konto administratora, jedną aktywację roli albo jeden ticket zmiany i sprawdź, czy potrafisz odtworzyć pełną ścieżkę.
Konta break glass są potrzebne, ale są bardzo ryzykowne. Mają umożliwić awaryjny dostęp, gdy standardowe mechanizmy nie działają. Nie mogą jednak być poza audit trail.
Dostawcy IT, MSP i integratorzy często mają dostęp uprzywilejowany do środowisk klientów. To wymaga szczególnej rozliczalności. Konto dostawcy nie powinno być czarną skrzynką.
Firma SaaS korzysta z Microsoft Entra ID, Azure, GitHub, systemu CI/CD, bazy danych i narzędzia do obsługi klientów. Ma kilku administratorów i zewnętrznego dostawcę DevOps. Zarząd zakłada, że audit trail działa, bo „mamy logi w chmurze”.
Podczas próbnego audytu okazuje się, że logowania administratorów są widoczne, ale nie wszystkie działania są powiązane z ticketami. Role są aktywne na stałe. Dostawca używa jednego współdzielonego konta. Logi PIM mają krótką retencję. Nagrania sesji nie istnieją. Nikt nie robił access review od dziewięciu miesięcy.
Firma wdraża PIM dla ról krytycznych, wymusza MFA i uzasadnienie aktywacji, dodaje numer ticketu, przenosi logi do centralnego SIEM, wprowadza konta imienne dla dostawcy i robi pierwszy access review. Po 90 dniach firma potrafi pokazać pełną ścieżkę: zgłoszenie, zatwierdzenie, aktywację, działania, logi i odebranie dostępu.
ccyber.io pomaga firmom przygotować audit trail dla dostępu uprzywilejowanego w środowiskach chmurowych, hybrydowych i SaaS. Łączymy perspektywę IAM, PAM, PIM, SIEM, compliance, audytu i incident response.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Privileged Access Audit Trail Workshop. W krótkim warsztacie można ustalić, które konta są najważniejsze, jakie logi już istnieją, gdzie są luki dowodowe i czy firma potrafi odtworzyć historię użycia konta administratora.
Nie. Logi są częścią audit trail. Audit trail obejmuje też wniosek o dostęp, zatwierdzenie, uzasadnienie, aktywację, działania, sesję, wygaśnięcie dostępu, review i dowody procesowe.
Najważniejsze jest powiązanie osoby, uprawnienia, celu, zatwierdzenia i wykonanych działań. Audytor powinien widzieć pełną historię, a nie pojedynczy log logowania.
Nie zawsze, ale warto to robić dla systemów krytycznych, dostawców, kont break glass i działań wysokiego ryzyka.
To zależy od ryzyka, regulacji i umów. W praktyce logi dostępu uprzywilejowanego często warto przechowywać co najmniej 12 miesięcy, a dla systemów krytycznych dłużej, jeśli wymagają tego audyty lub umowy.
PIM bardzo pomaga, bo daje aktywację, uzasadnienie, approval i historię. Nie wystarczy jednak samodzielnie, jeśli nie zbierasz logów działań w systemach docelowych i nie łączysz aktywacji z ticketem.
Trzeba mieć rejestr, właściciela, zakres uprawnień, monitoring użycia, rotację sekretów, alerty na nietypowe użycie i regularny przegląd nieużywanych kont oraz kluczy.
Zacznij od rejestru ról uprzywilejowanych, MFA dla administratorów, centralizacji logów, wymogu ticketu przy aktywacji i testu odtworzenia historii jednego administratora.
Wybierz jedną zmianę wysokiego ryzyka i spróbuj odtworzyć całą historię: wniosek, zatwierdzenie, aktywację, MFA, działania, logi, zakończenie i review. Braki pokażą, co trzeba poprawić.
Audit trail dla dostępu uprzywilejowanego to jeden z najważniejszych elementów kontroli nad tożsamością i chmurą. Bez niego firma nie wie, kto realnie miał władzę nad systemami, co zrobił i czy działanie było uprawnione.
Dobra ścieżka audytu łączy IAM, PAM, PIM, SIEM, logi chmurowe, logi systemowe, ticketing, nagrania sesji, access review i decyzje właścicieli. Największą wartość daje wtedy, gdy logi są kompletne, centralne, chronione przed zmianą i możliwe do odtworzenia po incydencie.
Najlepsza zasada brzmi: nie pytaj tylko, czy mamy logi. Zapytaj, czy po incydencie potrafimy udowodnić, kto poprosił o dostęp, kto go zatwierdził, kiedy został użyty, co dokładnie zrobiono i czy dostęp został odebrany.
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.