SLA dotyczące usuwania podatności na potrzeby NIS2 i DORA

O 08:17 we wtorkowy poranek na początku 2026 roku Anna, CISO szybko rosnącej firmy fintech, otrzymuje pierwszą wiadomość, zanim zdąży dopić kawę.

SOC oznaczył aktywne dyskusje o wykorzystywaniu podatności w bramie API obsługującej klientów. Zespół inżynieryjny informuje, że poprawka jest dostępna, ale jej wdrożenie jest ryzykowne, ponieważ brama znajduje się przed procesami płatniczymi. Menedżer ds. zgodności przekazuje formalny wniosek właściwego organu krajowego o dowody dotyczące „obsługi i ujawniania podatności” oraz potwierdzenie, że proces był skuteczny w ostatnich 12 miesiącach. Zakupy dodają trzeci problem: bramą zarządza MSP, a umowa stwierdza jedynie, że dostawca będzie stosował „aktualizacje bezpieczeństwa w odpowiednim czasie”.

O 09:00 nie jest to już wyłącznie problem wdrożenia poprawki. To kwestia dowodowa ISO/IEC 27001:2022, kwestia cyberhigieny w NIS2, kwestia zarządzania ryzykiem ICT w DORA, kwestia nadzoru nad dostawcą i potencjalnie kwestia zgłaszania incydentów, jeżeli wykorzystanie podatności wpływa na ciągłość świadczenia usług albo dane osobowe.

To praktyczna luka zgodności, z którą wiele organizacji zmierzy się w 2026 roku. Mają skanery, panele kontrolne, zgłoszenia i narzędzia do zarządzania poprawkami, ale nie potrafią jasno odpowiedzieć na pytania audytowe:

• Kto zatwierdził SLA dotyczące działań naprawczych?
• W jaki sposób SLA jest oparte na ryzyku?
• Co dzieje się, gdy poprawka krytyczna przekroczy termin?
• Jak priorytetyzowane są aktywa dostępne z Internetu?
• Jak dostawcy są zobowiązywani do tych samych terminów?
• Gdzie znajduje się zapis akceptacji ryzyka dla niezałatanego systemu?
• Które dowody potwierdzają, że zabezpieczenie działało, a nie tylko istniało?

Odpowiedzią nie jest kolejny arkusz kalkulacyjny z terminami realizacji. SLA dotyczące usuwania podatności muszą być zarządzane jako żywy system kontroli, który łączy własność aktywów, punktację podatności, informacje o zagrożeniach, zarządzanie zmianami, SLA dostawców, obsługę wyjątków, monitorowanie, reagowanie na incydenty i przegląd zarządzania.

Właśnie tutaj przydatne stają się rozwiązania Clarysec: korporacyjna Polityka zarządzania podatnościami i poprawkami (VPMP), wersja dla MŚP Polityka zarządzania podatnościami i poprawkami dla MŚP (VPMP-SME), Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP (TPSSP-SME), Zenith Blueprint (ZB) oraz Zenith Controls (ZC). Razem zmieniają hasło „wdrażaj poprawki szybciej” w możliwy do obrony proces ładu, odporny na wnikliwą kontrolę audytową w stylu ISO, NIS2, DORA, GDPR, NIST i ISACA.

Dlaczego SLA dotyczące usuwania podatności stały się dowodem na poziomie zarządu

Usuwanie podatności było kiedyś traktowane jako metryka higieny IT. W 2026 roku jest bliższe regulowanemu zobowiązaniu dotyczącemu odporności operacyjnej.

NIS2 czyni cyberbezpieczeństwo obszarem odpowiedzialności kierownictwa. Podmioty kluczowe i ważne muszą zapewnić, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia pozwalające rozumieć ryzyka oraz wpływ praktyk bezpieczeństwa na usługi. NIS2 Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego nabywania i utrzymania, obsługi i ujawniania podatności, cyberhigieny, szkoleń, kontroli dostępu, zarządzania aktywami oraz uwierzytelniania.

Dla podmiotów finansowych DORA jest wyspecjalizowanym reżimem odporności operacyjnej. Wymaga rozwiązań z zakresu ładu i kontroli ryzyka ICT, przy czym organ zarządzający definiuje, zatwierdza, nadzoruje i pozostaje odpowiedzialny za zarządzanie ryzykiem ICT. Wymaga także identyfikacji aktywów ICT i zależności, środków ochrony i zapobiegania, takich jak wdrażanie poprawek i zarządzanie zmianami, zarządzania incydentami związanymi z ICT, testowania cyfrowej odporności operacyjnej oraz zarządzania ryzykiem dostawców ICT.

Praktyczny wpływ jest znaczący. Przekroczenie terminu wdrożenia poprawki może wskazywać na nieskuteczność:

