Analiza zgodności i przygotowanie do audytu NIS2 / ISO 27001
Gap analysis, raport braków, plan naprawczy, budowa procesów, pełna dokumentacja i przygotowanie do audytu - z perspektywy IT i cyberbezpieczeństwa. Zapytaj o wycenę.
Doprowadzamy firmę do zgodności z NIS2 i ISO 27001 od strony, która zwykle decyduje o wyniku audytu - od strony IT i cyberbezpieczeństwa. Zaczynamy od rzetelnej analizy luk, pokazujemy dokładnie czego brakuje, a następnie budujemy procesy i kompletną dokumentację - aż do gotowości na audyt i jego pomyślnego przejścia.
To nie jest „produkcja segregatora z politykami". Łączymy język zgodności z realiami infrastruktury: mapujemy wymagania na konkretne mechanizmy techniczne, wykorzystujemy narzędzia, które już masz, a tam gdzie trzeba - wdrażamy własne (patrz projekt kompleksowej ochrony IT). Materiał czyta się dwutorowo: sekcje „Dla zarządu" tłumaczą wartość i ryzyko, sekcje „Dla IT" - jak to realnie wygląda w pracy.
Gap analysis, raport braków, plan naprawczy, budowa procesów, pełna dokumentacja, wyznaczenie ról i przygotowanie do audytu - z naciskiem na cyberbezpieczeństwo.
01 · KontekstNIS2 z obowiązku, ISO 27001 z przewagi - najlepiej razem
NIS2 (w Polsce: znowelizowana ustawa o KSC, w mocy od 3 kwietnia 2026 r.) to obowiązek prawny dla podmiotów kluczowych i ważnych - z karami do 10 mln euro lub 2% globalnego obrotu i osobistą odpowiedzialnością zarządu. ISO 27001 to dobrowolny, międzynarodowy standard systemu zarządzania bezpieczeństwem informacji (ISMS) - coraz częściej wymagany w przetargach i przez kontrahentów jako twardy dowód dojrzałości.
Te dwa światy świetnie się uzupełniają: dobrze wdrożony ISMS wg ISO 27001 pokrywa znaczną część technicznych i organizacyjnych wymagań NIS2 (art. 21). Dlatego prowadzimy je wspólnie - jedna analiza, jedna dokumentacja, dwa cele zgodności.
Dla zarządu - dlaczego to się opłaca
Brak zgodności z NIS2 to realne ryzyko finansowe i osobiste. Brak ISO 27001 to coraz częściej przegrane przetargi i utracone kontrakty. Jeden projekt zamyka oba tematy: ogranicza ryzyko regulacyjne i jednocześnie staje się argumentem sprzedażowym (certyfikat, którym można się pochwalić klientom). Dostajesz nie listę problemów, lecz gotowość na audyt i utrzymywalny system.
02 · ZakresCo dokładnie analizujemy
Patrzymy na firmę przez pryzmat ISO 27001:2022 (93 zabezpieczenia w 4 grupach z Załącznika A) oraz środków zarządzania ryzykiem z NIS2 (art. 21). Kliknij obszar, aby zobaczyć, co weryfikujemy i jakich dowodów szukamy.
Fundament systemu
Polityki bezpieczeństwa, podział ról i odpowiedzialności, metodyka zarządzania ryzykiem, klasyfikacja informacji, zarządzanie dostawcami (łańcuch dostaw), zarządzanie incydentami i ciągłością działania.
- Co sprawdzamy: czy polityki istnieją, są aktualne, zatwierdzone i realnie stosowane (nie „na półkę").
- Dowody: dokumenty z wersjonowaniem, rejestr ryzyk, umowy z dostawcami, zapisy z przeglądów zarządu.
Najsłabsze (i najczęściej pomijane) ogniwo
Weryfikacja pracowników, zapisy w umowach (poufność), szkolenia i budowanie świadomości, zasady pracy zdalnej, postępowanie dyscyplinarne, zgłaszanie zdarzeń bezpieczeństwa.
- Co sprawdzamy: czy ludzie wiedzą, jak postępować, i czy jest to udokumentowane oraz egzekwowane.
- Dowody: listy obecności na szkoleniach, podpisane zobowiązania, procedura onboarding/offboarding.
Ochrona pomieszczeń i sprzętu
Kontrola dostępu do biur i serwerowni, ochrona sprzętu i nośników, czyste biurko/ekran, bezpieczne niszczenie nośników, zasilanie i warunki środowiskowe.
- Co sprawdzamy: kto i jak wchodzi do stref krytycznych; co dzieje się ze starym sprzętem i dyskami.
- Dowody: rejestry dostępu, polityka nośników, protokoły niszczenia danych.
Serce oceny technicznej (nasza specjalność)
Kontrola dostępu i MFA, kryptografia, kopie zapasowe, logowanie i monitorowanie, zarządzanie podatnościami, ochrona przed złośliwym oprogramowaniem, segmentacja sieci, bezpieczne wytwarzanie oprogramowania.
- Co sprawdzamy: czy mechanizmy realnie działają i są monitorowane - testujemy, nie wierzymy deklaracjom.
- Dowody: konfiguracje, logi z SIEM, raporty skanów podatności, testy odtwarzania kopii.
To, czego ISO 27001 nie wymusza wprost
Zgłaszanie istotnych incydentów w terminach 24 h / 72 h / raport końcowy do CSIRT, bezpieczeństwo łańcucha dostaw, a także nadzór i odpowiedzialność kierownictwa (art. 20) oraz rejestracja podmiotu.
- Co sprawdzamy: czy istnieje proces i zdolność do zgłoszenia incydentu w wymaganym czasie.
- Dowody: procedura zgłaszania, oś czasu incydentu, kontakt do CSIRT, decyzje zarządu.
Audytor nie ocenia intencji, tylko dowody
Najczęstszy powód problemów na audycie to nie brak zabezpieczeń, lecz brak dowodów, że działają. Dbamy, by każdy mechanizm zostawiał ślad: logi, rejestry, metryki, zapisy z przeglądów.
- Co sprawdzamy: czy da się wykazać skuteczność środków danymi, a nie słowem.
- Dowody: centralne logowanie, rejestry (ryzyk, incydentów, dostępu), raporty cykliczne.
03 · ProcesJak pracujemy - od analizy luk do gotowości na audyt
Powtarzalny, etapowy proces. Każdy etap kończy się konkretnym produktem (raport, dokument, działający proces), a nie „statusem w mailu". Kliknij etap, aby zobaczyć szczegóły i efekt.
Inwentaryzacja zasobów, przegląd istniejącej dokumentacji, wywiady z zespołami i techniczna ocena zabezpieczeń. Porównujemy stan faktyczny z wymaganiami ISO 27001 i NIS2. Efekt: pełny obraz „gdzie jesteśmy".
Każda luka opisana, oceniona ryzykiem i przypisana do wymagania (ISO / NIS2). Bez ogólników - konkretnie co, gdzie i dlaczego. Efekt: priorytetyzowana lista braków, zrozumiała dla zarządu i dla IT.
Harmonogram zamknięcia luk: co robimy my, co po stronie klienta, w jakiej kolejności i z jakim terminem. Efekt: realny plan z kamieniami milowymi, dopasowany do terminów NIS2/audytu.
Budujemy procesy zgodne z wytycznymi - najpierw w oparciu o narzędzia, które już masz (skonfigurujemy i połączymy), a gdy ich brakuje, wdrażamy własne. Przykład gotowego stacku: projekt kompleksowej ochrony IT. Efekt: działające procesy, nie tylko opisy.
Komplet dokumentów wymaganych do zgodności i certyfikacji (szczegóły w sekcji 05). Pisane pod realia firmy, nie z szablonu. Efekt: dokumentacja, którą zaakceptuje audytor i którą da się realnie stosować.
Przypisujemy odpowiedzialności (RACI): kto za co odpowiada, kto zatwierdza, kto wykonuje, kto jest informowany - od zarządu po administratorów (szczegóły w sekcji 06). Efekt: jasna struktura, bez „nikt nie wiedział, że to do niego należy".
Przeprowadzamy audyt wewnętrzny/próbny „jak prawdziwy", kompletujemy dowody, domykamy ostatnie braki i przygotowujemy zespół na pytania audytora. Efekt: brak niespodzianek na audycie certyfikacyjnym (Etap 1 i 2).
Towarzyszymy podczas audytu, pomagamy w działaniach poaudytowych i ustawiamy cykl przeglądów (ISMS to proces, nie projekt na raz). Efekt: utrzymywana zgodność i gotowość na audyty nadzoru.
04 · LukiJak wykazujemy braki - mapa stanu zgodności
Wynik analizy prezentujemy jako czytelną mapę stanu: dla każdego obszaru status zgodne / częściowe / brak wraz z konkretną luką i sposobem jej domknięcia. Poniżej przykładowe (typowe) ustalenia z firm na starcie - kliknij wiersz, aby zobaczyć szczegóły.
Typowa luka: są pojedyncze polityki, ale brak spójnej metodyki oceny ryzyka, rejestru ryzyk i Deklaracji Stosowania (SoA). Jak domykamy: metodyka ryzyka + rejestr + SoA dopasowane do firmy.
Typowa luka: MFA tylko na poczcie, konta współdzielone, brak przeglądów uprawnień. Jak domykamy: polityka dostępu, MFA na kluczowych systemach, cykliczny przegląd uprawnień.
Typowa luka: kopie „są", ale nikt nigdy nie testował odtwarzania - to klasyczny powód katastrofy. Jak domykamy: polityka kopii (model 3-2-1), harmonogram i udokumentowane testy odtwarzania.
Typowa luka: logi rozproszone po urządzeniach, brak centralizacji i alertów - bez tego nie da się wykryć ani udowodnić incydentu. Jak domykamy: centralne logowanie i korelacja (np. nasz stack - projekt ochrony IT).
Typowa luka: brak cyklicznych skanów i procesu łatania - podatności wykrywa dopiero atakujący. Jak domykamy: regularne skany, rejestr podatności i proces naprawy z SLA.
Typowa luka: brak procedury i zdolności do zgłoszenia incydentu w terminach NIS2 do CSIRT. Jak domykamy: procedura obsługi i zgłaszania incydentów + szablony i oś czasu.
Typowa luka: jednorazowe szkolenie bez zapisów i bez cyklu. Jak domykamy: program szkoleń, materiały, rejestr uczestnictwa, testy phishingowe.
Typowa luka: umowy z dostawcami bez wymagań bezpieczeństwa, brak oceny ryzyka dostawców. Jak domykamy: klauzule bezpieczeństwa, rejestr i ocena dostawców.
05 · DokumentacjaKomplet dokumentów, który zaakceptuje audytor
Dokumentację piszemy pod realia Twojej firmy, nie z generycznego szablonu - tak, by była zgodna z wymaganiami, a jednocześnie realnie stosowalna. To m.in.:
Polityka ISMS ISO kl. 4-10
Nadrzędna polityka bezpieczeństwa informacji: zakres systemu, cele, zaangażowanie kierownictwa, struktura.
Metodyka i rejestr ryzyka A.5
Spójna metoda oceny ryzyka, rejestr ryzyk i plan postępowania z ryzykiem - serce ISO 27001 i NIS2.
Deklaracja Stosowania (SoA) 93 kontrole
Mapowanie wszystkich 93 zabezpieczeń Załącznika A: które stosujemy, jak i dlaczego (lub uzasadnienie wyłączenia).
Procedura incydentów NIS2 24/72h
Obsługa, klasyfikacja i zgłaszanie incydentów do CSIRT w terminach NIS2 - z szablonami i osią czasu.
Ciągłość działania (BCP/DR) A.5/A.8
Plan ciągłości i odtwarzania po awarii, w tym scenariusze i udokumentowane testy kopii zapasowych.
Polityki wspierające A.5-A.8
Kontrola dostępu, kryptografia, kopie, nośniki, czyste biurko, praca zdalna, klasyfikacja informacji, dostawcy.
Program szkoleń A.6
Plan budowania świadomości, materiały, rejestr uczestnictwa i testy (np. phishingowe).
Rejestry i dowody audyt
Rejestry aktywów, ryzyk, incydentów, uprawnień, dostawców i szkoleń - dowody, których wymaga audytor.
06 · RoleKto za co odpowiada - macierz RACI
Zgodność wymaga jasnego przypisania odpowiedzialności. Wyznaczamy role i budujemy macierz RACI (odpowiedzialny / zatwierdzający / konsultowany / informowany) dla kluczowych procesów - od zarządu po administratorów.
Zarząd / kierownictwo
Nadzór nad bezpieczeństwem (NIS2 art. 20), zatwierdzanie polityk, zapewnienie zasobów, akceptacja ryzyka. Odpowiedzialność osobista.
Pełnomocnik ISMS / CISO
Właściciel systemu zarządzania: koordynacja wdrożenia, utrzymanie dokumentacji, raportowanie do zarządu, kontakt z audytorem.
Właściciele procesów / ryzyk
Odpowiedzialność za ryzyka i zabezpieczenia w swoich obszarach biznesowych; decyzje o postępowaniu z ryzykiem.
IT / Administratorzy
Wdrożenie i utrzymanie zabezpieczeń technicznych, monitorowanie, kopie, łatanie podatności, dostarczanie dowodów.
Zespół reagowania (IRT)
Obsługa incydentów, decyzja o klasyfikacji i zgłoszeniu do CSIRT, komunikacja, działania naprawcze.
Pracownicy
Przestrzeganie polityk, bezpieczne praktyki, zgłaszanie zdarzeń i podejrzeń - pierwsza linia obrony.
07 · NarzędziaBudujemy na tym, co masz - lub wdrażamy własne
Zgodność to procesy, a procesy potrzebują narzędzi. Mamy tu dwie ścieżki - i często łączymy je obie:
Ścieżka A - Twoje obecne narzędzia
Jeśli masz już firewalle, antywirusy, M365/Google Workspace, systemy kopii czy MDM - konfigurujemy je i spinamy tak, by spełniały wymagania i dostarczały dowodów. Bez zbędnych zakupów.
Ścieżka B - nasze narzędzia
Tam, gdzie brakuje mechanizmów (np. centralne logi, skanowanie podatności, zarządzanie incydentami), wdrażamy sprawdzony, tani stack - najczęściej open source, spięty automatyzacją.
Nasz referencyjny stack bezpieczeństwa (OPNsense, Suricata, Zeek, Wazuh, skanery, DefectDojo + automatyzacja) realizuje technicznie większość wymagań NIS2/ISO 27001. Zobacz: Kompleksowa ochrona zasobów IT zgodna z NIS2.
08 · SynergiaNIS2 a ISO 27001 - jak jedno pokrywa drugie
Dobrze zbudowany ISMS wg ISO 27001 spełnia większość środków zarządzania ryzykiem z NIS2 (art. 21). Dlatego jeden projekt realizuje oba cele. Kliknij wymaganie NIS2, aby zobaczyć, jak pokrywa je ISO 27001.
ISO 27001 kl. 6 (planowanie/ryzyko) + A.5 (polityki). Metodyka ryzyka, rejestr i SoA realizują to wprost.
ISO A.5.24-A.5.28 (zarządzanie incydentami) + A.8.15-A.8.16 (logowanie, monitorowanie). Pełny cykl obsługi.
ISO A.5.29-A.5.30 (ciągłość) + A.8.13 (kopie zapasowe). BCP/DR + testy odtwarzania.
ISO A.5.19-A.5.22 (relacje z dostawcami). Ocena i wymagania bezpieczeństwa wobec dostawców.
ISO A.8.8 (zarządzanie podatnościami technicznymi) + A.8.25-A.8.28 (bezpieczne wytwarzanie). Skany + proces naprawy.
ISO A.6.3 (świadomość i szkolenia) + A.8 (higiena techniczna). Program szkoleń + zabezpieczenia podstawowe.
ISO wymaga obsługi incydentów, ale nie narzuca terminów ani zgłoszeń do CSIRT. Dokładamy procedurę i zdolność zgłaszania w reżimie NIS2.
ISO kl. 5 (przywództwo) pokrywa zaangażowanie zarządu; NIS2 dokłada formalną odpowiedzialność i obowiązek szkoleń kierownictwa - ujmujemy to w rolach i procedurach.
09 · Dlaczego myZgodność prowadzona od strony IT i cyber
Wiele firm doradczych dostarcza zgodność „papierową" - komplet dokumentów, które na audycie technicznym się sypią, bo nie mają pokrycia w rzeczywistości. My podchodzimy odwrotnie: zaczynamy od tego, jak naprawdę działa Twoje IT, i budujemy dokumentację na faktach.
Dla IT - co nas wyróżnia
Mówimy jednym językiem z Twoim zespołem. Testujemy mechanizmy zamiast wierzyć w deklaracje, mapujemy wymagania na konkretne konfiguracje i dowody, a gdy brakuje narzędzi - potrafimy je wdrożyć (nie tylko zalecić). To czyni transformację IT w stronę zgodności realną i utrzymywalną, a nie jednorazowym zrywem przed audytem.
Efekt to profesjonalna tranzycja: od chaotycznego „mamy jakieś zabezpieczenia" do udokumentowanego, audytowalnego systemu, który chroni firmę na co dzień i przechodzi audyt NIS2/ISO 27001 bez nerwów.
10 · PodsumowanieOd analizy luk do certyfikatu i zgodności
Bierzemy na siebie całą drogę: rzetelna analiza luk, czytelny raport braków, plan naprawczy, budowa procesów (na Twoich lub naszych narzędziach), pełna dokumentacja, wyznaczenie ról i przygotowanie do audytu - z naciskiem na cyberbezpieczeństwo. Zostajesz z systemem, nie ze stertą papierów.
Sprawdźmy, jak daleko jesteś od zgodności
Zacznijmy od analizy luk (gap analysis). Dostaniesz konkretny obraz braków i plan dojścia do zgodności z NIS2 i ISO 27001 - oraz wycenę dopasowaną do skali firmy.
Umów analizę luk →Powiązane
Zastrzeżenie
Materiał ma charakter informacyjny i edukacyjny - nie stanowi porady prawnej ani oferty handlowej. Zakres, harmonogram i wycena ustalane są indywidualnie po analizie. Liczby (np. czas trwania etapów) są poglądowe i zależą od wielkości oraz dojrzałości organizacji.