Wdrożenie ISO 27001 krok po kroku: ile trwa, jak wygląda proces i co sprawdza audyt certyfikujący

Wdrożenie a certyfikacja: dwie różne rzeczy

Zacznijmy od rozplątania pojęć, bo z ich mieszania rodzi się większość nieporozumień w harmonogramach i budżetach. Wdrożenie to budowa systemu zarządzania bezpieczeństwem informacji w Twojej firmie: decyzje, dokumenty, procesy, ludzie. Certyfikacja to moment, w którym niezależna jednostka przychodzi i potwierdza, że ten system istnieje i działa. Ty budujesz, jednostka sprawdza. Konsultant może pomóc w budowie, ale certyfikatu nie wystawia nigdy.

Dlaczego to takie ważne? Bo firmy regularnie zakładają, że po napisaniu dokumentacji certyfikat jest kwestią tygodnia. Nie jest. Między gotową dokumentacją a certyfikatem stoi jeszcze okres, w którym system musi realnie popracować, oraz dwa etapy audytu. O obu piszę dalej i oba trzeba mieć w kalendarzu od pierwszego dnia projektu.

Ile trwa wdrożenie ISO 27001

Widełki, które podaje rynek, są szerokie: od 3 do 12 miesięcy. Moje liczby są węższe: realne minimum przy pełnym zaangażowaniu i gotowej bazie to 4-5 miesięcy, a dla firmy 50-100 osób, startującej z przeciętnego poziomu, typowy wynik to 6-9 miesięcy od decyzji do certyfikatu. Dwanaście i więcej robi się wtedy, gdy projekt idzie po godzinach albo utknie na dokumentacyjnym perfekcjonizmie, o którym piszę w sekcji o błędach.

Od czego zależy tempo? Od czterech rzeczy: wielkości i złożoności organizacji, punktu startu (ile już masz, co pokazuje gap analysis), realnego zaangażowania zespołu oraz jednej rzeczy, o której prawie nikt nie mówi głośno: dostępności terminów w jednostce certyfikującej. Terminy audytów rezerwuje się z wyprzedzeniem i późna rezerwacja potrafi dołożyć do projektu dwa miesiące czekania na samym końcu, gdy wszystko już jest gotowe.

Pełny harmonogram miesiąc po miesiącu, z zaznaczeniem, co można robić równolegle, znajdziesz w sekcji 17. Tu zostawię jedno zdanie, które ustawia oczekiwania: systemu zarządzania nie da się nadrobić w tydzień przed audytem, bo audytor ogląda dowody z przeszłości, a przeszłości nie da się dopisać.

Ile kosztuje wdrożenie ISO 27001

Krótko, bo do liczenia jest lepsze narzędzie niż artykuł. Rząd wielkości dla małej organizacji to 35-55 tys. zł netto za wsparcie wdrożeniowe, plus koszt jednostki certyfikującej (audyt certyfikacyjny i późniejsze coroczne nadzory), plus koszty wewnętrzne, czyli czas Twoich ludzi, o którym za chwilę. Wycenę dopasowaną do Twojej firmy policzysz w kalkulatorze, a szczegółowe rozbicie kosztów masz w artykule ile kosztuje ISO 27001 dla małej firmy. Jak koszty cyklu certyfikacyjnego rozkładają się w czasie, pokazuję w sekcji o nadzorach i recertyfikacji.

Jedna rada zakupowa w tym miejscu: porównując oferty, pilnuj, żeby porównywać ten sam zakres. "Wdrożenie ISO" u jednego dostawcy znaczy pełne prowadzenie projektu z analizą ryzyka i szkoleniami, u innego paczkę szablonów z dwoma telefonami. Różnica w cenie zwykle jest różnicą w zawartości, nie w marży. Jak my dzielimy ten zakres na moduły, zobaczysz na stronie usługi wdrożenia ISO 27001.

Ile czasu zabierze Twojemu zespołowi

Przy gap analysis mogłem Cię uspokoić jednym dniem roboczym. Przy wdrożeniu nie będę zaklinał rzeczywistości: to jest projekt, który przez kilka miesięcy zabiera godziny tygodniowo, a nie godziny łącznie. Uczciwe liczby dla firmy do 100 osób wyglądają mniej więcej tak:

Zewnętrzny konsultant zdejmuje z tej listy dużo, ale nie wszystko: analizy ryzyka nie zrobi za Ciebie w próżni, decyzji zarządu nie podejmie wcale, a rąk Twojego IT przy konfiguracji systemów nie zastąpi. Jeśli ktoś obiecuje wdrożenie "bez angażowania zespołu", to obiecuje segregator, nie system.

Kto musi być zaangażowany po stronie firmy

Lista podobna jak przy analizie luk, ale role są tu cięższe, bo nie opowiadają o stanie firmy, tylko go zmieniają:

• Sponsor z zarządu. Norma wprost wymaga zaangażowania najwyższego kierownictwa i audytor będzie tego zaangażowania szukał w dowodach, nie w deklaracjach. Bez sponsora projekt przegrywa każde starcie z bieżącymi priorytetami.
• Lider projektu. Osoba, która pcha temat do przodu: wewnętrzny koordynator albo zewnętrzny konsultant w tej roli. Często nazywa się ją Pełnomocnikiem ds. SZBI i tu ważna uwaga porządkująca: norma nie wymaga funkcji "pełnomocnika", wymaga przypisania ról i odpowiedzialności. Pełnomocnik to wygodna polska praktyka, nie obowiązek. Więcej o tej roli i o tym, jak ją obsadzić, masz w osobnych tekstach: kim jest pełnomocnik i jak go wybrać.
• IT: właściciel największej paczki zabezpieczeń technicznych.
• HR: onboarding, offboarding, szkolenia, zakresy odpowiedzialności w umowach.
• Właściciele kluczowych procesów i osoba od umów z dostawcami: bo system obejmuje firmę, nie serwerownię.

Samodzielnie, z konsultantem czy z platformą compliance

Trzy realne ścieżki, każda z sensownym zastosowaniem. Będę uczciwy co do wszystkich trzech, łącznie z tą, na której zarabiam:

O platformach dopowiem to samo, co pisałem przy narzędziach do gap analysis: automat świetnie porządkuje dowody i pilnuje terminów, ale nie oceni, czy proces jest stosowany, i nie podejmie za zarząd ani jednej decyzji o ryzyku. Rozsądne hybrydy istnieją: samodzielna praca na dobrych szablonach z konsultantem w roli przeglądającego, albo platforma plus zewnętrzny audyt wewnętrzny. Wybór ścieżki warto zrobić po analizie luk, nie przed, bo dopiero ona mówi, ile pracy naprawdę jest do wykonania.

Kiedy NIE wdrażać ISO 27001

Żyję z wdrożeń, a mimo to zdarza mi się odradzać ich start. Trzy sytuacje, w których na rozmowie mówię wprost: nie teraz.

• Nikt od Ciebie certyfikatu nie wymaga i nie będzie wymagał. Jeśli nie sprzedajesz do enterprise, nie działasz w regulowanej branży i klienci nie przysyłają kwestionariuszy, sam porządek w bezpieczeństwie zbudujesz taniej bez certyfikacji. Norma jako źródło dobrych praktyk: tak. Pełny projekt certyfikacyjny: niekoniecznie. Komu certyfikat realnie się opłaca, opisałem w tekście dla kogo jest ISO 27001.
• Firma jest w środku organizacyjnego trzęsienia ziemi. Fuzja, pivot, wymiana połowy zespołu. System zarządzania buduje się na procesach, a nie da się ustabilizować czegoś, co właśnie się przemeblowuje. Poczekaj kwartał, wyjdzie taniej i sensowniej.
• Motywacja brzmi "bo konkurencja ma". Bez własnego powodu biznesowego projekt umiera po dwóch miesiącach, a wraca jako pilny dopiero, gdy pojawi się realny wymóg, tyle że wtedy pod presją czasu i drożej.

Jest też scenariusz odwrotny, o którym warto wiedzieć: klient enterprise daje Ci w umowie 12 miesięcy na certyfikat. To najlepszy możliwy moment na start, bo projekt ma sponsora, termin i uzasadnienie finansowe w jednym.

Certyfikat czy zgodność bez certyfikatu

Dylemat, który słyszę głównie od SaaS-ów: "a może wdrożymy normę, ale się nie certyfikujemy?". Da się i bywa to racjonalne. Zgodność bez certyfikatu daje Ci uporządkowany system i uczciwą odpowiedź "pracujemy zgodnie z ISO 27001" w kwestionariuszach. Czego nie daje: papieru od niezależnej strony. A praktyka rynkowa jest taka, że im większy klient, tym szybciej deklaracja przestaje wystarczać i pada prośba o certyfikat albo o audyt na Twój koszt.