• ładu, jeżeli kierownictwo nie zatwierdziło SLA opartych na ryzyku,
• zarządzania aktywami, jeżeli właściciel dotkniętego systemu jest nieznany,
• zarządzania zmianami, jeżeli awaryjne wdrażanie poprawek nie jest kontrolowane,
• zarządzania dostawcami, jeżeli terminy dostawcy są nieprecyzyjne,
• reagowania na incydenty, jeżeli oznaki wykorzystania podatności nie są kwalifikowane,
• zarządzania dowodami, jeżeli zgłoszenia i logi nie potwierdzają zamknięcia,
• postępowania z ryzykiem, jeżeli wyjątki nie są zatwierdzane i poddawane przeglądowi.

ISO/IEC 27001:2022 zapewnia szkielet systemu zarządzania. Klauzule 4.1 do 4.3 wymagają, aby organizacje rozumiały kwestie wewnętrzne i zewnętrzne, wymagania stron zainteresowanych, obowiązki prawne i umowne oraz interfejsy z innymi organizacjami. Klauzule 6.1.1 do 6.1.3 wymagają oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania oraz zatwierdzenia ryzyka szczątkowego przez właściciela ryzyka. Klauzule 9.1, 9.2, 9.3, 10.1 i 10.2 wymagają monitorowania, audytu wewnętrznego, przeglądu zarządzania, ciągłego doskonalenia, działań korygujących oraz zachowywania dowodów.

Mówiąc wprost: jeżeli SLA dotyczące usuwania podatności mają być audytowalne, muszą być częścią SZBI, a nie tylko metryką DevOps.

Model SLA, którego oczekują audytorzy

SLA dotyczące usuwania podatności powinno odpowiadać na trzy pytania:

1. Jak szybko musimy działać?
2. Kto ponosi odpowiedzialność?
3. Jakie dowody potwierdzają wynik?

Polityka zarządzania podatnościami i poprawkami definiuje praktyczny punkt wyjścia dla terminów usuwania podatności opartych na ryzyku:

Organizacja musi klasyfikować wszystkie wykryte podatności przy użyciu ustandaryzowanej metodyki (np. CVSS v3.x) oraz stosować terminy działań naprawczych zgodne z krytycznością biznesową: 5.2.1 Krytyczna (CVSS 9.0-10.0): natychmiastowy przegląd; maksymalny termin wdrożenia poprawki 72 godziny. 5.2.2 Wysoka (7.0-8.9): reakcja w ciągu 48 godzin; termin wdrożenia poprawki 7 dni kalendarzowych. 5.2.3 Średnia (4.0-6.9): reakcja w ciągu 5 dni; termin wdrożenia poprawki 30 dni kalendarzowych. 5.2.4 Niska (<4.0): reakcja w ciągu 10 dni; termin wdrożenia poprawki 60 dni kalendarzowych.

Ta klauzula jest silna, ponieważ oddziela czas reakcji od terminu wdrożenia poprawki. Podatność wysoka nie powinna pozostawać niezauważona przez sześć dni i zostać załatana dopiero siódmego dnia. Zegar reakcji potwierdza kwalifikację, przypisanie właściciela, ocenę wpływu i planowanie działań naprawczych. Termin wdrożenia poprawki potwierdza techniczne zamknięcie albo zatwierdzony wyjątek.

Dla mniejszych organizacji Polityka zarządzania podatnościami i poprawkami dla MŚP stosuje prostszy, ale nadal audytowalny język:

Poprawki krytyczne muszą zostać zastosowane w ciągu 3 dni od wydania, zwłaszcza dla systemów dostępnych z Internetu

A dla szerszego zakresu poprawek:

Wszystkie pozostałe poprawki muszą zostać zastosowane w ciągu 30 dni, chyba że udokumentowano ważny wyjątek

Nie chodzi o to, aby każda organizacja stosowała identyczne terminy. ISO/IEC 27001:2022, NIS2 i DORA wspierają zasadę proporcjonalności. Chodzi o to, aby SLA dotyczące działań naprawczych były zdefiniowane, zatwierdzone, oparte na ryzyku, monitorowane i udokumentowane dowodami.

W tym miejscu wiele firm ponosi porażkę. Definiują SLA, ale nie definiują dowodów. Z perspektywy audytora polityka bez zapisów operacyjnych jest obietnicą, a nie działającym zabezpieczeniem.

Własność aktywów to ukryta zależność

Skaner może wskazać, że na serwerze występuje CVE. Nie powie jednak, czy serwer wspiera krytyczny proces płatniczy, przechowuje szczególne kategorie danych osobowych, łączy się z dostawcą rozliczeń albo jest zaplanowany do wycofania z eksploatacji.

Ten kontekst pochodzi z zarządzania aktywami, klasyfikacji danych, inwentarza dostawców i oceny ryzyka.

ISO/IEC 27001:2022 Annex A control 8.8, Zarządzanie podatnościami technicznymi, jest centralny, ale nie działa samodzielnie. Silnie zależy od zarządzania konfiguracją, zarządzania zmianami, monitorowania dostawców, ładu chmury obliczeniowej, logowania, monitorowania i postępowania z ryzykiem.

