NIS 2 dla firm Białystok

Co dyrektywa mówi o dostawcy, który obsługuje Was z innego miasta?

Nie zabrania takiej obsługi ani słowem. Wymaga natomiast, żebyście panowali nad bezpieczeństwem łańcucha dostaw, a dostawca IT z dostępem administracyjnym jest w tym łańcuchu ogniwem najbardziej narażonym. W firmie z Podlasia, która nie ma własnego działu informatycznego, ten wątek jest zwykle najbardziej pracochłonną częścią całego projektu, bo dostawców z dostępem jest kilku i żaden nie był dotąd o nic pytany.

Praktycznie sprowadza się to do czterech pytań przy każdym z nich. Jaki ma zakres dostępu i czy odpowiada on temu, co faktycznie robi. Czy jego ludzie pracują na kontach imiennych z drugim składnikiem. Czy po jego pracy zostaje zapis. Czy w umowie jest zapisany obowiązek zgłoszenia Wam własnego incydentu, i w jakim czasie.

Wymaganie z artykułu 21	Jak wygląda u dostawcy zdalnego	Czym to potwierdzacie
Kontrola dostępu	konta imienne zamiast wspólnych, uprawnienia na czas zadania	wykaz kont i zapis sesji administracyjnych
Bezpieczeństwo łańcucha dostaw	wymagania w umowie, nie w rozmowie	klauzule i podpisane zobowiązanie dostawcy
Obsługa incydentów	dostawca zgłasza Wam swoje zdarzenia	zapis terminu w umowie i ćwiczenie
Ciągłość działania	odtworzenie możliwe bez wjazdu na teren firmy	protokół z testu powrotu
Zarządzanie ryzykiem	ryzyko odległości opisane, nie przemilczane	rejestr ryzyk z tym wpisem i środkiem
Odpowiedzialność kierownictwa	zarząd zna zakres dostępu dostawców	protokół przeglądu i decyzje zarządu

Ostatni wiersz bywa lekceważony, a w kontroli pada wcześnie. Dyrektywa przypisuje odpowiedzialność organom zarządzającym, więc zdanie o tym, że informatyką zajmuje się firma zewnętrzna, nie przenosi obowiązku na tę firmę.

Kto w Waszej firmie stwierdza, że zdarzenie jest incydentem?

To pytanie zatrzymuje projekt częściej niż kwestie techniczne, bo w firmie bez działu IT nie ma oczywistego kandydata. Osoba, która widzi objaw, zwykle nie ma wiedzy, żeby ocenić skalę. Osoba, która ma wiedzę, czyli my, nie jest podmiotem zobowiązanym i nie może decydować za Was.

Układamy to więc w dwóch krokach. My przekazujemy ustalenia techniczne w uzgodnionej formie: co się stało, jakich systemów dotyczy, czy dane wypłynęły, czy usługa jest przerwana i jaki jest przewidywany zasięg. Wskazana osoba po Waszej stronie podejmuje na tej podstawie decyzję o zgłoszeniu, mając przed sobą krótką listę kryteriów zamiast ogólnego pojęcia poważnego incydentu.

Wyznaczamy też zastępstwo i drugą drogę kontaktu, bo pierwsza osoba bywa akurat na urlopie albo w podróży. Bez tego cała procedura opiera się na jednym telefonie, który może nie zostać odebrany, a zegar biegnie niezależnie od tego.

Jak zmieścić się w dobie, gdy zdarzenie zaczyna się w nocy?

Zegar 24 godzin na wstępne zgłoszenie i 72 godzin na zgłoszenie pełne nie zatrzymuje się na noc ani na weekend, więc procedura musi działać poza godzinami pracy. U nas monitoring infrastruktury pracuje przez całą dobę i to on wykrywa zdarzenie, natomiast helpdesk odbiera od poniedziałku do piątku w godzinach 8:00 do 18:00. Tę różnicę zapisujemy w procedurze wprost, zamiast ją zacierać.

