NIS2 samodzielnie czy z firmą wdrożeniową? Porównanie kosztu, czasu i ryzyka

Decyzja „NIS2 samodzielnie czy z firmą wdrożeniową” nie sprowadza się do porównania wynagrodzenia doradcy z kosztem pracy własnego zespołu. O wyniku projektu przesądzają zakres obowiązków, dostępność osób decyzyjnych, jakość danych o procesach i zasobach oraz zdolność organizacji do późniejszego utrzymania przyjętych rozwiązań. Wariant pozornie najtańszy może okazać się najdroższy, jeżeli prowadzi do błędnej kwalifikacji, ponownego wykonywania analiz albo powstania dokumentacji, która nie odpowiada rzeczywistemu działaniu firmy. Dlatego najpierw trzeba rozpoznać zakres i luki, następnie porównać pełny koszt, czas oraz ryzyko trzech modeli realizacji, a dopiero potem wybrać wykonawcę i sposób prowadzenia prac.

Nie wybieraj wykonawcy przed rozpoznaniem obowiązków

Porównanie wdrożenia własnymi siłami ze wsparciem firmy zewnętrznej ma sens dopiero po ustaleniu, czy organizacja podlega obowiązkom wynikającym z NIS2 i polskich przepisów wdrażających te wymagania. Jeżeli podlega, należy określić, których usług, jednostek, lokalizacji i zasobów dotyczy analiza. Bez tej kwalifikacji nie można rzetelnie oszacować zakresu prac, czasu realizacji ani kosztu. Zarząd powinien również wskazać właściciela projektu uprawnionego do uzgadniania decyzji między działalnością operacyjną, działem prawnym i informatyką.

Punktem wyjścia nie jest zakup dokumentacji ani narzędzia informatycznego, lecz opis modelu działalności. Trzeba rozpoznać świadczone usługi, wspierające je procesy, systemy i dane, a także dostawców oraz zależności warunkujące ciągłość działania. Dopiero taka mapa pozwala ustalić, czy analizą należy objąć całą spółkę, czy tylko określone usługi i lokalizacje. Wynikiem pierwszego etapu powinny być: udokumentowana kwalifikacja podmiotu, określone granice zakresu oraz wykaz obszarów wymagających oceny i działań naprawczych.

Formalne podleganie przepisom trzeba odróżnić od biznesowej potrzeby zwiększenia odporności. Organizacja może pozostawać poza zakresem obowiązków ustawowych, a mimo to podlegać wymaganiom klientów, grupy kapitałowej, ubezpieczyciela lub uczestników łańcucha dostaw. Takiego projektu nie należy przedstawiać jako wykonania obowiązku prawnego, lecz jako odpowiedź na konkretne wymagania umowne i ryzyka operacyjne.

Przykładem jest firma produkcyjna, która ma zapory sieciowe, kopie zapasowe i ochronę stacji roboczych, ale nie potrafi wskazać właściciela procesu reagowania na incydent. Nie ustaliła również, jak awaria systemu planowania produkcji wpłynie na harmonogram zleceń, dostępność materiałów i terminowość dostaw. Problemem nie jest wówczas wyłącznie poziom zabezpieczeń technicznych, lecz także brak przypisanej odpowiedzialności i analizy zależności między systemem informatycznym a realizacją usługi.

Po opisaniu działalności należy przeprowadzić ocenę prawną według aktualnych na dzień publikacji kryteriów sektorowych, podmiotowych i wielkościowych. Formalne stanowisko powinno zostać zatwierdzone przez organ lub osobę uprawnioną do reprezentowania organizacji, z udziałem działu prawnego oraz właścicieli usług i procesów. Informatyka dostarcza danych o systemach, lecz nie powinna samodzielnie rozstrzygać kwalifikacji. Zagadnienie to rozwija materiał „Dyrektywa NIS2 – kogo dotyczy i jakie firmy muszą spełnić nowe wymagania?”.

Koszt wdrożenia nie kończy się na fakturze

Wariant samodzielny nie jest bezpłatny, podobnie jak wynagrodzenie firmy wdrożeniowej nie stanowi pełnego kosztu wsparcia zewnętrznego. Kalkulacja powinna obejmować pracę zarządu, właścicieli procesów, informatyków, zakupów, kadr, działu prawnego i pełnomocnika systemu zarządzania. Czas tych osób należy wyceniać według wewnętrznych stawek kosztowych i rzeczywistych roboczogodzin, uwzględniając zadania operacyjne, których nie wykonają podczas projektu. Pracochłonność zależy przede wszystkim od liczby lokalizacji, procesów, systemów, dostawców i spółek objętych zakresem.