NIST CSF 2.0 wyraża ten sam problem językiem wyników. Funkcja GOVERN oczekuje, że prawne, regulacyjne i umowne wymagania cyberbezpieczeństwa będą rozumiane i zarządzane, apetyt na ryzyko i tolerancja ryzyka będą udokumentowane, role i zasoby zostaną przypisane, a polityki cyberbezpieczeństwa będą ustanawiane, egzekwowane, przeglądane i aktualizowane. Wyniki IDENTIFY obejmują inwentarze sprzętu, oprogramowania, usług, systemów, danych i cyklu życia, wraz z identyfikacją podatności, analizą ryzyka, zarządzaniem wyjątkami oraz procesami ujawniania podatności.

W porannym scenariuszu Anny pierwsze pytanie techniczne brzmi: „gdzie znajduje się podatny komponent?”. Pierwsze pytanie z obszaru ładu brzmi: „na jaką usługę i jakie ryzyko wpływa?”.

Zenith Blueprint, faza zarządzania ryzykiem, krok 13: Planowanie postępowania z ryzykiem i Deklaracja stosowania, rozwiązuje to przez powiązanie ryzyk z zabezpieczeniami, właścicielami i terminami:

Ponadto przypisz właściciela i termin dla każdego działania (np. w osobnej kolumnie albo w komentarzach). Np. „Właściciel: Menedżer IT, termin: do III kwartału 2025 r.”. Dzięki temu staje się to rzeczywistym planem.

Dokładnie tego wymaga usuwanie podatności. Ustalenie bez właściciela staje się szumem w kolejce prac. Ustalenie z właścicielem, terminem, decyzją dotyczącą postępowania z ryzykiem i ścieżką dowodową staje się audytowalnym zabezpieczeniem.

Jak Zenith Controls mapuje relacje między zabezpieczeniami

Zenith Controls traktuje ISO/IEC 27002:2022 control 8.8, Zarządzanie podatnościami technicznymi, jako zabezpieczenie zapobiegawcze wspierające poufność, integralność i dostępność. Łączy je z koncepcjami cyberbezpieczeństwa Identify i Protect, zdolnością operacyjną zarządzania zagrożeniami i podatnościami oraz domenami bezpieczeństwa: ładem, ekosystemem, ochroną i obroną.

Ma to znaczenie, ponieważ SLA dotyczące działań naprawczych nie są wyłącznie mechanizmem ochronnym. Są również mechanizmem ładu i mechanizmem ekosystemu. Ekspozycja organizacji jest kształtowana przez dostawców, platformy chmurowe, usługi zarządzane, komponenty open source oraz zależności dostępne z Internetu.

Zenith Controls mapuje 8.8 do kilku wspierających zabezpieczeń:

Zenith Controls łączy również zarządzanie podatnościami z ISO/IEC 27005:2024, szczególnie z identyfikacją podatności i scenariuszami ryzyka obejmującymi niezałatane systemy. Wzmacnia to argument, że terminy wdrażania poprawek powinny być oparte na ryzyku, a nie arbitralne. Łączy także monitorowanie dostawców z ISO/IEC 27036-4:2016 w zakresie poziomów bezpieczeństwa umów dotyczących usług chmurowych oraz z ISO/IEC 20000-1:2018 w zakresie planowania świadczenia usług i zarządzania zmianami.

Taka struktura między normami ma znaczenie podczas audytu. Jeżeli organizacja twierdzi, że „podatności krytyczne są łatane w ciągu 72 godzin”, audytor sprawdzi, czy to stwierdzenie jest poparte oceną ryzyka, klasyfikacją aktywów, obowiązkami dostawców, zapisami zmian i dowodami monitorowania.

Cyberhigiena NIS2: od obsługi podatności do działań korygujących

NIS2 Article 21 wymaga podejścia obejmującego wszystkie zagrożenia dla sieci i systemów informatycznych. Dla SLA dotyczących usuwania podatności bezpośrednio istotnych jest kilka elementów Article 21:

• analiza ryzyka i polityki bezpieczeństwa systemów informatycznych,
• obsługa incydentów,
• ciągłość działania i zarządzanie kryzysowe,
• bezpieczeństwo łańcucha dostaw,
• bezpieczne nabywanie, rozwój i utrzymanie, w tym obsługa i ujawnianie podatności,
• procedury oceny skuteczności cyberbezpieczeństwa,
• podstawowa cyberhigiena i szkolenia,
• kontrola dostępu i zarządzanie aktywami,
• uwierzytelnianie wieloskładnikowe albo ciągłe uwierzytelnianie, gdy jest właściwe.

NIS2 Article 20 czyni organy zarządzające odpowiedzialnymi za zatwierdzanie i nadzorowanie środków zarządzania ryzykiem cyberbezpieczeństwa. Oznacza to, że metryki usuwania podatności nie mogą funkcjonować wyłącznie w panelu zespołu inżynieryjnego. Powinny pojawiać się w raportach zarządczych, materiałach komitetu ryzyka albo zapisach przeglądów zarządzania SZBI.