Moja rada jest prosta: jeśli budujesz system porządnie, dystans między "zgodni" a "certyfikowani" to głównie koszt jednostki i kilka tygodni. Zbuduj tak, żeby decyzja o certyfikacji była dopiskiem do projektu, nie nowym projektem. A jeśli Twoim rynkiem jest USA i klienci pytają o SOC 2 zamiast ISO, przeczytaj najpierw porównanie SOC 2 i ISO 27001, bo być może w ogóle rozmawiamy o innym standardzie.

Jak przebiega wdrożenie ISO 27001 krok po kroku

Czyli odpowiedź na pytanie, jak wdrożyć ISO 27001, w wersji z projektów, nie z podręcznika: trzynaście kroków w kolejności, w jakiej je prowadzę. Kolejność nie jest umowna, każdy krok karmi następny, a ich przestawianie to jeden z cichych powodów, dla których wdrożenia się rozłażą.

Krok 1. Decyzja, sponsor i lider projektu

Projekt zaczyna się od decyzji zarządu z nazwiskiem sponsora i wskazaniem lidera. Nie od kupna szablonów. Zaangażowanie kierownictwa to nie ceremonia, tylko wymaganie, z którego audytor będzie rozliczał na dowodach: kto zatwierdzał politykę, kto uczestniczył w przeglądzie, kto akceptował ryzyka. Jeśli zarząd planuje "podpisać, co trzeba, na końcu", lepiej nie zaczynać.

Krok 2. Zakres SZBI

Co obejmuje system: cała spółka czy jej część? Przykład z SaaS, bo tam ten dylemat wraca najczęściej: zakresem można objąć produkt i zespoły wokół niego (inżynieria, wsparcie, infrastruktura), zostawiając poza nim np. odrębną linię biznesową. Węższy zakres to szybszy projekt i tańszy audyt, ale uwaga: klient patrzący na certyfikat sprawdzi, czy zakres obejmuje usługę, którą od Ciebie kupuje. Zakres pisany pod skrócenie projektu, a nie pod klienta, mści się przy pierwszym kwestionariuszu.

Krok 3. Gap analysis jako punkt startu

Zanim zaplanujesz robotę, zmierz dystans. Temu służy analiza luk i nie będę tu powtarzał całego tematu, bo poświęciłem mu osobne kompendium. Z perspektywy wdrożenia ważne jest jedno: wynik gap analysis staje się listą zadań projektu i podstawą harmonogramu. Firmy, które ten krok pomijają, planują wdrożenie na wyczucie i zwykle dowiadują się o skali braków w najgorszym momencie, czyli od audytora.

Krok 4. Kontekst organizacji i strony zainteresowane

Krok, który wszyscy chcą przeskoczyć, bo brzmi akademicko: opisanie, czym firma jest, kto czego od niej oczekuje (klienci, regulatorzy, właściciele, pracownicy) i co z tego wynika dla bezpieczeństwa. A potem audytor otwiera audyt właśnie od tego i sprawdza, czy reszta systemu się z tym opisem klei. Zrób ten krok uczciwie na jednym warsztacie z zarządem, a dalsze decyzje o ryzyku i zabezpieczeniach przestaną być zgadywaniem.

Krok 5. Procesy krytyczne i ich wymagania (BIA)

Krok, którego nie znajdziesz pod tą nazwą w spisie wymagań normy, a który u mnie zawsze poprzedza analizę ryzyka, bo robi ją o połowę prostszą. Siadasz z właścicielami procesów i zasobów i ustalacie: które procesy są dla firmy krytyczne, na jakich systemach, danych i ludziach wiszą, jak długo firma wytrzyma ich przestój i ile danych może bezpowrotnie stracić. W metodyce ciągłości działania nazywa się to analizą wpływu na biznes, w skrócie BIA.

Efekt jest podwójny. Po pierwsze analiza ryzyka przestaje być teoretyczna: wiesz, co chronić najpierw i przed czym, bo priorytety wynikają z wymagań biznesu, a nie z wyobraźni zespołu projektowego. Po drugie zebrane od właścicieli wymagania (dopuszczalne przestoje, priorytety odtwarzania) to gotowy wsad do planów ciągłości działania, które i tak zrobisz przy zabezpieczeniach. Dwie pieczenie z jednej serii warsztatów: licz zwykle 2-3 godziny na proces, z jego właścicielem przy stole.

