Praktyczne przewodniki po regulacjach cyberbezpieczeństwa i wymaganiach zgodności dla firm działających w Polsce i Unii Europejskiej. Wyjaśniamy NIS2, ustawę o KSC, DORA, Cyber Resilience Act, ISO/IEC 27001, NIST Cybersecurity Framework oraz powiązane obowiązki w prosty, biznesowy sposób.
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.
HIPAA: 8 kroków do zgodności dla firm i dostawców IT
Amerykański klient medyczny pyta o zgodność z HIPAA? Zacznij od ustalenia roli firmy, zakresu chronionych danych i obowiązków wynikających z umowy BAA. Omawiamy osiem kroków: zasady HIPAA, odpowiedzialność, ocenę ryzyka, zabezpieczenia, zgłaszanie naruszeń, szkolenia, dostawców i monitorowanie. Wyjaśniamy również znaczenie terminów 60 dni i sześciu lat oraz różnicę między przeglądem zgodności a „certyfikatem HIPAA”. Przykład usługi SaaS pokazuje, dlaczego ocena nie może kończyć się na głównej bazie danych.
Opracowanie: Zespół redakcyjny CCyber
Przygotowanie do HIPAA zacznij od ustalenia, w jakiej roli firma obsługuje chronione informacje zdrowotne, gdzie te informacje trafiają i kto odpowiada za ich ochronę. Następnie połącz ocenę ryzyka, zabezpieczenia, umowy z dostawcami, szkolenia oraz obsługę naruszeń w działający proces.
Nie zaczynaj od poszukiwania „certyfikatu HIPAA” ani kopiowania zasad RODO. Najpierw ustal zakres konkretnej usługi i właściwych obowiązków. Lista kontrolna powinna prowadzić do wykonanych i sprawdzonych działań, nie do deklaracji zgodności opartej wyłącznie na podpisanej umowie.
20 września 2026 r.
Układ ośmiu kroków pochodzi z poradnika Vanta o przygotowaniu do HIPAA. Wyjaśnienia wymagań i doprecyzowania oparto na materiałach amerykańskiego Departamentu Zdrowia i Opieki Społecznej, HHS, oraz przepisach dostępnych w eCFR. Przykład usługi i proponowane dowody są opracowaniem CCyber.
Artykuł dotyczy wybranych wymagań prywatności i bezpieczeństwa. Nie zastępuje analizy prawnej konkretnej działalności ani wszystkich przepisów federalnych, stanowych i europejskich, które mogą jej dotyczyć.
Dla firm IT, dostawców SaaS, hostingu, usług analitycznych i wsparcia technicznego współpracujących z amerykańskim sektorem ochrony zdrowia. Także dla zespołów bezpieczeństwa, zgodności i zakupów, które potrzebują uporządkować odpowiedzi na wymagania klienta.
HIPAA to amerykańska ustawa Health Insurance Portability and Accountability Act. Jej przepisy wykonawcze dotyczą między innymi podmiotów określanych jako covered entities: planów zdrowotnych, podmiotów przetwarzających transakcje zdrowotne do standardowej postaci oraz świadczeniodawców realizujących określone transakcje elektroniczne. Nie każda organizacja medyczna spełnia tę definicję. Zakres wyjaśnia HHS.
Business associate to określony rodzaj usługodawcy działającego na rzecz covered entity. Status może obejmować także podwykonawcę innego business associate. Znaczenie ma wykonywana funkcja oraz tworzenie, otrzymywanie, przechowywanie lub przekazywanie PHI. Przykłady obejmują hosting i wybrane usługi IT. Szczegóły podaje HHS w przewodniku o business associates.
Polska siedziba nie jest automatycznym wyłączeniem. HHS dopuszcza przechowywanie ePHI poza USA przy spełnieniu właściwych wymagań i zawarciu odpowiedniej umowy. Lokalizację należy uwzględnić w ocenie ryzyka. Opisuje to poradnik HHS dotyczący chmury.
Privacy Rule określa zasady używania i ujawniania PHI oraz prawa osób. PHI to chronione informacje zdrowotne pozwalające zidentyfikować osobę w kontekście objętym HIPAA. Ochrona może dotyczyć informacji elektronicznej, papierowej i ustnej.
Leczenie, rozliczenia i działalność operacyjna ochrony zdrowia to ważne przykłady dopuszczalnych zastosowań, ale nie cały katalog. W przeciwieństwie do uproszczenia w materiale wyjściowym nie należy ograniczać wszystkich dozwolonych ujawnień wyłącznie do tych trzech celów. Warunki opisuje podsumowanie Privacy Rule.
Security Rule dotyczy elektronicznych PHI, czyli ePHI, i obejmuje zabezpieczenia administracyjne, fizyczne oraz techniczne. Breach Notification Rule określa obowiązki po naruszeniu danych objętym jego zakresem. Relację tych zasad wyjaśnia HHS w podsumowaniu Security Rule.
Do wykonania: przygotuj mapę obowiązków dla swojej roli. Dostawca nie powinien zakładać, że może używać danych do dowolnego celu tylko dlatego, że służy on branży medycznej.
Security Rule wymaga wskazania osoby odpowiedzialnej za rozwój i wdrażanie odpowiednich polityk bezpieczeństwa. Obowiązek dotyczy covered entities i business associates. Podstawą jest 45 CFR 164.308(a)(2).
Odrębnie 45 CFR 164.530(a) wymaga od covered entity wskazania osoby odpowiedzialnej za prywatność oraz kontaktu do obsługi skarg. Nie przenoś automatycznie całego tego obowiązku na każdego dostawcę w identycznej postaci.
Do wykonania: określ, kto zatwierdza dostęp, prowadzi ocenę ryzyka, kontaktuje się z klientem i podejmuje decyzje podczas incydentu. Sam tytuł „HIPAA Compliance Officer” nie wyjaśnia zakresu uprawnień ani dostępności tej osoby.
Analiza ryzyka powinna obejmować wszystkie ePHI tworzone, otrzymywane, utrzymywane i przekazywane w analizowanej działalności. HHS nie narzuca jednej metody, która automatycznie zapewnia zgodność. Wymaga jednak rzetelnego rozpoznania ryzyk dla poufności, integralności i dostępności. Podstawę opisuje Guidance on Risk Analysis.
Propozycja CCyber: prześledź drogę danych od ich otrzymania do usunięcia. Sprawdź bazę produkcyjną, eksporty, kopie, logi, zgłoszenia serwisowe i środowiska testowe. Dla każdego miejsca zapisz właściciela, dostęp i potrzebne zabezpieczenia.
Usunięcie imienia i nazwiska nie potwierdza deidentyfikacji. HHS opisuje dwie metody: Expert Determination i Safe Harbor. Lista 18 kategorii identyfikatorów wiąże się z warunkami Safe Harbor, nie jest prostym testem „czy plik zawiera PHI”. Szczegóły znajdują się w wytycznych deidentyfikacji.
Dowód wykonania: określony zakres analizy, uzasadnione ryzyka i zadania naprawcze. Ankieta bez sprawdzenia rzeczywistych przepływów nie powinna być jedyną podstawą decyzji.
Wymagania techniczne obejmują kontrolę dostępu, rejestrowanie i badanie aktywności, ochronę integralności, uwierzytelnianie oraz bezpieczeństwo transmisji. Określa je 45 CFR 164.312. Security Rule obejmuje również plany kopii, odtwarzania i działania awaryjnego oraz ochronę stanowisk i nośników.
Propozycja CCyber: połącz każdą zasadę z jej realizacją. Dla dostępu zapisz wymagane role i wykonaj test uprawnień. Dla backupu potwierdź możliwość odtworzenia. Dla logów ustal, kto przegląda istotne zdarzenia i reaguje na wynik.
Nie tłumacz oznaczenia addressable jako „opcjonalne”. Wymaga ono oceny, czy dana specyfikacja jest rozsądna i odpowiednia, oraz właściwego udokumentowania decyzji. Dotyczy to również szyfrowania w obowiązującym modelu Security Rule. Znaczenie wyjaśnia HHS.
Nie pomijaj strony prywatności: obsługi dostępu do informacji, żądań poprawienia danych i ograniczeń ujawniania. Zabezpieczenie systemu nie daje zgody na każde wykorzystanie przechowywanych informacji.
Dowód wykonania: zatwierdzone zasady, odpowiednia konfiguracja i wynik sprawdzenia w ustalonym zakresie. Praktykę zarządzania kontami rozwijamy w kategorii Tożsamość, dostęp i bezpieczeństwo chmury.
Najpierw oceń, czy zdarzenie stanowi naruszenie objęte Breach Notification Rule i dotyczy unsecured PHI w rozumieniu przepisów. Nie każde ostrzeżenie narzędzia jest takim naruszeniem. Niedozwolone użycie lub ujawnienie PHI wymaga jednak oceny i udokumentowania podstaw decyzji, a nie założenia, że „zapewne nic się nie stało”.
Zasadą jest zgłoszenie bez nieuzasadnionej zwłoki, najpóźniej w ciągu 60 dni kalendarzowych od wykrycia. Wykrycie uwzględnia także to, co powinno być znane przy zachowaniu należytej staranności. Wynika to z 45 CFR 164.410.
BAA może przewidywać krótszy termin. Nie czekaj z pierwszą informacją na zakończenie całego dochodzenia. Przepis przewiduje uzupełnianie informacji, gdy stają się dostępne.
Powiadomienie osób następuje bez nieuzasadnionej zwłoki, nie później niż 60 dni od wykrycia. Przy naruszeniu dotyczącym ponad 500 mieszkańców jednego stanu lub jurysdykcji dochodzi obowiązek zawiadomienia odpowiednich mediów. Zasady i wyjątki opisuje HHS.
Dla 500 lub więcej osób zgłoszenie do HHS odbywa się równolegle z powiadomieniem osób. Dla mniejszych naruszeń zgłoszenie do HHS można przekazać do 60 dni po zakończeniu roku, w którym je wykryto. To nie odracza powiadomienia osób. Rozróżnienie określa 45 CFR 164.408.
Do wykonania: zapisz odbiorców, moment rozpoczęcia biegu terminu, zastępstwa i obowiązki umowne. Nie kopiuj do HIPAA jednego terminu 72 godzin z procedury RODO.
Security Rule wymaga programu świadomości i szkoleń dla personelu, w tym kierownictwa. Privacy Rule wymaga od covered entity szkoleń odpowiednich do funkcji, także po dołączeniu nowej osoby i istotnych zmianach zasad. Podstawy znajdują się w 164.308(a)(5) i 164.530(b).
Coroczny cykl rekomendowany przez Vanta może być praktycznym rozwiązaniem. Nie należy jednak przedstawiać go jako jednej, uniwersalnej częstotliwości szkolenia wynikającej z tych przepisów.
Propozycja CCyber: serwisowi pokaż bezpieczne przyjmowanie załączników, administratorom kontrolę dostępów, a osobom kontaktującym się z pacjentami zasady udostępniania informacji. Ćwicz na danych syntetycznych. Zachowaj temat, uczestników i wynik sprawdzenia wiedzy.
BAA, czyli Business Associate Agreement, nie jest zwykłym NDA. Określa między innymi dozwolone wykorzystanie informacji, zabezpieczenia, zgłaszanie problemów, współpracę przy prawach osób i postępowanie po zakończeniu usługi. HHS udostępnia przykładowe postanowienia umowne.
Właściwe umowy są potrzebne również w łańcuchu podwykonawców obsługujących PHI. Podpisane BAA dokumentuje zobowiązania, ale samo nie dowodzi, że dostawca je wykonuje.
Brak możliwości odczytania danych nie zawsze wyłącza status business associate. HHS wskazuje, że operator przechowujący zaszyfrowane ePHI może mieć ten status również bez klucza odszyfrowania. Wyjaśnia to poradnik o chmurze.
Do wykonania: sprawdź hosting, backup, helpdesk, analitykę i ewentualne narzędzia AI. Ustal, które rzeczywiście otrzymują PHI, jaka usługa jest objęta umową i co pozostaje do skonfigurowania po stronie Twojej firmy. Nie podpisuj identycznej umowy ze wszystkimi dostawcami bez oceny ich roli.
Ważne doprecyzowanie wobec Vanta: obowiązujący Security Rule wymaga okresowej oceny technicznej i nietechnicznej oraz uwzględniania zmian. Sam 164.308(a)(8) nie ustanawia ogólnego obowiązku audytu wewnętrznego dokładnie raz w roku.
Audyt co najmniej co 12 miesięcy znalazł się w propozycji zmian Security Rule. HHS nadal rozdziela propozycję NPRM od obowiązujących przepisów. Nie należy przedstawiać projektu jako już stosowanego wymogu.
Propozycja CCyber: ustal cykl przeglądów i dodatkowe sprawdzenia po zmianie dostawcy, integracji, sposobu dostępu lub incydencie. Raportuj nie tylko liczbę polityk, ale również niezamknięte luki, wyniki testów i brakujące decyzje.
Dokumentację wymaganą przez Security Rule należy zachować przez sześć lat od utworzenia albo ostatniego obowiązywania, zależnie od późniejszej daty. Nie jest to przechowywanie „do sześciu lat”. Podstawę stanowi 45 CFR 164.316.
To inna kwestia niż okres przechowywania dokumentacji medycznej. HHS wyjaśnia, że Privacy Rule nie ustanawia jej ogólnego terminu retencji. Znaczenie mają między innymi przepisy stanowe. Zobacz wyjaśnienie HHS dotyczące dokumentacji pacjentów.
Propozycja CCyber: osobno ustal zasady dla polityk, ocen, zapisów operacyjnych i danych pacjentów. Nie kopiuj jednego okresu do każdego systemu i nie usuwaj danych wyłącznie dlatego, że minęło sześć lat.
Przykład modelowy CCyber. Polska firma rozwija aplikację dla amerykańskiej kliniki. Na potrzeby scenariusza przyjmujemy, że analiza potwierdziła status firmy jako business associate. Główna baza ma ograniczony dostęp i działa w uzgodnionej infrastrukturze.
Przegląd przepływów pokazuje jednak, że zgłoszenia serwisowe zawierają zrzuty ekranów z informacjami pacjentów. Trafiają do oddzielnego narzędzia, którego wcześniej nie uwzględniono w analizie ani ocenie podwykonawców.
Zespół ustala zakres danych, ocenia wcześniejsze użycie i wymagane umowy, a następnie projektuje bezpieczny sposób obsługi załączników. Wprowadza instrukcję dla klienta i testuje uprawnienia na danych syntetycznych. Nie usuwa pochopnie materiałów potrzebnych do oceny ewentualnego naruszenia.
Wniosek z przykładu: poprawna konfiguracja głównej bazy nie odpowiada na pytanie o wszystkie miejsca przetwarzania informacji. Lista kontrolna powinna prowadzić przez całą usługę.
Firma działająca w Polsce powinna niezależnie ocenić RODO. Przetwarzanie w ramach działalności podmiotu ustanowionego w UE może podlegać RODO bez względu na miejsce przetwarzania. Zakres opisuje Komisja Europejska.
Można wykorzystać wspólne rejestry zasobów, testy i zabezpieczenia. Nie należy jednak zakładać, że BAA automatycznie zastępuje umowę powierzenia, a amerykański tryb zawiadomienia zastępuje ocenę naruszenia na gruncie RODO.
Relacje między wymaganiami rozwijamy w kategorii Regulacje cyber UE i zgodność. HIPAA pozostaje w tym zestawieniu regulacją amerykańską.
HHS nie uznaje prywatnych certyfikatów Security Rule za urzędowe potwierdzenie zgodności. Zewnętrzna ocena może być użyteczna, ale nie usuwa obowiązków organizacji ani możliwości stwierdzenia naruszenia przez organ. Wyjaśnia to oficjalne FAQ HHS.
Gdy klient prosi o „certyfikat HIPAA”, ustal, jakiego potwierdzenia oczekuje: zakresu oceny, raportu z testów, BAA czy odpowiedzi na ankietę. Nie zastępuj tych ustaleń znakiem graficznym na stronie.
Przy wdrażaniu programu przydadzą się materiały o tożsamości, dostępie i bezpieczeństwie chmury oraz poradniki zgodności z regulacjami. Ten artykuł koncentruje się na organizacji przygotowania do HIPAA, nie na pełnej analizie wszystkich obowiązków ochrony zdrowia w USA.
W ramach audytu bezpieczeństwa CCyber analizuje środowisko IT, przepływy danych, konfiguracje oraz polityki i procedury. Wynikiem jest lista luk i priorytetowych działań.
Zacznij od uzgodnienia zakresu usługi i danych, które obsługujesz. Przy wymaganiach HIPAA rozdziel ocenę techniczną od kwalifikacji prawnej działalności i treści umów, wymagających wsparcia prawnika znającego prawo USA. Przegląd bezpieczeństwa nie jest urzędową certyfikacją HIPAA.
Tak, jeżeli spełnia właściwą definicję, na przykład business associate. Sam niewielki rozmiar firmy nie wyłącza obowiązków. Ocena powinna dotyczyć wykonywanej usługi i sposobu obsługi PHI, nie wyłącznie liczby pracowników.
Nie. Umowa musi odpowiadać rzeczywistej usłudze, a firma powinna realizować właściwe wymagania bezpieczeństwa i prywatności. Brak podpisu nie oznacza też automatycznie, że ustawowy status business associate nie powstał.
Nie należy tak tego interpretować. Sprawdź objęte usługą funkcje, umowę, konfigurację i podział odpowiedzialności. Dostawca chmury nie podejmuje za klienta wszystkich decyzji o kontach, danych i ich wykorzystaniu.
Osiem etapów porządkuje pracę, ale nie jest jednorazowym egzaminem. Zmiany usługi, personelu i ryzyk wymagają dalszej oceny. Zamknięte zadanie wdrożeniowe powinno prowadzić do ustalonego sposobu utrzymania.
Przygotowanie do HIPAA wymaga ustalenia roli firmy, poznania przepływów PHI i połączenia zasad z działaniem. Osiem etapów pomaga uporządkować odpowiedzialność, ryzyko, zabezpieczenia, naruszenia, szkolenia i dostawców.
Najbardziej użytecznym potwierdzeniem gotowości jest spójność umowy, rzeczywistej usługi i dowodów. Nie zastąpi jej ogólna deklaracja zgodności ani certyfikat bez jasno określonego zakresu.
ISO 27001:2022: 93 zabezpieczenia Załącznika A w praktyce
Załącznik A ISO/IEC 27001:2022 zawiera 93 zabezpieczenia, ale nie jest listą identycznych zakupów dla każdej firmy. Wyjaśniamy cztery grupy zabezpieczeń, prawidłowe oznaczenia wybranych pozycji oraz różnicę między wymaganiem, wdrożeniem i dowodem działania. Pokazujemy, jak dobierać zabezpieczenia, przygotować deklarację stosowania i uzasadniać wyłączenia. Przykład dostępu serwisowego ilustruje przejście od ryzyka do konkretnego działania, odpowiedzialności i sprawdzenia wyniku.
Opracowanie: Zespół redakcyjny CCyber
Załącznik A ISO/IEC 27001:2022 zawiera 93 zabezpieczenia uporządkowane w czterech grupach: organizacyjnej, dotyczącej ludzi, fizycznej i technologicznej. Jest katalogiem odniesienia przy sprawdzaniu, czy organizacja nie pominęła potrzebnej ochrony. Nie zastępuje oceny ryzyka ani całego systemu zarządzania bezpieczeństwem informacji.
Firma powinna ustalić, jakie zabezpieczenia są potrzebne w jej zakresie SZBI, uzasadnić wybór i wskazać stan wdrożenia. Decyzje zapisuje w deklaracji stosowania, czyli Statement of Applicability, w skrócie SoA. Następnie musi przełożyć je na działające procesy i rozwiązania.
Najważniejsze pytanie nie brzmi: „Ile pozycji zaznaczyliśmy?”. Brzmi: „Czy dobrane zabezpieczenia odpowiadają naszym potrzebom i czy potrafimy wykazać ich działanie?”.
19 września 2026 r.
Artykuł odnosi się do ISO/IEC 27001:2022 wraz z Amd 1:2024 oraz ISO/IEC 27002:2022. Punktem wyjścia jest poradnik Copla o Załączniku A. Zachowujemy podział na cztery grupy, natomiast numerację i zasady stosowania weryfikujemy w źródłach normatywnych oraz materiałach IAF.
Poniższe przykłady, kryteria odbioru i wzór rekordu są propozycją CCyber. Nie stanowią pełnego tekstu 93 zabezpieczeń ani oficjalnego tłumaczenia normy.
Dla osób wdrażających SZBI, kierowników IT, CISO, właścicieli procesów i zespołów przygotowujących organizację do certyfikacji. Szczególnie dla firm, które mają listę zabezpieczeń w arkuszu, ale nie potrafią jeszcze połączyć jej z ryzykami, odpowiedzialnością i rzeczywistym zakresem ochrony.
ISO/IEC 27001 określa wymagania wobec SZBI. Rozdziały 4-10 obejmują zarządzanie systemem, a nie tylko techniczne zabezpieczenia. Nie można ich wyłączać, deklarując zgodność z normą. Zakres wyjaśnia oficjalny opis ISO/IEC 27001 w IEC.
Załącznik A jest częścią ISO/IEC 27001. Pomaga porównać potrzebne zabezpieczenia z uporządkowanym katalogiem. Nie ogranicza organizacji do korzystania wyłącznie z tego katalogu.
ISO/IEC 27002 rozwija wskazówki dotyczące zabezpieczeń. Nie jest odrębnym standardem certyfikacji SZBI. Relację między dokumentami opisuje ISO.
W dokumentacji pilnuj pełnych oznaczeń. A.8.2 w Załączniku A odnosi się do uprawnień uprzywilejowanych. Rozdział 8.2 w głównej części ISO/IEC 27001 dotyczy innego zagadnienia. Pominięcie prefiksu i nazwy dokumentu może skierować zespół do niewłaściwego wymagania.
Podział i numerację można sprawdzić w publicznym podglądzie ISO/IEC 27002:2022. Przykłady zastosowania poniżej pokazują proponowany sposób pracy, nie pełną treść poszczególnych zabezpieczeń.
Zakres numeracji to A.5.1-A.5.37. Grupa obejmuje między innymi odpowiedzialność, zasady postępowania z informacją, dostawców, incydenty i ciągłość działania.
Przykład praktyczny: zanim firma kupi usługę chmurową, warto uzgodnić dopuszczalne dane, odpowiedzialność za dostęp i sposób zakończenia współpracy. Samo zatwierdzenie faktury nie dokumentuje tych ustaleń.
Pytanie do właściciela procesu: kto podejmuje decyzję i co potwierdza, że przyjęte zasady są realizowane?
Zakres numeracji to A.6.1-A.6.8. Grupa obejmuje relację organizacji z personelem, świadomość, pracę zdalną i zgłaszanie zdarzeń.
Przykład praktyczny: po szkoleniu pracownik powinien wiedzieć, jak zgłosić pomyłkowe wysłanie dokumentu. Lista obecności potwierdza udział, ale niekoniecznie umiejętność wykonania tej czynności.
Pytanie do HR i bezpieczeństwa: czy zasady są zrozumiałe także dla nowych osób i wykonawców zewnętrznych?
Zakres numeracji to A.7.1-A.7.14. Dotyczą miejsc, sprzętu, nośników i fizycznych warunków ochrony informacji.
Przykład praktyczny: przejście na pracę zdalną nie usuwa pytania o skradziony laptop, dokument pozostawiony w przestrzeni współdzielonej lub przekazanie nośnika do utylizacji.
Pytanie do organizacji: czy analizujemy rzeczywiste miejsca używania i przechowywania informacji, czy tylko adres siedziby?
Zakres numeracji to A.8.1-A.8.34. Grupa obejmuje między innymi dostęp, urządzenia, podatności, konfigurację, kopie, rejestrowanie zdarzeń, sieci i rozwój oprogramowania.
Przykład praktyczny: licencja na narzędzie ochronne nie mówi jeszcze, czy wszystkie istotne systemy są nim objęte i kto obsługuje wykryte problemy.
Pytanie do IT: jaki wynik techniczny i operacyjny potwierdzi, że zabezpieczenie działa w zadeklarowanym zakresie?
Materiał Copla wymaga korekty oznaczeń. Backup to A.8.13, a nie A.8.8. Z kolei A.6.8 dotyczy zgłaszania zdarzeń związanych z bezpieczeństwem informacji, nie uprawnień uprzywilejowanych. W dokumentacji roboczej sprawdzaj numer, nazwę i wydanie normy łącznie.
A.8.2 odnosi się do uprawnień uprzywilejowanych, a A.8.5 do bezpiecznego uwierzytelniania.
Nasza wskazówka: sprawdzaj osobno, czy użytkownik może potwierdzić swoją tożsamość i czy otrzymał właściwy zakres uprawnień. Poprawne logowanie nie uzasadnia nadania mu administracji całym środowiskiem.
A.8.8 dotyczy podatności technicznych, a A.8.9 zarządzania konfiguracją.
Nasza wskazówka: zestawiaj wyniki aktualizacji z przeglądem ustawień. Zainstalowana poprawka nie jest dowodem, że system ma właściwie ograniczony dostęp lub wyłączone zbędne funkcje.
A.8.15 dotyczy rejestrowania zdarzeń, a A.8.16 działań monitorujących.
Nasza wskazówka: potwierdź nie tylko istnienie zapisu, lecz także odbiorcę istotnego sygnału i sposób jego obsługi. Folder z logami nie odpowiada na pytanie, kto zauważy niepożądaną zmianę.
Szczegółowe przykłady pracy z kontami znajdziesz w kategorii Tożsamość, dostęp i bezpieczeństwo chmury.
Cel wyjaśnia, jaki efekt ma przynieść zabezpieczenie. Nie należy jednak traktować opisowej kolumny „Control Objective” z internetowego poradnika jako oficjalnego brzmienia normy.
IAF MD 26 wyjaśnia zmianę struktury: w ISO/IEC 27002:2022 cel opisuje się przy poszczególnym zabezpieczeniu, zamiast stosować wcześniejszy układ celów dla grup zabezpieczeń.
Rekomendujemy oddzielanie trzech pól: odwołania do normy, własnego sposobu realizacji i kryterium odbioru. Dzięki temu wewnętrzna procedura nie jest przedstawiana jako dosłowne wymaganie ISO.
Nie automatycznie, ale żadnej pozycji nie należy pominąć bez rozpatrzenia. Organizacja najpierw ustala potrzebne zabezpieczenia, a następnie porównuje je z Załącznikiem A, aby wychwycić ewentualne pominięcia. Rolę tego porównania potwierdza IAF.
Punktem wyjścia powinny być zakres SZBI, ryzyka i mające zastosowanie wymagania. Potrzebne mogą być również zabezpieczenia własne lub pochodzące z innych źródeł. Załącznik A nie jest maksymalnym dopuszczalnym zakresem ochrony.
Rekomendacja CCyber: nie używaj jednej kolumny do oznaczania, czy zabezpieczenie jest potrzebne i czy zostało wykonane. „Jeszcze nie wdrożyliśmy” nie znaczy „nie dotyczy”. Podobnie priorytet wdrożenia nie jest decyzją o wyłączeniu zabezpieczenia.
Wymaganie 6.1.3 d) ISO/IEC 27001 dotyczy dokumentu wskazującego potrzebne zabezpieczenia, powody ich uwzględnienia, stan wdrożenia oraz uzasadnienia wyłączeń z Załącznika A. Podstawę można sprawdzić w publicznym podglądzie tekstu normy.
SoA nie zastępuje planu postępowania z ryzykiem. Norma wymaga również zatwierdzenia tego planu i akceptacji ryzyk rezydualnych przez właścicieli ryzyka. Ryzyko rezydualne to ryzyko pozostające po uwzględnieniu przyjętego postępowania.
Poza wymaganym zakresem proponujemy powiązać rekord z właścicielem, systemami, procedurą, dowodami i otwartymi działaniami. Można prowadzić te dane w oddzielnych, połączonych rejestrach. Nie trzeba umieszczać całej dokumentacji w jednej komórce arkusza.
Ważne: szczegółowy opis wdrożenia, termin testu i odnośnik do zgłoszenia są praktycznymi rozszerzeniami proponowanego modelu. Nie przedstawiamy ich jako obowiązkowych nazw kolumn narzuconych przez ISO.
Uzasadnienie powinno wynikać z rzeczywistego zakresu i potrzeb ochrony. Nie wystarcza zdanie „nie mamy budżetu” albo „nikt dotychczas o to nie pytał”. Poniższe przykłady pokazują, jak weryfikować takie decyzje.
Sprawdź, co nadal pozostaje po stronie organizacji: urządzenia użytkowników, uprawnienia, konfiguracja usług i nadzór nad dostawcą. Zamiast wyłączać całą grupę, opisz podział wykonania i odpowiednie potwierdzenia.
Ustal, czy firma zamawia rozwój u dostawcy, utrzymuje własne integracje lub wprowadza istotne modyfikacje. Brak etatu programisty nie rozstrzyga jeszcze stosowalności zabezpieczeń związanych z wytwarzaniem.
Odróżnij brak zastosowania od realizacji zewnętrznej. W proponowanym rejestrze wskaż usługę, odpowiedzialność firmy oraz materiał potwierdzający zakres działania dostawcy. Nie zaznaczaj wdrożenia wyłącznie na podstawie ogólnego opisu marketingowego.
Przykład modelowy CCyber, nie opis konkretnego klienta. Firma korzysta z zewnętrznego serwisu aplikacji. Analiza wykazała, że uprawnienia serwisowe wymagają uporządkowania. Poniższy zapis pokazuje możliwy sposób połączenia SoA z wykonaniem.
Odwołanie: A.8.2, uprawnienia uprzywilejowane.
Uzasadnienie stosowania: serwisant może zmieniać konfigurację aplikacji i wpływać na dostępność usługi. Konieczne jest ograniczenie oraz nadzorowanie tego dostępu.
Zakres: wskazana aplikacja produkcyjna i konta zewnętrznych administratorów. Pozostałe systemy wymagają osobnej oceny.
Stan: zabezpieczenie potrzebne, wdrożenie częściowe. Uwierzytelnianie działa, lecz nie zakończono przeglądu zakresu uprawnień i zasad ich odbierania.
Proponowane działanie: ustalić potrzebne role, właściciela zatwierdzającego dostęp, warunki jego aktywacji i sposób zakończenia. Wykonać kontrolowane sprawdzenie na koncie testowym.
Kryterium odbioru: konto wykonuje uzgodnione zadania, nie może wykonać czynności poza zatwierdzonym zakresem, a po odebraniu uprawnień nie odzyskuje dostępu objętą testem ścieżką.
Dowody: decyzja właściciela, konfiguracja roli, zapis przeglądu i wynik testu. Materiały przechowuje się w zatwierdzonym repozytorium, bez haseł i sekretów.
Taki rekord może odwoływać się do działań dotyczących uwierzytelniania i logowania, ale nie oznacza automatycznego spełnienia wszystkich powiązanych zabezpieczeń.
Rekomendujemy rozdzielenie trzech perspektyw: zasad, konfiguracji i wykonanych czynności. Polityka pokazuje oczekiwany sposób działania. Konfiguracja pokazuje ustawienia. Raport z procesu lub testu pomaga potwierdzić wynik w określonym zakresie.
Przykład: zasada nakazuje przegląd uprawnień, system umożliwia wygenerowanie raportu, ale dopiero zakończony przegląd z decyzjami i wykonanymi zmianami pokazuje, że czynność rzeczywiście przeprowadzono.
Do projektowania sprawdzeń można pomocniczo wykorzystać NIST SP 800-53A. Jest to metodyka oceny zabezpieczeń, nie zamiennik wymagań ISO/IEC 27001 ani obowiązek przyjęcia całego katalogu NIST.
Każdy dowód powinien pozwalać ustalić zakres i datę. Nie przedstawiaj testu jednej aplikacji jako wyniku dla wszystkich systemów. Materiał zawierający wrażliwe konfiguracje udostępniaj wyłącznie uprawnionym odbiorcom.
Samo stwierdzenie „wdrożyliśmy 80 z 93 zabezpieczeń” nie wyjaśnia, czy dobór jest właściwy, które luki są istotne ani czy system zarządzania działa.
W raportowaniu proponujemy osobno pokazywać: decyzje o stosowalności wymagające uzupełnienia, potrzebne zabezpieczenia jeszcze niewdrożone, wdrożenia oczekujące na sprawdzenie i działania naprawcze po terminie.
Przy wskaźniku podaj jego znaczenie. „Udział sprawdzonych zabezpieczeń w wybranym zakresie” jest czymś innym niż „poziom zgodności całej firmy z ISO 27001”.
Najpierw uporządkuj podstawę: potwierdź wydanie normy, numery pozycji i zakres SZBI. Nie aktualizuj starego arkusza przez samą zmianę daty w nagłówku.
Następnie sprawdź uzasadnienia: wybierz kilka ryzyk i zobacz, czy prowadzą do konkretnych zabezpieczeń. Potem przejdź w drugą stronę i zapytaj, dlaczego dane zabezpieczenie jest potrzebne.
Na końcu zweryfikuj wykonanie: wybierz reprezentatywną usługę i porównaj deklaracje z jej rzeczywistym stanem. Zapisz braki, właścicieli i kryteria zamknięcia. Pilnych zagrożeń nie odkładaj do ukończenia całego rejestru.
W kategorii Regulacje cyber UE i zgodność rozwijamy zagadnienia wymagań i przygotowania dowodów. Przykłady dotyczące bezpieczeństwa produktów znajdziesz w obszarze Bezpieczne tworzenie oprogramowania i produktów cyfrowych.
Ten artykuł koncentruje się na doborze i realizacji zabezpieczeń Załącznika A. Nie jest pełnym harmonogramem certyfikacji ani oceną zgodności z konkretną ustawą.
Audyt gotowości do ISO/IEC 27001 w CCyber obejmuje identyfikację braków, priorytety, potrzebne polityki i procedury oraz etapowy plan wdrożenia.
Sprawdź, czy Twoja deklaracja stosowania odpowiada rzeczywistemu środowisku. Punktem wyjścia do ustalenia zakresu przeglądu mogą być obecna SoA, zakres SZBI i lista otwartych działań. Przegląd gotowości pomaga przygotować organizację, ale nie jest wydaniem certyfikatu przez jednostkę certyfikującą.
Nie. Jedna procedura może wspierać kilka zabezpieczeń, a pojedyncze zabezpieczenie może wymagać kilku procesów i konfiguracji. Dokumentację organizuj według sposobu działania firmy, zachowując możliwość wskazania właściwych odniesień.
Nie należy zaczynać od narzędzia. Do prowadzenia SoA można wykorzystać kontrolowany dokument lub rejestr. Ważne są spójność, wersjonowanie, uprawnienia i powiązanie z działaniami. Narzędzie nie podejmuje za organizację decyzji o stosowalności.
Nie, jeżeli zabezpieczenie jest potrzebne. Brak wdrożenia należy odzwierciedlić w jego statusie i planie działań. Uzasadnienie wyłączenia odpowiada na inne pytanie niż termin wykonania zadania.
Nie traktuj częstotliwości z internetowego poradnika jako automatycznego wymagania normy. Ustal potrzeby, role i sposób potwierdzania kompetencji oraz świadomości. Odrębny obowiązek częstotliwości może wynikać z innych wymagań dotyczących organizacji.
W Załączniku A ISO/IEC 27001:2022. Rozwinięcie wskazówek znajduje się w ISO/IEC 27002:2022. Korzystaj z właściwego wydania dostępnego przez ISO, IEC lub uprawnionego dystrybutora. Opisowe zestawienie z bloga nie zastępuje brzmienia normy.
Załącznik A pomaga uporządkować ochronę, ale wartość wdrożenia wynika z decyzji i działania. Poprawna numeracja to początek. Dalej potrzebne są uzasadnienie, właściwy zakres, odpowiedzialność i weryfikacja.
Dobra deklaracja stosowania łączy to, czego firma potrzebuje, z tym, co rzeczywiście robi. Nie ukrywa braków pod oznaczeniem „nie dotyczy” i nie przedstawia zakupionego narzędzia jako dowodu skuteczności.
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.