Article 21 oczekuje również, że podmioty identyfikujące niezgodność z wymaganymi środkami podejmą działania korygujące bez zbędnej zwłoki. To sformułowanie ma znaczenie. Jeżeli panel pokazuje przeterminowane podatności krytyczne, dowody zgodności nie powinny kończyć się na „wiemy o tym”. Powinny pokazywać eskalację, przegląd ryzyka, widoczność dla kierownictwa, działania korygujące i ponowną ocenę.

NIS2 Article 23 dodaje kolejny wymiar. Jeżeli wykorzystanie niezałatanej podatności powoduje albo może spowodować poważne zakłócenie operacyjne, stratę finansową lub szkodę dla innych osób, może stać się znaczącym incydentem. Cykl zgłaszania obejmuje wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o znaczącym incydencie, zgłoszenie incydentu w ciągu 72 godzin, raporty pośrednie na żądanie oraz raport końcowy w ciągu jednego miesiąca od zgłoszenia incydentu. Raport końcowy powinien obejmować wagę, wpływ, prawdopodobną analizę przyczyny źródłowej, środki łagodzące oraz wpływ transgraniczny, jeżeli ma zastosowanie.

Proces SLA musi więc łączyć się z reagowaniem na incydenty. Podatność krytyczna z dowodami aktywnego wykorzystania powinna uruchomić kwalifikację bezpieczeństwa, monitorowanie, zabezpieczenie dowodów i ocenę obowiązku zgłoszeniowego, a nie tylko rutynowe zgłoszenie poprawki.

Ryzyko ICT w DORA: terminy naprawcze jako dowód odporności

Dla podmiotów finansowych DORA obowiązuje od 17 stycznia 2025 r. i tworzy jednolite wymagania w zakresie zarządzania ryzykiem ICT, zgłaszania poważnych incydentów związanych z ICT, testowania cyfrowej odporności operacyjnej, wymiany informacji oraz zarządzania ryzykiem dostawców ICT. Jest traktowana jako sektorowy akt prawny UE dla objętych nim podmiotów finansowych wskazanych w krajowych przepisach wdrażających NIS2.

Model operacyjny DORA jest zbliżony do zintegrowanego SZBI. Articles 5 and 6 wymagają ładu, polityk, procedur, narzędzi, corocznego albo okresowego przeglądu, audytu, usunięcia krytycznych ustaleń z audytu oraz strategii cyfrowej odporności operacyjnej. Article 8 wymaga identyfikacji i inwentaryzacji funkcji biznesowych wspieranych przez ICT, aktywów informacyjnych, aktywów ICT, zależności, procesów stron trzecich oraz ryzyk związanych ze starszymi technologiami ICT. Article 9 wymaga środków ochrony i zapobiegania, w tym wdrażania poprawek i zarządzania zmianami. Articles 11 and 12 wymagają ciągłości, reagowania, odzyskiwania, kopii zapasowych, odtwarzania oraz celów odzyskiwania.

DORA Articles 17 to 19 wymagają procesu zarządzania incydentami związanymi z ICT, który wykrywa, obsługuje, rejestruje, klasyfikuje, eskaluje, raportuje, komunikuje, analizuje przyczynę źródłową i przywraca bezpieczne operacje. Articles 24 to 26 wymagają testowania cyfrowej odporności operacyjnej, w tym odpowiedniego testowania narzędzi i systemów ICT, ocen podatności, ocen bezpieczeństwa sieci, analiz luk, przeglądów kodu źródłowego tam, gdzie jest to wykonalne, testów penetracyjnych oraz testów penetracyjnych opartych na scenariuszach zagrożeń dla wybranych podmiotów finansowych. Articles 28 and 30 wymagają zarządzania ryzykiem dostawców ICT, rejestrów umów na usługi ICT, due diligence, praw audytu i inspekcji, poziomów usług, wsparcia dostawcy podczas incydentów, praw wypowiedzenia oraz ustaleń wyjścia.

Dla SLA dotyczących działań naprawczych DORA zmienia oczekiwania dowodowe na trzy sposoby.

Po pierwsze, ustalenia dotyczące podatności wynikające z testowania muszą zasilać priorytetyzowany proces działań naprawczych. Sam raport ze skanu nie wystarcza.

Po drugie, usuwanie ustaleń krytycznych musi być śledzone przez ład i audyt. DORA oczekuje formalnego usuwania krytycznych ustaleń audytowych w przypadku przedsiębiorstw innych niż mikroprzedsiębiorstwa.

Po trzecie, dostawcy ICT muszą być zobowiązani do mierzalnych obowiązków. Jeżeli dostawca chmury obliczeniowej, SaaS albo MSP kontroluje okno wdrażania poprawek, umowa i rejestr muszą pokazywać, jak jego terminy działań naprawczych wspierają obowiązki odpornościowe organizacji.