Krok 6. Analiza ryzyka i plan postępowania

Serce systemu. Ustalasz metodykę (jak oceniacie i co jest akceptowalne), identyfikujesz ryzyka dla informacji, oceniasz je i decydujesz, co z nimi robisz: ograniczasz zabezpieczeniami, przenosisz, unikasz albo świadomie akceptujesz. Dwa praktyczne ostrzeżenia. Pierwsze: metodyka ma być prosta na tyle, żebyście umieli ją powtórzyć za rok bez konsultanta. Druga: wyniki tej analizy muszą się zgadzać z resztą systemu, bo rozjazd między rejestrem ryzyk a wybranymi zabezpieczeniami to klasyka ustaleń audytowych.

Krok 7. Deklaracja Stosowania

SoA to dokument, po który audytor sięga jako po mapę całego systemu: 93 zabezpieczenia Załącznika A, przy każdym decyzja "stosujemy / nie stosujemy" z uzasadnieniem. Sedno, które odróżnia dobrą SoA od odbębnionej: wybór zabezpieczeń ma wynikać z Twojej analizy ryzyka, a nie z przeklejenia pełnej listy "na wszelki wypadek". Wykluczenia są w porządku, jeśli umiesz je uzasadnić; stosowanie wszystkiego bez refleksji jest podejrzane, bo znaczy, że nikt nie myślał.

Krok 8. Dokumentacja bez przerostu

Norma wymaga konkretnego, wcale nie ogromnego zestawu udokumentowanych informacji plus tego, co sami uznacie za potrzebne. I tu wpada najskuteczniejszy opóźniacz wdrożeń, jaki znam: perfekcjonizm dokumentacyjny, czyli trzecie przepisywanie polityki, która już za pierwszym razem była audytowalna. Zasada robocza: dokument ma opisywać to, co robicie, językiem, który zespół rozumie, i mieć właściciela. Tyle. Nie musisz też pisać od zera: sensowną bazą jest sprawdzony zestaw wzorców dopasowywany do firmy, nie pisany na kolanie. W naszych wdrożeniach taki zestaw jest częścią projektu, więc biała kartka w ogóle nie wchodzi do gry.

Krok 9. Wdrożenie zabezpieczeń

Realizujesz to, co wybrałeś w SoA, w czterech domenach Załącznika A: organizacyjnej, osobowej, fizycznej i technologicznej. Nie będę przechodził po liście 93 pozycji, bo to praca projektu, nie artykułu. Podpowiem za to zasadę kolejności: najpierw zabezpieczenia zamykające ryzyka ocenione najwyżej i te, które potrzebują czasu, żeby zostawić ślad (przeglądy dostępów, obsługa incydentów, kopie z testami odtworzenia), bo ich dowody będą audytorowi potrzebne najbardziej.

Krok 10. Szkolenia i świadomość

Każda osoba w zakresie systemu ma wiedzieć, co z niego dla niej wynika, i ma na to istnieć zapis. Temat rozpisałem w dwóch osobnych tekstach: co powinni wiedzieć pracownicy i jak zorganizować szkolenia pod ISO, więc tu tylko jedno zdanie z sali audytowej: na Stage 2 audytor nie pyta o świadomość Ciebie, pyta losowo wybranych ludzi z zespołu. Szkolenie "odhaczone" mailem poznaje się po odpowiedziach w trzydzieści sekund.

Krok 11. Okres działania systemu

Najczęściej pomijany krok w polskich przewodnikach, a bez niego cały harmonogram jest fikcją. Po zbudowaniu system musi realnie popracować, zanim przyjdzie audyt. To nie jest zapis normy, tylko twarda praktyka jednostek certyfikujących: audytor na Stage 2 chce zobaczyć dowody funkcjonowania, a te potrzebują czasu, żeby powstać. W praktyce mówimy o co najmniej 2-3 miesiącach życia systemu, w których wydarzy się minimum jeden pełny audyt wewnętrzny i przegląd zarządzania, uzbierają się zapisy z przeglądów, szkoleń i ewentualnych incydentów.

