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 z dofinansowaniem: usługi i szkolenia CCyber
Przygotowujesz projekt z dofinansowaniem, realizujesz przyznany grant lub szukasz partnera do konsorcjum? CCyber wspiera szkolenia, analizę ryzyka, zgodność, wdrożenia i rozwój zespołów cyberbezpieczeństwa. Pokazujemy możliwe modele współpracy z beneficjentami, integratorami, firmami szkoleniowymi i doradcami dotacyjnymi. Wyjaśniamy, jak powiązać usługi z naborami 2026, ustalić rolę wykonawcy i przygotować zapytanie ofertowe. Z uwzględnieniem zasad wyboru dostawców, kwalifikowalności kosztów i dokumentowania rezultatów.
Opracowanie: Zespół redakcyjny CCyber
CCyber zaprasza do współpracy przy projektach cyberbezpieczeństwa finansowanych ze środków publicznych: od przygotowania zakresu, przez szkolenia i wdrożenia, po sprawdzenie rezultatów i wsparcie dokumentacji projektu. Możemy rozmawiać o wykonaniu określonej części prac, podwykonawstwie, udziale eksperckim lub partnerstwie w konsorcjum.
Nie musisz powierzać nam całego przedsięwzięcia. Możesz zgłosić potrzebę jednego szkolenia, warsztatu dla kierownictwa, oceny ryzyka, wdrożenia zabezpieczeń albo zespołu specjalistów do większego programu. Zakres i forma udziału muszą odpowiadać zasadom konkretnego finansowania.
Masz już projekt lub zapytanie ofertowe? Prześlij jego krótki opis na kontakt@ccyber.io. Wskaż program, etap prac, potrzebne wsparcie i termin. Na początek nie potrzebujemy haseł, danych klientów ani szczegółów podatności.
20 września 2026 r.
Punktem odniesienia jest zestawienie CPPC „Nabory 2026 z obszaru Cyberbezpieczeństwo”. Informacje o programie odróżniamy od proponowanych zakresów współpracy z CCyber. Opis możliwej usługi nie jest potwierdzeniem jej kwalifikowalności w każdym projekcie ani deklaracją przyznania dofinansowania.
Dla firm i instytucji przygotowujących wniosek lub realizujących już finansowane przedsięwzięcie. Także dla liderów konsorcjów, integratorów IT, dostawców technologii, firm szkoleniowych, uczelni, organizacji branżowych i doradców pomagających klientom pozyskiwać środki.
Zaproszenie dotyczy zarówno pojedynczych zadań, jak i większych zakresów realizacyjnych. Status beneficjenta lub partnera ocenia się według warunków konkursu, nie na podstawie samej przynależności do wskazanej grupy.
Europejskie Centrum Kompetencji w dziedzinie Cyberbezpieczeństwa, ECCC, otworzyło rundę DIGITAL-ECCC-2027-DEPLOY-CYBER-11 z pulą 96 mln euro. Termin składania wniosków to 14 stycznia 2027 r., godz. 17:00 CET. Daty i zakres potwierdza komunikat ECCC.
To konkursy europejskie, a nie osobna pula wyłącznie dla polskich firm. Termin dotyczy złożenia wniosku. Nie oznacza wspólnego terminu zakończenia szkoleń, wdrożeń ani zamówień we wszystkich projektach.
Dla organizacji planującej udział jest to moment na ustalenie, kto dostarczy potrzebne rezultaty. Opis projektu powinien łączyć zadania, zasoby, harmonogram i sposób wykazania efektu, zgodnie z instrukcją przygotowania aplikacji Komisji Europejskiej.
Masz przyznane środki i potrzebujesz realizacji szkolenia, oceny ryzyka, dokumentacji albo wdrożenia? Zapraszamy do przesłania zakresu zamówienia. Możemy przygotować propozycję prac z rezultatami, harmonogramem i zasadami odbioru.
Nie musisz składać kolejnego wniosku tylko po to, aby zapytać o wykonanie zatwierdzonego zadania. Trzeba natomiast potwierdzić, czy zakres mieści się w Twoim projekcie i jakie zasady wyboru wykonawcy obowiązują.
Wdrażasz infrastrukturę, platformę lub usługę i potrzebujesz części cyberbezpieczeństwa? Możemy uzgodnić wydzielony zakres: analizę wymagań, przegląd architektury, zarządzanie dostępem, szkolenia użytkowników albo przygotowanie procedur operacyjnych.
W takim modelu ważny jest podział odpowiedzialności z głównym wykonawcą. Ustalamy, kto kontaktuje się z odbiorcą, kto zatwierdza zmiany i jakie materiały trafią do końcowego raportu. Podwykonawstwo wymaga zgodności z dokumentacją finansowania i zawartymi umowami.
Budujesz projekt i szukasz organizacji odpowiedzialnej za kompetencje, bezpieczeństwo wdrożenia lub ocenę rezultatów? Zapraszamy do rozmowy o udziale CCyber w odpowiednio zdefiniowanym pakiecie prac.
Partner będący beneficjentem realizuje własne zadania, ma przypisany budżet i uczestniczy w raportowaniu. To inny model niż sprzedaż usługi. Udział wymaga potwierdzenia warunków formalnych, zasobów, finansowania i podmiotu podpisującego umowę.
Nie każda rola nazwana „partnerem” daje prawo do środków z grantu. Partner stowarzyszony, czyli associated partner, nie otrzymuje finansowania z grantu na takich zasadach jak beneficjent. Różnice wyjaśnia podręcznik Komisji dotyczący uczestników projektu.
Potrzebujesz czasowego wsparcia, a nie całej usługi? Oferta wzmocnienia zespołu CCyber pozwala rozpocząć rozmowę o brakujących kompetencjach. W zapytaniu opisz zadania, oczekiwaną samodzielność, okres i wymiar zaangażowania.
Możliwe jest także uzgodnienie udziału trenerów lub ekspertów w wybranych warsztatach. Sposób rozliczenia w projekcie trzeba ustalić przed zaangażowaniem. Nazwanie współpracy „wzmocnieniem zespołu” nie przesądza o jej kwalifikacji jako kosztu personelu.
Prowadzisz projekt rozwojowy, ale potrzebujesz specjalistycznego modułu cyberbezpieczeństwa? Możemy omówić program, materiały, prowadzenie zajęć i sprawdzenie efektów uczenia się.
Jeżeli przygotowujesz klientowi wniosek, zapraszamy do ustalenia technicznego zakresu, nakładu pracy i rezultatów. Rzeczywista rola CCyber powinna być ujawniona zgodnie z wymaganiami projektu. Wspólna oferta handlowa nie zastępuje formalnego określenia beneficjenta, dostawcy lub podwykonawcy.
Poniższe propozycje rozwijają opublikowaną ofertę CCyber. Są przykładami zakresu do dopasowania, a nie listą kosztów automatycznie refundowanych przez program.
Oferta szkoleniowa CCyber obejmuje cyberhigienę, phishing, regulacje, bezpieczeństwo chmury, DevSecOps oraz OT. Program można dopasować do pracowników, kierownictwa i zespołów technicznych.
Przykładowym rezultatem do uzgodnienia może być umiejętność zgłoszenia incydentu, oceny podejrzanej prośby albo wykonania przeglądu uprawnień. Zakres szkolenia powinien określać zadania uczestników, poziom wejściowy i sposób sprawdzenia wyniku.
Forma zdalna, stacjonarna lub hybrydowa, język zajęć, liczba grup i dostępność materiałów wymagają ustalenia przed wyceną. Nie każdy temat wymaga całodniowego szkolenia, a samo uczestnictwo nie jest dowodem opanowania umiejętności.
W ramach projektów cyberbezpieczeństwa zakres może obejmować ocenę ryzyka, analizę luk, zasady zarządzania dostępem oraz przygotowanie procedur i planu działań.
Przykładowy pakiet do omówienia łączy warsztat z właścicielami usług, rejestr ryzyk i priorytetowe zadania. Dokumentację warto powiązać z konkretnym procesem, zamiast zamawiać liczbę polityk bez określenia ich zastosowania.
Przegląd gotowości należy odróżnić od audytu ustawowego lub certyfikacji, które mogą wymagać odrębnych uprawnień i niezależności.
Oferta projektowa obejmuje między innymi IAM, PAM, MFA, segmentację, bezpieczeństwo chmury i aplikacji. Do rozmowy o wdrożeniu potrzebne są granice środowiska, zależności od dostawców i kryteria odbioru.
Proponujemy łączyć zmianę techniczną z instrukcją utrzymania i kontrolowanym testem. Przykładowo wdrożenie zasad dostępu można odebrać przez sprawdzenie dozwolonej operacji, odmowy działania poza zakresem i odebrania uprawnień.
W projektach przemysłowych testy trzeba uzgodnić z właścicielem procesu. Finansowanie zadania nie jest zgodą na ingerencję w działające urządzenia.
Współpraca może obejmować także koordynację działań bezpieczeństwa i wsparcie eksperckie. Usługi zarządzane CCyber obejmują monitoring, reagowanie i vCISO, czyli zewnętrzną funkcję zarządzania bezpieczeństwem.
W projekcie dotacyjnym trzeba określić okres usługi i dalszy sposób jej finansowania. Nie zakładaj, że grant opłaci utrzymanie bezterminowo. Przygotuj plan przekazania wiedzy, konfiguracji i odpowiedzialności po zakończeniu prac.
Poniżej zachowujemy kolejność tematów z zestawienia CPPC. Opisy po słowach „do rozmowy” są propozycjami współpracy, nie urzędowym potwierdzeniem dopuszczalności konkretnego zamówienia.
DUALUSE: technologie cywilno-obronne. Do rozmowy: wymagania bezpieczeństwa, ocena ryzyka i przygotowanie użytkowników rozwiązania. Nie oznacza to deklaracji wykonania dowolnej technologii obronnej.
AI4SME: rozwiązania AI dla cyberbezpieczeństwa MŚP. Do rozmowy: ocena potrzeb użytkowników, bezpieczeństwo pilotażu, warsztaty i sprawdzenie, czy odbiorcy potrafią korzystać z rozwiązania.
EULEG: wdrażanie unijnych wymagań cyberbezpieczeństwa. Do rozmowy: zakres zgodności, procedury, szkolenia i materiały potwierdzające wykonanie zadań.
CYBERAI: narzędzia AI wspierające cyberbezpieczeństwo. Do rozmowy: scenariusze użycia, wymagania dostępu, ocena ryzyka i przygotowanie zespołu operacyjnego.
REGCABH: bezpieczeństwo kabli podmorskich. Do rozmowy: wydzielone zadania kompetencyjne i organizacyjne. Wymagany skład obejmuje właściwe organy z co najmniej dwóch państw członkowskich, więc zwykła współpraca dwóch firm nie wystarcza.
COORDPREP: testy gotowości i działania przygotowawcze. Do rozmowy: ocena ryzyka, ćwiczenia decyzyjne, szkolenia i uzgodniona weryfikacja ochrony. Rolę realizatora trzeba dopasować do właściwego komponentu.
NCC: rozwój krajowych centrów koordynacyjnych. Do rozmowy: programy edukacyjne i eksperckie wsparcie społeczności. Udział NCC jest obowiązkowy. Wskazana możliwość wsparcia podmiotów trzecich nie oznacza, że każdy taki nabór jest już otwarty.
Przed decyzją sprawdź pełne warunki tematu, w tym ograniczenia bezpieczeństwa. Sam opis dopasowania kompetencji nie potwierdza kwalifikowalności organizacji.
Przyjmujemy zapytania dotyczące istniejących projektów i ich zatwierdzonych zadań, także poza omawianą rundą Cyfrowej Europy. Prześlij zakres zamówienia, warunki wykonania i termin. Nie trzeba czekać na nowy konkurs, aby omówić brakujące wsparcie.
Dodanie nowego wykonawcy lub zmiana zakresu może wymagać odpowiedniej procedury. Dlatego najpierw sprawdzamy warunki współpracy, a dopiero potem termin rozpoczęcia.
Pełny projekt europejski nie musi być właściwą ścieżką dla pojedynczej potrzeby szkoleniowej. Warto osobno ocenić programy korzystające z Bazy Usług Rozwojowych i operatorów wsparcia albo Krajowy Fundusz Szkoleniowy. KFS ma lokalne nabory i warunki, które trzeba sprawdzić we właściwym urzędzie pracy.
Nie przenoś stawek dofinansowania między programami. Dla konkretnego szkolenia należy potwierdzić dopuszczalny zakres, status dostawcy, wymagane wpisy i moment rozpoczęcia. Wskazanie tej ścieżki nie jest potwierdzeniem, że dowolna usługa CCyber ma już aktywną kartę w BUR.
Organizatorów szkoleń korzystających z takich instrumentów zapraszamy także do rozmowy o udziale ekspertów CCyber. Forma udziału musi odpowiadać aktualnym zasadom programu i powierzania części usługi.
W grancie unijnym nie można rozliczać podzlecenia zadań między beneficjentami tego samego projektu. Partnerstwo ustalaj więc na podstawie rzeczywistego udziału i budżetu, nie jako inną nazwę zakupu usługi. Zasadę wyjaśnia podręcznik Komisji dotyczący uczestników.
Zakup usługi pomocniczej i powierzenie wykonania zadania projektu mogą należeć do różnych kategorii kosztów. Rozróżnienie opisuje Annotated Grant Agreement. Nazwa na fakturze nie zastępuje oceny rzeczywistego zakresu.
AGA wskazuje wymóg odpowiedniej relacji jakości do ceny lub najniższej ceny oraz brak konfliktu interesów. Podmioty objęte prawem zamówień publicznych stosują również właściwe przepisy krajowe. Nie należy zakładać, że każda wcześniejsza współpraca pozwala na bezpośrednie zamówienie.
Jeżeli CCyber pomaga w przygotowaniu postępowania, ewentualny udział w jego realizacji wymaga oceny zasad uczciwej konkurencji. Art. 85 Pzp przewiduje środki zapobiegające przewadze wynikającej z wcześniejszego zaangażowania. Rozmowa i wycena orientacyjna nie są rezerwacją zamówienia.
Zakres musi pasować do zatwierdzonego projektu, okresu kwalifikowalności i kategorii budżetowej. Sprawdź wymagane zgody na zmiany oraz zakaz podwójnego finansowania tych samych kosztów. Nie zakładaj refundacji pracy wykonanej przed dopuszczalnym terminem.
Dokumentowanie zależy od modelu finansowania. Komisja rozróżnia dowody poniesionych kosztów i potwierdzenie wykonania prac, w szczególności w grantach ryczałtowych. Zobacz zasady przechowywania dokumentacji.
Przykład modelowy CCyber. Lider projektu potrzebuje przygotować zespoły kilku instytucji do zgłaszania i obsługi incydentów. Integrator odpowiada za narzędzia, ale brakuje części organizacyjnej.
Proponowany zakres CCyber można podzielić na rozpoznanie ról, warsztat, dopracowanie procedury i zapowiedziane ćwiczenie. Celem nie jest wyłącznie frekwencja, lecz sprawdzenie, czy zgłoszenie dociera do właściwej osoby i uruchamia uzgodnioną reakcję.
Do uzgodnienia jako rezultaty: program zajęć, materiały, zapis przeprowadzenia szkolenia, aktualna procedura oraz raport z ćwiczenia z listą poprawek. Zakres informacji o uczestnikach powinien odpowiadać wymaganiom projektu i zasadom ochrony danych.
CCyber może rozmawiać o takim zadaniu jako wykonawca albo partner merytoryczny konsorcjum. Rola formalna i budżet muszą zostać ustalone osobno. Ten sam zakres nie powinien być jednocześnie wykazywany jako koszt własnego zadania beneficjenta i faktura podwykonawcza.
Przekazujesz program, etap projektu i zadanie, do którego potrzebujesz wsparcia. Może to być koncepcja wniosku, zapytanie do oszacowania budżetu albo opublikowane postępowanie.
Uzgadniamy odbiorców, zadania, rezultat i sposób sprawdzenia. Przy szkoleniu określamy grupy i formę zajęć. Przy wdrożeniu analizujemy środowisko i zależności. Oferta powinna rozdzielać wynagrodzenie, VAT oraz ewentualne koszty dodatkowe.
Ustalamy odpowiedzialność, prawa do materiałów, poufność, dostęp do systemów, harmonogram i odbiory. Rozpoczęcie prac zależy również od właściwych ustaleń zakupowych i projektowych.
Prace są odbierane według uzgodnionych kryteriów. Dokumentacja powinna pokazywać, co wykonano, czego dotyczył test lub szkolenie i jakie działania pozostają. Zakres wsparcia w raportowaniu określamy w umowie, bez obietnicy automatycznej akceptacji kosztów przez instytucję finansującą.
Program i etap: nazwa naboru, identyfikator tematu lub link do postępowania oraz informacja, czy przygotowujesz wniosek, masz przyznane środki czy realizujesz zamówienie.
Potrzebny zakres: szkolenie, analiza, dokumentacja, wdrożenie, test, eksperci lub partnerstwo. Przy zajęciach dodaj liczbę uczestników i grup, język oraz lokalizację lub formę zdalną.
Termin i budżet: data złożenia oferty, oczekiwany czas realizacji i dostępny budżet, jeżeli jest znany. Wskaż także wymagania wobec wykonawców.
Model współpracy: wykonawca dla beneficjenta, podwykonawca integratora, partner konsorcjum albo zakres jeszcze do ustalenia. Brak rozstrzygnięcia roli nie wyklucza pierwszej rozmowy.
Możesz użyć tematu wiadomości: „Projekt z dofinansowaniem: szkolenia, usługi lub partnerstwo”. Do wstępnej oceny wystarczy opis bez informacji poufnych.
W kategorii Finansowanie i dotacje na cyberbezpieczeństwo znajdziesz poradnik „Dotacje na cyberbezpieczeństwo z programu Cyfrowa Europa: jak przygotować i dobrze zrealizować projekt?”. Praktykę pracy z zespołami rozwijamy w kategorii Szkolenia i cyberświadomość.
Wsparcie projektów z dofinansowaniem obejmuje dobór ścieżki, przygotowanie projektu oraz uzgodnioną pomoc w realizacji i rozliczeniu. Możesz rozpocząć od jednego zadania, zamiast zamawiać cały program bezpieczeństwa.
Zapraszamy beneficjentów, liderów konsorcjów, integratorów, organizatorów szkoleń i doradców dotacyjnych. Prześlij opis potrzeby na kontakt@ccyber.io. Wskaż, jakiego rezultatu potrzebujesz i na jakim etapie projektu jesteś.
Tak. Możemy omówić zakres, nakład pracy i możliwe rezultaty. Wstępne ustalenia nie gwarantują finansowania ani wyboru wykonawcy. Rozpoczęcie prac i zasady płatności wymagają osobnego uzgodnienia.
Tak, zapytanie może dotyczyć pojedynczego zadania. Możliwość pokrycia go ze środków publicznych zależy od projektu, programu i warunków wyboru dostawcy.
Zapraszamy do takiej rozmowy. Warto wskazać zakres integratora i brakujące zadanie, aby ustalić odpowiedzialność, dostęp i sposób odbioru bez powielania prac.
Nie. Trzeba potwierdzić rolę, kwalifikowalność, budżet i zasady uczestnictwa. Samo wpisanie nazwy do koncepcji nie ustanawia prawa do grantu ani umowy na realizację.
Nie. Materiały potwierdzają wykonanie ustalonego zakresu. Ocena kwalifikowalności zależy również od zasad programu, wyboru wykonawcy, kosztów i warunków umowy grantowej.
Projekt z dofinansowaniem może potrzebować nie tylko technologii, ale również ludzi, procedur i sprawdzenia wyników. W tych obszarach warto zaplanować udział CCyber już podczas budowania zakresu lub przy realizacji zatwierdzonych zadań.
Określ rezultat, wybierz właściwą formę współpracy i połącz wykonanie z dowodami. Szkolenie, wydzielony moduł wdrożenia lub wsparcie konsorcjum powinny odpowiadać rzeczywistej potrzebie projektu, a nie tylko dostępnej pozycji w budżecie.
NIS2 Diagnoza czy Gotowość? Koszt, zakres i proces wdrożenia
Czy firma potrzebuje najpierw oceny gotowości do NIS2, czy wsparcia we wdrożeniu? Porównujemy dwa warianty: NIS2 Diagnoza i NIS2 Gotowość. Pokazujemy proces od spotkania otwierającego przez analizę dokumentów i systemów po raport oraz realizację działań. Wyjaśniamy orientacyjne ceny, ramy czasowe i warunki, które trzeba uzgodnić przed rozpoczęciem współpracy. Przykład procedury incydentowej pokazuje różnicę między wykryciem luki a potwierdzeniem, że została usunięta.
Opracowanie: Zespół redakcyjny CCyber
NIS2 Diagnoza pomaga ustalić, czego firmie brakuje i jakie działania są potrzebne. NIS2 Gotowość obejmuje również przełożenie planu na uzgodnione wdrożenia. Wybór zależy przede wszystkim od tego, czy organizacja zna swój stan i potrafi samodzielnie przeprowadzić poprawki.
W obu wariantach warto zacząć od określenia zakresu, odpowiedzialności i sposobu sprawdzenia rezultatów. Diagnoza nie powinna kończyć się listą ogólnych uwag, a wdrożenie nie powinno być uznane za zakończone wyłącznie dlatego, że przygotowano dokumenty.
Różnica jest praktyczna: po diagnozie wiesz, co zrobić. Po wykonaniu i sprawdzeniu uzgodnionych działań możesz wykazać, co zostało poprawione.
20 września 2026 r.
Nazwy wariantów, cztery etapy procesu oraz przedziały cen i czasu pochodzą z opisu modelu usług będącego podstawą artykułu. Nie są badaniem stawek rynkowych ani wiążącą wyceną każdej organizacji. Zakres rezultatów, kryteria odbioru i przykład poniżej stanowią propozycję CCyber do uzgodnienia w ofercie.
Dla właścicieli firm, zarządów, kierowników IT i osób koordynujących przygotowanie do NIS2 oraz polskiej ustawy o krajowym systemie cyberbezpieczeństwa, czyli KSC. Szczególnie dla organizacji, które porównują oferty doradcze, mają już część dokumentacji albo potrzebują wsparcia we wdrożeniu znalezionych wcześniej zaleceń.
Przed oceną stanu firmy trzeba określić właściwą podstawę wymagań. Dla polskiej organizacji oznacza to sprawdzenie działalności, kryteriów podlegania KSC, statusu podmiotu i mających zastosowanie przepisów szczególnych. Takie podejście wskazuje Ministerstwo Cyfryzacji w informacji o obowiązkach podmiotów kluczowych i ważnych.
Analiza podlegania i analiza luk to różne zadania. Pierwsza odpowiada na pytanie, które obowiązki dotyczą organizacji. Druga porównuje jej stan z ustalonymi wymaganiami. W ofercie powinno być jasne, czy ocena podlegania jest częścią usługi, czy opiera się na wcześniej przygotowanej analizie.
Punkt wyjścia opisuje również poradnik „Czy moja firma podlega NIS2?” w kategorii Cyberbezpieczeństwo dla MŚP.
Celem jest szybkie zrozumienie organizacji i ustalenie sposobu pracy. Warto omówić usługi, ważne systemy, dostawców, istniejącą dokumentację i oczekiwany rezultat. Potrzebna jest również informacja, kto może udzielać odpowiedzi oraz zatwierdzać decyzje.
Proponowany rezultat: potwierdzony zakres, lista materiałów, osoby kontaktowe i harmonogram. Godzinne spotkanie nie zastępuje szczegółowej analizy podlegania ani przeglądu całego środowiska.
W opisie procesu assessment oznacza etap oceny. Materiały są porównywane z ustalonymi wymaganiami, a deklaracje zestawiane z dostępnymi informacjami o działaniu systemów i procesów.
Proponowany zakres do uzgodnienia: przegląd polityk, rejestrów, raportów i wybranych konfiguracji oraz wyjaśnienie rozbieżności z osobami odpowiedzialnymi. Badanie powinno wskazywać, co potwierdzono, czego nie wdrożono i czego nie można było sprawdzić.
Ramy 3-5 dni nie są obietnicą pełnego przetestowania wszystkich aplikacji i lokalizacji. Assessment nie oznacza automatycznie testu penetracyjnego, aktywnego skanowania ani zmian w systemach produkcyjnych. Takie czynności wymagają odrębnie uzgodnionego zakresu i zasad bezpieczeństwa.
Raport powinien pozwolić zdecydować, co poprawić, dlaczego i w jakiej kolejności. Rekomendacja „zwiększyć bezpieczeństwo dostępu” jest zbyt ogólna, jeżeli nie wskazuje systemu, problemu i oczekiwanego wyniku.
Proponowany rezultat: podsumowanie dla kierownictwa, lista luk z uzasadnieniem oraz plan działań. Przy zadaniu warto wskazać właściciela, zależności, termin i sposób sprawdzenia naprawy. Ustal także, które wnioski wymagają dodatkowej weryfikacji.
Po diagnozie organizacja może wykonać działania własnym zespołem lub uzgodnić dalsze wsparcie. W przedstawionym modelu ten szerszy etap odpowiada wariantowi NIS2 Gotowość.
Nie chodzi wyłącznie o przekazanie kolejnych rekomendacji. Zakres powinien rozdzielać przygotowanie zasad, konfigurację, koordynację prac i sprawdzenie efektu. Każda ze stron musi wiedzieć, co wykonuje konsultant, co administrator, a co wymaga decyzji kierownictwa.
Proponowany rezultat: wdrożone i zweryfikowane działania w uzgodnionym zakresie oraz przekazanie ich do utrzymania. Czynności pozostające poza projektem powinny być nazwane, a nie ukryte pod ogólnym statusem „gotowe”.
Zakres modelu: ocena gotowości do NIS2 oraz identyfikacja luk, ryzyk i wymaganych działań.
Orientacyjny budżet: 10 000-20 000 zł.
Ramy czasowe: 5-30 dni.
Ten wariant odpowiada na potrzebę: „Nie wiemy, gdzie jesteśmy i ile pracy nas czeka”. Może być punktem wyjścia do decyzji o budżecie, podziale zadań lub zamówieniu konkretnych wdrożeń.
Jest też wart rozważenia, gdy firma posiada dokumentację, ale nie sprawdziła jej zgodności z rzeczywistymi procesami. Wówczas celem nie powinno być automatyczne przepisywanie materiałów od początku, lecz ustalenie, co pozostaje użyteczne i czego brakuje.
Granica wariantu: wykrycie luki nie oznacza jej naprawy. Raport może pomóc przygotować program, ale sam nie uruchamia zabezpieczeń ani nie potwierdza pełnej zgodności.
Zakres modelu: przygotowanie organizacji do wymagań NIS2 poprzez praktyczne rekomendacje, plan działań i uzgodnione wdrożenie.
Orientacyjny budżet: 15 000-40 000 zł.
Ramy czasowe: 1-12 miesięcy.
Ten wariant odpowiada na potrzebę: „Znamy część braków, ale potrzebujemy pomocy, aby je usunąć i uporządkować realizację”. Plan działań, często nazywany roadmapą, powinien wskazywać kolejność prac i ich zależności.
Przykładowy zakres może obejmować aktualizację procedury, wdrożenie uzgodnionych zasad dostępu albo przygotowanie i sprawdzenie procesu reagowania. Konkretne zadania, liczba objętych systemów i udział wykonawców muszą wynikać z oferty.
Nazwa „Gotowość” określa cel pracy, nie bezwarunkową gwarancję wyniku kontroli. Trzeba wskazać, jakie wymagania objęto projektem i na jakich dowodach opiera się ocena. Zakup pakietu nie oznacza automatycznie wykonania wszystkich obowiązków organizacji.
Opis procesu podaje 3-5 dni dla analizy, a opis Diagnozy 5-30 dni. Nie określa jednak, czy chodzi o dni robocze, kalendarzowe lub nakład pracy zespołu. Nie należy tych wartości utożsamiać ani samodzielnie sumować.
Do uzgodnienia w ofercie: początek biegu terminu, oczekiwany termin raportu, czas na dostarczenie materiałów i konsultację ustaleń. Rozdzielenie czasu pracy analitycznej od czasu kalendarzowego projektu jest użyteczne, ale musi zostać potwierdzone w harmonogramie.
W przedstawionym modelu nie określono statusu VAT. Dlatego kwoty 10 000-20 000 zł i 15 000-40 000 zł należy traktować jako orientacyjne ramy wymagające doprecyzowania. Indywidualna oferta powinna jednoznacznie wskazywać cenę, VAT i sposób rozliczenia.
Nie ma również potwierdzenia, czy koszt Diagnozy jest zawarty w Gotowości, odliczany od niej czy rozliczany osobno. Nie należy więc automatycznie dodawać cen ani przedstawiać niższej sumy jako uzgodnionego rabatu.
Przed zakupem ustal, czy wycena obejmuje licencje, sprzęt, pracę dotychczasowego dostawcy IT, testy, dojazdy i późniejsze utrzymanie. Opisane widełki nie rozstrzygają tych kwestii.
Zakres 1-12 miesięcy nie oznacza nieograniczonego zaangażowania zespołu w tej samej cenie. Oferta powinna określać zadania, dostępność, odbiory i sposób zatwierdzania zmian. Przy większym zakresie potrzebna może być inna wycena.
Dla organizacji spełniających kryteria w dniu wejścia w życie nowelizacji, czyli 3 kwietnia 2026 r., właściwy okres dostosowawczy przewiduje wdrożenie obowiązków do 3 kwietnia 2027 r. Podmioty zobowiązane do samorejestracji muszą uwzględnić termin 3 października 2026 r. Szczegóły podaje oficjalny harmonogram Ministerstwa Cyfryzacji.
Dwunastomiesięczny projekt rozpoczynany jesienią 2026 r. nie może zakładać, że wymagane na kwiecień 2027 r. działania zostaną wykonane dopiero na jego końcu. Podobnie oczekiwanie na raport Diagnozy nie uzasadnia pominięcia wcześniejszego terminu rejestracji.
Rekomendacja CCyber: oddziel działania wymagane przed właściwym terminem od późniejszego utrzymania i doskonalenia. Dla organizacji objętych innym trybem lub spełniających kryteria później harmonogram trzeba ustalić osobno.
Wyznacz jednego koordynatora, który zbierze materiały i przekaże pytania właściwym osobom. Nie musi sam znać każdej konfiguracji. Powinien wiedzieć, kto może ją potwierdzić i kto zatwierdza decyzję.
Na początek przygotuj: opis działalności i ważnych usług, listę systemów oraz dostawców, istniejące polityki, rejestr ryzyka i wyniki wcześniejszych przeglądów. Jeżeli materiałów brakuje, oznacz ten fakt. Nie twórz pozornych dowodów tylko po to, aby wypełnić listę.
Do pytań technicznych można przygotować aktualne raporty lub kontrolowane prezentacje konfiguracji. Dostęp bezpośredni, wizyta na miejscu i testy powinny wynikać z potrzeb oraz uzgodnionego zakresu. Sama możliwość przeprowadzenia rozmowy online nie oznacza, że każdą ocenę da się wykonać w pełni zdalnie.
Ustal bezpieczne repozytorium, osoby uprawnione i zasady zakończenia dostępu. Nie wysyłaj haseł, kluczy prywatnych ani pełnych baz klientów jako zwykłych załączników do wstępnej rozmowy.
Proponujemy raport wskazujący zakres i datę oceny, podstawy wymagań, potwierdzone ustalenia, obszary niesprawdzone oraz listę działań. Każdy istotny brak powinien mieć opis skutku i proponowany sposób usunięcia.
Nie myl braku dowodu z dowodem braku zabezpieczenia. Jeżeli wykonawca nie otrzymał konfiguracji, właściwym wynikiem może być „niezweryfikowane”, a nie automatycznie „spełnione” lub „niespełnione”.
Uzgodnij, jakie materiały potwierdzą wykonanie: zatwierdzona procedura, konfiguracja, wynik testu albo zapis przeprowadzonego procesu. Po zakończeniu projektu powinno być wiadomo, kto utrzymuje zabezpieczenie i kiedy trzeba je sprawdzić ponownie.
Przykłady dowodów i mapowanie wymagań zawiera ENISA NIS2 Technical Implementation Guidance. Materiał wspiera wdrażanie rozporządzenia 2024/2690 dla wskazanych podmiotów. Nie jest automatycznie pełną checklistą dla każdej organizacji objętej KSC.
Rozdziel „zaplanowane”, „wdrożone” i „sprawdzone”. Przy braku określ dalszą decyzję, właściciela i termin. Ukończenie 90% zadań projektu nie oznacza samo w sobie 90% zgodności z ustawą, zwłaszcza gdy pozostała luka dotyczy istotnej usługi.
Przykład modelowy CCyber. Firma usługowa ma dokument opisujący reagowanie na incydenty. Wskazano w nim administratora, lecz nie ustalono zastępstwa ani sposobu kontaktu przy niedostępności firmowej poczty.
W Diagnozie zespół opisuje lukę, jej zakres i możliwy skutek: opóźnienie rozpoczęcia reakcji. Rekomenduje wyznaczenie zastępstwa, uzgodnienie kanału kontaktu i sprawdzenie działania. Na tym etapie problem został rozpoznany, ale jeszcze nie usunięty.
W Gotowości organizacja i wykonawca realizują uzgodnione zadania. Kierownictwo zatwierdza odpowiedzialność, dostawca potwierdza dostępność, a procedura otrzymuje aktualne kontakty. Następnie odbywa się zapowiedziane ćwiczenie bez przesyłania fikcyjnego incydentu do produkcyjnego kanału organu.
Kryterium odbioru: właściwa osoba odbiera zgłoszenie, rozumie swoją rolę i uruchamia uzgodnione działania w przyjętym czasie. Wynik dotyczy sprawdzonego scenariusza, nie wszystkich możliwych incydentów.
Przygotowanie podobnych ćwiczeń rozwijamy w kategorii Reagowanie na incydenty i ciągłość działania.
Konsultant może analizować, rekomendować i wykonywać uzgodnione zadania. Firma nadal musi podejmować decyzje, zapewniać udział właściwych osób i utrzymywać wdrożone procesy.
Zlecenie prac nie usuwa ustawowej odpowiedzialności kierownictwa. Art. 8c-8d KSC obejmują odpowiedzialność także przy powierzaniu obowiązków innym osobom oraz zadania związane z decyzjami, zasobami i nadzorem.
Dlatego w planie przypisz osobno wykonawcę, osobę zatwierdzającą i właściciela utrzymania. Nie wpisuj „konsultant” przy każdym zadaniu, którego wykonanie zależy od dostawcy systemu lub decyzji biznesowej.
W kategorii Regulacje cyber UE i zgodność znajdziesz rozwinięcia obowiązków i przygotowania dowodów. Ten artykuł pomaga wybrać zakres współpracy i ustalić warunki realizacji, zamiast powtarzać całą checklistę NIS2.
Program zgodności NIS2 CCyber obejmuje analizę luk, ocenę dojrzałości, plan działań oraz wsparcie wdrażania polityk, procedur i kontroli. Zakres współpracy można oprzeć na rozpoznaniu stanu organizacji albo na realizacji uzgodnionych poprawek.
Wybierz potrzebny rezultat: diagnozę sytuacji czy pomoc we wdrożeniu. Do rozmowy przygotuj opis działalności, ważne systemy, obecny stan prac i termin, który obowiązuje firmę. Pozwoli to określić zakres, sposób liczenia czasu, pełną cenę i zasady odbioru, zanim rozpocznie się projekt.
Nie automatycznie. Audyt z art. 15 KSC ma określone warunki dotyczące wykonawców i niezależności. Ocena gotowości oraz wsparcie wdrożenia nie stają się nim przez zmianę nazwy usługi. W ofercie trzeba jednoznacznie wskazać rodzaj badania.
W przedstawionym modelu wsparcie wdrożenia jest opcjonalne. Warto uzgodnić format raportu i poziom szczegółowości zaleceń, aby własny zespół lub inny wykonawca mogli przełożyć je na zadania.
Nie należy tego zakładać. Najpierw sprawdź zakres, aktualność wymagań, jakość dowodów i zmiany w środowisku. Wcześniejsza praca może zostać wykorzystana, ale nie powinna być uznawana za aktualną wyłącznie na podstawie daty dokumentu.
Nie ma podstaw do takiej bezwarunkowej obietnicy. Można określić rezultaty, kryteria odbioru i dowody dla uzgodnionego zakresu. Organ ocenia właściwe obowiązki i stan organizacji, nie sam fakt zakupienia pakietu.
Uzgodnij sposób szybkiego powiadomienia i osobę podejmującą decyzję. Istotnego zagrożenia lub podejrzenia incydentu nie należy odkładać do przekazania końcowego raportu. Działania techniczne nadal wymagają oceny wpływu i odpowiednich uprawnień.
NIS2 Diagnoza pomaga podjąć decyzję na podstawie rozpoznanych luk. NIS2 Gotowość dodaje realizację uzgodnionych zmian. Cztery etapy współpracy porządkują przejście od poznania organizacji do raportu i ewentualnego wdrożenia.
Porównuj oferty przez zakres, odpowiedzialność i rezultat, nie tylko cenę lub liczbę dni. Dobrze uzgodniony projekt pokazuje, co zostało sprawdzone, co poprawiono i jakie działania nadal pozostają po stronie organizacji.
Czego oczekuje regulator? Zabezpieczenia i dokumentacja firmy
ISMS, zarządzanie ryzykiem, IAM, ochrona kluczy, pentesty, Disaster Recovery, ciągłość działania, SOC i obsługa incydentów: jak połączyć te obszary w spójny program? Wyjaśniamy, co warto przygotować do oceny regulacyjnej, jak rozdzielić wymagania prawne od sposobu ich realizacji i jakie znaczenie mają dokumenty. Pokazujemy rolę rejestrów ryzyka, RACI, matryc kontroli i raportów technicznych. Przykład odtwarzania zaszyfrowanej bazy ujawnia, dlaczego osobne polityki nie zastępują sprawdzenia całej usługi.
Opracowanie: Zespół redakcyjny CCyber
Przygotowanie do oceny regulatora polega na wykazaniu, że organizacja rozpoznaje właściwe obowiązki, zarządza ryzykiem i realizuje wymagane działania. Dokumentacja powinna wyjaśniać zasady oraz potwierdzać ich wykonanie. Nie wystarczy lista zakupionych narzędzi ani folder podpisanych polityk.
ISMS, IAM, zarządzanie kluczami, testy, odtwarzanie i monitoring trzeba powiązać z konkretnymi usługami oraz odpowiedzialnością. Jednocześnie nie wolno zakładać, że każda instytucja musi mieć identyczny SOC, wykonywać taki sam pentest i przygotować taką samą liczbę dokumentów.
Najpierw ustal wymaganie. Następnie określ sposób realizacji i dowód, który rzeczywiście potwierdza wynik.
20 września 2026 r.
Artykuł rozwija przekazaną notatkę, zachowując jej dziesięć obszarów bezpieczeństwa oraz temat dokumentacji. Notatka nie wskazuje konkretnego regulatora, jurysdykcji ani rodzaju giełdy. Przykłady wymagań NIS2, KSC i DORA stanowią uzupełnienie oparte na źródłach urzędowych, a nie przypisanie wszystkich tych regulacji każdemu czytelnikowi.
Pytania do przeglądu, przykłady dowodów i model dokumentacji są propozycją CCyber. Nie są urzędową checklistą ani kompletnym katalogiem obowiązków.
Dla zarządów, kierowników instytucji, CISO, zespołów IT, compliance i audytu. Szczególnie dla organizacji przygotowujących wdrożenie regulacyjne, postępowanie licencyjne, kontrolę lub przegląd wewnętrzny oraz firm zamawiających dokumentację i usługi bezpieczeństwa.
Określenie „regulator oczekuje” wymaga wskazania podstawy. Wymagania mogą wynikać z ustawy, rozporządzenia, warunków zezwolenia, decyzji nadzorczej lub właściwych wytycznych. Zobowiązanie wobec klienta i dobrowolnie przyjęta norma to odrębne źródła.
NIS2 przewiduje odpowiednie i proporcjonalne środki zarządzania ryzykiem. W Polsce właściwe obowiązki trzeba ustalać na podstawie KSC. DORA dotyczy określonych podmiotów finansowych i zawiera również szczególne zasady oraz wyłączenia. Nie stosuj wszystkich tych wymagań łącznie bez analizy zakresu.
Sama nazwa „giełda” nie wystarcza do ustalenia reżimu prawnego. Trzeba wiedzieć, jaki podmiot prowadzi działalność, jakie usługi świadczy, na jakiej podstawie i w jakiej jurysdykcji. Nie należy utożsamiać infrastruktury rynku kapitałowego z każdą platformą wymiany lub handlu.
Przygotuj rejestr: podmiot, usługa, obowiązek, podstawa, termin i właściciel. Ten krok ogranicza zarówno pomijanie wymagań, jak i zamawianie prac, których znaczenia nikt nie potrafi uzasadnić.
ISMS, czyli Information Security Management System, to po polsku SZBI. ISO/IEC 27001 opisuje ustanowienie, wdrożenie, utrzymanie i doskonalenie takiego systemu. Obejmuje on ludzi, procesy i technologię, nie tylko dokument zatytułowany „Polityka bezpieczeństwa”. Zakres wyjaśnia ISO.
Wdrożenie SZBI jest również wskazane w obowiązkach właściwych podmiotów KSC. Nie należy utożsamiać tego automatycznie z obowiązkiem posiadania certyfikatu ISO.
Do sprawdzenia: zakres systemu, odpowiedzialność kierownictwa, cele, przeglądy i sposób usuwania braków. Proponowany materiał dowodowy to zatwierdzone zasady wraz z decyzjami i zapisami wykonania, nie sama deklaracja wdrożenia.
Art. 21 NIS2 łączy zabezpieczenia z ryzykiem, skalą działalności i możliwymi skutkami incydentu. Nie sprowadza oceny do liczby podatności ani zakupu określonego produktu. Podstawę stanowi dyrektywa NIS2.
Do sprawdzenia: czy ryzyko opisuje możliwe zdarzenie i konsekwencję dla usługi, czy ma właściciela oraz decyzję o dalszym postępowaniu? Wpis „brak MFA” wskazuje lukę. Nie wyjaśnia jeszcze, jakie uprawnienia można przejąć i co to oznacza dla organizacji.
W proponowanym rejestrze połącz scenariusz z działaniem, terminem i oceną ryzyka pozostającego po wdrożeniu zabezpieczeń. Zgoda na pozostawienie ryzyka nie powinna być używana jako zastępstwo wykonania obowiązku prawnego.
IAM to zarządzanie tożsamością i dostępem. Dla podmiotów objętych odpowiednimi wymaganiami DORA art. 20-21 rozporządzenia delegowanego 2024/1774 określają zasady identyfikacji oraz kontroli uprawnień, w tym cyklu życia kont. To konkretny przykład regulacyjny, nie obowiązek zakupu produktu o nazwie IAM.
Do sprawdzenia: kto zatwierdza dostęp, jak obsługiwane są zmiany roli i odejścia oraz czy kontrola obejmuje administratorów, dostawców i konta aplikacji.
Proponowany dowód powinien łączyć wniosek, decyzję, konfigurację oraz sprawdzenie odebrania dostępu. Sam raport aktywnych kont nie wyjaśnia, czy wszystkie są potrzebne. Szczegóły rozwijamy w kategorii Tożsamość, dostęp i bezpieczeństwo chmury.
Stwierdzenie „dane są szyfrowane” nie opisuje zarządzania kluczami. Art. 6-7 rozporządzenia 2024/1774 obejmują, w odpowiednim zakresie DORA, zasady kryptografii oraz cykl życia kluczy: od utworzenia i przechowywania po odnowienie, unieważnienie i zniszczenie.
Do sprawdzenia: kto może użyć klucza, jak wykrywana jest utrata lub nieuprawnione użycie i jak zostanie odzyskana możliwość odszyfrowania danych po awarii.
Proponowane dowody to rejestr odpowiedzialności, konfiguracja dostępów i wynik kontrolowanego testu. W dokumentacji audytowej wskazuj identyfikatory oraz lokalizację chronionego materiału, nie wartości kluczy prywatnych ani haseł.
Pentest, audyt zgodności i skan podatności nie są tym samym. W DORA testy penetracyjne są jednym z rodzajów testowania. Zaawansowane testy oparte na informacjach o zagrożeniach, czyli TLPT, dotyczą wyznaczonych podmiotów. Zakres określają art. 24-26 DORA.
Do sprawdzenia: czy test obejmuje właściwą usługę, czy wykonawca ma uzgodniony zakres i czy ustalenia prowadzą do naprawy oraz ponownej weryfikacji.
Proponowany komplet to zakres testu, raport, decyzje dotyczące ustaleń i wyniki sprawdzenia poprawek. Faktura za pentest nie potwierdza usunięcia podatności. Testy mogące zakłócić produkcję wymagają odrębnych uzgodnień i zabezpieczeń.
Disaster Recovery, czyli DR, dotyczy odzyskiwania zdolności technicznych po poważnym zakłóceniu. Powiązania planów odtwarzania z szerszym planowaniem awaryjnym opisuje NIST SP 800-34 Rev. 1. Jest to wskazówka techniczna, nie uniwersalny polski wymóg prawny.
Do sprawdzenia: czy plan obejmuje aplikacje, dane, konfiguracje, tożsamości, klucze i zależności od dostawców? Ustal docelowy czas odzyskania oraz akceptowalną utratę aktualności danych.
Proponowany dowód to odtworzenie w uzgodnionym środowisku i potwierdzenie użyteczności wyniku. Poprawne wykonanie kopii zapasowej nie jest jeszcze takim testem.
Business Continuity, czyli ciągłość działania, odpowiada na szersze pytanie: jak organizacja utrzyma potrzebne funkcje podczas zakłócenia? NIST opisuje między innymi alternatywne lokalizacje, sprzęt i tymczasowe sposoby realizacji procesów w materiałach o planowaniu awaryjnym.
Do sprawdzenia: priorytety usług, potrzebni ludzie, zastępstwa, komunikacja i dopuszczalne ograniczenia pracy. W razie potrzeby plan powinien określać również warunki bezpiecznego wstrzymania usługi.
Proponowany dowód to ćwiczenie z właścicielem procesu. Nie uznawaj działającego serwera za potwierdzenie ciągłości, jeżeli użytkownicy nadal nie mogą obsłużyć klientów lub wykonać wymaganej operacji.
SOC, czyli Security Operations Centre, to sposób organizacji operacji bezpieczeństwa. Sama notatka nie wskazuje podstawy obowiązku prowadzenia własnego centrum przez każdą firmę.
Przykładowo punkt 3.2 załącznika do rozporządzenia 2024/2690 wymaga monitorowania, logowania i właściwej reakcji od podmiotów objętych tym aktem. Nie należy rozszerzać jego szczegółowego zakresu na wszystkie organizacje.
Do sprawdzenia: źródła logów, pokrycie systemów, godziny obsługi, eskalacja i uprawnienia do reakcji. Własny zespół i usługa zewnętrzna wymagają jasnego podziału zadań. Proponowany dowód to kontrolowany test od zdarzenia do działania, nie tylko wykres liczby alertów.
Skan dostarcza informacji, ale nie zastępuje zarządzania podatnościami. W szczególności aktualizacje wymagają identyfikacji, ustalenia priorytetu, wdrożenia i sprawdzenia rezultatu. Taki proces opisuje NIST SP 800-40 Rev. 4.
Do sprawdzenia: czy wynik można powiązać z właścicielem systemu i jego znaczeniem dla usługi? Czy terminy napraw, wyjątki i środki tymczasowe mają uzasadnienie?
Proponowany dowód to połączone zgłoszenia wykrycia i zmiany oraz ponowna weryfikacja. Zamknięcie zadania przez wykonawcę nie powinno automatycznie oznaczać, że problem już nie występuje.
Przygotowanie do incydentów powinno być połączone z zarządzaniem ryzykiem, wykrywaniem i odtwarzaniem. Takie podejście opisuje NIST SP 800-61 Rev. 3.
Do sprawdzenia: kto ocenia zdarzenie, ogranicza skutki, zabezpiecza informacje i podejmuje decyzje biznesowe? Osobno przypisz obowiązki zewnętrznego zgłaszania, z właściwymi przesłankami, odbiorcami i terminami.
Proponowany dowód to oś czasu rzeczywistego incydentu albo wyraźnie oznaczonego ćwiczenia. Sam numer telefonu do dostawcy nie potwierdza gotowości organizacji. Praktykę ćwiczeń rozwijamy w kategorii Reagowanie na incydenty i ciągłość działania.
W przekazanej notatce pojawia się taki przedział, ale bez źródła, opisu organizacji i sposobu liczenia. Nie traktujemy go jako potwierdzonego standardu branżowego ani wymogu prawnego.
Do jednej liczby można wliczyć politykę nadrzędną, instrukcje dla kilkudziesięciu systemów, formularze, załączniki i lokalne warianty. Bez wspólnej definicji porównanie liczby plików niewiele mówi o zakresie i jakości.
Nie oznacza to, że dokumentacja jest zbędna. Wymagana polityka lub procedura pozostaje obowiązkiem, nawet gdy zabezpieczenie techniczne działa. Z drugiej strony rozbudowany katalog dokumentów nie potwierdza wykonania opisanych czynności.
Lepsze kryterium zakupu: wymagaj listy obowiązków, dokumentów i rezultatów, które mają zostać dostarczone, zamiast oferty „pakiet 200 procedur”.
Poniżej proponujemy strukturę łączącą polityki bezpieczeństwa, rejestry ryzyka, opisy procesów, RACI, matryce kontroli, procedury operacyjne i raporty techniczne. To model organizacyjny, nie narzucony przez wszystkie regulacje układ folderów.
Opisują cele, zakres, odpowiedzialność i reguły. Przykładowo polityka dostępu określa, kto może zatwierdzać uprawnienia i jak traktować wyjątki. Nie musi zawierać instrukcji kliknięć dla każdej aplikacji.
Rejestr ryzyka wyjaśnia, czym organizacja musi zarządzać. Opis procesu pokazuje przebieg pracy, wejścia, decyzje, wykonawców i wynik. Połącz je, aby wiadomo było, dlaczego określona czynność jest potrzebna.
RACI rozdziela wykonawcę zadania, osobę odpowiedzialną za rezultat, osoby konsultowane i informowane. Znaczenie ról przedstawia między innymi oficjalny materiał Section508.gov. Wykorzystujemy go wyłącznie jako wyjaśnienie metody, nie podstawę obowiązków cyberbezpieczeństwa.
W praktycznym zastosowaniu wskaż, kto zatwierdza pilne odebranie dostępu i kto je wykonuje. Wpisanie „IT” w każdą komórkę nie rozstrzyga współpracy między administratorem, dostawcą i właścicielem usługi. RACI nie przenosi odpowiedzialności ustawowej.
Łączą wymaganie, zabezpieczenie, zakres, właściciela, sposób sprawdzenia i dowód. Jedna kontrola może wspierać kilka obowiązków, ale tylko w zakresie, który rzeczywiście realizuje.
ENISA publikuje przykłady dowodów i mapowanie wymagań dla wdrażania rozporządzenia 2024/2690. Materiał jest pomocny, lecz jego zakres nie jest uniwersalnym katalogiem dla każdej firmy i instytucji.
Wyjaśniają, jak wykonać czynność: odebrać dostęp, odnowić klucz, odtworzyć usługę albo eskalować alert. Powinny wskazywać warunki rozpoczęcia, uprawnienia, kolejne działania i sposób zakończenia. Warto sprawdzić je z osobą, która faktycznie ma ich używać.
Pokazują stan lub wynik: konfigurację, wykonany przegląd, ustalenia pentestu, przebieg incydentu lub odtwarzania. Opis powinien wskazywać datę, zakres, ograniczenia i dalsze działania. Raport bez decyzji o istotnych ustaleniach pozostawia otwarte zadanie.
Rekomendujemy powiązanie: wymaganie → ryzyko → zasada → procedura → wykonanie → wynik → działanie naprawcze.
Każdy dokument powinien mieć właściciela, zakres, wersję, status zatwierdzenia i zasady przeglądu. Zmiana usługi powinna uruchamiać ocenę powiązanych materiałów, nie tylko aktualizację daty na stronie tytułowej.
Przy konsolidacji nie usuwaj wymaganej treści w imię skracania dokumentacji. Można ograniczyć duplikaty, ale trzeba zachować właściwe zatwierdzenia, zakres i możliwość odtworzenia wcześniejszych decyzji.
Ustal również uprawnienia i retencję materiałów. Dokumentacja może zawierać informacje o słabościach, dostawcach i architekturze. Przekazuj ją organowi zgodnie z właściwym żądaniem i bezpiecznym kanałem, bez dokładania zbędnych sekretów lub danych.
Przykład modelowy CCyber. Organizacja ma politykę szyfrowania, plan Disaster Recovery i raport poprawnie wykonanej kopii bazy. Każdy dokument przeszedł osobne zatwierdzenie.
W uzgodnionym teście okazuje się, że zespół odtwarzający nie ma dostępnej ścieżki użycia klucza potrzebnego do odszyfrowania. Dostęp zależy od usługi tożsamości, która w scenariuszu awarii również jest niedostępna. W rezultacie kopia nie pozwala wznowić działania w zakładanym czasie.
Firma aktualizuje zależności, uprawnienia awaryjne, odpowiedzialność za klucze i instrukcję odtwarzania. Następnie powtarza kontrolowany test i uzyskuje potwierdzenie działania aplikacji od właściciela biznesowego. Nie rozwiązuje problemu przez zapisanie klucza w ogólnodostępnym dokumencie.
Wniosek: osobne potwierdzenia szyfrowania, backupu i IAM nie wystarczają do wykazania, że cały scenariusz odzyskiwania działa.
Ustal podstawę i zakres. Wskaż właściwy reżim, etap oceny oraz systemy i usługi. Innego materiału może wymagać postępowanie przed uruchomieniem usługi, a innego weryfikacja kilku miesięcy jej działania. Nie przedstawiaj planowanego wdrożenia jako już wykonanego.
Wybierz przekrojowy scenariusz. Przejdź przez jedną ważną usługę, uwzględniając dostęp, klucze, monitoring, incydent i odzyskiwanie. Taki przegląd nie zastępuje wymaganego pełnego zakresu, ale pomaga wykryć niespójności.
Sprawdź dokumenty i wykonanie oddzielnie. Rozróżnij brak zasad, brak wdrożenia, brak dowodu i negatywny wynik testu. To różne problemy wymagające różnych działań.
Zatwierdź plan naprawczy. Każdy istotny brak powinien mieć właściciela, termin i sposób ponownej oceny. Plan naprawczy dokumentuje reakcję, ale nie zmienia automatycznie niezgodności w zgodność.
Szczegółowe zagadnienia obowiązków, deklaracji stosowania i przygotowania dowodów rozwijamy w kategorii Regulacje cyber UE i zgodność. Ten artykuł pomaga połączyć zakres bezpieczeństwa z dokumentacją, zamiast zastępować szczegółowy poradnik wdrożeniowy.
W ramach wsparcia zgodności z regulacjami UE CCyber oferuje analizę luk, przygotowanie i aktualizację polityk, mapowanie odpowiedzialności oraz uporządkowanie rejestrów i materiałów audytowych.
Sprawdź, czy Twoja dokumentacja odpowiada rzeczywistemu sposobowi działania. Do określenia zakresu przeglądu przygotuj listę obowiązków, ważnych usług i otwartych problemów. Celem powinien być plan usunięcia konkretnych luk, a nie powiększenie liczby plików.
Nie należy wyprowadzać takiego obowiązku z samej potrzeby monitorowania. Sprawdź właściwe przepisy, wymagany zakres i dostępność reakcji. Sposób organizacji może obejmować własny zespół lub usługę zewnętrzną, o ile spełnia odpowiednie wymagania.
Zakres i częstotliwość trzeba ustalić na podstawie mających zastosowanie przepisów, ryzyka i zmian. DORA rozróżnia program testowania i zaawansowane TLPT. Nie przenoś jednego harmonogramu na każdą organizację i każdy system.
Nie. Certyfikat dotyczy określonego zakresu systemu zarządzania. Nadal trzeba sprawdzić właściwe obowiązki prawne, w tym te dotyczące rejestracji, zgłoszeń lub szczególnych wymagań sektorowych.
Może być punktem wyjścia, ale trzeba dopasować treść do usług, ról i konfiguracji. Przed zatwierdzeniem sprawdź, czy organizacja potrafi wykonać opisane czynności i czy nie deklaruje zabezpieczeń, których nie wdrożyła.
Nie. To zakres przekazanej notatki. W pełnej analizie mogą być potrzebne również inne obszary, na przykład zasoby, dostawcy, szkolenia, bezpieczeństwo fizyczne lub tworzenie oprogramowania. Każde rozszerzenie powinno wynikać z właściwych wymagań i ryzyka.
Przygotowanie do regulatora wymaga połączenia zarządzania, technologii i dokumentacji. ISMS, ryzyko, IAM, klucze, testy, DR, ciągłość, monitoring, podatności i reagowanie powinny tworzyć współpracujące procesy.
Nie zaczynaj od liczby dokumentów. Zacznij od pytania, co organizacja musi umieć zrobić i jak to wykaże. Dokumentacja ma pomagać wykonać obowiązek i sprawdzić rezultat, a nie zastępować działanie.
Zmiany NIS2 w 2026 r.: co mogą oznaczać dla MŚP?
Komisja Europejska proponuje uproszczenia NIS2 dotyczące wymagań technicznych, raportowania ransomware, certyfikacji, nadzoru i zakresu regulacji. Wyjaśniamy, które zmiany mogą pomóc MŚP, czym small mid-cap różni się od małego lub średniego przedsiębiorstwa i dlaczego projekt nie przesuwa obecnych terminów KSC. Artykuł zawiera przykład firmy analizującej możliwe wyłączenie oraz kartę zmiany regulacyjnej. Pokazujemy, jak przygotować się na reformę bez przedwczesnego zatrzymywania wdrożenia.
Opracowanie: Zespół redakcyjny CCyber
Proponowane zmiany NIS2 mogą ograniczyć część obciążeń administracyjnych i zmienić klasyfikację niektórych przedsiębiorstw. Nie są jednak powszechnym zwolnieniem MŚP z cyberbezpieczeństwa ani podstawą do odłożenia obecnych obowiązków.
Dla polskiej firmy trzeba rozdzielić dwie analizy: co wynika dzisiaj z ustawy o krajowym systemie cyberbezpieczeństwa, czyli KSC, oraz co może zmienić przyszła reforma. W planie warto przygotować miejsce na aktualizację zakresu, ale nie usuwać obowiązków na podstawie zapowiedzi.
Największą praktyczną różnicę może zrobić nie samo hasło „uproszczenie”, lecz jego konkretny mechanizm: ograniczenie dodatkowych wymagań krajowych, węższy zakres sektora albo mniejsza liczba powtarzanych audytów.
20 września 2026 r.
Podstawą są komunikat Komisji Europejskiej z 20 stycznia 2026 r. oraz analiza Global Policy Watch z 23 stycznia 2026 r.. Zachowujemy sześć obszarów zmian wyróżnionych w analizie, a szczegóły sprawdzamy w projekcie COM(2026) 13 i dokumentach instytucji UE.
Status legislacyjny, informacje o odrębnym pakiecie Omnibus IV i polskie terminy są uzupełnieniem materiałów wyjściowych. Przykład firmy, zalecenia i karta zmiany są opracowaniem CCyber. Artykuł nie zastępuje indywidualnej oceny podlegania.
Dla właścicieli i zarządów MŚP, dostawców IT, osób odpowiedzialnych za zgodność oraz przedsiębiorstw rosnących poza kategorię MŚP. Szczególnie dla firm, które realizują już program KSC i chcą ocenić, czy zapowiedziana reforma powinna zmienić jego zakres lub budżet.
Pakiet obejmuje projekt zmiany Cybersecurity Act, określany jako CSA2, oraz odrębne, ukierunkowane zmiany NIS2. Komisja łączy je z uproszczeniem zgodności, rozwojem certyfikacji i wzmocnieniem ENISA, czyli unijnej agencji cyberbezpieczeństwa.
Według szacunków Komisji uproszczenia mają objąć 28 700 przedsiębiorstw, w tym 6 200 mikroprzedsiębiorstw i małych firm. Są to przewidywania dla UE, nie liczba polskich beneficjentów ani przedsiębiorstw automatycznie wyłączanych z regulacji. Źródłem jest oficjalny komunikat Komisji.
Nie łącz wszystkich zapowiedzi w jedną zmianę prawa. Styczniowy projekt NIS2 i projekt CSA2 są odrębnymi aktami. Propozycja wspólnego punktu zgłaszania incydentów pochodzi natomiast z wcześniejszego Digital Omnibus. Ich powiązanie wyjaśnia strona Komisji poświęcona projektowi NIS2.
Omawiany projekt COM(2026) 13 pozostaje propozycją legislacyjną. Sprawdzona karta procedury 2026/0012(COD) wskazuje oczekiwanie na decyzję komisji parlamentarnej. Ostateczny zakres może różnić się od wersji przedstawionej w styczniu.
Projekt przewiduje 12 miesięcy na transpozycję przez państwa członkowskie od wejścia przyszłej dyrektywy w życie. To proponowany termin dla ustawodawców krajowych, nie dodatkowy rok dla każdej firmy liczony od komunikatu prasowego.
Wniosek dla planowania: utrzymuj osobno obowiązki aktualne i zmiany obserwowane. Nie zamieniaj prawdopodobnego przyszłego uproszczenia w dzisiejszy status „nie dotyczy”.
Projekt przewiduje regularną ocenę potrzeby przyjmowania dalszych aktów wykonawczych. Tam, gdzie Komisja określi odpowiednie wymagania, państwa członkowskie nie mogłyby dodawać dalszych wymagań technicznych, metodycznych lub sektorowych w objętym zakresie. Mechanizm opisuje proponowana zmiana art. 21 ust. 5 w COM(2026) 13.
Możliwe znaczenie dla firmy: mniejsze dublowanie pracy przy działalności w kilku państwach. Nie oznacza to jednak identyczności wszystkich przepisów krajowych, formularzy i obowiązków. Ograniczenie dotyczyłoby konkretnych wymagań oraz podmiotów objętych danym aktem wykonawczym.
Rekomendacja CCyber: przy każdym wymaganiu w rejestrze zapisz jego źródło. Rozdziel przepis unijny, krajowy i zobowiązanie wobec klienta. Dzięki temu przyszła zmiana pozwoli wskazać rzeczywiste duplikaty, zamiast usuwać działania wyłącznie dlatego, że brzmią podobnie.
Projekt rozróżnia informacje, które mają znaleźć się w przyszłych przepisach wykonawczych o zgłoszeniach, oraz informacje przekazywane na żądanie właściwego CSIRT lub organu. Pierwsza grupa dotyczy wykrycia ransomware, drogi ataku i zastosowanych środków. Druga obejmuje szczegóły żądania okupu i ewentualnej płatności przy incydencie poważnym.
Nie jest to automatyczny nakaz natychmiastowego wysyłania wszystkich szczegółów każdej próby wymuszenia. Trzeba zachować warunki wskazane w proponowanych ust. 12 i 13 art. 23. Sam obowiązek informowania o płatności nie jest też zgodą na jej dokonanie.
Doprecyzowanie materiału źródłowego: nie należy przyjmować, że szczegółowe unijne zasady dotyczące incydentów dopiero powstaną. Obowiązuje już rozporządzenie wykonawcze 2024/2690, obejmujące między innymi kwalifikację incydentów u wskazanych dostawców cyfrowych. Określenie istotności incydentu i ujednolicenie formatu zgłoszenia to różne kwestie.
Rekomendacja CCyber: uporządkuj dokumentowanie żądań, decyzji i dostępnych informacji. Wskaż osobę odpowiedzialną za kontakt z organem i bezpieczne przechowywanie materiałów. Nie zastępuj obecnego kanału zgłaszania zapowiedzianym rozwiązaniem, którego zasady nie weszły jeszcze w życie.
Propozycja dotyczy europejskiej certyfikacji poziomu cyberbezpieczeństwa organizacji, nie tylko produktu. Certyfikat potwierdzający określone wymagania art. 21 miałby ograniczać dodatkowe audyty nadzorcze dotyczące tych samych wymagań. Państwa mogłyby również ustanowić obowiązek uzyskania odpowiedniego certyfikatu.
Nie oznacza to „ISO 27001 zamiast całego NIS2”. Znaczenie miałyby właściwy europejski program certyfikacji, ważność certyfikatu i dokładny zakres potwierdzonych wymagań. Odpowiedzialność organizacji za zgodność pozostaje, co wskazują proponowane ust. 4-6 art. 24.
Rekomendacja CCyber: przed planowaniem oszczędności sprawdź, jaki audyt miałby zostać zastąpiony i na jakiej podstawie. Nie rezygnuj z obecnych obowiązków ani nie kupuj usługi reklamowanej jako przyszłe zwolnienie bez potwierdzonego zakresu prawnego.
ENISA miałaby wspierać współpracę organów krajowych i analizę ryzyk dotyczących podmiotów działających ponad granicami. Kierunek ten wskazuje również oficjalne omówienie projektu.
Nie jest to ustanowienie ENISA jedynym regulatorem wszystkich firm ani powszechnego modelu jednego organu kontaktowego na wzór RODO. Wspólne działania organów nie usuwają automatycznie obowiązków wobec właściwych instytucji krajowych.
Rekomendacja CCyber: uporządkuj informacje o spółkach, usługach, państwach działalności i lokalizacji systemów. Jeden kontrolowany zestaw danych będzie bardziej użyteczny niż kilka niespójnych opisów przygotowywanych oddzielnie dla każdego zapytania.
Styczniowy projekt odwołuje się do zalecenia Komisji 2025/1099. Chodzi o przedsiębiorstwa, które nie są MŚP, zatrudniają mniej niż 750 osób i spełniają co najmniej jeden z dwóch limitów: roczny obrót nieprzekraczający 150 mln euro albo roczna suma bilansowa nieprzekraczająca 129 mln euro.
To doprecyzowanie skrótu użytego w Global Policy Watch. Sama liczba pracowników i obrót nie wyczerpują definicji. Przy kalkulacji trzeba uwzględnić właściwe zasady dotyczące przedsiębiorstw partnerskich i powiązanych.
W proponowanym modelu część podmiotów z sektorów załącznika I mogłaby przejść z kategorii kluczowej do ważnej. Pozostają jednak inne podstawy kwalifikacji i wyjątki. Nie wolno wyciągać wniosku, że każda firma poniżej 750 osób przestaje podlegać NIS2.
Zmiana klasyfikacji może wpływać na sposób nadzoru. Nie oznacza jednak, że wymagania bezpieczeństwa zaczynają działać dopiero po incydencie. Rozróżnienie nadzoru nad podmiotami kluczowymi i ważnymi znajduje się w NIS2.
Rekomendacja CCyber: osobno oceniaj podleganie, kategorię podmiotu i wynikające z niej obowiązki. „Ważny zamiast kluczowego” oraz „poza zakresem ustawy” to dwie różne decyzje.
9 czerwca 2026 r. Rada ogłosiła wstępne porozumienie dotyczące small mid-caps w odrębnym pakiecie Omnibus IV, z progami poniżej 1000 osób oraz do 200 mln euro obrotu lub 172 mln euro sumy bilansowej. Opisuje to komunikat Rady UE.
Nie przenoś tych liczb automatycznie do obecnej KSC ani do styczniowego tekstu NIS2. Najpierw sprawdź konkretny akt, jego ostateczne brzmienie i moment stosowania.
Projekt usuwa automatyczne objęcie dostawców DNS niezależnie od wielkości. Dla mikroprzedsiębiorstw i małych firm może to mieć znaczenie, ale nadal trzeba sprawdzić pozostałe podstawy podlegania.
W sektorze chemicznym proponowany załącznik usuwa dystrybucję z opisu sektora i doprecyzowuje działalności przez odniesienia do REACH. To więcej niż zmiana nazwy. Szczegóły zawiera załącznik do COM(2026) 13.
Pakiet nie zawęża wyłącznie zakresu. Przewiduje również nowe lub doprecyzowane kategorie, między innymi dotyczące europejskich portfeli tożsamości i infrastruktury transmisji danych pod wodą. Dlatego ocena firmy musi uwzględniać wszystkie świadczone usługi.
Proponowana zmiana art. 26 ust. 3 rozszerza obowiązek wyznaczenia przedstawiciela na podmioty kluczowe lub ważne niemające siedziby w UE, ale oferujące w niej usługi. Global Policy Watch zwraca uwagę, że zakres sformułowania wymaga dalszego doprecyzowania.
Nie oznacza to, że polska firma musi wyznaczyć dodatkowego przedstawiciela tylko dlatego, że sprzedaje usługi za granicę. Kluczowe są ustanowienie podmiotu i jego status, nie sam fakt posiadania zagranicznych klientów.
Rekomendacja CCyber: w grupie międzynarodowej przypisz usługi do konkretnych osób prawnych. Nie zakładaj, że obecność dowolnej spółki grupy w UE automatycznie rozstrzyga sytuację wszystkich pozostałych spółek.
Tekst projektu przewiduje kierunek prac nad wytycznymi dotyczącymi informacji o bezpieczeństwie dostawców. Mają one pomagać ograniczać nieuzasadnione przenoszenie obciążeń na firmy poza zakresem NIS2. To element opisany w uzasadnieniu i motywach projektu, nie gotowe prawo do odrzucenia każdej ankiety klienta.
Rekomendacja CCyber: wymagania klienta przypisz do usługi, do której mają zastosowanie. Przygotuj aktualny zestaw potwierdzeń z określonym zakresem i zasadami udostępniania. Jeżeli pytanie nie dotyczy usługi, wyjaśnij to, zamiast składać nieprawdziwą deklarację.
Nie utożsamiaj wymagań kontrahenta z ustawowym statusem firmy. Podstawowe rozróżnienia rozwija przewodnik podlegania NIS2 w kategorii Cyberbezpieczeństwo dla MŚP.
Projekt unijny nie zmienia samodzielnie obecnych terminów KSC. Dla podmiotów objętych właściwym okresem przejściowym samorejestracja przypada do 3 października 2026 r., a wdrożenie obowiązków do 3 kwietnia 2027 r. Nie każdy podmiot rejestruje się samodzielnie. Zakres i warunki wyjaśnia harmonogram Ministerstwa Cyfryzacji.
Rekomendacja CCyber: nie zatrzymuj prac nad kontrolą dostępu, odtwarzaniem danych i obsługą incydentów tylko dlatego, że możliwa jest zmiana klasyfikacji. W budżecie rozdziel potrzebne zabezpieczenia od kosztów czynności, których obowiązek rzeczywiście może się zmienić.
Przykład modelowy CCyber. Firma zatrudnia 120 osób i zajmuje się wyłącznie dystrybucją chemikaliów. Na potrzeby przykładu przyjmujemy, że aktualna analiza potwierdziła status podmiotu ważnego wyłącznie z tej działalności.
Po przeczytaniu informacji o reformie zarząd rozważa zakończenie projektu KSC. Zespół zamiast tego zapisuje warunkową ocenę: proponowane zawężenie może mieć znaczenie, ale trzeba sprawdzić ostateczny tekst, polskie przepisy i brak innej podstawy podlegania.
Firma kontynuuje aktualnie wymagane działania. Oddzielnie oznacza koszty, które należy ponownie ocenić po zmianie prawa. Nie usuwa danych z rejestru ani nie informuje klientów o utracie statusu na podstawie samego projektu.
Równolegle utrzymuje potrzebne zabezpieczenia dostępu i odtwarzania. Nawet ewentualna zmiana zakresu regulacji nie stanowi dowodu, że ryzyko utraty danych lub przestoju zniknęło.
Poniższy wzór jest propozycją CCyber. Pozwala zapisać wpływ reformy bez mieszania stanu obecnego z prognozą.
Obowiązek dzisiaj: konkretna podstawa, podmiot, zakres i termin.
Proponowana zmiana: numer projektu, przepis i wersja dokumentu, na której opiera się analiza.
Warunki zastosowania: sektor, wielkość, rola, zakres certyfikacji lub inne przesłanki wymagające potwierdzenia.
Możliwy wpływ: które zadanie, koszt lub sposób raportowania rzeczywiście mogłyby się zmienić?
Decyzja na teraz: co kontynuujemy, co przygotowujemy warunkowo i czego jeszcze nie wolno uznać za rozstrzygnięte?
Właściciel i ponowny przegląd: kto śledzi zmianę i jakie zdarzenie uruchomi aktualizację, na przykład publikacja ostatecznego aktu lub polskiej nowelizacji?
W takim rejestrze nie wystarczy status „UE planuje uproszczenie”. Potrzebne jest połączenie zapowiedzi z konkretną decyzją dotyczącą firmy.
Aktualne obowiązki, dowody i przygotowanie do kontroli rozwijamy w kategorii Regulacje cyber UE i zgodność. Ten artykuł dotyczy zarządzania proponowaną zmianą, nie zastępuje pełnej analizy podlegania ani planu wdrożenia KSC.
Program zgodności NIS2 CCyber obejmuje analizę luk, ocenę dojrzałości, plan działań oraz wsparcie wdrożenia polityk, procedur i kontroli.
Sprawdź, które zadania są obowiązkowe dzisiaj, a które zależą od przyszłej reformy. Punktem wyjścia mogą być aktualna analiza podlegania, zakres usług i harmonogram projektu. Celem jest aktualizacja konkretnych decyzji, bez obietnicy zwolnienia z przepisów, które nadal obowiązują.
Nie wynika to z projektu. Próg jest częścią określonej definicji, obejmującej również status spoza MŚP i dane finansowe. Możliwa zmiana kategorii na podmiot ważny nie jest wyłączeniem z regulacji.
Nie można tego przyjąć na podstawie omawianej propozycji. Mechanizm dotyczy odpowiedniej europejskiej certyfikacji i objętych nią wymagań. Obecne obowiązki trzeba oceniać według aktualnego prawa.
Sam projekt nie daje takiej podstawy. Jeżeli firma jest obecnie zobowiązana do złożenia wniosku w określonym terminie, powinna realizować ten obowiązek zgodnie z właściwymi przepisami.
Nie. Poszczególne zmiany dotyczą różnych grup. Inaczej może wyglądać sytuacja małego dostawcy DNS, dystrybutora chemikaliów, firmy działającej w kilku krajach i przedsiębiorstwa przekraczającego kategorię MŚP.
Sprawdzone źródła nie pozwalają wskazać pewnej daty zakończenia procesu. Należy śledzić przyjęcie aktu i jego publikację, a następnie właściwe przepisy wykonawcze i krajowe. Prognoza legislacyjna nie jest terminem wykonania obowiązku.
Propozycja Komisji może ograniczyć część dublowania wymagań i zmienić sytuację wybranych przedsiębiorstw. Nie jest jednak sygnałem, że MŚP mogą zrezygnować z przygotowania do KSC.
Najbezpieczniejsze podejście organizacyjne to dwa równoległe zadania: wykonywać obowiązki aktualne i przygotować udokumentowaną ocenę przyszłych zmian. Dzięki temu firma może skorzystać z rzeczywistych uproszczeń, gdy zaczną obowiązywać, bez podejmowania przedwczesnych decyzji.
OT Security w 2026: ocena ryzyka PLC, DCS i SCADA
Bezpieczeństwo OT chroni nie tylko systemy, ale również działanie procesów fizycznych. Wyjaśniamy role PLC, DCS i SCADA oraz pokazujemy, jak przeprowadzić ocenę ryzyka z wykorzystaniem stref i kanałów komunikacyjnych IEC 62443. Omawiamy dostęp serwisowy, ochronę przed malware, odtwarzanie i dowody działania zabezpieczeń. Rozdzielamy obowiązki NIS2 i KSC od zakresu DORA, a możliwości AI i cyfrowych bliźniaków od obietnic automatycznej ochrony. Przykład modelowy pokazuje, jak zamienić zagrożenie w wymaganie i bezpieczny test.
Opracowanie: Zespół redakcyjny CCyber
OT Security jest kluczowe, ponieważ naruszenie systemu przemysłowego może wpłynąć na rzeczywisty proces: pompowanie wody, pracę linii, temperaturę, ciśnienie lub dostępność usługi. Ochrona powinna obejmować urządzenia, oprogramowanie, komunikację i sposób ich obsługi.
Rzetelna ocena ryzyka zaczyna się od procesu i możliwych skutków, a nie od zakupu narzędzia. Następnie trzeba rozpoznać zasoby i połączenia, ustalić strefy bezpieczeństwa, dobrać zabezpieczenia oraz sprawdzić je bez narażania produkcji. Wynikiem powinien być plan działań z właścicielami i dowodami wykonania.
20 września 2026 r.
Artykuł rozwija przekazaną notatkę o bezpieczeństwie OT, ocenie ryzyka, dowodach i systemach PLC, DCS oraz SCADA. Definicje i wymagania zweryfikowano w źródłach NIST, IEC, instytucji cyberbezpieczeństwa i aktach prawnych. Przykład, kryteria odbioru i proponowany sposób pracy są opracowaniem CCyber.
Technologie wskazane w notatce, w tym AI, cyfrowe bliźniaki i automatyczne symulacje, traktujemy jako możliwe wsparcie. Nie zakładamy ich powszechnego wdrożenia ani obowiązkowego stosowania w każdym środowisku OT.
Dla zarządów firm przemysłowych, dyrektorów zakładów, automatyków, utrzymania ruchu, zespołów IT i bezpieczeństwa oraz integratorów. Także dla operatorów usług infrastrukturalnych przygotowujących ocenę ryzyka, modernizację lub przegląd zgodności.
Łączenie zakładów z usługami analitycznymi, chmurą i zdalnym serwisem tworzy dodatkowe zależności. Nie oznacza automatycznie błędu architektury, ale wymaga ustalenia, jakie dane i polecenia mogą przepływać między środowiskami. Takie podejście rozwijają międzynarodowe zasady bezpiecznej łączności OT, opublikowane w styczniu 2026 r.
Ryzyko nie jest wyłącznie prognozą. W komunikacie z 30 lipca 2026 r. FBI i EPA opisały ataki na dostępne z internetu PLC w amerykańskim sektorze wodno-kanalizacyjnym. Zmiany konfiguracji prowadziły do utraty widoczności lub funkcji sterowania. To udokumentowany przykład z USA, nie statystyka częstości takich zdarzeń w Polsce.
Brak oceny ryzyka sam nie powoduje włamania. Może jednak pozostawić nierozpoznaną drogę dostępu, nieuzasadnione uprawnienia lub brak przygotowania do odzyskania procesu. Dlatego ocena powinna prowadzić do decyzji technicznych i operacyjnych.
Security dotyczy ochrony przed naruszeniem systemu i nieuprawnionym działaniem. Safety dotyczy ochrony ludzi, środowiska i instalacji przed niebezpiecznymi skutkami procesu. Obszary te muszą współpracować, ale nie są zamienne.
Międzynarodowe zasady cyberbezpieczeństwa OT stawiają safety na pierwszym miejscu. NIST również podkreśla odrębne wymagania bezpieczeństwa, niezawodności i działania w przewodniku OT Security.
Nie przyjmuj więc sztywnej reguły „w IT liczy się poufność, a w OT tylko dostępność”. Działający system przekazujący błędne pomiary może być niebezpieczny. Poufność dokumentacji inżynierskiej również ma znaczenie.
W proponowanej ocenie zapytaj: kiedy kontynuowanie pracy jest dopuszczalne, kiedy potrzebny jest tryb awaryjny i kto decyduje o kontrolowanym zatrzymaniu? Odpowiedzi muszą pochodzić od osób znających proces i jego zabezpieczenia.
PLC, czyli Programmable Logic Controller, wykonuje zaprogramowane funkcje sterowania na podstawie wejść i określonej logiki. Może obsługiwać maszynę, fragment instalacji lub bardziej złożony proces. Nie jest ograniczony wyłącznie do prostego „włącz/wyłącz”. Zakres funkcji opisuje NIST.
Pytanie bezpieczeństwa: kto może zmienić program, konfigurację i sposób działania sterownika oraz jak wykryjemy zmianę bez zgody?
DCS, czyli Distributed Control System, rozdziela funkcje sterowania między elementy związane z procesem, zamiast opierać całą kontrolę na jednym centralnym urządzeniu. Definicję podaje NIST.
DCS może integrować sterowanie, wizualizację i narzędzia inżynierskie. Sama nazwa nie gwarantuje jednak redundancji ani braku pojedynczych punktów awarii. To cechy konkretnego wdrożenia.
Pytanie bezpieczeństwa: czy naruszenie wspólnej stacji inżynierskiej lub usługi zarządzającej może wpłynąć na kilka części procesu?
SCADA, czyli Supervisory Control and Data Acquisition, zbiera i przetwarza dane oraz umożliwia nadzór i sterowanie nadrzędne. Jest wykorzystywana również przy zasobach rozproszonych geograficznie. Nie musi być jednym centralnym programem i nie służy wyłącznie do raportowania biznesowego. Zobacz definicję NIST.
Pytanie bezpieczeństwa: czy operator widzi wiarygodny stan procesu i czy polecenia może wydawać wyłącznie uprawniona osoba?
PLC jest urządzeniem sterującym, a DCS i SCADA opisują szersze systemy. Mogą współpracować. W przeglądzie uwzględnij także panele operatorskie HMI, stacje inżynierskie, serwery historii danych i urządzenia komunikacyjne.
Poniższy sposób pracy jest propozycją CCyber. Łączy analizę procesu z architekturą, ryzykiem i weryfikacją zabezpieczeń.
Zacznij od usługi lub procesu, na przykład uzdatniania wody albo konkretnej linii. Określ granice analizy, właściciela, zależności i dopuszczalne warunki pracy.
Rozważ osobno zagrożenie dla ludzi, środowiska, jakości produktu i ciągłości dostaw. Nie sprowadzaj wszystkiego do kosztu godziny przestoju. Zapisz też, jakich skutków nie potrafisz jeszcze ocenić.
Połącz dokumentację automatyki, konfiguracje i wiedzę operatorów z obserwacją ruchu. Sprawdź również modemy serwisowe, urządzenia integratora, nośniki wymienne i połączenia z usługami zewnętrznymi.
Wytyczne dotyczące utrzymywania obrazu architektury OT zalecają wykorzystanie wielu źródeł. Ostrzegają również, że aktywne skanowanie może przeciążyć starsze urządzenia. Metodę trzeba dobrać i zweryfikować przed użyciem.
Rezultat: potwierdzona mapa zasobów i zależności, z oznaczeniem obszarów nieznanych. Brak ruchu w krótkiej obserwacji nie powinien być jedyną podstawą usunięcia połączenia.
Strefa grupuje zasoby o wspólnych wymaganiach bezpieczeństwa. Conduit opisuje grupę połączeń między strefami, dla których określa się wspólne wymagania komunikacji.
IEC 62443-3-2 obejmuje określenie analizowanego systemu, podział na strefy i kanały, ocenę ryzyka oraz ustalenie docelowych poziomów bezpieczeństwa SL-T. Sam wybór SL-T nie potwierdza ich osiągnięcia.
W naszym modelu: oddziel biuro, dostęp serwisowy i poszczególne obszary sterowania według potrzeb procesu. Dla połączeń zapisz cel, kierunek, odpowiedzialność i dopuszczalną komunikację. Sam diagram lub nazwa VLAN-u nie dowodzą skutecznej separacji.
Przeanalizuj między innymi przejęcie konta dostawcy, nieuprawnioną zmianę konfiguracji, utratę wiarygodnych pomiarów i ransomware na stacji potrzebnej do obsługi procesu.
Dla każdego scenariusza wskaż potrzebny dostęp, słabości, obecne zabezpieczenia i możliwe skutki. Nie zakładaj, że zatrzymanie zakładu wymaga zaszyfrowania samego PLC. W scenariuszu mogą wystarczyć niedostępne systemy nadzoru lub zależności biznesowe.
Rezultat: uzasadniony priorytet, a nie wyłącznie wynik skanera. Brak informacji oznacz jako niepewność, nie jako niskie ryzyko.
Wybierz działania odpowiadające scenariuszowi: ograniczenie dostępu, segmentację, ochronę konfiguracji, poprawę monitoringu lub odzyskiwania. Zapisz wykonawcę, termin i sposób oceny efektu.
Jeżeli aktualizacja wymaga okna serwisowego, uwzględnij test zgodności i możliwość wycofania zmiany. Gdy naprawa nie jest od razu możliwa, określ środki tymczasowe oraz termin ponownej decyzji. „Nie można zaktualizować” nie powinno kończyć analizy.
Sprawdź, czy zabezpieczenie działa i czy nie pogorszyło warunków procesu. Właściciel ryzyka powinien znać pozostałe ograniczenia.
Do ponownej oceny wracaj po istotnej zmianie: nowej bramie IIoT, dostępie integratora, modernizacji PLC lub zmianie sposobu odtwarzania. Okresowy przegląd uzupełnia takie zdarzenia, a nie zastępuje ich.
Zasady bezpiecznej łączności OT wskazują połączenia pośredniczone przez kontrolowaną bramę, zamiast bezpośredniego dostępu zewnętrznego do sterowania. Opisują również ograniczanie funkcji i przepływów między strefami.
Proponowany dowód: wykaz dozwolonych połączeń, konfiguracja ograniczeń i uzgodniony test dostępu serwisanta. Powinien on objąć także odmowę dostępu poza zakresem i zakończenie sesji.
Szczegóły rozwija poradnik „Bezpieczny zdalny dostęp do OT” w kategorii Bezpieczeństwo OT, przemysłu i infrastruktury krytycznej.
Nie zakładaj możliwości instalacji standardowego agenta ochronnego na każdym PLC lub systemie czasu rzeczywistego. Dobór rozwiązania wymaga sprawdzenia wsparcia, wpływu na działanie i warunków utrzymania.
Proponowane działanie: ustal zatwierdzoną drogę przekazywania projektów i aktualizacji, kontrolę nośników oraz sposób sprawdzenia pochodzenia i integralności plików.
Proponowany dowód: zgodność zastosowanej ochrony z platformą, wynik testu i zapis obsługi wyjątków. Sama faktura za antywirusa nie potwierdza ochrony całego OT.
Uzgodnij, jakie zmiany są istotne: nowe połączenie, logowanie dostawcy poza oknem, modyfikacja projektu lub utrata komunikacji. Określ, kto odróżni planowany serwis od sytuacji wymagającej reakcji.
Proponowany dowód: kontrolowany test alarmowania z potwierdzeniem odbioru przez właściwą osobę. Nowy adres IP nie oznacza automatycznie ataku, ale wymaga oceny w kontekście procesu i zmian.
W scenariuszu odtwarzania uwzględnij nie tylko pliki biurowe, ale również właściwe projekty sterowników, konfiguracje, wersje oprogramowania i potrzebne środowisko inżynierskie.
Proponowany dowód: odtworzenie w uzgodnionym środowisku oraz sprawdzenie konfiguracji i wymaganych funkcji przez automatykę. Powrót procesu do pracy powinien odbywać się według zatwierdzonej procedury uruchomienia, nie wyłącznie na podstawie komunikatu „restore completed”.
Przykład modelowy CCyber, nie opis rzeczywistego incydentu. Zakład uzdatniania wody dopuszcza zdalny serwis przez stację inżynierską. Analiza ma sprawdzić, czy przejęcie konta serwisowego mogłoby pozwolić na zmianę parametrów procesu.
Scenariusz: nieuprawniona osoba używa dostępu serwisowego do wykonania zmiany wykraczającej poza zatwierdzone zadanie.
Możliwy skutek: utrata wiarygodności sterowania, konieczność zatrzymania części procesu lub zagrożenie jakości wody. Ocena musi uwzględnić rzeczywiste blokady, alarmy i niezależne pomiary. Nie zakładamy automatycznie zatrucia wody po każdym przejęciu konta.
Wymaganie: dostęp jest ograniczony do uzgodnionych zadań, zmiany wymagają właściwej zgody, a niepożądana operacja może zostać zauważona i obsłużona.
Weryfikacja: test uprawnień w środowisku laboratoryjnym lub innym bezpiecznie uzgodnionym zakresie oraz ćwiczenie decyzji z operatorami. Bez celowej zmiany parametrów czynnej instalacji.
Dowód: wersja konfiguracji, zakres testu, wynik, właściciel działania i pozostałe ograniczenia. Wynik nie jest oceną całego zakładu, jeżeli sprawdzono tylko jedną ścieżkę.
AI może wspierać analizę danych i wykrywanie anomalii, ale jego integracja tworzy również ryzyka. Wspólne wytyczne bezpiecznego używania AI w OT wymagają uwzględnienia testów, nadzoru i bezpiecznych sposobów działania przy błędzie.
Nasza rekomendacja: przed automatycznym blokowaniem połączeń lub zmianą działania urządzenia sprawdź skutki fałszywego alarmu i brakujących danych. Automatyzacja reakcji nie powinna niejawnie przejmować decyzji o bezpieczeństwie procesu.
NIST opisał badanie łączące cyfrowy model procesu, uczenie maszynowe i wiedzę ekspercką do wykrywania ataków na laboratoryjną drukarkę 3D. To przykład możliwości badawczej, nie dowód pełnej ochrony dowolnej instalacji.
Nasza rekomendacja: sprawdź zgodność modelu z rzeczywistym urządzeniem, zakres odtwarzanych zjawisk i ograniczenia. Wyniku symulacji nie przenoś automatycznie na proces produkcyjny.
Breach and Attack Simulation oznacza symulowanie wybranych działań atakujących w celu weryfikacji ochrony. W tym artykule nie przyjmujemy BAS jako obowiązkowego elementu każdej oceny OT.
Nasza rekomendacja: zaczynaj od laboratorium i uzgodnionego zakresu. Każde testowanie na produkcji wymaga zgody właściciela procesu, oceny wpływu, warunków przerwania i planu odzyskania działania. Nie uruchamiaj standardowego profilu testów IT na sterownikach bez takiego przygotowania.
W Załączniku A ISO/IEC 27001:2022 ochrona przed malware ma oznaczenie A.8.7, a przekazywanie informacji A.5.14. Kopie zapasowe to A.8.13. Wskazówki rozwija ISO/IEC 27002:2022, którego strukturę pokazuje publiczny podgląd wydania SIST.
Raport z kontroli plików serwisowych może wspierać ocenę tych zabezpieczeń. Nie jest jednak certyfikatem bezpieczeństwa PLC ani całego zakładu. Znaczenie ma zakres SZBI i deklaracji stosowania.
IEC 62443-3-2 wspiera ocenę ryzyka przy projektowaniu systemu, a IEC 62443-3-3 określa techniczne wymagania bezpieczeństwa systemowego i poziomy zdolności ochrony.
W zamówieniu wskaż część normy, analizowany system i kryteria. Certyfikowany komponent nie potwierdza automatycznie poprawności całej integracji. Diagram stref powinien być powiązany z wymaganiami, konfiguracją i weryfikacją.
Art. 20 NIS2 dotyczy zatwierdzania i nadzorowania środków zarządzania ryzykiem przez organy zarządzające. W Polsce art. 8c-8d KSC określają odpowiedzialność kierownika i jego zadania. Nie jest to automatyczna kara za każdą nietrafną ocenę lub wystąpienie incydentu. Trzeba ustalić właściwy obowiązek i przesłanki odpowiedzialności. Podstawy znajdują się w NIS2 oraz KSC.
Posiadanie PLC nie przesądza o podleganiu KSC. Dla podmiotów objętych właściwym okresem przejściowym ważne są samorejestracja do 3 października 2026 r. i wdrożenie obowiązków do 3 kwietnia 2027 r. Sprawdź status organizacji i oficjalny harmonogram.
DORA dotyczy odporności cyfrowej określonych podmiotów finansowych i przewiduje wymagania dotyczące dostawców ICT. Jej zakres wyjaśnia ESMA.
Nie obejmuje automatycznie wodociągu ani zakładu produkcyjnego tylko dlatego, że ich usługi są ważne dla gospodarki. Wymaganie DORA w projekcie OT trzeba uzasadnić konkretną rolą, usługą lub zobowiązaniem, a nie dopisać do każdego audytu infrastruktury krytycznej.
Rekomendujemy powiązanie: proces → scenariusz ryzyka → wymaganie → zabezpieczenie → wynik sprawdzenia → decyzja o pozostałym ryzyku.
Każdy materiał powinien wskazywać zakres, datę, wersję konfiguracji i właściciela. Zachowaj także niepowodzenia testów oraz sposób ich usunięcia. Nie przedstawiaj nowej konfiguracji jako działającej od miesięcy.
Rozdziel przegląd gotowości, test techniczny, audyt względem uzgodnionych kryteriów i certyfikację. Nazwa „audyt OT” nie określa sama w sobie, co wykonawca sprawdził i jakie wnioski może wydać.
Pierwszy krok: wybierz jeden ważny proces i zbierz automatykę, utrzymanie ruchu, IT, bezpieczeństwo oraz właściciela biznesowego. Ustal granice i warunki bezpiecznej pracy.
Drugi krok: sprawdź mapę połączeń, zdalny serwis i odzyskiwanie konfiguracji. Znane, poważne zagrożenia obsługuj od razu w sposób uzgodniony z operacjami, bez czekania na zakończenie dokumentacji.
Trzeci krok: zatwierdź priorytety i terminy. Raportuj osobno zabezpieczenia zaplanowane, wdrożone i sprawdzone. Nie mierz poprawy wyłącznie liczbą zainstalowanych sensorów.
Bezpieczny serwis i segmentację rozwijamy w kategorii Bezpieczeństwo OT, przemysłu i infrastruktury krytycznej. Przy planowaniu ćwiczeń przydadzą się materiały o reagowaniu na incydenty i ciągłości działania.
Ten artykuł koncentruje się na ocenie ryzyka procesu oraz dowodach. Szczegółowy projekt sieci i dobór zabezpieczeń wymagają analizy rzeczywistej instalacji.
W ramach projektów i wdrożeń cyberbezpieczeństwa CCyber wspiera analizę ryzyka IT i OT, segmentację, kontrolę dostępu oraz przygotowanie do audytów.
Zacznij od oceny jednego procesu, którego utrata najbardziej dotknie organizację. Do ustalenia zakresu przygotuj opis instalacji, dostępne schematy, listę dostawców i znane ograniczenia. Celem jest uzgodniony plan ochrony i dowody, bez testów zagrażających ludziom lub produkcji. Informacje techniczne przekazuj dopiero po uzgodnieniu bezpiecznego kanału.
Nie można tego ustalić wyłącznie na tej podstawie. W ocenie uwzględnij również dostęp serwisowy, połączenia z IT, urządzenia dostawców i przenoszenie plików. Izolacja musi odpowiadać rzeczywistej architekturze.
Nie. Może dostarczyć części informacji, ale nie określi samodzielnie skutków dla procesu, bezpieczeństwa ludzi ani sposobu odzyskania działania. Metoda skanowania również wymaga oceny wpływu na OT.
Nie należy przenosić konfiguracji komputera biurowego na każdy sterownik. Mechanizmy dobiera się do platformy i ryzyka. Silne uwierzytelnianie może być realizowane na kontrolowanej ścieżce administracyjnej, a ochrona urządzenia uzupełniona ograniczeniem komunikacji i zmian.
Możliwość techniczna nie jest zgodą operacyjną. Przed taką automatyzacją trzeba ocenić skutki odłączenia, błędnej klasyfikacji i utraty danych wejściowych. Reguły muszą uwzględniać bezpieczne zachowanie procesu.
Zakres powinien odpowiadać procesowi i możliwym skutkom. Mała liczba urządzeń nie oznacza małego znaczenia sterowania. Można rozpocząć od ograniczonego przeglądu, nie przedstawiając go jako oceny całej organizacji.
Bezpieczeństwo OT w 2026 r. wymaga połączenia znajomości procesu, architektury i zagrożeń. PLC, DCS i SCADA pełnią różne funkcje, dlatego nie powinny otrzymywać jednego zestawu zabezpieczeń bez oceny zastosowania.
Dobra ocena ryzyka kończy się sprawdzalną decyzją: co chronimy, przed jakim scenariuszem, kto odpowiada za działanie i jak potwierdzimy rezultat bez zagrożenia procesu. AI i nowe narzędzia mogą pomagać, ale nie zastępują tych ustaleń.
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.