Polityka zarządzania podatnościami i poprawkami ujmuje to wprost:

Wdrażanie poprawek przez strony trzecie i nadzór nad ryzykiem SaaS 6.6.1 Wszystkie systemy stron trzecich (SaaS, PaaS, zarządzane przez MSP) muszą wykazywać odpowiednie kontrole zarządzania podatnościami i poprawkami. 6.6.2 SLA dostawców muszą obejmować terminy działań naprawczych równoważne z wewnętrznie zdefiniowanymi progami opartymi na krytyczności.

Ta klauzula często stanowi brakujący pomost między wewnętrznymi dowodami ISO a nadzorem nad dostawcami w DORA.

GDPR: kiedy opóźnienia we wdrażaniu poprawek stają się nieskutecznością rozliczalności za dane osobowe

GDPR nie jest standardem zarządzania podatnościami, ale zmienia konsekwencje nieskutecznego wdrażania poprawek.

GDPR Article 5 wymaga, aby dane osobowe były przetwarzane bezpiecznie, oraz wymaga od administratora możliwości wykazania zgodności. Article 32 wymaga odpowiednich środków technicznych i organizacyjnych zapewniających poziom bezpieczeństwa odpowiedni do ryzyka. Gdy niezałatane systemy przetwarzają dane osobowe, zwłaszcza dane tożsamościowe, dane finansowe, dane biometryczne, dane dotyczące zdrowia, dane pracownicze albo informacje KYC, SLA dotyczące działań naprawczych stają się częścią rozliczalności bezpieczeństwa przetwarzania.

Opóźniona poprawka może być możliwa do obrony, jeżeli ryzyko zostało ocenione, zastosowano środki kompensujące, a ryzyko rezydualne zostało zaakceptowane przez właściwą osobę. Znacznie trudniej ją obronić, jeżeli podatność była przeterminowana, dostępna z Internetu i nie miała właściciela.

Zenith Controls mapuje zarządzanie podatnościami do GDPR Articles 32 and 5(1)(f), ponieważ terminowe wdrażanie poprawek ogranicza ryzyko dla poufności i integralności danych osobowych. Mapuje również zarządzanie zmianami do GDPR Article 24 and Article 32, ponieważ zmiany w systemach przetwarzających dane osobowe powinny być oceniane pod kątem ryzyka, zatwierdzane, dokumentowane i przeglądane.

Wniosek z perspektywy zgodności jest prosty: jeżeli w grę wchodzą dane osobowe, dowody dotyczące poprawek powinny obejmować kontekst danych. Audytorzy i organy regulacyjne zapytają nie tylko „czy załatano?”, ale także „jakie dane były narażone na ryzyko, przez jak długi czas i jakie zabezpieczenia ograniczały to ryzyko?”.

Praktyczny proces Clarysec dla audytowalnych dowodów SLA

Dojrzały proces usuwania podatności nie zaczyna się wtedy, gdy audytor prosi o zapisy. Jest zaprojektowany tak, aby wytwarzać zapisy co miesiąc.

Krok 1: Zatwierdź politykę SLA

Zacznij od Polityki zarządzania podatnościami i poprawkami albo Polityki zarządzania podatnościami i poprawkami dla MŚP, zależnie od modelu operacyjnego. Dostosuj progi SLA do apetytu na ryzyko, zakresu regulacyjnego, krytyczności usług, wrażliwości danych i ograniczeń technicznych. Zapewnij zatwierdzenie przez CISO, komitet ryzyka albo organ zarządzający.

W środowiskach korporacyjnych używaj CVSS, krytyczności aktywów, możliwości wykorzystania, ekspozycji internetowej, wrażliwości danych i wpływu biznesowego. W przypadku MŚP utrzymaj model prosty, ale jednoznaczny: poprawki krytyczne w ciągu trzech dni, pozostałe poprawki w ciągu 30 dni, chyba że istnieje ważny wyjątek.

Krok 2: Mapuj aktywa do właścicieli i usług krytycznych

Każde ustalenie dotyczące podatności powinno wskazywać:

• nazwę aktywa i unikalny identyfikator,
• usługę biznesową albo aplikację,
• właściciela systemu,
• właściciela technicznego,
• klasyfikację danych,
• ekspozycję internetową,
• zależność od dostawcy, jeżeli dotyczy,
• krytyczność wspieranej funkcji.

Wspiera to własność ryzyka w ISO/IEC 27001:2022, zarządzanie aktywami NIS2, inwentarz aktywów i zależności ICT w DORA oraz wyniki IDENTIFY w NIST CSF.

Krok 3: Przeprowadź kwalifikację podatności

Utwórz zgłoszenie dla każdego ustalenia albo zgrupowanego zestawu ustaleń. Uwzględnij wynik CVSS, skaner źródłowy, dotknięte aktywo, status exploita, informacje o zagrożeniach, krytyczność biznesową i wymagane SLA. Jeżeli podejrzewa się wykorzystanie podatności, powiąż zgłoszenie z oceną incydentu.