Z tego wynika prosty wniosek, który firmy przyjmują z ulgą: doba na wstępne zgłoszenie jest terminem wykonalnym nawet wtedy, gdy zdarzenie zaczyna się w piątek wieczorem, pod warunkiem że wcześniej ustalono, kto dzwoni do kogo i pod jaki numer. Zgłoszenie wstępne nie wymaga pełnej analizy, tylko stwierdzenia faktu, dlatego nie warto go odkładać do czasu wyjaśnienia wszystkiego.

Pełne zgłoszenie po 72 godzinach wymaga już danych: przebiegu, zasięgu i podjętych działań. Tu decyduje to, czy w środowisku w ogóle są zapisy zdarzeń i jak długo się trzymają. Firma z rejestrem obejmującym kilka dni nie odtworzy przebiegu sprzed tygodnia i to jest brak, który wpisujemy do analizy niemal zawsze.

Skąd bierzemy dowody, skoro większość pracy toczy się przez sieć?

Z tych samych miejsc, z których bierze je kontrola: z konfiguracji, rejestrów i protokołów. Zrzut ustawień dostępu warunkowego jest dowodem mocniejszym niż zdanie w polityce. Protokół z próby odtworzenia kopii jest dowodem, a zielony status zadania nie jest. Wykaz kont zestawiony z listą zatrudnienia pokazuje porządek albo jego brak, bez potrzeby wchodzenia do budynku.

Dwa obszary wymagają jednak obecności i mówimy o tym na starcie. Pierwszy to fizyczne zabezpieczenie sprzętu: pomieszczenie z serwerem, dostęp do szaf, zasilanie. Drugi to ćwiczenie zgłoszenia incydentu, które ma sens przy jednym stole, bo sprawdza ludzi i przepływ informacji, a nie konfigurację.

Całość porządkujemy w jednym miejscu, opisaną w kolejności, w jakiej pyta o to kontrola. Punktem wyjścia bywa zwykle audyt bezpieczeństwa IT, bo połowa dowodów do tego projektu i tak powstaje przy takim badaniu.

Jak układamy harmonogram, skoro nie mamy biura w Białymstoku?

Dzielimy projekt na bloki zdalne i dwa terminy na miejscu, a nie na dziesięć krótkich spotkań. Bloki zdalne to warsztaty po dwie godziny: zakres obowiązku, ryzyka, incydenty, ciągłość działania, dostawcy. Prowadzimy je z zarządem i z osobami odpowiedzialnymi za poszczególne obszary, bo dokumentacja pisana bez nich opisuje firmę, której nie ma.

Pierwszy przyjazd wypada zwykle na początku, przy przeglądzie środowiska i zabezpieczeń fizycznych. Drugi na końcu, przy ćwiczeniu zgłoszenia i przekazaniu dokumentacji. Wszystko pomiędzy toczy się przez sieć, co skraca projekt i obniża jego koszt, bo płacicie za pracę, a nie za przejazdy.

Warstwę techniczną, bez której dokumentacja pozostaje papierem, opisuje bezpieczeństwo IT dla firm, a wymaganie dotyczące odtwarzalności danych ochrona przed ransomware. Zgodność z ISO/IEC 27001, jeśli równolegle jej potrzebujecie, prowadzi wdrożenie ISO 27001.

Czego ten projekt nie załatwia?

Nie wydajemy certyfikatu zgodności z NIS 2, bo taki dokument nie istnieje, a firmy, które go proponują, sprzedają własny wzór. Nie reprezentujemy Was przed organem nadzoru i nie zgłaszamy incydentu w Waszym imieniu, chyba że umowa mówi inaczej i wskazuje osobę z pełnomocnictwem. Nie prowadzimy też obsługi prawnej umów, choć przygotowujemy treść wymagań technicznych do klauzul.

Nie obiecujemy, że zgodność da się kupić raz. To stan utrzymywany: przeglądy, aktualizacja rejestrów, ćwiczenia i reakcja na zmiany w firmie. Zakres pierwszego etapu ustalamy przez kontakt.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026