Wdrożenie wymogów znowelizowanej ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC) często przekracza wewnętrzne możliwości operacyjne firm, co wymusza korzystanie z zewnętrznych usług IT oraz Security Operations Center (SOC). Należy jednak pamiętać, że delegowanie procesów bezpieczeństwa nie przenosi na dostawcę ostatecznej odpowiedzialności prawnej za zgodność z dyrektywą NIS2, dlatego proces ten wymaga rygorystycznego zabezpieczenia umownego.
Dlaczego outsourcing bezpieczeństwa to naturalny kierunek przy KSC?
Nowa ustawa o KSC, będąca polską implementacją dyrektywy NIS2, nakłada na podmioty kluczowe i podmioty ważne rygorystyczne obowiązki w zakresie monitorowania sieci, wykrywania anomalii oraz reagowania na zagrożenia. Wymóg zachowania ciągłości monitorowania (w trybie 24/7/365) sprawia, że budowa wewnętrznego zespołu bezpieczeństwa staje się dla wielu organizacji barierą finansową i kompetencyjną. W praktyce rynkowej najskuteczniejszą strategią osiągnięcia zgodności z prawem (compliance) jest outsourcing tych zadań do wyspecjalizowanych dostawców usług zarządzanych (MSP) oraz dostawców usług zarządzanych w zakresie bezpieczeństwa (MSSP).
Należy jednak wyraźnie oddzielić odpowiedzialność operacyjną od odpowiedzialności prawnej. O ile zewnętrzny dostawca SOC może technicznie analizować logi sieciowe i mitygować ataki w czasie rzeczywistym, o tyle z punktu widzenia organów nadzorczych, to zarząd podmiotu objętego ustawą ponosi wyłączną odpowiedzialność za niedopełnienie obowiązków wynikających z KSC. Właśnie dlatego tradycyjne umowy outsourcingowe w IT muszą zostać zrewidowane i dostosowane do nowych realiów prawnych.
Dostawcy usług zarządzanych (MSSP) jako podmioty regulowane
Warto zaznaczyć, że dyrektywa NIS2 oraz znowelizowana ustawa o KSC wprowadzają istotną nowość w łańcuchu dostaw cyfrowych: sami dostawcy usług IT oraz MSSP zostają włączeni do katalogu podmiotów kluczowych lub ważnych. Oznacza to, że firma zewnętrzna, której powierzasz swoje bezpieczeństwo, musi spełniać równie rygorystyczne, a nierzadko wyższe standardy cyberbezpieczeństwa co Twoja organizacja.
Przed podpisaniem umowy o współpracy należy bezwzględnie zweryfikować, czy potencjalny dostawca SOC posiada wdrożony, udokumentowany i certyfikowany System Zarządzania Bezpieczeństwem Informacji (SZBI), jest w pełni świadomy swoich obowiązków ustawowych oraz potrafi na piśmie udowodnić zgodność z wymogami polskiego prawa. Współpraca z dostawcą, który nie podlega rygorom nowej ustawy lub w praktyce je ignoruje, wprowadza do Twojej organizacji nieakceptowalne ryzyko, co w razie incydentu może skutkować nałożeniem potężnych kar finansowych przewidzianych przez KSC.
Kluczowe elementy umowy z zewnętrznym SOC pod kątem KSC
Prawidłowo skonstruowana umowa o świadczenie usług z zakresu cyberbezpieczeństwa (Managed Services Agreement) musi ściśle odzwierciedlać wymogi raportowania i zarządzania incydentami określone w przepisach KSC. Standardowe zapisy SLA (Service Level Agreement) dotyczące ogólnej dostępności usługi serwerowej są w tym wypadku całkowicie niewystarczające. Umowa z dostawcą SOC powinna bezwzględnie regulować następujące kwestie:
- Czas wykrycia i analizy (MTTD i MTTA): Ustawa KSC narzuca niezwykle krótkie okna czasowe na raportowanie incydentów poważnych. Twój podmiot ma zaledwie 24 godziny na przekazanie wczesnego ostrzeżenia do właściwego Zespołu Reagowania na Incydenty Komputerowe (np. CSIRT NASK). Aby było to możliwe operacyjnie, zewnętrzny SOC musi zobowiązać się w SLA do kategoryzacji incydentu i poinformowania Twojej firmy w czasie znacznie krótszym (najlepiej od 1 do 4 godzin od wystąpienia anomalii).
- Współpraca przy reagowaniu na incydenty: Wykrycie zagrożenia to zaledwie pierwszy krok. Umowa musi precyzować uprawnienia wykonawcze. KSC wymaga od podmiotów posiadania skutecznych, przetestowanych procedur reagowania na incydenty. Dostawca SOC i wewnętrzny dział IT muszą wypracować wspólne playbooki bezpieczeństwa, które jasno określają, kto ma uprawnienia do podjęcia radykalnych kroków, takich jak odcięcie zainfekowanych serwerów od sieci zewnętrznej w celu powstrzymania ataku ransomware.
- Retencja logów i dostęp do materiału dowodowego: W przypadku audytu po poważnym incydencie, organ nadzorczy zażąda dowodów i dostępu do logów z systemów informacyjnych. Umowa z zewnętrznym partnerem musi gwarantować nienaruszalność logów, czas ich przechowywania wprost zgodny z wytycznymi KSC oraz natychmiastowy, nieograniczony dostęp dla autoryzowanego personelu Twojej firmy.
Model operacyjny: Kto fizycznie zgłasza incydent do CSIRT?
Jednym z najczęstszych dylematów firm w sektorze B2B, które decydują się na delegowanie cyberbezpieczeństwa, jest proces formalnego raportowania. Zgodnie z przepisami KSC, twardy obowiązek zgłoszenia incydentu poważnego spoczywa bezpośrednio na podmiocie kluczowym lub ważnym. Powstaje jednak pytanie: czy analityk z zewnętrznego centrum SOC może kliknąć przycisk „wyślij” i przesłać formularz do krajowego CSIRT w imieniu klienta?
Prawo na to zezwala, jednak wymaga to precyzyjnego umocowania prawnego i udzielenia oficjalnych pełnomocnictw. Zewnętrzny dostawca może widnieć w rejestrach jako osoba kontaktowa, jednak rekomendowanym i najbezpieczniejszym modelem jest tzw. zgłoszenie autoryzowane. Polega ono na tym, że zewnętrzny SOC przygotowuje pełny wsad techniczny i raport, przekazuje go wyznaczonemu wewnętrznemu Pełnomocnikowi ds. Cyberbezpieczeństwa, a ten ocenia biznesowy wpływ incydentu (np. na ciągłość dostaw) i to on dokonuje ostatecznej autoryzacji wysyłki do CSIRT. Ten mechanizm skutecznie chroni firmę przed eskalacją fałszywych alarmów, które nie spełniają ustawowej definicji incydentu poważnego.
Prawo do audytu u dostawcy usług (Right to Audit)
Polska ustawa KSC kładzie ogromny nacisk na odpowiedzialność najwyższego kierownictwa za systematyczną ocenę skuteczności wdrażanych środków zarządzania ryzykiem. Jeśli opierasz cyfrowe bezpieczeństwo swojej firmy w dużej mierze na dostawcy zewnętrznym, musisz mieć sprawne narzędzia weryfikacji jakości jego pracy.
W każdym zaawansowanym kontrakcie B2B z dostawcą IT lub SOC absolutnie konieczna jest klauzula prawa do audytu. Gwarantuje ona, że podmiot objęty KSC ma pełne prawo wyznaczyć niezależnego audytora w celu skontrolowania mechanizmów bezpieczeństwa u swojego dostawcy, wglądu w wyniki jego testów penetracyjnych, czy też sprawdzenia procedur bezpieczeństwa fizycznego w centrach danych. Brak takiego zapisu w umowie pozbawia Cię kluczowego argumentu obronnego podczas państwowej kontroli z KSC i uniemożliwia udowodnienie, że właściwie nadzorujesz swój łańcuch dostaw.
Integracja zarządzania podatnościami (Vulnerability Management)
Ustawa wymaga od podmiotów nie tylko reakcji na wycieki danych, ale również proaktywnego zapobiegania atakom m.in. poprzez higienę cybernetyczną i systematyczne zarządzanie podatnościami. W modelach outsourcingowych bardzo często tworzy się niebezpieczna luka kompetencyjna: zewnętrzny SOC cyklicznie skanuje infrastrukturę i wykrywa słabe punkty, ale nie ma w umowie wpisanego obowiązku fizycznej instalacji poprawek (patch management).
Jeżeli luki nie są łatane z powodu niejasnego podziału obowiązków między Twoim działem IT a zewnętrznym MSSP, organizacja łamie wymogi KSC. Umowa outsourcingowa musi zatem uwzględniać jasną macierz podziału odpowiedzialności (RACI). Należy wyraźnie wskazać, czy dostawca usług bezpieczeństwa pełni jedynie rolę doradczą, dostarczając raporty o koniecznych aktualizacjach, czy odpowiada również za zatwierdzenie okien serwisowych i wdrożenie łatek bezpieczeństwa w systemach produkcyjnych.
Najważniejsze wnioski
- Niezbywalna odpowiedzialność zarządu: Przekazanie procesu monitorowania logów i obsługi incydentów do wyspecjalizowanego, zewnętrznego dostawcy SOC nie przenosi na niego odpowiedzialności prawnej za brak zgodności z ustawą KSC. Zarząd firmy musi aktywnie nadzorować ten proces.
- Rygorystyczne warunki SLA: Umowa z dostawcą IT musi zawierać niezwykle krótkie czasy gwarantowane (SLA) na identyfikację i kategoryzację zdarzeń, aby umożliwić firmie spełnienie surowego obowiązku przesłania wczesnego ostrzeżenia do krajowego CSIRT w ciągu zaledwie 24 godzin.
- Zabezpieczenie prawa do audytu dostawcy: Kontrakt biznesowy musi przyznawać Twojej firmie prawo do przeprowadzania niezależnych kontroli u podmiotu zewnętrznego, co stanowi podstawowy dowód dla organu nadzorczego na właściwe zarządzanie ryzykiem w łańcuchu dostaw.
- Wspólne procedury i podział ról: Skuteczne wdrożenie wymogów KSC wymaga zintegrowania playbooków reakcji na incydenty zewnętrznego zespołu SOC z procedurami kryzysowymi obowiązującymi wewnątrz Twojej organizacji.
Treść ma charakter informacyjny i edukacyjny — nie stanowi porady prawnej. Przy wyniku granicznym skonsultuj się z radcą prawnym lub adwokatem.