Krok 4: Realizuj przez zarządzanie zmianami

Wdrażanie poprawek jest zmianą. Stosuj zmianę standardową dla rutynowych aktualizacji i zmianę awaryjną dla krytycznych, aktywnie wykorzystywanych podatności. Uwzględnij dowody testowania, zatwierdzenie, znacznik czasu wdrożenia, plan wycofania zmian i walidację po zmianie.

Jest to zgodne z relacją Zenith Controls między 8.8 i 8.32, w której stosowanie poprawek jest zarządzane przez zarządzanie zmianami, aby zrównoważyć pilność i stabilność operacyjną.

Krok 5: Zweryfikuj zamknięcie

Nie zamykaj zgłoszeń wyłącznie na podstawie informacji „poprawka zainstalowana”. Wymagaj walidacji przez ponowne skanowanie, potwierdzenie wersji, weryfikację konfiguracji albo potwierdzenie zabezpieczeń kompensujących. Jeżeli poprawki nie można zastosować, otwórz wyjątek.

Krok 6: Rejestruj wyjątki i ryzyko rezydualne

Polityka zarządzania podatnościami i poprawkami definiuje wymaganą treść wyjątku:

Wnioski o wyjątek muszą obejmować: 7.2.1 Uzasadnienie biznesowe opóźnienia albo braku działań naprawczych 7.2.2 Ocenę ryzyka (opartą na CVSS, krytyczności aktywów, informacjach o zagrożeniach) 7.2.3 Proponowane środki kompensujące 7.2.4 Termin działań naprawczych albo ponownej oceny

Definiuje również zatwierdzenie i przegląd:

Wyjątki muszą być zatwierdzone przez CISO albo delegowany komitet ryzyka i zapisane w Rejestrze odstępstw SZBI, z interwałem przeglądu nieprzekraczającym 90 dni.

Ten rejestr wyjątków staje się kluczowym dowodem dla ISO/IEC 27001:2022 Clause 6.1.3 w zakresie postępowania z ryzykiem i akceptacji ryzyka rezydualnego, a także przeglądu zarządzania.

Ten zapis pokazuje, że organizacja nie zignorowała podatności. Oceniła ryzyko, zastosowała środki kompensujące, zatwierdziła ryzyko rezydualne i wyznaczyła datę przeglądu.

Krok 7: Zbuduj miesięczny pakiet dowodowy

Miesięczny pakiet dowodów dotyczących usuwania podatności powinien obejmować:

W przypadku MŚP dowody mogą być lżejsze, ale nadal muszą być spójne. Polityka zarządzania podatnościami i poprawkami dla MŚP wymaga rejestrów poprawek zapewniających identyfikowalność:

Logi muszą obejmować nazwę urządzenia, zastosowaną aktualizację, datę wdrożenia poprawki i powód każdego opóźnienia

Ta jedna klauzula ma ogromną wartość audytową. Zmienia wdrażanie poprawek z deklaracji w zapis.

Wdrażanie poprawek przez dostawców: umowa musi odpowiadać Twojemu SLA

Jeżeli MSP, dostawca SaaS, dostawca PaaS albo dostawca usług chmurowych kontroluje wdrożenie poprawek, wewnętrzne SLA są bezużyteczne, chyba że obowiązki dostawcy im odpowiadają.

Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP obejmuje obowiązki w zakresie bezpieczeństwa informacji jako wymaganie ładu. W przypadku usuwania podatności obowiązki te powinny zostać przełożone na mierzalny język umowny:

• okna powiadamiania o podatnościach krytycznych,
• terminy działań naprawczych dla podatności krytycznych, wysokich, średnich i niskich,
• proces zmian awaryjnych,
• wymagania dotyczące zatwierdzania przestojów przez klienta,
• format dowodów zakończenia wdrożenia poprawki,
• proces ujawniania podatności,
• obowiązki wsparcia podczas incydentów,
• prawo do audytu albo otrzymywania raportów zapewniających,
• obowiązki podwykonawców przetwarzania albo podwykonawców w zakresie poprawek,
• wsparcie wyjścia i przejścia dla usług krytycznych.

Zenith Blueprint, faza Controls in Action, krok 20, Control 8.21 Bezpieczeństwo usług sieciowych, jasno przedstawia zasadę:

Jeżeli usługi są świadczone zewnętrznie, w tym przez ISP, dostawców SD-WAN albo dostawców chmury prywatnej, wymagania bezpieczeństwa muszą być wbudowane w umowy i SLA. Obejmuje to gwarancje dostępności, czasy reakcji na incydenty, obowiązki wdrażania poprawek albo mitygacji podatności oraz jasne granice postępowania z danymi. Nigdy nie należy zakładać, że dostawca spełnia oczekiwania, chyba że jest to zapisane, mierzalne i audytowalne.