Najczęściej niedoszacowane pozostają: zebranie danych, uzgodnienie odpowiedzialności, inwentaryzacja aktywów i dostawców, przygotowanie dowodów, przeprowadzenie testów i szkoleń oraz poprawianie niespójnych regulacji. Firma wdrożeniowa skróci te prace tylko wtedy, gdy potrafi przełożyć wymagania na istniejące procesy, role i narzędzia. Przekazanie wzorcowych polityk bez rozpoznania działalności nie usuwa kosztu, lecz przesuwa go na etap uzgodnień, wdrażania i późniejszych aktualizacji.

Dokumentacja dotycząca incydentów może powstać szybko, lecz pozostanie pozorna, jeżeli nie uzgodniono dyżurów, ścieżki eskalacji, sposobu zabezpieczania dowodów i zastępstw. Rzeczywisty koszt ujawni się podczas testu albo zdarzenia, gdy procedurę trzeba będzie przebudować. Budżet powinien więc oddzielać wydatki jednorazowe od stałych oraz obejmować wynagrodzenie doradcy, nakłady techniczne, przestoje projektowe, poprawki i roczne utrzymanie: przeglądy, testy, szkolenia, aktualizacje dokumentacji, oceny dostawców i obsługę incydentów.

Funkcjonujący system zarządzania bezpieczeństwem informacji lub certyfikat może ograniczyć zakres inwentaryzacji, oceny ryzyka, nadzoru nad dokumentacją i audytów, jeżeli rozwiązania rzeczywiście działają w analizowanym obszarze. Nie zastępuje jednak oceny konkretnych obowiązków wynikających z właściwych przepisów ani sprawdzenia, czy istniejące zabezpieczenia odpowiadają objętym nimi usługom. Zależność tę wyjaśnia materiał NIS2 a ISO 27001: co daje certyfikat, a czego nadal brakuje do zgodności z KSC.

Czas zależy od gotowości do podejmowania decyzji

O czasie przygotowania do wymagań NIS2 rzadko przesądza tempo pisania procedur. Głównymi ograniczeniami są dostępność wiarygodnych danych, właścicieli procesów oraz osób uprawnionych do zatwierdzania zmian. Harmonogram powinien uwzględniać rzeczywistą dostępność tych osób, częstotliwość posiedzeń komitetu sterującego i czas potrzebny na rozstrzygnięcia między działami. Deklarowany termin przekazania dokumentacji nie jest miarą postępu, jeżeli organizacja nie zatwierdziła zakresu, odpowiedzialności i priorytetów.

Prace należy układać według zależności. Najpierw trzeba ustalić zakres, role, procesy i aktywa, następnie przeprowadzić analizę ryzyka, przyjąć plan postępowania z ryzykiem, wdrożyć zabezpieczenia, wykonać testy i zebrać dowody działania. Równolegle można prowadzić zadania oparte na tych samych zatwierdzonych założeniach, na przykład inwentaryzację umów i przegląd istniejących zabezpieczeń. Nie należy natomiast rozpoczynać szczegółowej analizy ryzyka przed wskazaniem usług, procesów, systemów, informacji i zależności od dostawców objętych oceną.

Przy ustalaniu kolejności działań trzeba rozróżnić luki wymagające zakupów, zmian umów, integracji technicznych lub testów. Każda z tych grup ma odmienną ścieżkę zatwierdzania i czas realizacji. Wsparcie zewnętrzne może skrócić diagnozę, usprawnić warsztaty i uporządkować ich wyniki, ale doradca nie podejmie za zarząd decyzji o akceptacji ryzyka, kolejności inwestycji ani tolerowanym czasie przerwy w świadczeniu usług. Jeżeli takie rozstrzygnięcia są odkładane do końca projektu, dokumentacja wyprzedza rozwiązania operacyjne, a część analiz trzeba powtórzyć.

Postęp należy zatem mierzyć liczbą zatwierdzonych decyzji, zamkniętych zależności i zabezpieczeń, których działanie sprawdzono, a nie liczbą opracowanych dokumentów. Nawet harmonogram kilkutygodniowy będzie niewykonalny, gdy organizacja nie ma aktualnej listy systemów, rejestru umów z dostawcami ani uzgodnionych właścicieli procesów. Zespół może wówczas opisać stan deklarowany, lecz nie ustali odpowiedzialności za ciągłość działania, odtworzenie usługi i nadzór nad dostawcą.

Mapowanie procesów powinno wspierać właśnie takie decyzje, a nie rozbudowywać dokumentację. Dobór właściwego poziomu szczegółowości ułatwia porównanie „BPMN czy flowchart – które narzędzie lepiej sprawdza się w mapowaniu procesów jakościowych?”. W tym zastosowaniu właściwe jest narzędzie, które jednoznacznie pokazuje role, miejsca przekazania odpowiedzialności, zależności informacyjne oraz obszary wymagające zabezpieczenia lub zastępstwa.

Ryzyko wynika przede wszystkim z błędnych założeń

