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.
Cyberbezpieczeństwo bez działu IT: co trzeba wdrożyć w pierwszej kolejności
Mała firma bez działu IT nie musi zaczynać od skomplikowanych narzędzi. Najpierw trzeba zabezpieczyć to, co najczęściej powoduje realne straty: pocztę, konta, komputery, telefony, backup, dostęp administratora, płatności, dane klientów, dostawców i reakcję na incydent. Minimum na start to MFA, menedżer haseł, aktualizacje, backup z testem odtworzenia, ochrona urządzeń, porządek w kontach, szkolenie pracowników, procedura płatności i prosty plan działania po ataku.
Opracowanie: Zespół redakcyjny CCyber
Firma bez działu IT powinna wdrażać cyberbezpieczeństwo etapami, zaczynając od kontroli, które szybko zmniejszają największe ryzyko. Pierwsza kolejność to: zabezpieczenie poczty i kont firmowych przez MFA, użycie menedżera haseł, aktualizacje komputerów i telefonów, backup najważniejszych danych, test odtworzenia, ochrona urządzeń, ograniczenie kont administratora, procedura płatności i zmiany rachunku dostawcy, podstawowe szkolenie pracowników oraz prosty plan reakcji na incydent. Nie trzeba od razu budować centrum operacji bezpieczeństwa ani kupować wielu narzędzi. Trzeba wiedzieć, które dane i konta są krytyczne, kto za nie odpowiada, jak je odzyskać i co zrobić w pierwszych godzinach po podejrzanym zdarzeniu.
Lipiec 2026
Cyberbezpieczeństwo bez działu IT oznacza, że firma nie ma wewnętrznego zespołu administratorów, security managera ani specjalistów od infrastruktury. To typowa sytuacja w MŚP. Nie oznacza to jednak, że firma może ignorować ryzyko.
W praktyce odpowiedzialność za technologię często jest rozproszona:
Problem zaczyna się wtedy, gdy nikt nie ma pełnego obrazu: jakie konta istnieją, kto ma dostęp, gdzie są dane, czy działa backup, kto może zmienić hasło, kto odbiera dostęp po odejściu pracownika i co zrobić po ataku.
Małe firmy często zakładają, że są zbyt małe, aby interesować cyberprzestępców. To niebezpieczne założenie. Dla atakującego mała firma bywa atrakcyjna, bo ma pieniądze, dane, pocztę, klientów i bankowość online, ale często nie ma dojrzałych zabezpieczeń.
Najczęstsze cele ataków na MŚP:
Atak nie musi być bardzo zaawansowany. Wystarczy phishing, przejęcie hasła, brak MFA, złośliwy załącznik, fałszywa faktura, przejęte konto dostawcy albo ransomware na komputerze z ważnymi plikami.
Pierwszą kontrolą nie jest narzędzie. Pierwszą kontrolą jest właściciel. W firmie bez działu IT trzeba jasno wyznaczyć osobę, która odpowiada za cyberbezpieczeństwo organizacyjnie. Nie musi sama wszystkiego konfigurować, ale musi pilnować planu, dostawców, terminów i dowodów.
Dowód do przygotowania: jedna strona odpowiedzialności: kto odpowiada za konta, backup, komputery, płatności, dostawców i incydenty.
Nie da się chronić tego, czego firma nie widzi. Pierwszym praktycznym krokiem jest prosta inwentaryzacja.
Minimum: arkusz z nazwą systemu, właścicielem, administratorem, liczbą użytkowników, MFA, backupem i dostawcą.
Dowód do przygotowania: rejestr kont, systemów i urządzeń aktualizowany co najmniej raz na kwartał.
MFA, czyli uwierzytelnianie wieloskładnikowe, jest jedną z najważniejszych kontroli dla małej firmy. Hasło może zostać wykradzione, ale MFA utrudnia wykorzystanie samego hasła do przejęcia konta.
Dowód do przygotowania: raport kont krytycznych z informacją, czy MFA jest włączone.
W małej firmie hasła często są zapisywane w notatnikach, przeglądarkach, arkuszach albo wysyłane przez komunikator. To duże ryzyko. Menedżer haseł pomaga tworzyć i przechowywać unikalne hasła do każdego systemu.
Dowód do przygotowania: lista systemów objętych menedżerem haseł i lista wyjątków do zamknięcia.
Aktualizacje zamykają błędy, które mogą być wykorzystane do ataku. Firma bez działu IT powinna dążyć do prostego modelu: automatyczne aktualizacje wszędzie tam, gdzie to możliwe.
Dowód do przygotowania: prosty raport aktualizacji: urządzenie, właściciel, system, data ostatniej aktualizacji, status.
Backup jest jednym z najważniejszych zabezpieczeń dla firmy bez działu IT. Chroni przed ransomware, przypadkowym usunięciem, awarią komputera, odejściem pracownika i błędami w chmurze.
Najważniejsze: backup bez testu odtworzenia jest założeniem, nie dowodem.
Dowód do przygotowania: raport backupu i raport testu odtworzenia pliku, skrzynki albo systemu krytycznego.
Komputery i telefony przechowują pocztę, pliki, sesje logowania i dostęp do kont. Jeśli urządzenie jest przejęte albo zgubione, atakujący może dostać się do wielu systemów.
Jeśli pracownicy używają prywatnych telefonów albo laptopów do pracy, firma powinna mieć jasne zasady: co wolno, jakie aplikacje są dopuszczone, czy wymagany jest PIN, czy można pobierać pliki klientów i co dzieje się po odejściu pracownika.
Dowód do przygotowania: lista urządzeń z minimalnymi wymaganiami bezpieczeństwa i statusem zgodności.
W małej firmie konta często zostają aktywne po odejściu pracownika, zmianie roli albo zakończeniu współpracy z dostawcą. To prosta droga do incydentu.
Dowód do przygotowania: kwartalny raport access review z decyzją: zostaje, ograniczyć, odebrać, wyjaśnić.
Poczta jest centrum małej firmy. Przez pocztę przychodzą faktury, umowy, reset haseł, komunikacja z klientami i dostęp do innych kont. Przejęcie poczty często oznacza przejęcie dużej części firmy.
Dowód do przygotowania: raport konfiguracji poczty, status SPF/DKIM/DMARC i rejestr zgłoszonych podejrzanych wiadomości.
Dla małej firmy fałszywa faktura albo zmiana rachunku bankowego może być bardziej dotkliwa niż techniczny atak. Dlatego bezpieczeństwo płatności jest częścią cyberbezpieczeństwa.
Dowód do przygotowania: procedura płatności i rejestr zmian rachunków dostawców z potwierdzeniem drugim kanałem.
Firma bez działu IT szczególnie potrzebuje prostego planu działania po incydencie. W stresie nie ma czasu zastanawiać się, do kogo zadzwonić i co wyłączyć.
Dowód do przygotowania: jednostronicowy plan incydentu, lista kontaktów awaryjnych i raport z krótkiego ćwiczenia.
Najlepszy model dla MŚP to nie pełny dział IT od pierwszego dnia, ale jasny właściciel po stronie firmy i zaufany partner techniczny z konkretnym zakresem odpowiedzialności.
Jeśli firma nie ma działu IT, dostawca staje się bardzo ważną częścią bezpieczeństwa. Nie powinien być wybierany wyłącznie po cenie albo dostępności.
Dowód do przygotowania: karta dostawcy IT z zakresem usług, dostępami, MFA, czasem reakcji i osobą kontaktową.
Wszyscy zakładają, że ktoś się tym zajmuje, ale nikt nie ma listy kont, urządzeń, backupów i dostawców.
Poczta, chmura, social media, hosting i konto administratora są równie ważne. Przejęcie poczty może prowadzić do przejęcia wielu innych kont.
Firma ma kopię, ale nigdy nie sprawdziła, czy da się ją odtworzyć i ile to trwa.
Hasło do poczty, social media albo systemu fakturowania zna kilka osób i nie wiadomo, kto wykonał zmianę.
To bardzo częsta luka. Dostęp trzeba odbierać w dniu zakończenia współpracy.
Dostawca może być potrzebny, ale jego dostęp powinien być imienny, zabezpieczony MFA, udokumentowany i regularnie przeglądany.
Fałszywa faktura albo zmiana rachunku dostawcy może spowodować dużą stratę bez żadnego malware.
Pracownicy powinni wiedzieć, co zrobić, zanim pojawi się phishing, fałszywy telefon albo ransomware.
Narzędzie nie pomoże, jeśli nikt nie wie, kto ma konta, gdzie są dane i jak reagować na alert.
Po ataku firma traci godziny na szukanie numeru do banku, informatyka, hostingu i dostawcy poczty.
Firma usługowa zatrudnia 18 osób. Korzysta z Microsoft 365, systemu fakturowania, CRM, bankowości online, strony internetowej i kilku kont social media. Nie ma działu IT. Właściciel zakłada, że dostawca poczty i zewnętrzny informatyk „dbają o bezpieczeństwo”.
Po krótkim przeglądzie okazuje się, że tylko część kont ma MFA, hasła do social media są współdzielone, backup nie był testowany, były pracownik nadal ma dostęp do CRM, a procedura zmiany rachunku dostawcy nie istnieje. Firma nie potrzebuje od razu skomplikowanego systemu bezpieczeństwa. Potrzebuje podstaw.
W ciągu 30 dni firma włącza MFA na poczcie, bankowości, CRM i hostingu, wdraża menedżer haseł, tworzy listę kont i urządzeń oraz procedurę płatności. W kolejnych 60 dniach uruchamia backup, testuje odtworzenie, szkoli pracowników i robi pierwszy przegląd dostępów. Po 90 dniach ma prosty plan incydentu i listę kontaktów awaryjnych.
Największa zmiana nie polega na zakupie drogiego narzędzia. Polega na tym, że firma wie, co ma, kto ma dostęp, co jest krytyczne, jak to odzyskać i kto podejmuje decyzję po ataku.
ccyber.io pomaga małym firmom wdrożyć cyberbezpieczeństwo bez budowania pełnego działu IT. Zaczynamy od minimum, które realnie zmniejsza ryzyko: konta, MFA, backup, urządzenia, poczta, płatności, dostawcy, szkolenia i plan reakcji na incydent.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Cyber Minimum Workshop dla MŚP. W krótkim warsztacie można ustalić, które konta i dane są najważniejsze, gdzie brakuje MFA, czy backup działa, kto ma dostęp, jakie procedury są potrzebne i które działania warto wdrożyć w pierwszych 30 dniach.
Tak. Małe firmy mają pocztę, pieniądze, dane klientów, faktury, konta online i reputację. To wystarczy, aby były celem phishingu, ransomware albo oszustwa płatniczego.
Zacznij od listy kont i urządzeń, MFA na poczcie i kontach krytycznych, menedżera haseł, backupu, aktualizacji, przeglądu dostępów, procedury płatności i szkolenia pracowników.
Nie na początku. Najpierw uporządkuj podstawy. Droższe narzędzia mają sens dopiero wtedy, gdy firma wie, co chroni, kto ma dostęp i jak reaguje na incydent.
Powinna być wyznaczona jedna osoba organizacyjnie odpowiedzialna za temat. Może to być właściciel, członek zarządu, office manager albo osoba operacyjna wspierana przez zewnętrznego specjalistę.
Może bardzo pomóc, ale firma nadal powinna znać zakres jego odpowiedzialności, dostępy, czas reakcji, zasady MFA, backupu i procedury po incydencie.
Poczta, administrator Microsoft 365 albo Google Workspace, bankowość, CRM, system fakturowania, hosting, domena, sklep internetowy, social media i backup.
Minimum raz na kwartał dla danych krytycznych oraz po większych zmianach systemów, dostawcy backupu albo struktury plików.
Zacznij od trzech prostych procedur: zgłaszanie phishingu, płatności i zmiana rachunku dostawcy, reakcja na przejęcie konta albo ransomware.
Cyberbezpieczeństwo bez działu IT musi być proste, praktyczne i uporządkowane. Mała firma nie powinna zaczynać od skomplikowanych narzędzi, ale od kontroli, które chronią przed najczęstszymi stratami: przejęciem poczty, utratą danych, fałszywą fakturą, ransomware, brakiem backupu i niekontrolowanym dostępem.
Najważniejsze pierwsze kroki to MFA, menedżer haseł, aktualizacje, backup z testem, ochrona urządzeń, przegląd kont, bezpieczna poczta, procedura płatności, szkolenie pracowników i prosty plan incydentu.
Najlepsza zasada brzmi: zacznij od widoczności i odpowiedzialności. Firma musi wiedzieć, jakie konta, urządzenia, dane i dostępy posiada. Dopiero potem warto dobierać narzędzia, dostawców i kolejne poziomy zabezpieczeń.
Dyrektywa NIS2: Za co osobiście odpowiada zarząd firmy?
NIS2 nie oznacza, że zarząd musi samodzielnie konfigurować firewalle, backupy czy systemy monitoringu. Oznacza jednak, że zarząd ma zatwierdzać środki zarządzania ryzykiem cyber, nadzorować ich wdrożenie, rozumieć wpływ ryzyk na działalność firmy, zapewnić zasoby, przejść szkolenie i posiadać dowody, że cyberbezpieczeństwo jest realnie zarządzane. Osobista odpowiedzialność zarządu dotyczy przede wszystkim braku nadzoru, braku decyzji, ignorowania ryzyka, braku reakcji na zalecenia i niezdolności wykazania, że firma działała odpowiedzialnie.
Opracowanie: Zespół redakcyjny CCyber
Zarząd firmy odpowiada pod NIS2 przede wszystkim za nadzór nad cyberbezpieczeństwem jako ryzykiem biznesowym. Nie musi samodzielnie wdrażać technicznych zabezpieczeń, ale musi zatwierdzić środki zarządzania ryzykiem cyber, nadzorować ich wdrożenie, zapewnić zasoby, rozumieć ryzyka, uczestniczyć w szkoleniach i wymagać dowodów działania kontroli. Osobista odpowiedzialność zarządu nie oznacza automatycznej winy za każdy incydent. Oznacza jednak, że zarząd nie może powiedzieć „to sprawa IT”, jeśli firma nie miała analizy ryzyka, planu reagowania, backupu, kontroli dostępu, nadzoru nad dostawcami, szkoleń, raportowania i dowodów. Szczegółowy zakres odpowiedzialności zależy od prawa krajowego, roli konkretnej osoby, struktury firmy i okoliczności naruszenia.
Lipiec 2026
Osobista odpowiedzialność zarządu pod NIS2 nie oznacza, że każdy członek zarządu staje się administratorem systemów albo specjalistą od cyberbezpieczeństwa. Oznacza, że cyberbezpieczeństwo staje się obszarem, nad którym zarząd musi sprawować realny nadzór.
W praktyce zarząd odpowiada za to, czy firma:
Najprościej: zarząd nie odpowiada za każdy techniczny detal, ale odpowiada za to, czy w firmie istnieje skuteczny system zarządzania ryzykiem cyber.
Zarząd może delegować wykonanie zadań do IT, security, compliance, zewnętrznych doradców i dostawców. Nie powinien jednak delegować odpowiedzialności za nadzór.
Jeśli zarząd nie ma raportów, nie zna ryzyk i nie podejmuje decyzji, trudno będzie wykazać, że nadzór był realny.
Pierwszą odpowiedzialnością zarządu jest dopilnowanie, aby firma wiedziała, czy podlega NIS2 albo krajowym przepisom wdrażającym. Nie powinno to być założenie ani opinia ustna. Potrzebna jest udokumentowana analiza.
Analiza powinna obejmować:
Dowód dla zarządu: analiza podlegania NIS2 z decyzją, kto jest właścicielem dalszych działań.
NIS2 wskazuje, że organy zarządzające mają zatwierdzać środki zarządzania ryzykiem cyber. To oznacza, że zarząd powinien znać główne ryzyka i zaakceptować plan środków technicznych, operacyjnych i organizacyjnych.
Środki zarządzania ryzykiem obejmują między innymi:
Dowód dla zarządu: zatwierdzony plan środków zarządzania ryzykiem, powiązany z rejestrem ryzyk i budżetem.
Zatwierdzenie planu nie wystarczy. Zarząd powinien nadzorować, czy plan jest wykonywany. Nadzór nie musi oznaczać codziennego monitorowania zadań. Powinien jednak oznaczać cykliczne raportowanie, pytania o opóźnienia i decyzje w sprawie ryzyk wysokiego priorytetu.
Zarząd powinien widzieć:
Dowód dla zarządu: cykliczny panel raportowy NIS2 z decyzjami i działaniami naprawczymi.
NIS2 wymaga, aby członkowie organów zarządzających odbywali szkolenia. Celem nie jest zrobienie z zarządu zespołu technicznego. Celem jest to, aby zarząd potrafił rozumieć ryzyka cyber, oceniać praktyki zarządzania ryzykiem i rozumieć wpływ cyberbezpieczeństwa na usługi firmy.
Szkolenie zarządu powinno obejmować:
Dowód dla zarządu: materiały szkoleniowe, lista uczestników, wynik testu albo potwierdzenie udziału i notatka z wnioskami.
Zarząd nie musi sam wdrażać kontroli, ale musi zapewnić realne zasoby. Brak budżetu nie usuwa ryzyka. Może natomiast pokazać, że firma świadomie nie wdrożyła potrzebnych środków.
Zarząd powinien wymagać jasnej informacji:
Dowód dla zarządu: zatwierdzony budżet albo świadoma decyzja o akceptacji ryzyka z uzasadnieniem i terminem przeglądu.
NIS2 przewiduje krótkie terminy zgłaszania istotnych incydentów. Zarząd powinien upewnić się, że organizacja ma proces, który działa w pierwszych godzinach incydentu.
Firma powinna umieć przygotować:
Zarząd nie musi sam pisać zgłoszenia, ale powinien wiedzieć, kto decyduje o kwalifikacji incydentu, kto informuje organ, kto prowadzi komunikację i kto zatwierdza raport.
Dowód dla zarządu: procedura zgłaszania incydentów, szablony zgłoszeń i raport z ćwiczenia pierwszych 24 i 72 godzin.
Cyberbezpieczeństwo w NIS2 dotyczy nie tylko ochrony przed atakiem, ale też ograniczenia wpływu incydentu na usługi. Zarząd powinien wiedzieć, czy firma potrafi kontynuować działanie i odtworzyć systemy krytyczne.
Zarząd powinien pytać:
Dowód dla zarządu: plan ciągłości działania, raport testu odtwarzania i decyzje dotyczące ryzyk pozostających po teście.
NIS2 podkreśla bezpieczeństwo łańcucha dostaw. Zarząd powinien wiedzieć, którzy dostawcy są krytyczni i jakie ryzyka wnoszą do organizacji.
Program dostawców powinien obejmować:
Dowód dla zarządu: rejestr dostawców krytycznych, oceny ryzyka i decyzje dotyczące dostawców wysokiego ryzyka.
Zarząd odpowiada za ton organizacji. Jeśli pracownicy boją się zgłaszać błędy albo podejrzane sytuacje, firma traci czas. Jeśli managerowie wymagają obchodzenia procedur, szkolenia nie zadziałają.
Zarząd powinien wspierać:
Dowód dla zarządu: plan szkoleń, raport skuteczności szkoleń, raport zgłoszeń i działania naprawcze po ćwiczeniach.
W kontroli, audycie albo po incydencie sama deklaracja nie wystarczy. Firma musi umieć pokazać dowody. Zarząd powinien wymagać uporządkowanego pakietu dowodów.
Dowody powinny obejmować:
Dowód dla zarządu: repozytorium dowodów i macierz wymagań NIS2, KSC, ISO 27001 oraz wymagań klientów.
Nie każdy incydent oznacza automatyczną odpowiedzialność zarządu. Incydenty mogą się zdarzyć nawet w dobrze zarządzanych organizacjach. Kluczowe pytanie brzmi: czy firma działała odpowiedzialnie przed incydentem, w trakcie incydentu i po incydencie.
Wiele firm omawia cyberbezpieczeństwo na spotkaniach, ale nie dokumentuje decyzji. To błąd. Po incydencie liczy się ślad decyzyjny.
IT jest kluczowe, ale NIS2 dotyczy zarządzania ryzykiem, ciągłości działania, dostawców, budżetu, incydentów i odpowiedzialności zarządczej.
Firma zakłada, że NIS2 jej nie dotyczy, bo nie jest klasyczną infrastrukturą krytyczną. Zakres NIS2 jest szerszy, a dodatkowo wymagania mogą pojawić się przez klientów i łańcuch dostaw.
Ryzyka są omawiane, ale nie ma decyzji, właścicieli, budżetu i terminów. Po incydencie trudno pokazać realny nadzór.
Zarząd nie musi być techniczny, ale musi rozumieć ryzyka, obowiązki i konsekwencje decyzji.
Plan reagowania, backup i ciągłość działania bez testów są tylko założeniem. Zarząd powinien wymagać raportów z ćwiczeń.
Dostawca ICT, chmura, oprogramowanie, integrator albo firma serwisowa może być źródłem incydentu. NIS2 wymaga uwzględnienia ryzyka łańcucha dostaw.
Kary są ważne, ale większym problemem może być przerwanie usług, utrata klientów, kontrola po incydencie i brak możliwości wykazania, że firma działała odpowiedzialnie.
Firma może robić wiele dobrych rzeczy, ale bez dowodów trudno to pokazać organowi, klientowi, audytorowi albo ubezpieczycielowi.
Firma technologiczna świadczy usługi dla klientów z sektora zdrowia i przemysłu. Zarząd początkowo zakłada, że NIS2 to temat techniczny, więc przekazuje go do IT. Po pierwszej analizie okazuje się, że firma jest ważnym dostawcą dla podmiotów regulowanych, ma dostęp do danych klientów i utrzymuje systemy wpływające na ciągłość usług klientów.
Analiza luk pokazuje, że firma ma MFA, backup i monitoring, ale brakuje formalnego rejestru ryzyk, decyzji zarządu, ćwiczenia incydentowego, programu dostawców, raportów z access review i dowodów szkoleń. IT wykonywało wiele działań, ale zarząd nie otrzymywał cyklicznego raportu i nie podejmował formalnych decyzji o ryzyku.
Zarząd uruchamia 90-dniowy plan. Powstaje analiza podlegania, rejestr ryzyk, plan działań, raport dla zarządu, ćwiczenie scenariuszowe, test odtwarzania i rejestr dostawców krytycznych. Najważniejsza zmiana nie polega na stworzeniu jednego dokumentu. Polega na tym, że zarząd zaczyna regularnie nadzorować ryzyko cyber i podejmować udokumentowane decyzje.
ccyber.io pomaga zarządom i zespołom bezpieczeństwa przygotować organizację do NIS2 w sposób praktyczny, mierzalny i oparty na dowodach. Nie zaczynamy od dokumentów dla dokumentów. Zaczynamy od podlegania, ryzyka, odpowiedzialności zarządu, incydentów, dostawców i decyzji biznesowych.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Board Accountability Workshop. W krótkim warsztacie można ustalić, czy firma podlega NIS2, jakie są obowiązki zarządu, które ryzyka wymagają decyzji, jakie dowody trzeba przygotować i które działania warto rozpocząć w pierwszych 30 dniach.
NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyber, nadzorowały ich wdrożenie i mogły ponosić odpowiedzialność za naruszenia. Szczegółowy zakres odpowiedzialności zależy od prawa krajowego i okoliczności sprawy.
Nie automatycznie. Incydent może się wydarzyć mimo rozsądnych zabezpieczeń. Kluczowe jest, czy firma miała adekwatne środki, nadzór, procedury, zgłoszenie w terminie, reakcję i dowody.
Nie musi znać wszystkich szczegółów technicznych. Musi jednak rozumieć ryzyka, wpływ na działalność, obowiązki raportowania, stan kontroli, luki i decyzje budżetowe.
Tak. Dyrektywa wymaga szkoleń dla członków organów zarządzających, aby mieli wiedzę i umiejętności potrzebne do identyfikowania ryzyk oraz oceny praktyk zarządzania ryzykiem cyber.
Możliwe konsekwencje zależą od prawa krajowego. NIS2 przewiduje odpowiedzialność osób mających wpływ na zapewnienie zgodności oraz w określonych przypadkach możliwość czasowego zakazu pełnienia funkcji zarządczych w podmiotach kluczowych.
Nie. CISO lub vCISO może prowadzić program, ale zarząd nadal powinien zatwierdzać środki, nadzorować wdrożenie, zapewniać zasoby i podejmować decyzje o ryzyku.
Analiza podlegania, rejestr ryzyk, raporty dla zarządu, decyzje budżetowe, dowody szkoleń, testy backupu, ćwiczenia incydentowe, access review, oceny dostawców i działania naprawcze.
Zacznij od analizy podlegania, szkolenia zarządu, rejestru ryzyk, raportu stanu kontroli i planu działań na 90 dni. Potem przeprowadź ćwiczenie incydentowe i przygotuj pakiet dowodów.
Dyrektywa NIS2 nie wymaga, aby zarząd stał się działem IT. Wymaga jednak, aby zarząd realnie nadzorował cyberbezpieczeństwo jako ryzyko biznesowe. To oznacza zatwierdzanie środków zarządzania ryzykiem, nadzór nad wdrożeniem, szkolenia, decyzje budżetowe, zarządzanie dostawcami, gotowość do zgłaszania incydentów i dowody działania kontroli.
Osobista odpowiedzialność zarządu najczęściej nie będzie wynikała z samego faktu, że wystąpił incydent. Będzie wynikała z pytania, czy zarząd zrobił to, czego można racjonalnie oczekiwać: znał ryzyka, wymagał działań, zapewnił zasoby, reagował na luki, szkolił się, ćwiczył incydenty i dokumentował decyzje.
Najlepsza zasada brzmi: zarząd nie musi robić wszystkiego sam, ale musi mieć dowód, że nadzoruje. W NIS2 brak nadzoru, brak decyzji i brak dowodów są często większym problemem niż sama luka techniczna.
Jakie dowody zgodności przygotować pod NIS2, KSC i ISO 27001?
Dowody zgodności pod NIS2, KSC i ISO 27001 to nie tylko polityki i procedury. Firma powinna umieć pokazać, że cyberbezpieczeństwo działa w praktyce: ma rejestr ryzyk, właścicieli kontroli, decyzje zarządu, raporty z backupu, testy odtwarzania, access review, szkolenia, ocenę dostawców, logi, raporty podatności, ćwiczenia incident response, działania naprawcze i cykliczne przeglądy. Najlepszy pakiet dowodów pokazuje nie tylko „mamy dokument”, ale „wdrożyliśmy, testujemy, mierzymy i poprawiamy”.
Opracowanie: Zespół redakcyjny CCyber
Pod NIS2, KSC i ISO 27001 trzeba przygotować dowody, które pokazują, że firma realnie zarządza cyberbezpieczeństwem, a nie tylko posiada dokumenty. Najważniejsze dowody to: analiza podlegania, rejestr ryzyk, decyzje zarządu, polityki bezpieczeństwa, Statement of Applicability dla ISO 27001, plan postępowania z ryzykiem, raporty z backupu, testy odtwarzania, access review, MFA, zarządzanie podatnościami, szkolenia, ocena dostawców, plan reagowania na incydenty, raporty z ćwiczeń, logi, metryki i działania korygujące. Dobry pakiet dowodów odpowiada na cztery pytania: co firma miała zrobić, kto za to odpowiada, czy zostało to wykonane i jaki jest dowód, że działa.
Lipiec 2026
Dowody zgodności to dokumenty, raporty, logi, zapisy, decyzje, wyniki testów i inne ślady działania, które pokazują, że organizacja spełnia określone wymaganie. W cyberbezpieczeństwie dowody są szczególnie ważne, ponieważ wiele kontroli nie jest widocznych z zewnątrz. Trzeba pokazać, że działają w praktyce.
Przykład: polityka backupu jest dokumentem. Raport z ostatniego backupu, raport testu odtworzenia i lista problemów po teście są dowodami działania procesu.
Dobry dowód powinien pokazywać:
NIS2 jest dyrektywą UE. Wymaga zarządzania ryzykiem cyber, odpowiednich środków technicznych, operacyjnych i organizacyjnych, zgłaszania istotnych incydentów, odpowiedzialności organów zarządzających, ciągłości działania, zarządzania dostawcami i szkoleń. Dowody pod NIS2 powinny pokazywać, że firma wie, czy podlega regulacji, jakie ma ryzyka, jakie środki wdrożyła i jak reaguje na incydenty.
KSC, czyli ustawa o krajowym systemie cyberbezpieczeństwa, jest polską podstawą prawną dla krajowego systemu cyberbezpieczeństwa. Aktualny tekst należy zawsze sprawdzać w oficjalnych źródłach, ponieważ przepisy i akty wykonawcze mogą się zmieniać. Dowody pod KSC powinny być zgodne z krajowymi obowiązkami, terminami, definicjami incydentów, wymogami nadzoru i oczekiwaniami organów właściwych.
ISO 27001 jest normą systemu zarządzania bezpieczeństwem informacji. Tu dowody pokazują, że organizacja ma ISMS, czyli system zarządzania bezpieczeństwem informacji, działa według cyklu ciągłego doskonalenia i potrafi wykazać ryzyka, cele, kontrole, audyty, przeglądy zarządzania i działania korygujące.
Wspólny mianownik jest prosty: zarządzanie ryzykiem, odpowiedzialność, kontrole, testy, monitorowanie, incydenty, dostawcy, szkolenia i doskonalenie. Różni się język wymagań, ale duża część dowodów może obsługiwać jednocześnie NIS2, KSC i ISO 27001.
Nie trzeba tworzyć osobnego zestawu dokumentów dla każdej regulacji. Dobrze zaprojektowany dowód może wspierać kilka wymagań naraz.
Przykłady:
Najlepsze podejście to zbudować jedną macierz dowodów i przypisać każdy dowód do wymagań NIS2, KSC, ISO 27001, umów klientów i cyberubezpieczenia.
Macierz dowodów to centralna tabela, która mówi, jakie dowody firma posiada, czego dotyczą i kiedy trzeba je odświeżyć.
Obszar: backup i odtwarzanie.
Dowód: raport testu odtworzenia systemu krytycznego.
Właściciel: IT operations.
Częstotliwość: kwartalnie dla systemów krytycznych.
Wspiera: NIS2 continuity, KSC system zarządzania bezpieczeństwem informacji, ISO 27001 Annex A continuity and backup controls.
To pierwsza grupa dowodów. Zanim firma pokaże kontrole, musi wiedzieć, czy i w jakim zakresie podlega NIS2 oraz KSC, a dla ISO 27001 musi określić zakres ISMS.
Firma przygotowuje polityki i procedury, ale nie potrafi powiedzieć, których usług, systemów i podmiotów w grupie one dotyczą.
NIS2 i KSC przenoszą cyberbezpieczeństwo na poziom odpowiedzialności kierownictwa. ISO 27001 również wymaga zaangażowania najwyższego kierownictwa w system zarządzania bezpieczeństwem informacji.
Dobrym dowodem nie jest sama prezentacja dla zarządu. Dobrym dowodem jest protokół lub notatka z decyzjami, ryzykami, budżetem, właścicielami i terminami.
Ryzyko jest wspólnym fundamentem NIS2, KSC i ISO 27001. Bez rejestru ryzyk trudno pokazać, dlaczego wybrane kontrole są adekwatne.
Rejestr ryzyk istnieje, ale nie ma właścicieli, dat, działań, metryk ani decyzji zarządu. Wtedy jest dokumentem, a nie narzędziem zarządzania.
Polityki pokazują oczekiwany sposób działania. Procedury pokazują, jak firma wykonuje konkretne procesy. Same polityki nie wystarczą, ale są potrzebną warstwą systemu.
Polityka powinna mieć właściciela, wersję, datę zatwierdzenia, zakres, okres przeglądu i powiązanie z ryzykami oraz kontrolami.
Statement of Applicability, czyli SoA, jest jednym z najważniejszych dokumentów ISO 27001. Pokazuje, które kontrole z Annex A mają zastosowanie, które nie mają zastosowania i dlaczego.
SoA jest traktowany jak tabela do certyfikacji, a nie jako żywa mapa kontroli. Dobry SoA powinien być aktualny po zmianach ryzyka, technologii i zakresu ISMS.
Kontrola dostępu jest jednym z najważniejszych obszarów dowodowych. Przejęcie konta, zbyt szerokie uprawnienia i brak MFA to częste źródła incydentów.
Raport access review powinien pokazać nie tylko listę użytkowników, ale decyzje właścicieli: zostaje, ograniczyć, odebrać, do wyjaśnienia.
NIS2 i KSC wyraźnie podkreślają ciągłość działania, backup i odtwarzanie. ISO 27001 również wymaga przygotowania organizacji na zakłócenia i utratę dostępności.
Firma pokazuje, że backup się wykonuje, ale nie pokazuje testu odtworzenia. Dla audytu i realnej odporności restore jest ważniejszy niż sama informacja, że kopia istnieje.
Pod NIS2 i KSC dowody incident response mają szczególne znaczenie, ponieważ terminy zgłaszania są krótkie, a organ nadzoru może pytać o przebieg obsługi incydentu.
Najlepszym dowodem jest raport z ćwiczenia, w którym firma przetestowała pierwsze 24 i 72 godziny incydentu: kto decyduje, kto zgłasza, kto zbiera fakty i kto informuje zarząd.
Zarządzanie podatnościami pokazuje, że firma aktywnie wykrywa i zamyka luki, a nie czeka na incydent.
Firma ma raport z testu, ale nie ma dowodu, że podatności zostały naprawione albo świadomie zaakceptowane przez właściciela ryzyka.
NIS2 i KSC mocno podkreślają ryzyko łańcucha dostaw. ISO 27001 również wymaga zarządzania bezpieczeństwem relacji z dostawcami.
Dobrym dowodem jest karta dostawcy krytycznego: usługa, właściciel biznesowy, zakres dostępu, ryzyko, wymagania umowne, data ostatniej oceny i plan awaryjny.
Szkolenie jest wymaganiem organizacyjnym, ale także dowodem kultury bezpieczeństwa. Pod NIS2 i KSC ważne są szkolenia zarządu oraz personelu. Pod ISO 27001 ważna jest świadomość, kompetencje i zapisy potwierdzające udział.
Firma pokazuje listę obecności, ale nie pokazuje, czy szkolenie zmieniło zachowania. Dobrze jest mierzyć zgłoszenia phishingu, użycie drugiego kanału i wyniki ćwiczeń.
Bez logów i metryk trudno pokazać, że firma wykrywa incydenty, reaguje i poprawia zabezpieczenia.
Dobry raport z monitoringu pokazuje nie tylko liczbę alertów, ale też czas reakcji, status zamknięcia, właścicieli i działania naprawcze.
Zakres ISMS pokazuje, które procesy, lokalizacje, systemy, zespoły i usługi są objęte systemem zarządzania bezpieczeństwem informacji.
Dowód powinien pokazywać interesariuszy, wymagania prawne, wymagania klientów, czynniki wewnętrzne i zewnętrzne oraz wpływ tych elementów na ISMS.
ISO 27001 wymaga metodycznego podejścia do ryzyka. Dowodem jest metodyka, rejestr ryzyk, oceny, decyzje i plan działań.
SoA pokazuje, które kontrole są stosowane, które nie są stosowane i dlaczego. Powinien być spójny z oceną ryzyka.
Organizacja powinna mieć mierzalne cele bezpieczeństwa informacji, na przykład zamknięcie podatności wysokiego ryzyka, testy backupu, access review, szkolenia albo poprawę MFA.
Dowodem są plan audytów, checklista, raport audytu, niezgodności, obserwacje i działania korygujące.
Dowodem jest protokół przeglądu zarządzania, w tym status ryzyk, wyniki audytów, incydenty, metryki, działania korygujące i decyzje kierownictwa.
Dowodem są rejestr niezgodności, analiza przyczyn, plan korekty, właściciel, termin i potwierdzenie zamknięcia.
Trzeba pokazać, dlaczego firma uznała, że podlega albo nie podlega regulacji. To powinien być udokumentowany wniosek, a nie ustna opinia.
Jeśli firma jest podmiotem kluczowym albo ważnym, powinna mieć dowód wpisu, decyzji, kwalifikacji albo innego potwierdzenia zgodnie z właściwym trybem krajowym.
Trzeba mieć procedurę i szablony dla pierwszych godzin incydentu. Dowody powinny obejmować testy procesu zgłaszania, a nie tylko opis w dokumencie.
Dowodem są raporty dla zarządu, decyzje, szkolenia, zatwierdzone plany i budżet.
KSC może przewidywać możliwość żądania dokumentów, informacji i dowodów realizacji wymogów. Dlatego pakiet dowodów powinien być gotowy przed kontrolą, a nie tworzony dopiero po wezwaniu.
Repozytorium dowodów powinno być uporządkowane, bezpieczne i łatwe do przeglądu. Nie powinno być folderem, do którego każdy wrzuca przypadkowe pliki.
Nie każdy plik jest dobrym dowodem. Dowód powinien być wiarygodny, aktualny i powiązany z wymaganiem.
Polityka mówi, co powinno się dziać. Dowód pokazuje, co faktycznie się wydarzyło.
Jeżeli nikt nie odpowiada za dowód, szybko staje się przeterminowany.
Podczas audytu firma traci czas na szukanie plików, a część dowodów znika razem z właścicielem folderu.
Audytor musi wiedzieć, czy dowód jest aktualny. Brak daty osłabia wiarygodność.
Firma ma plan backupu, BCP albo incident response, ale nie ma raportu z testu. To bardzo częsta luka.
Zarząd omawia cyberbezpieczeństwo, ale nie ma protokołu, decyzji, budżetu ani akceptacji ryzyka.
Firma ma wiele plików, ale nie wie, które wymaganie każdy plik potwierdza.
Raport z podatności albo audytu nie wystarczy. Trzeba pokazać, co poprawiono, kiedy i kto zatwierdził zamknięcie.
Firma SaaS przygotowuje się do wymagań klienta enterprise, NIS2 i ISO 27001. Zespół IT ma wiele dobrych praktyk: MFA, backup, monitoring, skany podatności i szkolenia. Problem pojawia się podczas audytu klienta. Firma nie potrafi szybko pokazać, kiedy wykonano ostatni restore, kto zatwierdził access review, jakie ryzyka zaakceptował zarząd i czy dostawcy krytyczni byli ocenieni.
Firma tworzy macierz dowodów. Każdy obszar kontroli dostaje właściciela, lokalizację plików, częstotliwość aktualizacji i status. W ciągu 90 dni firma porządkuje rejestr ryzyk, Statement of Applicability, raporty backupu, access review, szkolenia, dostawców, podatności i incident response.
Efekt: podczas kolejnego audytu firma nie szuka dowodów chaotycznie. Pokazuje pakiet dowodowy: co jest wymagane, jaki dowód istnieje, kiedy został zaktualizowany i jakie działania naprawcze są w toku. To skraca audyt i zwiększa wiarygodność wobec klienta, zarządu i ubezpieczyciela.
ccyber.io pomaga firmom przygotować praktyczny pakiet dowodów zgodności pod NIS2, KSC, ISO 27001, audyty klientów i cyberubezpieczenie. Nie tworzymy dokumentów dla dokumentów. Budujemy system dowodowy, który pokazuje, że kontrole działają w praktyce.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Compliance Evidence Workshop. W krótkim warsztacie można ustalić, jakie dowody już istnieją, czego brakuje, które dowody są przeterminowane i jak zbudować pakiet gotowy dla zarządu, audytora, klienta albo organu nadzoru.
Nie. Polityka jest potrzebna, ale trzeba pokazać dowody działania: raporty, testy, przeglądy, logi, decyzje i działania naprawcze.
Analiza podlegania, rejestr ryzyk, plan działań, polityka bezpieczeństwa, raport MFA, access review, test restore, plan incydentowy, ocena dostawców i dowody szkoleń.
Tak. Wiele dowodów może wspierać kilka wymagań jednocześnie. Dlatego warto stworzyć macierz dowodów i mapować je do różnych regulacji oraz standardów.
To zależy od obszaru. Ryzyka, dostawcy, access review, backup, szkolenia i podatności powinny mieć ustaloną częstotliwość przeglądu, zwykle kwartalną, półroczną albo roczną.
Brak testów. Firmy mają procedury backupu, incident response albo BCP, ale nie mają raportów pokazujących, że proces był przećwiczony.
Nie automatycznie. ISO 27001 bardzo pomaga, ale trzeba osobno sprawdzić wymagania NIS2, KSC, zgłaszanie incydentów, zakres regulacji i przepisy krajowe.
Najczęściej compliance, CISO, vCISO, risk albo osoba odpowiedzialna za ISMS. Właściciele poszczególnych dowodów powinni być w IT, security, HR, legal, zakupach, finansach i biznesie.
Zacznij od macierzy dowodów: wymaganie, dowód, właściciel, data, status i luka. Następnie uzupełnij najważniejsze obszary: ryzyko, dostęp, backup, incydenty, dostawcy i szkolenia.
Dowody zgodności pod NIS2, KSC i ISO 27001 powinny pokazywać realne działanie cyberbezpieczeństwa. Sama polityka, prezentacja albo deklaracja nie wystarczy. Potrzebne są raporty, testy, logi, decyzje, przeglądy i działania korygujące.
Najważniejsze grupy dowodów to: zakres i podleganie, decyzje zarządu, ryzyko, polityki, Statement of Applicability, kontrola dostępu, backup, incident response, podatności, dostawcy, szkolenia, monitoring, audyty i działania naprawcze.
Najlepsze podejście to jedno repozytorium i jedna macierz dowodów, która łączy wymagania NIS2, KSC, ISO 27001, klientów i ubezpieczycieli. Wtedy firma nie przygotowuje się do audytu w panice. Ma system dowodowy, który działa na co dzień.
Kary za NIS2. Co zarząd musi wiedzieć o nowej dyrektywie?
Kary za NIS2 mogą sięgać milionów euro albo procentu globalnego rocznego obrotu, ale dla zarządu najważniejsze nie są same liczby. NIS2 przenosi cyberbezpieczeństwo na poziom odpowiedzialności kierownictwa: zarząd ma zatwierdzać środki zarządzania ryzykiem cyber, nadzorować ich wdrożenie, rozumieć obowiązki zgłaszania incydentów i zapewnić dowody zgodności. Kara grozi nie tylko za sam incydent, ale za brak właściwego zarządzania ryzykiem, brak raportowania, ignorowanie zaleceń organu lub brak realnych kontroli.
Opracowanie: Zespół redakcyjny CCyber
Kary za NIS2 mogą być bardzo wysokie, ale zarząd nie powinien traktować dyrektywy wyłącznie jako tematu sankcji. NIS2 wymaga, aby organizacje objęte regulacją miały realny system zarządzania ryzykiem cyber, procedury zgłaszania incydentów, nadzór nad dostawcami, ciągłość działania, szkolenia, kontrolę dostępu, bezpieczeństwo łańcucha dostaw i dowody wdrożenia. Dyrektywa wskazuje, że dla podmiotów kluczowych maksymalna kara ma wynosić co najmniej 10 000 000 EUR albo 2% całkowitego światowego rocznego obrotu, zależnie od tego, która kwota jest wyższa. Dla podmiotów ważnych próg wynosi co najmniej 7 000 000 EUR albo 1,4% obrotu. Szczegółowe zasady w Polsce trzeba jednak sprawdzać w krajowej ustawie wdrażającej NIS2, ponieważ dyrektywa jest wdrażana przez prawo krajowe.
Lipiec 2026
NIS2 jest dyrektywą Unii Europejskiej. Oznacza to, że państwa członkowskie muszą wdrożyć jej wymagania do prawa krajowego. Sama dyrektywa określa minimalny poziom wymagań, w tym minimalny poziom maksymalnych kar, ale szczegółowy tryb kontroli, organ nadzoru, procedury, definicje krajowe i szczegółowe sankcje wynikają z ustawy wdrażającej w danym państwie.
Dla zarządu praktyczny wniosek jest prosty: nie wystarczy znać tekst dyrektywy. Trzeba sprawdzić trzy rzeczy:
W Polsce wdrożenie NIS2 jest powiązane z ustawą o krajowym systemie cyberbezpieczeństwa i jej nowelizacją. Dlatego w praktyce zarząd powinien pracować na aktualnym tekście krajowej ustawy, a nie tylko na ogólnych prezentacjach o NIS2.
Dla podmiotów kluczowych dyrektywa przewiduje, że naruszenia obowiązków dotyczących środków zarządzania ryzykiem cyber i zgłaszania incydentów mogą podlegać administracyjnym karom pieniężnym o maksymalnym poziomie co najmniej:
Dla podmiotów ważnych dyrektywa przewiduje maksymalny poziom kar co najmniej:
To bardzo ważne sformułowanie. NIS2 wskazuje minimalny poziom maksymalnych kar, który państwa członkowskie muszą zapewnić. Krajowe przepisy mogą zawierać własne rozwiązania, procedury, przeliczenia, kary okresowe, zasady dla administracji publicznej i dodatkowe środki nadzorcze.
Nie każdy incydent oznacza automatycznie karę. Cyberbezpieczeństwo nie polega na obietnicy, że incydent nigdy się nie wydarzy. Regulacja patrzy raczej na to, czy organizacja zarządzała ryzykiem odpowiednio do swojej skali, sektora, zagrożeń i wpływu na usługi.
Ryzyko kary rośnie, gdy firma:
Najważniejszy komunikat dla zarządu: organ nie będzie oceniał tylko tego, że coś się stało. Będzie oceniał, czy firma działała rozsądnie, proporcjonalnie, terminowo i z dowodami.
NIS2 wymaga środków technicznych, operacyjnych i organizacyjnych. To nie jest tylko firewall albo antywirus. To cały system zarządzania ryzykiem cyber.
Do obszarów ryzyka należą między innymi:
NIS2 wprowadza rygorystyczne terminy zgłaszania istotnych incydentów. W uproszczeniu organizacja powinna przygotować się na:
Praktyczny problem polega na tym, że firma musi mieć proces, który działa w stresie. Nie da się przygotować dobrego zgłoszenia w 24 godziny, jeśli wcześniej nie wiadomo, kto decyduje, kto zbiera fakty, kto kontaktuje CSIRT, kto informuje zarząd i kto prowadzi komunikację.
NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyber i nadzorowały ich wdrożenie. Zarząd nie może ograniczyć się do stwierdzenia „IT się tym zajmuje”.
W praktyce zarząd powinien mieć:
Ryzyko sankcji rośnie, gdy firma otrzyma zalecenia, nakazy albo wyniki audytu i nie podejmie działań. NIS2 przewiduje szeroki katalog środków nadzorczych, nie tylko kary pieniężne.
Organ może w praktyce wymagać między innymi:
W zgodności z NIS2 duże znaczenie mają dowody. Firma może mieć dobre działania techniczne, ale jeśli nie potrafi ich udokumentować, trudno będzie obronić swoje podejście przed organem, audytorem albo klientem.
Dowody mogą obejmować:
NIS2 wyraźnie podnosi cyberbezpieczeństwo do poziomu zarządu. Nie chodzi o to, że każdy członek zarządu ma sam konfigurować systemy. Chodzi o to, że zarząd ma rozumieć ryzyko, zatwierdzać kierunek działań, nadzorować wdrożenie i zapewnić zasoby.
NIS2 wymaga, aby państwa członkowskie zapewniły możliwość pociągnięcia osób odpowiedzialnych albo przedstawicieli prawnych podmiotu kluczowego do odpowiedzialności za naruszenie obowiązków zapewnienia zgodności. Dyrektywa przewiduje też możliwość czasowego zakazu pełnienia funkcji zarządczych w określonych przypadkach dotyczących podmiotów kluczowych, zgodnie z prawem krajowym i gwarancjami proceduralnymi.
To nie oznacza, że każda awaria albo każdy incydent automatycznie prowadzi do osobistej odpowiedzialności członka zarządu. Oznacza jednak, że zarząd powinien traktować cyberbezpieczeństwo jako obowiązek nadzorczy, a nie tylko techniczne zadanie IT.
NIS2 rozróżnia podmioty kluczowe i ważne. To rozróżnienie wpływa między innymi na poziom nadzoru, podejście organów i maksymalne poziomy kar.
To zwykle organizacje z sektorów o najwyższej krytyczności, których zakłócenie może mieć szczególnie istotny wpływ na społeczeństwo, gospodarkę, bezpieczeństwo publiczne albo ciągłość ważnych usług.
To organizacje objęte regulacją, które również muszą wdrożyć wymagania NIS2, ale podlegają innemu modelowi nadzoru i niższym minimalnym progom maksymalnych kar.
Zarząd nie powinien zgadywać kategorii. Powinien zlecić formalną analizę podlegania, która obejmuje sektor, wielkość firmy, rodzaj świadczonych usług, zależności grupowe, kraj działalności i przepisy krajowe.
NIS2 obejmuje szeroki zakres sektorów. Komisja Europejska wskazuje, że dyrektywa ustanawia ramy dla 18 krytycznych sektorów w Unii Europejskiej.
Zakres regulacji może zależeć od szczegółów krajowych, wielkości organizacji i rodzaju usługi. Dlatego analiza podlegania powinna być pierwszym krokiem.
Po poważnym incydencie organ lub klient może zapytać nie tylko o to, co się stało. Pytania zwykle dotyczą przygotowania organizacji przed incydentem.
Najgorsza odpowiedź brzmi: „nie wiemy”, „nie było właściciela”, „nie było procedury”, „nie testowaliśmy”, „nie mamy dowodów”.
Najlepsza odpowiedź brzmi: „mieliśmy proces, znamy zakres, zgłosiliśmy w terminie, mamy logi, mamy raport, mamy decyzje zarządu, mamy plan naprawczy i potrafimy pokazać dowody”.
Najpierw trzeba ustalić, czy firma podlega regulacji i w jakiej roli.
Analiza powinna obejmować:
Dowód do przygotowania: raport analizy podlegania NIS2 i decyzja zarządu o dalszych działaniach.
Firma powinna porównać obecny stan z wymaganiami NIS2. Chodzi o praktyczne luki, a nie tylko listę dokumentów.
Sprawdź:
Dowód do przygotowania: NIS2 gap analysis z priorytetami i planem działań.
Zarząd potrzebuje widzieć cyberbezpieczeństwo jako ryzyko biznesowe. Rejestr ryzyk powinien pokazywać wpływ na usługi, klientów, przychody, ciągłość działania i zgodność.
Rejestr powinien zawierać:
Dowód do przygotowania: rejestr ryzyk cyber zatwierdzony lub okresowo przeglądany przez zarząd.
Firma musi wiedzieć, jak działać w pierwszych godzinach incydentu. NIS2 wymaga szybkiego raportowania, więc proces musi być przećwiczony.
Plan powinien wskazywać:
Dowód do przygotowania: incident response plan i raport z ćwiczenia tabletop.
NIS2 mocno podkreśla bezpieczeństwo łańcucha dostaw. Firma powinna wiedzieć, którzy dostawcy są krytyczni i jakie ryzyka wnoszą.
Program dostawców powinien obejmować:
Dowód do przygotowania: rejestr dostawców i raport oceny ryzyka łańcucha dostaw.
Zarząd powinien otrzymywać regularny, zrozumiały raport. Nie musi zawierać nadmiaru technicznych szczegółów, ale musi pokazywać ryzyko, decyzje i postęp.
Raport powinien obejmować:
Dowód do przygotowania: cykliczny dashboard NIS2 dla zarządu.
IT może wdrażać wiele kontroli, ale odpowiedzialność dotyczy całej organizacji: zarządu, ryzyka, prawników, dostawców, finansów, HR, komunikacji i ciągłości działania.
Kary są ważne, ale lepsze pytanie brzmi: czy firma potrafi zapewnić ciągłość usług, zgłosić incydent w terminie i pokazać dowody zarządzania ryzykiem?
Firma zakłada, że NIS2 jej nie dotyczy, bo nie jest dużą infrastrukturą krytyczną. Tymczasem zakres NIS2 jest szerszy niż wcześniejsze regulacje.
Bez dowodów trudno pokazać, że środki zostały wdrożone, testowane i nadzorowane.
Terminy zgłaszania są krótkie. Bez ćwiczenia firma może stracić cenne godziny na ustalanie ról i kanałów komunikacji.
Dostawcy ICT, chmury, oprogramowania, integratorzy i firmy outsourcingowe mogą być źródłem istotnego ryzyka.
NIS2 wymaga, aby członkowie organów zarządzających mieli wiedzę potrzebną do rozumienia ryzyka i praktyk zarządzania ryzykiem cyber.
Zarząd może zaakceptować ryzyko, ale powinien robić to świadomie, na podstawie danych, a nie przez brak decyzji.
Firma technologiczna świadczy usługi dla klientów z sektora ochrony zdrowia i przemysłu. Zarząd początkowo uznaje, że NIS2 dotyczy głównie operatorów infrastruktury krytycznej, więc temat odkłada na później. Po analizie okazuje się, że firma może być istotnym dostawcą w łańcuchu usług objętych wymaganiami klientów, a część obowiązków NIS2 będzie wpływać na umowy, audyty i oczekiwania bezpieczeństwa.
Firma wykonuje gap analysis. Największe luki to brak formalnego rejestru ryzyk, nieprzetestowany incident response, brak cyklicznego access review, słabe dowody backupu, brak oceny dostawców i brak raportowania cyber do zarządu. Zespół IT miał wiele dobrych praktyk, ale nie były one uporządkowane ani udokumentowane.
Zarząd zatwierdza 90-dniowy plan: analiza podlegania, rejestr ryzyk, tabletop, MFA dla kont krytycznych, test restore, program dostawców i dashboard. Po trzech miesiącach firma nie jest „gotowa na wszystko”, ale ma dowody, właścicieli i plan. To znacząco zmniejsza ryzyko sankcji, ale też zwiększa odporność biznesową.
ccyber.io pomaga zarządom i zespołom bezpieczeństwa przygotować organizację do NIS2 w sposób praktyczny, mierzalny i nastawiony na dowody. Nie zaczynamy od dokumentów dla dokumentów. Zaczynamy od podlegania, ryzyka, usług krytycznych, incydentów, dostawców i odpowiedzialności zarządu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Board Readiness Workshop. W krótkim warsztacie można ustalić, czy firma podlega NIS2, jakie są najważniejsze ryzyka, co musi wiedzieć zarząd, jakie decyzje są potrzebne i które działania warto rozpocząć natychmiast.
Dla podmiotów kluczowych dyrektywa wskazuje maksymalny poziom kar co najmniej 10 000 000 EUR albo 2% światowego rocznego obrotu. Dla podmiotów ważnych co najmniej 7 000 000 EUR albo 1,4% obrotu. Szczegóły wynikają z prawa krajowego.
Tak, NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyber, nadzorowały ich wdrożenie i mogły ponosić odpowiedzialność za naruszenia, zgodnie z prawem krajowym.
Nie każdy incydent oznacza automatycznie karę. Ryzyko kary rośnie, gdy firma nie miała adekwatnych środków, nie zgłosiła incydentu, zignorowała zalecenia albo nie potrafiła pokazać dowodów.
Podmiot kluczowy ma zwykle większą krytyczność i podlega mocniejszemu nadzorowi oraz wyższemu poziomowi kar. Podmiot ważny również musi spełniać wymagania, ale podlega innemu modelowi nadzoru i niższym progom kar.
Najpierw zlecić analizę podlegania NIS2, potem gap analysis, rejestr ryzyk, plan działań, plan zgłaszania incydentów i dashboard nadzorczy.
Tak. Dyrektywa wymaga, aby członkowie organów zarządzających odbywali szkolenia, które pozwolą im rozumieć ryzyka cyber i oceniać praktyki zarządzania tym ryzykiem.
ISO 27001 może bardzo pomóc, bo porządkuje zarządzanie bezpieczeństwem informacji, ryzykiem, kontrolami i ciągłym doskonaleniem. Nie zastępuje jednak automatycznie analizy NIS2, obowiązków incydentowych i wymagań krajowych.
Zacznij od czterech rzeczy: analiza podlegania, rejestr ryzyk, plan incydentowy z terminami 24 i 72 godziny oraz raport dla zarządu z priorytetami i budżetem.
Kary za NIS2 są wysokie, ale największa zmiana nie polega wyłącznie na wysokości sankcji. Największa zmiana polega na tym, że cyberbezpieczeństwo staje się formalnym tematem zarządu, nadzoru, dowodów i odpowiedzialności organizacyjnej.
Zarząd powinien rozumieć, czy firma podlega NIS2, jakie usługi są krytyczne, jakie ryzyka są najważniejsze, czy firma potrafi zgłosić incydent w terminie, czy dostawcy są pod kontrolą i czy istnieją dowody wdrożenia środków bezpieczeństwa.
Najlepszą odpowiedzią na ryzyko kar nie jest panika ani sama dokumentacja. Najlepszą odpowiedzią jest praktyczny program NIS2 readiness: analiza podlegania, gap analysis, rejestr ryzyk, incident response, dostawcy, szkolenia, testy, metryki i regularny nadzór zarządu.
Phishing od AI: jak AI zmienia oszustwa i jak przygotować pracowników
AI zmienia phishing, bo oszuści mogą szybciej tworzyć poprawne językowo, spersonalizowane i wielokanałowe wiadomości, rozmowy oraz fałszywe scenariusze. Phishing od AI może wyglądać jak e-mail od dostawcy, wiadomość od prezesa, telefon od helpdesku, SMS od kuriera, deepfake na spotkaniu albo prośba klienta o dokumenty. Pracowników trzeba szkolić nie tylko z rozpoznawania oszustwa, ale przede wszystkim z bezpiecznej reakcji: zatrzymaj się, zweryfikuj drugim kanałem, nie podawaj kodów MFA, nie omijaj procedur i zgłoś podejrzany kontakt.
Opracowanie: Zespół redakcyjny CCyber
Phishing od AI to phishing wspierany przez sztuczną inteligencję. Nie oznacza to, że każdy atak jest całkowicie automatyczny albo bardzo zaawansowany. Oznacza, że oszust może użyć AI do napisania lepszej wiadomości, przetłumaczenia jej na język odbiorcy, dopasowania stylu do konkretnej osoby, przygotowania fałszywego dokumentu, sklonowania głosu, stworzenia deepfake albo prowadzenia bardziej przekonującej rozmowy. Dla pracownika najważniejsza zmiana jest prosta: wiadomość bez błędów, znajomy ton, poprawny język i wiarygodny głos nie są już wystarczającym dowodem autentyczności. Firmy powinny szkolić pracowników nie tylko z rozpoznawania phishingu, ale z właściwej reakcji: zatrzymać się, sprawdzić kontekst, potwierdzić drugim kanałem, nie podawać kodów MFA, nie omijać procedur i zgłaszać podejrzane sytuacje.
Lipiec 2026
Phishing od AI to potoczne określenie ataków phishingowych, w których oszust wykorzystuje sztuczną inteligencję do przygotowania lub przeprowadzenia oszustwa. Może chodzić o tekst, głos, obraz, analizę informacji publicznych, automatyzację rozmów albo tworzenie wielu wariantów tej samej wiadomości.
W praktyce AI może pomóc oszustowi w:
Nie trzeba zakładać, że każdy atak jest bardzo zaawansowany. Czasem wystarczy, że oszust użyje AI do napisania lepszego e-maila. To już może zwiększyć skuteczność ataku.
Pracownicy przez lata słyszeli, że phishing można rozpoznać po błędach językowych. To coraz słabsza wskazówka. AI potrafi pisać poprawnie, naturalnie i w języku odbiorcy.
Atak może odnosić się do realnej roli pracownika, działu, projektu, klienta, wydarzenia, wpisu w mediach społecznościowych albo informacji ze strony firmy.
Oszust może wygenerować wiele wariantów tej samej wiadomości, dopasować je do różnych odbiorców i szybko testować, który scenariusz działa najlepiej.
Atak może zacząć się e-mailem, potem przejść na telefon, Teams, SMS albo WhatsApp. AI może pomóc utrzymać spójny scenariusz w różnych kanałach.
Phishing nie musi już być tekstowy. Atak może zawierać wiadomość głosową, telefon z klonowanym głosem albo fałszywe spotkanie online.
AI może pomóc stworzyć dokument, historię korespondencji, notatkę ze spotkania, podsumowanie projektu albo wiadomość, która wygląda jak naturalna część pracy.
Pracownik może pomyśleć: „to brzmi normalnie”. Problem w tym, że dzisiejszy phishing może właśnie tak brzmieć. Dlatego procedura jest ważniejsza niż intuicja.
Najważniejsza zmiana dla pracownika: nie wystarczy ocenić, czy wiadomość wygląda profesjonalnie. Trzeba ocenić, czy prośba ma sens, czy jest zgodna z procedurą i czy wymaga niezależnej weryfikacji.
Wiadomość jest poprawna, uprzejma i odnosi się do prawdziwej usługi. W załączniku znajduje się faktura albo link do pobrania dokumentu. Rachunek bankowy może być inny niż wcześniej.
Osoba z finansów otrzymuje pilną prośbę o przelew, zmianę rachunku albo przygotowanie dokumentów. Styl może być podobny do prawdziwej komunikacji managera.
Oszust podaje się za IT i mówi, że wykryto problem z kontem. Prosi o kod MFA, zatwierdzenie powiadomienia, instalację narzędzia albo udostępnienie ekranu.
Pracownik dostaje wiadomość wyglądającą jak prośba od współpracownika, klienta albo dostawcy. Link prowadzi do fałszywej strony logowania albo pliku.
Atak może wyglądać jak wiadomość od kuriera, banku, dostawcy usług, przełożonego albo klienta. AI może pomóc dopasować język i stworzyć bardziej wiarygodny tekst.
Pracownik otrzymuje dokument lub plakat z kodem QR. Kod prowadzi do fałszywej strony logowania, płatności albo formularza. Ponieważ link nie jest widoczny od razu, część filtrów i użytkowników może go gorzej ocenić.
Sprzedaż, obsługa klienta albo projekt manager otrzymuje brief, umowę, specyfikację lub zamówienie. Dokument wygląda normalnie, ale prowadzi do fałszywego logowania, złośliwego pliku albo prośby o dane.
Atakujący wykorzystuje fałszywy obraz lub głos, aby uwiarygodnić polecenie podczas spotkania. Celem może być przelew, zmiana procedury, wysyłka dokumentów albo nadanie dostępu.
Oszust dzwoni głosem brzmiącym jak znana osoba. Może podszyć się pod prezesa, managera, klienta, dostawcę albo pracownika IT.
Pracownik używa AI do streszczenia maila, dokumentu albo strony. Jeśli narzędzie AI analizuje zewnętrzną treść, może zostać zmanipulowane ukrytą instrukcją. To szczególnie ważne przy chatbotach, RAG i agentach AI.
„Zrób to teraz”, „klient czeka”, „zarząd już zatwierdził”, „nie mamy czasu na procedurę”.
„Nie mów nikomu”, „to poufne”, „nie angażuj zespołu”, „formalności później”.
Kod MFA jest prywatny. Nikt nie powinien o niego prosić przez e-mail, telefon, SMS, Teams ani komunikator.
Każda zmiana danych płatności wymaga niezależnego potwierdzenia. Nawet jeśli wiadomość wygląda wiarygodnie.
Prezes pisze z prywatnego komunikatora, dostawca prosi o dokumenty przez nowy adres, klient kontaktuje się z nieznanego numeru.
Oszust często mówi, że sprawa jest wyjątkowa. Dobra procedura powinna działać właśnie w sytuacjach wyjątkowych.
Załącznik albo link może wyglądać profesjonalnie. Nadal warto sprawdzić, czy był oczekiwany i czy pochodzi z właściwego kanału.
Jeśli rozmówca naciska, aby nie oddzwaniać, nie pytać przełożonego i nie sprawdzać sprawy drugim kanałem, to silna czerwona flaga.
Poprawny język nie oznacza bezpieczeństwa. AI może tworzyć wiadomości bez błędów.
Atakujący może dopasować styl do osoby lub organizacji, szczególnie jeśli ma dostęp do wcześniejszej korespondencji albo publicznych treści.
Głos może być sklonowany. Nie należy podejmować decyzji o pieniądzach, danych ani dostępie tylko dlatego, że ktoś brzmi znajomo.
Fałszywa faktura, oferta albo brief może wyglądać bardzo dobrze. Ważna jest weryfikacja źródła i procesu.
Phishing nie zawsze ma załącznik. Może polegać na rozmowie, prośbie o odpowiedź, zmianie rachunku, QR code albo fałszywym logowaniu.
Pracownik nie zawsze rozpozna AI. Może jednak zawsze zastosować procedurę.
Prosty model reakcji:
Drugi kanał to niezależna metoda potwierdzenia prośby. Nie używaj numeru telefonu, linku ani adresu podanego w podejrzanej wiadomości. Użyj danych kontaktowych znanych wcześniej.
Drugi kanał powinien być obowiązkowy przy:
Pracownicy powinni zapamiętać jedną zasadę: kodu MFA nie podaje się nikomu. Nie zatwierdza się też powiadomienia logowania, którego samemu się nie rozpoczęło.
Szkolenie powinno obejmować:
Najskuteczniejsze szkolenie dotyczy realnej pracy. Inaczej szkoli się finanse, inaczej HR, IT, sprzedaż i zarząd.
Pracownik powinien móc szybko zgłosić e-mail, telefon, wiadomość głosową, SMS, komunikator albo spotkanie online. Zgłoszenie musi być proste i bezpieczne psychologicznie.
Nie mierz tylko obecności na szkoleniu. Mierz, czy pracownicy zgłaszają, weryfikują, odmawiają podania kodu MFA i stosują procedury.
Największe ryzyka to przelewy, faktury, zmiana rachunku dostawcy i presja ze strony osób podszywających się pod zarząd.
Ćwicz:
Największe ryzyka to reset hasła, kod MFA, dostęp administratora, zdalne wsparcie i podszywanie się pod użytkownika.
Ćwicz:
Największe ryzyka to fałszywi kandydaci, załączniki, dane osobowe, deepfake na rozmowie online i wyłudzenia związane z wynagrodzeniami.
Ćwicz:
Największe ryzyka to fałszywy klient, link do dokumentu, prośba o dane, zmiana adresu kontaktowego i wyłudzenie informacji z CRM.
Ćwicz:
Największe ryzyka to fałszywe kampanie, deepfake, oszustwa reklamowe, linki do zasobów, fałszywe prośby o dostęp do kont społecznościowych i użycie narzędzi AI bez oceny.
Ćwicz:
Największe ryzyka to oszustwa na autorytet, klonowanie głosu, deepfake, prośby o poufność, presja czasu i kultura omijania procedur.
Ćwicz:
Pracownik musi wiedzieć, gdzie zgłosić podejrzaną wiadomość, telefon, SMS, komunikator albo spotkanie online.
Opisuje, kiedy trzeba potwierdzić prośbę niezależnym kanałem i jakie kanały są akceptowane.
Opisuje progi kwotowe, zatwierdzenia, role, zasadę dwóch osób i zakaz płatności poza procesem.
Każda zmiana rachunku bankowego powinna wymagać niezależnej weryfikacji przez znany wcześniej kontakt.
Helpdesk musi mieć jasne zasady weryfikacji tożsamości, szczególnie przy prośbach pilnych i nietypowych.
Pracownik powinien wiedzieć, że może zakończyć rozmowę, nie podawać informacji i zgłosić sytuację.
Pracownicy powinni wiedzieć, jakich danych nie wolno wprowadzać do niezatwierdzonych narzędzi AI i jak zgłosić potrzebę użycia nowego narzędzia.
Phishing od AI może przyjść przez telefon, SMS, Teams, LinkedIn, WhatsApp, QR code, dokument albo spotkanie online.
Nie zawsze rozpozna. Dlatego trzeba szkolić procedurę reakcji, a nie tylko ocenę, czy treść wygląda sztucznie.
Kliknięcia są ważne, ale równie ważne są zgłoszenia, drugi kanał, odmowy podania MFA i czas reakcji.
Jeśli firma nie ma jasnej procedury weryfikacji, pracownik zostaje sam z decyzją pod presją.
To zmniejsza liczbę zgłoszeń. Pracownicy będą ukrywać błędy, a firma straci czas na reakcję.
Zarząd jest często używany jako element presji. Członkowie zarządu muszą wspierać procedury, nawet gdy sprawa wygląda pilnie.
Helpdesk jest celem, bo może resetować hasła, pomagać w dostępie i obsługiwać konta.
Ataki zmieniają się szybko. Szkolenie powinno być aktualizowane po incydentach, nowych scenariuszach i zmianach w sposobie pracy.
Firma usługowa zauważa wzrost podejrzanych wiadomości do działu finansów i sprzedaży. Wiadomości są poprawne językowo, odnoszą się do prawdziwych klientów i wyglądają jak normalna komunikacja. Jeden z maili prosi o zmianę rachunku dostawcy, a drugi zawiera link do rzekomego briefu klienta.
Firma nie ogranicza się do kolejnej prezentacji o phishingu. Tworzy program przygotowania na phishing wspierany przez AI. Finanse ćwiczą zmianę rachunku i pilny przelew. Sprzedaż ćwiczy fałszywy brief klienta. IT ćwiczy telefon od osoby proszącej o reset hasła. Zarząd ćwiczy scenariusz klonowania głosu i presji czasu.
Po 90 dniach firma widzi więcej zgłoszeń, mniej decyzji podejmowanych pod presją i lepsze stosowanie drugiego kanału. Pracownicy nie muszą rozpoznawać, czy wiadomość została napisana przez AI. Wystarczy, że wiedzą, kiedy zatrzymać się, zweryfikować i zgłosić.
ccyber.io pomaga firmom przygotować pracowników na phishing wspierany przez AI, vishing, klonowanie głosu, deepfake, fałszywe faktury, wyłudzenia kodów MFA i oszustwa na autorytet. Nie skupiamy się tylko na teorii. Budujemy scenariusze, procedury, ćwiczenia i metryki zachowań.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest AI Phishing Readiness Workshop. W krótkim warsztacie można ustalić, które działy są najbardziej narażone, jakie scenariusze są realne dla firmy, jakie procedury trzeba poprawić i jakie ćwiczenia powinny zostać uruchomione w pierwszych 30 dniach.
To raczej nowa wersja znanego problemu. AI pomaga oszustom tworzyć bardziej przekonujące wiadomości, głosy, dokumenty i scenariusze, ale cel pozostaje podobny: pieniądze, dane, hasła, dostęp albo kod MFA.
Czasem tak, ale nie wolno na tym polegać. Lepszą ochroną jest procedura: drugi kanał, zgłoszenie, zasada dwóch osób i zakaz podawania kodów MFA.
Wiadomości mogą być poprawne językowo, spersonalizowane, wielokanałowe i bardziej dopasowane do kontekstu firmy.
Finanse, księgowość, IT, helpdesk, HR, sprzedaż, obsługę klienta, asystentów zarządu i osoby zatwierdzające płatności, dostęp albo wysyłkę danych.
Nie. Phishing od AI może obejmować telefon, wiadomości głosowe, komunikatory, QR code, spotkania online, fałszywe dokumenty i deepfake.
Mierz zgłoszenia, drugi kanał weryfikacji, odmowy podania kodów MFA, poprawne reakcje w ćwiczeniach, czas reakcji i liczbę wyjątków od procedur.
Nie działaj pod presją. Jeśli prośba dotyczy pieniędzy, danych, dostępu, hasła albo kodu MFA, zweryfikuj ją drugim kanałem i zgłoś podejrzaną sytuację.
Zacznij od listy scenariuszy AI phishing dla firmy, zasady drugiego kanału, zakazu podawania kodów MFA, prostego kanału zgłoszeń i szkolenia działów wysokiego ryzyka.
AI zmienia phishing, bo usuwa wiele dawnych sygnałów ostrzegawczych. Wiadomości mogą być poprawne, głos może brzmieć znajomo, a dokument może wyglądać profesjonalnie. To nie oznacza, że pracownicy są bezradni. Oznacza, że trzeba ich szkolić inaczej.
Najlepsze szkolenie nie polega na zgadywaniu, czy coś zostało wygenerowane przez AI. Polega na ćwiczeniu zachowania: zatrzymaj się, zweryfikuj drugim kanałem, nie podawaj kodów MFA, nie omijaj procedury, zgłoś podejrzany kontakt.
Firmy, które przygotują pracowników na phishing wspierany przez AI, będą szybciej wykrywać ataki, ograniczać straty i budować kulturę, w której ostrożność jest częścią profesjonalnej pracy, a nie przeszkodą w działaniu.
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.