DORA czyni to szczególnie istotnym dla podmiotów finansowych. Uzgodnienia z dostawcami ICT muszą obejmować poziomy usług, wsparcie dostawcy podczas incydentów ICT, dostęp do danych i ich odzyskiwanie, współpracę z organami, prawa wypowiedzenia oraz silniejsze postanowienia dla funkcji krytycznych lub ważnych, w tym monitorowanie, prawa audytu, plany awaryjne i środki bezpieczeństwa.

NIST CSF 2.0 mówi to samo przez wyniki dotyczące ryzyka łańcucha dostaw: dostawcy powinni być znani, priorytetyzowani według krytyczności, oceniani przed rozpoczęciem współpracy, objęci wymaganiami umownymi, monitorowani przez cały okres relacji, uwzględniani w planowaniu incydentów i zarządzani przy zakończeniu współpracy.

O co faktycznie zapytają audytorzy

Rozmowa audytowa zmienia się w zależności od doświadczenia audytora.

Audytor ISO/IEC 27001:2022 zacznie od SZBI. Sprawdzi, czy zarządzanie podatnościami jest ujęte w Deklaracji stosowania, czy ocena ryzyka identyfikuje niezałatane systemy jako ryzyko, czy plany postępowania z ryzykiem mają właścicieli i terminy, czy Annex A control 8.8 jest wdrożony, czy dowody są zachowywane oraz czy audyt wewnętrzny i przegląd zarządzania oceniają skuteczność działania.

Zenith Blueprint, faza Controls in Action, krok 19, wyraża oczekiwanie audytowe wprost:

To zabezpieczenie o wysokim priorytecie dla audytorów i zwykle będą wchodzić głęboko w szczegóły. Spodziewaj się pytań o to, jak często systemy są łatane, jaki proces stosujesz po ogłoszeniu zero-day oraz które systemy najtrudniej załatać.

Kontynuuje praktycznymi oczekiwaniami dowodowymi:

Audytorzy prawdopodobnie poproszą o wyniki skanów podatności. Jeżeli używasz narzędzi takich jak Nessus, OpenVAS albo Qualys, wyeksportuj raport pokazujący ostatnio wykryte podatności i sposób ich obsługi. Najlepiej, aby obejmował oceny ryzyka (CVSS) i terminy działań naprawczych.

Audytor skoncentrowany na NIS2 albo właściwy organ będzie szukał zatwierdzenia przez zarząd, proporcjonalności, cyberhigieny, obsługi podatności, bezpieczeństwa dostawców, obsługi incydentów, oceny skuteczności, działań korygujących bez zbędnej zwłoki oraz zapisów decyzji raportowych, jeżeli wykorzystanie podatności spowodowało istotny wpływ.

Organ nadzorczy DORA sprawdzi, czy ustalenia dotyczące podatności są zintegrowane z zarządzaniem ryzykiem ICT, testowaniem cyfrowej odporności operacyjnej, klasyfikacją incydentów, analizą przyczyny źródłowej, rejestrami stron trzecich, obowiązkami umownymi, prawami audytu i usuwaniem ustaleń krytycznych.

Asesor NIST CSF prawdopodobnie zorganizuje przegląd wokół funkcji GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. Zapyta, czy wymagania prawne i umowne są rozumiane, czy tolerancja ryzyka jest udokumentowana, czy podatności są identyfikowane i priorytetyzowane, czy wyjątki są zarządzane, czy monitorowanie wykrywa wykorzystanie podatności oraz czy działania reagowania i odzyskiwania są skoordynowane.

Audytor COBIT 2019 albo w stylu ISACA skupi się na celach ładu, zdolności procesu, praktykach zarządzania, metrykach, własności, projekcie zabezpieczenia, działaniu zabezpieczenia i wystarczalności dowodów. Zapyta, czy usuwanie podatności jest powtarzalne, mierzone, eskalowane, doskonalone i dostosowane do celów przedsiębiorstwa oraz apetytu na ryzyko.

Eskalacja i metryki: jak udowodnić, że SLA jest zarządzane

SLA bez eskalacji jest tylko celem. Możliwy do obrony program usuwania podatności wymaga eskalacji przed naruszeniem terminu, w momencie naruszenia i po powtarzających się nieskutecznościach.

Clarysec rekomenduje czteropoziomowy model eskalacji:

1. Eskalacja operacyjna — właściciel zgłoszenia i lider techniczny są powiadamiani przed naruszeniem terminu.
2. Eskalacja ryzyka — właściciel aktywa i właściciel ryzyka przeglądają wpływ, gdy naruszenie terminu jest prawdopodobne.
3. Eskalacja ładu bezpieczeństwa — CISO albo komitet ryzyka zatwierdza wyjątek albo działanie awaryjne.
4. Eskalacja zarządcza — powtarzające się albo krytyczne naruszenia SLA są raportowane do przeglądu zarządzania wraz z działaniami korygującymi.

Polityka zarządzania podatnościami i poprawkami wzmacnia to oczekiwanie audytowe:

