Co właściwie wdrażasz: klauzule 4-10 i Załącznik A
ISO/IEC 27001:2022 opisuje system zarządzania bezpieczeństwem informacji (SZBI, ang. ISMS). Norma ma dwie części, które łatwo pomylić. Klauzule od 4 do 10 to wymagania obowiązkowe: kontekst organizacji, przywództwo, planowanie, wsparcie, działania operacyjne, ocena efektów i doskonalenie. Nie można z nich zrezygnować ani ich wyłączyć.
Załącznik A zawiera 93 zabezpieczenia pogrupowane w cztery tematy: organizacyjne (37), ludzkie (8), fizyczne (14) i technologiczne (34). To katalog odniesienia, a nie lista do odhaczenia. Wybierasz zabezpieczenia na podstawie analizy ryzyka i uzasadniasz zarówno te zastosowane, jak i wyłączone. Okres przejściowy dla certyfikatów według wersji z 2013 roku zakończył się 31 października 2025 r., więc dziś wdraża się wyłącznie wersję 2022.
Krok 1-3: decyzja zarządu, analiza luk i zakres
Krok pierwszy to formalna decyzja kierownictwa. Klauzula 5 wymaga, aby najwyższe kierownictwo wykazało przywództwo: zatwierdziło politykę bezpieczeństwa informacji, przydzieliło role i zapewniło zasoby. W praktyce wystarczy krótka uchwała lub zarządzenie, wskazanie właściciela projektu i budżetu na czas pracy ludzi.
Krok drugi to analiza luk. Porównujesz stan obecny z wymaganiami klauzul 4-10 i z tematami Załącznika A. Celem nie jest raport na sto stron, tylko lista braków z priorytetami, którą później zamienisz w harmonogram.
Krok trzeci to zakres SZBI (klauzula 4.3). Określasz, które lokalizacje, procesy, usługi i systemy obejmuje system oraz jakie są interfejsy i zależności z podmiotami zewnętrznymi. Zbyt wąski zakres, na przykład tylko dział IT bez procesów sprzedaży czy obsługi klienta, bywa kwestionowany przez klientów, którzy wymagają certyfikatu. Zbyt szeroki zakres wydłuża projekt bez potrzeby.
- Dokument zakresu z listą lokalizacji, usług i wyłączeń wraz z uzasadnieniem
- Analiza kontekstu: czynniki wewnętrzne i zewnętrzne (4.1)
- Lista stron zainteresowanych i ich wymagań, w tym umownych i prawnych (4.2)
Krok 4-5: metodyka i analiza ryzyka
Klauzula 6.1.2 wymaga zdefiniowania procesu oceny ryzyka: kryteriów akceptacji ryzyka, sposobu identyfikacji, analizy i oceny oraz wskazania właścicieli ryzyk. Metodyka musi dawać spójne, powtarzalne i porównywalne wyniki. Nie musi być skomplikowana. Dla większości MŚP wystarczy skala prawdopodobieństwa i skutku od 1 do 5 oraz jasno zapisany próg akceptacji.
Następnie przeprowadzasz samą analizę. Można zacząć od aktywów informacyjnych (systemy, bazy danych, dokumenty, ludzie, dostawcy) albo od scenariuszy zdarzeń. Ważne, aby każde ryzyko miało właściciela, który formalnie akceptuje ryzyko rezydualne. Audytorzy często proszą o pokazanie podpisu lub wpisu, z którego wynika ta akceptacja.
Sprawdź gotowość bezpłatnie
10–15 minut, bez konta: wynik gotowości, raport luk i rekomendacje AI.
Krok 6-7: deklaracja stosowania i plan postępowania z ryzykiem
Deklaracja stosowania (Statement of Applicability, SoA) wynika z klauzuli 6.1.3 d. Zawiera wszystkie 93 zabezpieczenia z Załącznika A, informację, czy są stosowane, uzasadnienie włączenia lub wyłączenia oraz status wdrożenia. To jeden z pierwszych dokumentów, które audytor czyta podczas etapu 1.
Plan postępowania z ryzykiem (6.1.3 e) opisuje, co, kto i do kiedy zrobi, aby obniżyć ryzyka powyżej progu akceptacji. Typowy błąd polega na tym, że SoA deklaruje zabezpieczenie jako wdrożone, a w planie nadal widnieje ono jako zadanie otwarte. Te dwa dokumenty muszą być ze sobą spójne.
- Każde wyłączenie w SoA ma konkretne uzasadnienie, a nie formułę nie dotyczy
- Zabezpieczenia z planu mają przypisanego właściciela i termin
- Cele bezpieczeństwa (6.2) są mierzalne, na przykład czas wdrażania krytycznych poprawek
Krok 8: wdrożenie zabezpieczeń i dokumentacji
Teraz zaczyna się właściwa praca operacyjna. Norma wymaga udokumentowanych informacji tylko w określonych miejscach, ale w praktyce potrzebujesz zestawu polityk i procedur, które opisują, jak działają wybrane zabezpieczenia. Lepiej mieć dziesięć krótkich dokumentów, które ludzie faktycznie znają, niż jeden podręcznik, którego nikt nie otwiera.
Najczęściej wdrażane w MŚP obszary to zarządzanie dostępem i uwierzytelnianiem, zarządzanie dostawcami, kopie zapasowe, zarządzanie podatnościami, logowanie i monitorowanie, obsługa incydentów oraz ciągłość działania. Wersja 2022 dodała m.in. zabezpieczenia dotyczące analizy zagrożeń (threat intelligence), bezpieczeństwa usług chmurowych, zarządzania konfiguracją, usuwania informacji, maskowania danych i zapobiegania wyciekom danych.
Równolegle prowadzisz szkolenia i budowanie świadomości (klauzule 7.2 i 7.3). Audytor zapyta losowego pracownika, gdzie znajdzie politykę bezpieczeństwa i jak zgłosić incydent. Odpowiedź nie wiem jest jednym z najczęstszych źródeł niezgodności.
Krok 9: audyt wewnętrzny i przegląd zarządzania
Zanim zaprosisz jednostkę certyfikującą, system musi działać przez pewien czas i wygenerować zapisy. Klauzula 9.2 wymaga programu audytów wewnętrznych, przeprowadzanych przez osoby zachowujące obiektywizm. W małej firmie audytor wewnętrzny nie może sprawdzać własnej pracy, dlatego często korzysta się z osoby z innego działu lub zewnętrznego audytora wewnętrznego.
Klauzula 9.3 wymaga przeglądu zarządzania z określonymi danymi wejściowymi: status działań z poprzednich przeglądów, zmiany w kontekście, wyniki monitorowania, wyniki audytów, informacje zwrotne od stron zainteresowanych, wyniki oceny ryzyka i możliwości doskonalenia. Protokół z przeglądu jest dowodem, o który audytor certyfikujący poprosi niemal zawsze.
Niezgodności znalezione w audycie wewnętrznym trzeba obsłużyć zgodnie z klauzulą 10.2: korekcja, analiza przyczyn, działania korygujące i ocena ich skuteczności. Samo poprawienie objawu nie wystarczy.
Najczęstsze błędy, które wychodzą na audycie
Większość niezgodności w pierwszym audycie certyfikującym nie dotyczy braku firewalla czy szyfrowania. Dotyczy rozjazdu między tym, co firma zapisała, a tym, co robi na co dzień. Audytor porównuje dokumenty z rzeczywistością, wybierając próbki: kilka kont użytkowników, kilka umów z dostawcami, kilka zgłoszeń incydentów, kilka zmian w systemach.
Drugim częstym problemem jest analiza ryzyka wykonana raz, na początku projektu, i nigdy niezaktualizowana. Klauzula 8.2 wymaga przeprowadzania oceny ryzyka w zaplanowanych odstępach czasu oraz przy istotnych zmianach. Nowy system CRM, przejście do chmury czy zmiana kluczowego dostawcy powinny znaleźć odzwierciedlenie w rejestrze ryzyk.
- Konta byłych pracowników nadal aktywne w systemach lub aplikacjach SaaS
- Brak przeglądów uprawnień albo przeglądy bez śladu, kto i kiedy je wykonał
- Umowy z dostawcami bez klauzul dotyczących bezpieczeństwa informacji i zgłaszania incydentów
- Kopie zapasowe wykonywane, ale nigdy nietestowane pod kątem odtworzenia
- Rejestr incydentów pusty, mimo że w firmie zdarzyły się phishingi lub zgubione laptopy
- Cele bezpieczeństwa zapisane ogólnikowo, bez miary i bez monitorowania postępu
- Szkolenia przeprowadzone, ale bez listy obecności lub potwierdzenia zapoznania się
Krok 10: certyfikacja i utrzymanie
Certyfikacja składa się z dwóch etapów. Etap 1 to przegląd dokumentacji i gotowości: zakres, SoA, metodyka ryzyka, polityka, wyniki audytu wewnętrznego i przeglądu zarządzania. Etap 2 to ocena wdrożenia na miejscu lub zdalnie, z rozmowami z pracownikami i weryfikacją zapisów. Warto wybrać jednostkę akredytowaną, w Polsce akredytacji udziela Polskie Centrum Akredytacji.
Certyfikat jest ważny trzy lata, a w tym czasie odbywają się coroczne audyty nadzoru. Po trzech latach następuje recertyfikacja. Oznacza to, że SZBI musi stale generować dowody: kolejne audyty wewnętrzne, przeglądy, aktualizacje analizy ryzyka i obsługę incydentów.
Czas trwania całego projektu zależy od wielkości firmy, dojrzałości obecnych praktyk i dostępności ludzi. Rozsądniej jest zaplanować harmonogram na podstawie wyników analizy luk niż przyjmować z góry termin narzucony przez klienta. Bezpłatna samoocena na baltum.ai pokazuje, w których klauzulach i tematach Załącznika A masz największe luki, zanim zaczniesz planować budżet.
Najczęstsze pytania
Czy muszę wdrożyć wszystkie 93 zabezpieczenia z Załącznika A?
Nie. Musisz rozważyć wszystkie 93 i w deklaracji stosowania uzasadnić, dlaczego każde z nich jest stosowane lub wyłączone. Decyzja wynika z analizy ryzyka, wymagań prawnych i umownych. Wyłączenia bez uzasadnienia są częstą przyczyną uwag audytora.
Jakie dokumenty są obowiązkowe w ISO 27001?
Norma wymaga udokumentowanych informacji m.in. dla zakresu, polityki bezpieczeństwa informacji, procesu oceny i postępowania z ryzykiem, deklaracji stosowania, celów bezpieczeństwa, dowodów kompetencji, wyników monitorowania, programu i wyników audytów wewnętrznych, przeglądu zarządzania oraz niezgodności i działań korygujących. Pozostałe dokumenty tworzysz wtedy, gdy są potrzebne do skutecznego działania zabezpieczeń.
Czy mała firma może wdrożyć ISO 27001 bez konsultanta?
Tak, norma nie wymaga wsparcia zewnętrznego. Kluczowe jest, aby w firmie była osoba z czasem i mandatem od zarządu oraz aby audyt wewnętrzny przeprowadził ktoś niezależny od audytowanego obszaru. Wiele firm korzysta z narzędzi do samooceny, aby uporządkować pracę przed wyborem jednostki certyfikującej.
Czym różni się etap 1 od etapu 2 audytu certyfikującego?
Etap 1 ocenia, czy system jest zaprojektowany i udokumentowany zgodnie z normą oraz czy firma jest gotowa na etap 2. Etap 2 sprawdza, czy system faktycznie działa: audytor rozmawia z ludźmi, przegląda zapisy i weryfikuje działanie zabezpieczeń. Niezgodności duże muszą zostać zamknięte przed wydaniem certyfikatu.
Czy ISO 27001 pomaga w spełnieniu wymagań NIS2?
Tak, w dużej części. Systemowe podejście do ryzyka, obsługa incydentów, zarządzanie dostawcami i ciągłość działania pokrywają się z obszarami wymaganymi przez NIS2. Certyfikat nie zastępuje jednak obowiązków ustawowych, takich jak rejestracja czy terminy zgłaszania incydentów.
Sprawdź gotowość bezpłatnie
10–15 minut, bez konta: wynik gotowości, raport luk i rekomendacje AI.
Źródła
Artykuł ma charakter informacyjny i nie stanowi porady prawnej. baltum.ai to niezależne oprogramowanie, a nie jednostka certyfikująca.