Wpisz ten okres do harmonogramu od początku. Firmy, które go nie planują, kończą budowę systemu i dopiero wtedy odkrywają, że do audytu zostały jeszcze miesiące, tyle że już bez momentum i z rozczarowanym zarządem.

Krok 12. Audyt wewnętrzny

Obowiązkowy element systemu i generalna próba przed certyfikacją: własny albo zlecony przegląd, czy robicie to, co zapisaliście. Ma pokryć cały system, znaleźć problemy przed jednostką i zostawić po sobie raport oraz działania korygujące. Jak go zaplanować i przeprowadzić, opisałem krok po kroku w tekście o audycie wewnętrznym ISO 27001. Jedna uwaga tutaj: audyt wewnętrzny zrobiony "na miękko", żeby ładnie wyszło, to prezent dla audytora certyfikującego, bo znajdzie wszystko to, czego Wasz audytor grzecznościowo nie zauważył.

Krok 13. Przegląd zarządzania

Zarząd siada nad systemem: wyniki audytu wewnętrznego, ryzyka, incydenty, skuteczność zabezpieczeń, potrzebne zasoby. I podejmuje decyzje, bo to po decyzjach, nie po protokole, poznaje się przegląd zrobiony naprawdę. Przegląd "pod dokumentację", z protokołem bez jednego postanowienia, audytorzy rozpoznają natychmiast, sam rozpoznaję je na audytach wewnętrznych bez pudła. Dobra wiadomość: porządny przegląd to półtorej godziny z sensowną agendą, mniej niż niejedno spotkanie statusowe.

Jak wybrać jednostkę certyfikującą

Trzy kryteria, w tej kolejności:

• Akredytacja. Pierwsze sito, o którym w Polsce mówi się zaskakująco mało: jednostka ma mieć akredytację uznanego organu (w Polsce PCA, za granicą organy zrzeszone w IAF) na certyfikację ISO 27001. Certyfikat od nieakredytowanej jednostki bywa tańszy i bywa też odrzucany przez klientów enterprise przy pierwszej weryfikacji. Sprawdzenie akredytacji zajmuje pięć minut w publicznym rejestrze i oszczędza bardzo drogą pomyłkę. Do porównania jednostek działających w Polsce polecam też przegląd jednostek certyfikujących na Certiget: akredytacje, normy i lokalizacje zebrane w jednym miejscu.
• Terminy. Audyty w rozpoznawalnych jednostkach rezerwuje się z wyprzedzeniem, w sezonie nawet 2-3 miesiące naprzód. Rezerwuj Stage 1, gdy system wchodzi w okres działania, nie gdy wszystko jest gotowe. To najtańszy sposób skrócenia projektu, jaki istnieje.
• Rozpoznawalność u Twoich klientów. Formalnie każdy akredytowany certyfikat jest równoważny. Praktycznie, jeśli Twoi klienci to np. niemieckie korporacje, logo jednostki, którą znają, potrafi ułatwić rozmowy.

I zasada, która porządkuje rynek: jednostka certyfikująca musi być niezależna od wdrożenia. Ten, kto pomagał budować Twój system, nie może go certyfikować. Jeśli ktoś oferuje jedno i drugie w pakiecie, to nie jest okazja, tylko sygnał ostrzegawczy najwyższego kalibru.

Stage 1: przegląd gotowości

Opisuję oba etapy z pozycji, z której je znam: osoby, która przygotowuje firmy do tych audytów i towarzyszy im po stronie audytowanego. Stage 1 to przegląd dokumentacji i ogólnej gotowości: audytor sprawdza zakres, SoA, analizę ryzyka, obowiązkowe elementy systemu i ocenia, czy firma jest gotowa na etap drugi. Coraz częściej odbywa się zdalnie.

Ustawienie oczekiwań: uwagi po Stage 1 to norma, nie katastrofa. Formę ich przekazania jednostki mają różną: u części dostaniesz pisemne podsumowanie, a w praktyce, którą znam najlepiej, wraca się do nich na spotkaniu otwierającym Stage 2, gdzie pada decyzja zarządu, jak i kiedy je domykacie, przy czym drobne rzeczy bywają zamykane jeszcze w trakcie audytu. Odstęp między etapami też bywa różny: od tygodnia czy dwóch, gdy uwag jest mało, po kilka tygodni, gdy jest co poprawiać albo kalendarz jednostki nie daje wcześniejszego terminu. Ten czas to ostatnie okno na spokojne poprawki, bo na Stage 2 improwizować się już nie da.