Okresowe audyty muszą być przeprowadzane przez audyt wewnętrzny albo niezależną stronę trzecią w celu weryfikacji: 5.6.1 Zgodności z SLA 5.6.2 Dowodów priorytetyzacji opartej na ryzyku 5.6.3 Skuteczności wdrożonych poprawek 5.6.4 Kontroli nad niezałatanymi systemami

Metryki powinny wspierać decyzje, a nie ozdabiać panele. Najsilniejsze metryki w 2026 roku obejmują:

• procent zgodności z SLA dla podatności krytycznych,
• procent zgodności z SLA dla podatności wysokich,
• średni czas do kwalifikacji,
• średni czas do usunięcia według klasy aktywów,
• liczbę przeterminowanych podatności krytycznych,
• liczbę zaakceptowanych wyjątków według wieku,
• wyjątki przekraczające 90 dni,
• liczbę krytycznych ekspozycji dostępnych z Internetu,
• naruszenia SLA przez dostawców,
• podatności ponownie otwarte po walidacji,
• zmiany awaryjne spowodowane wykorzystanymi podatnościami,
• niepowodzenia poprawek według platformy albo jednostki biznesowej.

Powiąż te metryki z ISO/IEC 27001:2022 Clause 9.3, czyli przeglądem zarządzania, raportowaniem ładu w DORA oraz nadzorem kierownictwa w NIS2. Dla NIST CSF 2.0 wykorzystaj je do aktualizacji profili bieżących i docelowych, analizy luk oraz planów działań.

Lista kontrolna Clarysec dla SLA dotyczących usuwania podatności

Użyj tej listy kontrolnej do oceny obecnego programu:

• Czy istnieje zatwierdzona polityka zarządzania podatnościami i poprawkami?
• Czy SLA dotyczące działań naprawczych są zdefiniowane według wagi i krytyczności biznesowej?
• Czy podatności dostępne z Internetu i aktywnie wykorzystywane są obsługiwane w trybie przyspieszonym?
• Czy aktywa są mapowane do właścicieli, usług, danych i dostawców?
• Czy ustalenia skanera są przekształcane w przypisane zgłoszenia?
• Czy poprawki są realizowane przez zarządzanie zmianami?
• Czy zmiany awaryjne są dokumentowane i przeglądane?
• Czy wyniki działań naprawczych są walidowane przez ponowne skany albo kontrole wersji?
• Czy wyjątki są oceniane pod kątem ryzyka, zatwierdzane i przeglądane co najmniej co 90 dni?
• Czy środki kompensujące są udokumentowane dla systemów, których nie można załatać?
• Czy umowy z dostawcami są dostosowane do wewnętrznych progów działań naprawczych?
• Czy logi poprawek są wystarczająco kompletne, aby udowodnić, co i kiedy się wydarzyło?
• Czy naruszenia SLA są eskalowane i korygowane?
• Czy metryki są przeglądane przez kierownictwo?
• Czy incydenty i oceny naruszeń są uruchamiane, gdy podejrzewa się wykorzystanie podatności?

Jeżeli kilka odpowiedzi brzmi „nie”, problemem nie są narzędzia. Problemem jest projekt zabezpieczenia.

Kolejne kroki: zamień terminy poprawek w audytowalną odporność

W 2026 roku SLA dotyczące usuwania podatności muszą robić więcej niż zaspokajać panel skanera. Muszą dowodzić, że organizacja potrafi identyfikować ekspozycję, priorytetyzować ryzyko, działać w zatwierdzonych terminach, kontrolować wyjątki, nadzorować dostawców i dokumentować decyzje w ramach oczekiwań audytowych ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 oraz COBIT 2019.

Clarysec może pomóc przejść od rozproszonych zgłoszeń poprawek do zintegrowanego, opartego na dowodach programu usuwania podatności z wykorzystaniem:

• Polityki zarządzania podatnościami i poprawkami
• Polityki zarządzania podatnościami i poprawkami dla MŚP
• Polityki bezpieczeństwa dostawców i stron trzecich dla MŚP
• Zenith Blueprint: 30-krokowej mapy drogowej audytora
• Zenith Controls: przewodnika po zgodności międzyramowej

Zacznij od jednej usługi wysokiego ryzyka. Zmapuj jej aktywa, dostawców, podatności, zgłoszenia, zmiany, wyjątki i dowody. Następnie zastosuj wobec niej pytania audytowe. Jeżeli nie możesz udowodnić SLA od wykrycia do zamknięcia, to jest Twój pierwszy projekt naprawczy.

Celem nie jest perfekcyjne wdrażanie poprawek. Celem jest zarządzane, oparte na ryzyku, mierzalne i audytowalne usuwanie podatności. Pobierz szablony polityk Clarysec, przeprowadź ukierunkowaną ocenę luk albo zarezerwuj demo Clarysec, aby zmienić usuwanie podatności z presji audytowej w odporność operacyjną.