O powodzeniu przygotowania do wymagań NIS2 częściej decyduje poprawność założeń niż liczba wykonanych zadań. W modelu samodzielnym największe ryzyko wiąże się z błędną interpretacją zakresu, pominięciem zależności biznesowych oraz sprowadzeniem cyberbezpieczeństwa do odpowiedzialności działu informatycznego. Organizacja może wówczas pominąć procesy produkcyjne, logistykę, utrzymanie ruchu, ciągłość dostaw lub zobowiązania wobec odbiorców. Brakuje również niezależnego spojrzenia na praktyki uznawane wewnętrznie za wystarczające tylko dlatego, że dotąd nie doprowadziły do widocznego zakłócenia.

Wsparcie zewnętrzne nie usuwa tych zagrożeń automatycznie. Ryzyko zwiększa wykonawca, który dostarcza jednolity pakiet dokumentów bez rozpoznania usług, procesów i zależności organizacji, nie angażuje właścicieli procesów albo nie przekazuje wiedzy potrzebnej do utrzymania przyjętych rozwiązań. Powstaje wtedy system zależny od autora dokumentacji, a nie od osób odpowiedzialnych za codzienne działanie.

Warto więc rozdzielić wykonanie prac od niezależnej oceny końcowej, zwłaszcza gdy ten sam podmiot projektował zakres, oceniał ryzyko i dobierał zabezpieczenia. Decyzja o akceptacji ryzyka rezydualnego powinna pozostać po stronie właściwego kierownictwa.

Pozorna zgodność ujawnia się w rozbieżności między zapisem a praktyką: polityka opisuje inne działanie niż rzeczywisty proces, rejestr ryzyka nie wpływa na priorytety i inwestycje, a procedura obsługi incydentów nie została przećwiczona. Luka dokumentacyjna oznacza brak lub niespójność potrzebnego zapisu. Luka operacyjna występuje wtedy, gdy organizacja nie potrafi wykonać działania, przypisać odpowiedzialności albo przedstawić dowodu jego skuteczności. Uzupełnienie formularza może usunąć pierwszą lukę, lecz nie zastąpi testu, decyzji ani zmiany sposobu pracy.

Przykładem jest zakład z zatwierdzoną procedurą zgłaszania incydentów, w którym pracownicy produkcji nie wiedzą, jak zgłosić niedostępność systemu sterującego lub planistycznego. Jednocześnie z dostawcą usługi nie uzgodniono ścieżki eskalacji, osób kontaktowych ani zasad działania poza godzinami pracy. Dokument istnieje, ale podczas zakłócenia pierwsze minuty są tracone na ustalanie odpowiedzialności. Taką lukę wykryje dopiero ćwiczenie obejmujące użytkownika, właściciela procesu, informatykę, kierownictwo i dostawcę.

Audyt gotowości powinien sprawdzać zdolność do działania i przedstawienia wiarygodnych dowodów, a nie samą kompletność dokumentacji. Przydatnymi miarami są liczba niewykonanych działań po wcześniejszych audytach i testach, wyniki prób odtworzeniowych, wnioski z przeglądów incydentów i zakłóceń oraz odsetek kluczowych dostawców objętych oceną i uzgodnionymi wymaganiami — zawsze na podstawie danych organizacji. Sposób prowadzenia takiej weryfikacji rozwija materiał „Audyt NIS2 w firmie produkcyjnej – jak sprawdzić, czy organizacja jest gotowa na nowe obowiązki”.

Model mieszany zwykle zapewnia najlepszą kontrolę

Wybór sposobu wdrożenia powinien wynikać z rzeczywistej zdolności organizacji do wykonania prac, a nie wyłącznie z porównania stawek doradczych. Samodzielne wdrożenie jest racjonalne, gdy projekt ma kompetentnego właściciela, procesy zarządzania ryzykiem są dojrzałe, inwentaryzacje zasobów i zależności pozostają aktualne, a kluczowi pracownicy mają czas i potrafią interpretować wymagania. Pełniejsze wsparcie zewnętrzne jest uzasadnione przy dużej luce kompetencyjnej, rozproszonej strukturze, istotnych zależnościach technologicznych, krótkim czasie przygotowania albo braku uporządkowanego systemu zarządzania.

Najczęściej najlepszą kontrolę kosztu, czasu i ryzyka zapewnia model mieszany. Organizacja zachowuje odpowiedzialność za decyzje, dane źródłowe, właścicielstwo ryzyka i wykonanie działań operacyjnych. Doradca odpowiada za diagnozę, metodykę, prowadzenie warsztatów, analizy wymagające wiedzy specjalistycznej oraz kontrolę jakości wyników.

W organizacji powinny pozostać co najmniej:

• określenie znaczenia procesów i usług;
• wskazanie właścicieli ryzyka;
• akceptacja ryzyka rezydualnego;
• ustalenie priorytetów inwestycyjnych;
• potwierdzenie, że zabezpieczenia działają w praktyce.