Stage 2: audyt właściwy

Etap, na którym rozstrzyga się certyfikacja: audytor sprawdza, czy system działa, a nie czy jest opisany. Jak to wygląda od środka: rozmowy z pracownikami różnych działów, przegląd dowodów (zapisy z przeglądów dostępów, obsłużone incydenty, wyniki audytu wewnętrznego, protokół przeglądu zarządzania, listy szkoleń), oglądanie zabezpieczeń w działaniu. Długość zależy od wielkości organizacji i zakresu: w małych firmach to zwykle 2-3 dni audytowe, w większych odpowiednio więcej, bo czas audytu jednostki wyliczają według reguł swojej akredytacji, nie według uznania handlowca.

Czego audytor NIE robi, wbrew obiegowym strachom: nie łapie ludzi za słówka, nie oczekuje recytowania numerów kontroli i nie szuka pretekstu do oblania. Szuka dowodów, że system żyje. Najlepsze przygotowanie zespołu do Stage 2 nie polega na wkuwaniu polityk, tylko na jednym komunikacie: opowiadajcie, jak naprawdę pracujecie, a jak czegoś nie wiecie, powiedzcie, gdzie byście to sprawdzili. Odpowiedź "mamy to w procedurze X, sprawdziłbym tam" jest lepsza niż wyuczona formułka, bo pokazuje działający system, a nie przygotowany teatr.

Niezgodność duża i mała: co naprawdę oznaczają

Słowo "niezgodność" brzmi jak wyrok, a jest zwykłym narzędziem pracy audytora. Różnica między dużą a małą ma za to bardzo praktyczne skutki:

Zasada spinająca obie kolumny: żadna niezgodność nie zostaje bez odpowiedzi przed decyzją certyfikacyjną. Różnica dotyczy tego, czego jednostka wymaga do wydania certyfikatu: przy dużej wykonanej i zweryfikowanej korekty, przy małej zaakceptowanego planu z terminem. Wniosek praktyczny: bój się nie niezgodności, tylko niespodzianek. Firma po rzetelnym audycie wewnętrznym zna swoje słabe punkty przed jednostką i na audycie certyfikacyjnym nie dowiaduje się niczego nowego. To jest osiągalny standard i do niego przygotowuję klientów.

Najczęstsze niezgodności na audytach

Wzorce, które widuję na audytach wewnętrznych i przy przygotowaniach do certyfikacji, u siebie i w branżowych podsumowaniach jednostek. Powtarzalność jest tu równie duża jak przy lukach z gap analysis:

• Analiza ryzyka oderwana od reszty systemu. Rejestr ryzyk swoje, SoA swoje, zabezpieczenia swoje. Audytor połączy te trzy dokumenty w pięć minut i zapyta, czemu się nie zgadzają.
• Przegląd zarządzania bez decyzji. Protokół jest, postanowień brak. Pisałem o tym wyżej i piszę drugi raz, bo to jeden z najczęstszych zarzutów w ogóle.
• Audyt wewnętrzny niepokrywający całego systemu. Przejrzano IT, pominięto HR i dostawców. Formalnie audyt był, praktycznie nie spełnił swojej roli.
• Przeglądy dostępów na papierze. Procedura jest, ostatni faktyczny przegląd był "przy okazji", konta byłych pracowników żyją. Ten sam wzorzec, który w kompendium gap opisałem jako typową lukę, tu wraca jako typowa niezgodność.
• Ciągłość działania bez testów. Plany istnieją, nikt ich nie ćwiczył, więc nie wiadomo, czy działają. Dla audytora plan nietestowany to deklaracja, nie zabezpieczenie.
• Leczenie objawów w działaniach korygujących. Poprawiono znaleziony przypadek, nie ruszono przyczyny, problem wraca w kolejnym audycie w nowym miejscu.

Wspólny mianownik wszystkich sześciu: to nie są braki wiedzy, to są braki rytmu. System był budowany zrywem, a nie prowadzony stale. Dlatego tak upieram się przy okresie działania systemu z kroku 11.

Certyfikat, nadzory i recertyfikacja

Certyfikat jest ważny 3 lata i to nie jest okres ciszy. Cykl wygląda tak:

