Od kopii zapasowej do odporności operacyjnej. Odpowiedź na wymogi NIS2
Znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026 r. Dla działów IT oznacza koniec sytuacji, w której plan odtworzenia jest dokumentem, a nie procesem. Czego ustawa o KSC wymaga od odtwarzania danych? W poniższym artykule pokazujemy, które przepisy dotyczą wprost kopii zapasowych i disaster recovery — i co musi realnie działać w serwerowni, żeby audytor zobaczył dowód, a nie deklarację.
Terminy już biegną
Polska wdrożyła dyrektywę NIS2 jako jedno z ostatnich państw Unii. Nowelizacja ustawy o KSC (Dz.U. 2026 poz. 252) weszła w życie 3 kwietnia 2026 r. i z tym dniem dotychczasowi operatorzy usług kluczowych stali się podmiotami kluczowymi, bez decyzji administracyjnej, na zasadzie samoidentyfikacji.
Stawka jest wymierna. Za brak wdrożenia środków technicznych i organizacyjnych podmiotowi kluczowemu grozi kara do 10 mln euro lub 2% przychodu, podmiotowi ważnemu do 7 mln euro lub 1,4% (art. 73 ust. 3 i 4 uKSC). Osobno ustawa przewiduje karę do 300% wynagrodzenia dla kierownika podmiotu prywatnego (art. 73a ust. 4). Odpowiedzialność przestała być wyłącznie sprawą działu IT.
Cztery przepisy, które decydują o architekturze odtwarzania
Sercem ustawy jest art. 8, wymieniający czternaście obszarów, w których trzeba wdrożyć środki odpowiednie i proporcjonalne do oszacowanego ryzyka. Cztery z nich dotyczą wprost backupu i disaster recovery:
• Art. 8 ust. 1 pkt 2 lit. f — plany ciągłości działania, plany awaryjne i plany odtworzenia działalności: wdrażanie, dokumentowanie, testowanie i utrzymywanie. Testowanie jest w treści przepisu. Plan, którego nikt nie uruchomił, formalnie tego wymogu nie spełnia.
• Lit. h — polityki i procedury oceny skuteczności zastosowanych środków. Musi istnieć mechanizm pomiaru i zapis z pomiaru.
• Lit. j — podstawowe zasady „cyberhigieny”, w tym kopie zapasowe.
• Pkt 5 lit. a i c — mechanizmy zapewniające poufność, integralność, dostępność i autentyczność danych oraz ochrona przed nieuprawnioną modyfikacją.
Ostatni punkt warto przeczytać dwa razy. Kopia, którą da się zaszyfrować lub skasować z poziomu przejętego konta administratora domeny, tego wymogu nie spełnia — a w większości audytowanych przez nas środowisk odpowiedź na pytanie „czy administrator domeny może usunąć nasze kopie” brzmi: tak.
Ustawa świadomie nie podaje wartości RPO i RTO. Wymaga natomiast, żeby były wyznaczone dla każdego procesu krytycznego, uzasadnione analizą ryzyka i potwierdzone testem.
Ransomware łamie klasyczny plan DR
Klasyczny disaster recovery odpowiada na utratę ośrodka: pożar, zalanie, awarię zasilania. Ransomware nie niszczy infrastruktury, szyfruje dane. To zmienia niemal każdy element procedury odtwarzania.
• Miejsce odtworzenia. Przy awarii przełączamy produkcję na ośrodek zapasowy. Przy ataku ten ośrodek jest równie skażony potrzebne jest środowisko odizolowane.
• Punkt odzyskiwania. Awaria ma jeden moment. Atak trwa tygodniami, więc trzeba przeszukać wiele punktów wstecz i mieć głębszą retencję.
• Przebieg. DR jest liniowy — runbook krok po kroku. Odtwarzanie po ataku jest iteracyjne: sprawdź, odrzuć, cofnij się, sprawdź ponownie.
• Krok, którego w DR nie ma. Analiza złośliwego kodu — statyczna i behawioralna — zanim cokolwiek wróci na produkcję.
Do tego dochodzi presja czasu wynikająca z art. 11 uKSC: wczesne ostrzeżenie w 24 godziny, pełne zgłoszenie incydentu poważnego w 72 godziny, sprawozdanie końcowe w miesiąc. Zegar biegnie od momentu wykrycia i nie zatrzymuje się w weekend. Żeby złożyć sensowne zgłoszenie, trzeba wiedzieć, co się stało i od kiedy.
Jak odpowiada na to VMware Live Recovery
Rozwiązanie Broadcom łączy w jednej subskrypcji dwa scenariusze, które dotąd obsługiwały osobne produkty: klasyczną orkiestrację odtworzenia ośrodka (VMware Live Site Recovery) oraz odtwarzanie po cyberataku (VMware Live Cyber Recovery).
Przepływ odtwarzania po ataku. Niebieskie elementy pracują stale, fioletowe uruchamiają się w scenariuszu incydentu. Źródło: Broadcom, Ransomware Recovery Technical Overview.
• Niezmienne punkty odzyskiwania. Migawki trafiają do chmurowego systemu plików zapisem jednokierunkowym, odseparowane od domeny produkcyjnej. Retencja jest egzekwowana po stronie usługi — przejęte konto w produkcji nie usunie ani nie nadpisze kopii.
• Izolowane środowisko odzyskiwania (IRE). Czysty pokój uruchamiany na żądanie, z izolacją sieciową sterowaną regułami na poziomie pojedynczej maszyny. To miejsce, w którym wolno popełnić błąd: uruchomić podejrzaną maszynę, zobaczyć, co robi, i odrzucić ten punkt.
• Analiza wbudowana w proces. Skan podatności, skan malware i analiza behawioralna działającego obciążenia są częścią przebiegu odtwarzania, a nie osobnym narzędziem do integracji.
• Wskazanie czystego punktu. Metryki tempa zmian i entropii danych w kolejnych migawkach pokazują moment rozpoczęcia szyfrowania — zawężają poszukiwania z tygodni do godzin i stanowią materiał do sprawozdania z art. 12 uKSC.
• Orkiestracja i szybkie RPO. Plany odtworzenia z grupami ochrony i mapowaniem sieci zamiast autorskich skryptów; RPO od jednej minuty per maszyna wirtualna, failback jako opisany element planu.
Test bez przestoju zamiast planu w szufladzie
Powód, dla którego organizacje nie testują planów, jest zawsze ten sam: test wymagałby okna serwisowego albo zatrzymania replikacji. Litera f nie przewiduje jednak wyjątku dla środowisk zbyt krytycznych, żeby je testować.
Ryzyko nieudanego odtworzenia rośnie wraz ze zmianami w aplikacjach i konfiguracji. Luka testowa to obszar pod krzywą. Źródło: Broadcom, VMware Live Site Recovery Technical Overview.
W VMware Live Recovery test polega na uruchomieniu maszyn z migawek w odizolowanej sieci testowej. Replikacja pracuje dalej, RPO nie ulega zmianie, produkcja nie jest dotykana. Znika ostatni argument przeciwko regularnemu testowaniu — i znika linia obrony przed organem nadzoru.
Dowód, a nie deklaracja
Organ nadzoru nie przyjedzie oceniać architektury. Przyjedzie sprawdzić dokumenty i zapyta: kiedy ostatnio testowaliście plan odtworzenia, jaki był wynik i ile to trwało. „Testowaliśmy w zeszłym roku, poszło dobrze” to deklaracja. Raport z każdej operacji — z datą, wynikiem, czasem trwania i osobą, która ją uruchomiła — to dowód.
Raport historii operacji — materiał, którego oczekuje art. 8 ust. 1 pkt 2 lit. h uKSC. Źródło: Broadcom, VMware Live Site Recovery Technical Overview.
Raport szczegółowy schodzi do poziomu pojedynczego kroku planu — pozwala zobaczyć, gdzie naprawdę tracimy czas, i realnie skracać RTO zamiast deklarować je w dokumencie.
Wymóg ustawy a funkcja rozwiązania
Czego żadne narzędzie nie załatwi
Technologia dostarcza dowodów i skraca czas reakcji. Nie zastąpi systemu zarządzania bezpieczeństwem informacji, polityk, rejestru aktywów ani szkoleń kierownictwa. Nie chroni przed eksfiltracją danych — wyciek pozostaje zdarzeniem podlegającym zgłoszeniu do UODO niezależnie od uKSC. Nie zwalnia też z klasyfikacji i zgłoszenia incydentu w terminie: to obowiązek podmiotu. Jeżeli ktoś oferuje Państwu zgodność z ustawą o KSC w postaci produktu, mija się z prawdą.
Stan prawny: ustawa o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 20 t.j.) w brzmieniu nadanym ustawą z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252), obowiązującym od 3 kwietnia 2026 r. Materiał ma charakter informacyjny i nie stanowi porady prawnej. Schematy pochodzą z dokumentacji technicznej Broadcom / VMware Live Recovery i pozostają własnością producenta. Parametry techniczne oraz warunki licencyjne należy potwierdzić w procesie ofertowym.