Zarząd nie może przekazać wykonawcy odpowiedzialności za odporność organizacji.

Firma z kilkoma zakładami może samodzielnie zebrać informacje o usługach, zasobach, dostawcach i skutkach zakłóceń, ponieważ ich wiarygodna ocena wymaga wiedzy operacyjnej. Zewnętrzny specjalista może następnie uporządkować metodę oceny, zakwestionować niespójności, przeprowadzić warsztaty między działami i sprawdzić kompletność dowodów. O opłacalności takiego podziału przesądzają liczba i kompetencje osób, które można faktycznie oddelegować, a nie formalny skład zespołu projektowego.

Oferty należy porównywać według identycznego zakresu produktów i kryteriów odbioru. Referencje wykonawcy trzeba oceniać przez podobieństwo sektora, skali, procesów i środowiska technologicznego, a nie samą liczbę realizacji. Umowa powinna jednoznacznie określać produkty prac, kryteria odbioru, obowiązek odnoszenia rozwiązań do rzeczywistych procesów, przekazanie wiedzy, zasady poufności i dostępu do danych wrażliwych, odpowiedzialność za poprawki oraz zakres wsparcia po wdrożeniu. Model wynagrodzenia nie powinien premiować liczby dokumentów, lecz osiągnięcie uzgodnionych, możliwych do zweryfikowania rezultatów.

Praktyczne granice odpowiedzialności zarządu, właścicieli procesów i funkcji wspierających rozwija materiał NIS2 w praktyce zarządczej: jak przełożyć wymagania na decyzje, odpowiedzialność i realną odporność organizacji.

Decyzję oprzyj na dowodach i zdolności do utrzymania systemu

Wybór modelu wdrożenia powinien poprzedzać krótka diagnoza organizacyjna. Trzeba potwierdzić zakres projektu, wyznaczyć jego właściciela, ocenić dostępność kompetencji, zinwentaryzować istniejące dowody działania oraz oszacować najważniejsze luki. Dopiero wtedy można ustalić, które prace organizacja wykona samodzielnie, a gdzie udział specjalisty ograniczy ryzyko błędnej interpretacji, przeoczeń lub ponownego wykonywania zadań.

Decyzja zarządu powinna porównywać trzy warianty: realizację własnymi siłami, model mieszany i pełniejsze wsparcie zewnętrzne. Do każdego należy zastosować te same kryteria:

• pełny koszt, w tym pracę personelu, poprawki i utrzymanie;
• czas potrzebny do osiągnięcia zdolności operacyjnej;
• ryzyko błędu i konieczności powtarzania prac;
• rzeczywistą dostępność kompetencji;
• zdolność organizacji do samodzielnego utrzymania rozwiązań.

Uchwała albo decyzja zarządu powinna wskazywać wybrany wariant, zakres odpowiedzialności, właściciela projektu, zasoby, sposób raportowania, kryteria odbioru oraz mierniki skuteczności wynikające z procesów organizacji, a nie z uniwersalnych progów pozbawionych kontekstu.

Wdrożenia nie należy odbierać na podstawie liczby przygotowanych polityk. Rezultatem ma być powtarzalne działanie: przypisane role, udokumentowane decyzje dotyczące ryzyka, zastosowane zabezpieczenia, przetestowane reakcje na zakłócenia i incydenty, nadzór nad dostawcami oraz wiarygodne zapisy. Zatwierdzona procedura reagowania nie potwierdza gotowości, jeżeli test ujawnia nieaktualne kontakty, niejasną ścieżkę eskalacji albo brak osoby uprawnionej do podjęcia decyzji.

Kryteria odbioru powinny obejmować zgodność dokumentów z praktyką, zamknięcie uzgodnionych luk, wyniki testów, przekazanie wiedzy i jednoznaczny plan dalszego doskonalenia, w tym plan audytów wewnętrznych. Wśród dowodów odbiorowych mogą znaleźć się zatwierdzenia, rejestry, wyniki testów, protokoły szkoleń, decyzje dotyczące ryzyka oraz potwierdzenia wykonania działań. Sposób przygotowania i utrzymania takich dowodów rozwija materiał Dokumentacja NIS2 i KSC przed kontrolą: jakie polityki, rejestry i dowody naprawdę trzeba mieć.

Trwałość rozwiązania można ocenić dopiero po ograniczeniu udziału doradcy. Właściciele procesów powinni wtedy samodzielnie aktualizować rejestry, podejmować decyzje dotyczące ryzyka, analizować wyniki testów i inicjować działania korygujące. Jeżeli system działa wyłącznie dzięki wiedzy wykonawcy, projekt nie został zakończony: organizacja otrzymała dokumentację, lecz nie zbudowała zdolności do jej utrzymania.