• Rok 1 i 2 po certyfikacji: audyty nadzoru. Krótsze wizyty (zwykle ułamek czasu audytu certyfikacyjnego), na próbce systemu, z naciskiem na to, co się zmieniło, i na status działań korygujących. Kosztowo licz rząd 30-50% audytu głównego rocznie.
• Rok 3: recertyfikacja. Pełniejszy audyt odnawiający certyfikat na kolejne 3 lata, zwykle już bez osobnego Stage 1, bo jednostka zna Twój system.

Praktyczna konsekwencja, którą warto usłyszeć przed projektem, nie po: certyfikacja to nie meta, tylko wejście w stały rytm. Budżet i kalendarz na nadzory planuje się razem z decyzją o wdrożeniu, wtedy nic potem nie zaskakuje.

Utrzymanie SZBI na co dzień

Żywy system po certyfikacie ma swój rytm i on wcale nie jest ciężki, jeśli się go trzyma:

• Na bieżąco: obsługa incydentów, nadawanie i odbieranie dostępów zgodnie z procedurą, zapisy z tego, co się dzieje.
• Co kwartał (typowo): przeglądy dostępów, przegląd ryzyk przy większych zmianach, kontrola statusu działań korygujących.
• Co rok: audyt wewnętrzny, przegląd zarządzania, szkolenie przypominające, przegląd dokumentacji, audyt nadzoru jednostki.

Kto ma to robić? W większych firmach wewnętrzna rola, w mniejszych coraz częściej funkcja kupowana jako usługa: od zewnętrznego specjalisty ds. bezpieczeństwa po vCISO, zależnie od skali. To zresztą naturalna kontynuacja wdrożenia: system zbudowany, ktoś musi go prowadzić, a etat bezpiecznika w 50-osobowej firmie rzadko się broni ekonomicznie.

Harmonogram miesiąc po miesiącu

Obiecany konkret, którego brakuje w polskich przewodnikach: realny plan dla firmy 50-100 osób, startującej z przeciętnego poziomu, z konsultantem prowadzącym. Dziewięć miesięcy z buforami, nie wersja marketingowa:

Da się szybciej? Da: mała firma, gotowa baza dokumentacyjna, zdyscyplinowany zespół i wolne terminy w jednostce potrafią zbić to do 4-5 miesięcy. Czego skrócić się nie da, to okresu, w którym system zostawia ślady, i na tym wykłada się każda obietnica "certyfikatu w 6 tygodni". Jeżeli gdzieś taką widzisz, wróć do sekcji o wyborze jednostki i sprawdź akredytację oferującego.

Najczęstsze błędy wdrożeniowe

Zestaw grzechów z projektów, przy których sprzątałem albo które oglądałem z bliska. Częściowo pokrywa się z tym, co w tekście o wyzwaniach wdrożeniowych opisałem od strony trudności; tu patrzę od strony decyzji, których dało się nie podjąć:

1. Projekt "po godzinach". Wdrożenie bez zabudżetowanego czasu lidera rozciąga się z 7 miesięcy na 14 i traci sponsora w połowie. Godziny z sekcji 4 to nie postulat, to warunek.
2. System budowany przez jedną osobę. Lider pisze wszystko sam, firma żyje obok. Na Stage 2 wychodzi to w pierwszej rozmowie z pracownikiem spoza projektu.
3. Perfekcjonizm dokumentacyjny. Trzecia iteracja polityki zamiast pierwszego przeglądu dostępów. Audytowalne i wdrożone bije eleganckie i martwe w każdym starciu.
4. Dokumenty pisane pod audyt. Dwadzieścia procedur na miesiąc przed Stage 1, daty w metadanych, zespół widzi je pierwszy raz. Pisałem to przy gap analysis i powtórzę: szkoda czasu, serio.
5. Brak rezerwacji jednostki. System gotowy w czerwcu, pierwszy wolny termin audytu we wrześniu. Dwa miesiące dryfu, w których projekt stygnie.
6. Uznanie certyfikatu za koniec. Po celebracji system zamiera, a pierwszy audyt nadzoru za rok odkrywa, że żył tylko do certyfikacji. Wróć do sekcji o utrzymaniu, zanim to się przydarzy.

Checklista: jak przygotować firmę do startu projektu

Osiem punktów do odhaczenia przed pierwszym dniem wdrożenia. Godzina pracy, która ustawia cały projekt:

FAQ: najczęstsze pytania o wdrożenie ISO 27001