Rekomendacja Pełnomocnika nr 2026-67a-9 punkt po punkcie. Jak sprawdzić własny podmiot według katalogu ministerstwa?

Osiem obszarów i jedno zastrzeżenie o dobrowolności. Jakie pytanie zadaję w każdym obszarze, jakiego dowodu szukam i jak zapisać to, czego nie wdrażamy.

Autor: Paweł Rosół
Data: 19.10.2026
Aktualizacja: 19.10.2026
Czytanie: 15 min
Kategoria: Zarządzanie ryzykiem

Stan prawny sprawdzony: 19.10.2026

Spis treści

Jak czytać ten dokument?
Czy ryzyko jest oszacowane i czy ktoś z tego korzysta?
Czy wiemy, co mamy i kto ma do czego dostęp?
Czy bezpieczeństwo jest w zakupie, w aktualizacji, w szyfrowaniu i w serwerowni?
Czy kopie zapasowe przeżyją atak i czy ktoś je odtwarzał?
Czy wiemy, od których dostawców zależy usługa?
Czy ktoś patrzy na logi i czy wiemy, kogo zawiadomić?
Czy pracownicy wiedzą, co zgłaszać?
Kto nadzoruje i kto sprawdza?
Jak zapisać to, czego nie wdrażamy?
Które rekomendacje Pełnomocnika Rządu ukazały się ostatnio?

Rekomendacja Pełnomocnika RząduRekomendacja Pełnomocnika Dokument Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa o środkach ochrony albo o stosowaniu konkretnego produktu lub usługi ICT. Publikowany w BIP; rekomendacje o środkach ochrony są dobrowolne. do Spraw Cyberbezpieczeństwa nr 2026-67a-9 z 15 października 2026 r. to osiem stron i osiem obszarów: od szacowania ryzykaSzacowanie ryzyka Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”. po audyt. Ministerstwo Cyfryzacji opisało ją 16 października jako podstawowy katalog działań dla ponad 70 tys. podmiotów kluczowychPodmiot kluczowy Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata. i ważnych, który ma być punktem wyjścia do budowy albo wzmocnienia cyberodporności.

Dokument nie jest listą kontrolną i sam tak o sobie nie pisze, ale da się go tak przeczytać: każdy punkt oznaczony literą to pytanie, na które podmiot odpowiada „mamy”, „nie mamy” albo „nie dotyczy”. Ten tekst przechodzi te osiem obszarów w kolejności z dokumentu i przy każdym mówi, jakie pytanie zadaję w podmiocie, jakiego dowodu szukam i gdzie zwykle znajduję lukę.

Z każdej litery rekomendacji da się zrobić pytanie, na które podmiot odpowiada dowodem, a nie deklaracją, i to jest najszybszy przegląd SZBI, jaki znam.

O samej rekomendacji napisałem w aktualnościach, a o tym, które z jej punktów są obowiązkiem z ustawy o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych., a które sposobem jego wykonania, w planie do 3 kwietnia 2027 r.. Tutaj tych dwóch rzeczy nie powtarzam.

Jak czytać ten dokument?

Rekomendacja została wydana na podstawie art. 67a ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawy o KSC), a jej stosowanie jest dobrowolne (art. 67a ust. 5). Nie jest kierowana do jednego sektora ani do jednej klasy produktów, inaczej niż wcześniejsze rekomendacje o urządzeniach brzegowych, poczcie czy systemach OTTechnologia operacyjna Systemy, które sterują procesami fizycznymi: sterowniki, SCADA, automatyka w wodociągach i energetyce. W tekstach zostaje angielski skrót OT. w wodociągach. Podpisał ją Krzysztof Gawkowski jako Pełnomocnik Rządu, wicepremier i minister cyfryzacji.

Każdy z ośmiu obszarów ma tę samą budowę: jedno zdanie o celu, potem „w szczególności zaleca się” i lista środków oznaczonych literami. Przy części z nich stoi przypis, który mówi więcej niż sam punkt: definicja zasady 3-2-1, gdzie szukać systemu Artemis, od kiedy zgłaszanie przez system S46System S46 System teleinformatyczny ministra właściwego do spraw informatyzacji, przez który zgłasza się incydenty i prowadzi wykaz podmiotów. Nazwa S46 jest potoczna, od numeru artykułu. jest obowiązkiem. Czytam te przypisy jako część rekomendacji, bo tam są konkrety.

Wnioski końcowe wyznaczają skalę: środki mają być dopasowane do charakteru działalności, usług, znaczenia systemów, poziomu ryzyka i skali podmiotu, a dokument sam nazywa się pomocniczym. Co z tego wynika dla zarządu i które punkty są obowiązkiem, a które sposobem, opisałem w planie do 3 kwietnia 2027 r.. Tu wyciągam z tego jedno: nie każdy punkt jest dla każdego, ale rezygnację z punktu trzeba uzasadnić ryzykiem, a nie brakiem czasu.

Czy ryzyko jest oszacowane i czy ktoś z tego korzysta?

Obszar 1 zaczyna się od szacowania ryzyka (pkt 1.1): systematycznego i udokumentowanego, powtarzanego „nie rzadziej niż raz w roku” i po każdej istotnej zmianie organizacyjnej, technologicznej lub infrastrukturalnej, z uwzględnieniem nowych podatnościPodatność Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV. i zagrożeń zgłaszanych przez zespoły CSIRTCSIRT Zespół reagowania na incydenty bezpieczeństwa komputerowego. Na poziomie krajowym działają trzy: CSIRT GOV (Szef ABW), CSIRT MON (Minister Obrony Narodowej) i CSIRT NASK (NASK-PIB)., producentów oprogramowania i organizacje typu ISAC. Ostatnia litera tego punktu jest dla mnie najważniejsza: wyniki analizy ryzyka mają być podstawą doboru środków.

W podmiocie proszę więc o dwie rzeczy. O ostatni dokument z szacowania ryzyka z datą i podpisem, a potem o jeden dowolny środek z listy zabezpieczeń i wskazanie, które ryzyko z tego dokumentu on ogranicza. Jeśli drugiej odpowiedzi nie ma, rejestr ryzyka istnieje dla audytora, a nie dla organizacji, i to jest luka, którą spotykam najczęściej.

Pkt 1.2 wylicza dziewięć dokumentów, które dokumentacja „powinna obejmować co najmniej”: politykę bezpieczeństwa informacji, politykę szacowania i zarządzania ryzykiem, procedury zarządzania aktywami, kontroli dostępu, zasady pracy zdalnej i korzystania z poczty, procedury reagowania na incydenty, kopii zapasowych i ciągłości działania. Sprawdzam, czy każdy istnieje, kto go zatwierdził i kiedy był ostatnio zmieniany. Procedura kopii zapasowych z datą sprzed migracji do chmury jest dokumentem o systemie, którego już nie ma.

Pkt 1.3 dotyczy kierownictwa: formalne przypisanie odpowiedzialności za obowiązki z ustawy o KSC, coroczne szkolenia dla kierownika podmiotu i osób odpowiedzialnych za cyberbezpieczeństwo, określone role i kompetencje, macierz odpowiedzialności RACI oraz okresowe raportowanie kierownictwu poziomu ryzyka i stanu obowiązków ustawowych. Dla kierownika szkolenie raz w roku kalendarzowym z udokumentowanym udziałem jest obowiązkiem z art. 8e ustawy o KSC, więc tu rekomendacja tylko przypomina. Dowód, o który proszę, to ostatni raport dla zarządu: jeśli nie ma żadnego, obszar 1 jest otwarty niezależnie od tego, jak dobre są polityki.

Czy wiemy, co mamy i kto ma do czego dostęp?

Obszar 2 to inwentaryzacja aktywów (pkt 2.1), tożsamość i uprawnienia (pkt 2.2) oraz uwierzytelnianie wieloskładnikowe i dostęp zdalny (pkt 2.3). Rejestr ma obejmować urządzenia końcowe, serwery, urządzenia sieciowe, systemy OT, bazy danych i oprogramowanie, z właścicielem i klasą krytyczności przy każdym aktywie, a do tego listę usług dostępnych publicznie z internetu oraz ewidencję portów, protokołów i zależności między systemami.

Ten ostatni punkt sprawdzam od zewnątrz. Spisuję publiczne adresy podmiotu i patrzę, co na nich odpowiada, a potem porównuję z rejestrem. Różnica między tymi dwiema listami to zwykle kilka usług, o których dział IT zapomniał albo o których nigdy nie wiedział, bo zostawił je integrator.

Rejestr aktywów, w którym nie ma systemów OT i usług widocznych z internetu, opisuje organizację, w której napastnik nie szuka wejścia.

Pkt 2.2 opiera dostęp na zasadzie minimalnych uprawnień i wiedzy niezbędnej: tylko uprawnienia potrzebne do zadań, wyłączone nieużywane porty, usługi i protokoły, usunięte albo zablokowane konta domyślne i nieużywane, blokada konta po wielokrotnych nieudanych logowaniach, okresowe przeglądy uprawnień i niezwłoczne odbieranie uprawnień osobom, które zmieniają stanowisko albo odchodzą. Dowód jest prosty: lista osób, które odeszły w ostatnim roku, zestawiona z listą aktywnych kont. Rzadko zdarza się, żeby te dwie listy nie miały części wspólnej.

Pkt 2.3 jest najbardziej konkretnym punktem w całym dokumencie. Uwierzytelnianie wieloskładnikowe (MFA) ma być obowiązkowe dla dostępu zdalnego, poczty elektronicznej, systemów krytycznych i kont uprzywilejowanych; bezpośredni dostęp administracyjny do urządzeń i serwerów z publicznego internetu ma być wyłączony; administracja ma iść „wyłącznie za pośrednictwem bezpiecznych połączeń VPN zabezpieczonych MFA”, a konta uprzywilejowane mają być ewidencjonowane i monitorowane. Jeśli w podmiocie poczta administratora nie ma MFA, nie szukam dalej, tylko od tego zaczynam.

Czy bezpieczeństwo jest w zakupie, w aktualizacji, w szyfrowaniu i w serwerowni?

Obszar 3 łączy cztery tematy. Cykl życia systemów (pkt 3.1): wymagania cyberbezpieczeństwa już na etapie planowania i zakupu, testy bezpieczeństwa przed uruchomieniem, bezpieczna eksploatacja i wycofanie, procedury dla urządzeń i oprogramowania po końcu wsparcia producenta (EOL/EOSL). Dowód: ostatnia specyfikacja zamówienia na system albo urządzenie i to, czy jest w niej choć jeden wymóg bezpieczeństwa. Zwykle jest tylko cena i termin.

Zarządzanie podatnościami (pkt 3.2): formalny proces, regularne aktualizacje, regularne skany infrastruktury, w tym państwowym systemem Artemis, monitorowanie komunikatów CSIRT i producentów oraz rejestr wykrytych podatności i działań naprawczych. Przypis 3 mówi, że Artemis jest dostępny przez portal cyber.gov.pl, poprzez moje.cert.pl. To jedyne narzędzie do skanowania nazwane z imienia w całej rekomendacji i narzędzie państwowe, więc brak skanu trudno uzasadnić budżetem. Pytam o datę ostatniego skanu i o to, co zrobiono z wynikiem.

Kryptografia (pkt 3.3): polityka stosowania środków kryptograficznych, szyfrowanie danych przesyłanych i przechowywanych, aktualne i uznane standardy, zarządzanie cyklem życia kluczy, poziom ochrony dopasowany do klasyfikacji aktywów, szyfrowanie danych osobowych i tajemnic prawnie chronionych, a do tego szyfrowanie wiadomości e-mail (rekomendacja wymienia S/MIME lub OpenPGP) i zabezpieczanie udostępnianych plików i archiwów hasłem. Szyfrowanie poczty w praktyce rzadko wychodzi poza kilka osób; zaczynam od dysków w laptopach i od tego, jak podmiot przesyła dostawcom pliki z danymi.

Bezpieczeństwo fizyczne i środowiskowe (pkt 3.4): pomieszczenia techniczne zabezpieczone przed osobami nieuprawnionymi, kontrola dostępu do serwerowni i szaf, rejestry wejść do pomieszczeń kluczowych dla zadań podmiotu, monitoring tej infrastruktury, zasilanie awaryjne (UPS) i jego redundancja. Tu dowód zbieram nogami: idę do serwerowni i sprawdzam, czy drzwi są zamknięte, kto ma klucz i kiedy ostatnio testowano UPS pod obciążeniem.

Czy kopie zapasowe przeżyją atak i czy ktoś je odtwarzał?

Obszar 4 to kopie zapasowe (pkt 4.1) i odtwarzanie po awarii (pkt 4.2). Polityka ma być zgodna z zasadą 3-2-1, którą przypis 4 definiuje: co najmniej trzy kopie danych (oryginał i dwie zapasowe), na co najmniej dwóch różnych nośnikach lub w dwóch technologiach, z jedną kopią poza podstawową lokalizacją albo odseparowaną (offline). Do tego kopie danych, konfiguracji i systemów, logiczna lub fizyczna separacja środowiska backupowego od produkcyjnego oraz ochrona kopii „przed usunięciem, modyfikacją lub zaszyfrowaniem”.

Przypis 4 mówi wprost, że celem tej zasady jest odtworzenie danych także po ataku ransomware. Pytanie, które zadaję, brzmi: czy administrator domeny, którego konto zostało przejęte, może skasować kopie? Jeśli odpowiedź brzmi „tak”, zasada 3-2-1 jest spełniona na papierze i tylko tam.

Kopia zapasowa, której nikt nie odtwarzał, jest hipotezą, a nie zabezpieczeniem.

Pkt 4.2 wymaga regularnych testów odtwarzania z udokumentowanymi wynikami, planu ciągłości działania, planu odtwarzania po awarii, określenia RTO i RPO dla systemów kluczowych dla zadań podmiotu oraz bezpiecznych procedur odbudowy środowiska po incydencie. Dowodem jest protokół z ostatniego testu odtworzenia jednego systemu z czasem, jaki to zajęło. Jak zbudować i sprawdzić plan ciągłości, opisałem w osobnym tekście.

Czy wiemy, od których dostawców zależy usługa?

Obszar 5 ma jedną listę dla łańcucha dostaw: ocena ryzyka przed wyborem dostawcy i okresowa w trakcie współpracy, identyfikacja zależności od podmiotów trzecich, analiza skutków niedostępności usług, wymagania cyberbezpieczeństwa, poziomy usług (SLA) i uprawnienia audytowe w umowach, kontrola zakresu dostępów dostawców, ograniczanie koncentracji usług u jednego dostawcy oraz uwzględnianie ostrzeżeń, decyzji i zaleceń dotyczących dostawców wysokiego ryzyka.

Dla zamawiających publicznych rekomendacja dodaje przesłanki odrzucenia ofert z art. 226 ust. 1 pkt 16, 17 i 19 ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych. Sprawdziłem je w tekście ustawy: pkt 16 dotyczy oferty, której przyjęcie naruszałoby bezpieczeństwo publiczne lub istotny interes bezpieczeństwa państwa, pkt 17 oferty obejmującej produkt, usługę lub proces ICT wskazane w rekomendacji z art. 33 ust. 4 ustawy o KSC jako mające negatywny wpływ na podstawowy interes bezpieczeństwa państwa, a pkt 19 oferty obejmującej produkt, usługę lub proces ICT określone w decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka. Zamawiający, którego regulamin zamówień tych przesłanek nie wymienia, powinien je tam dopisać, bo komisja przetargowa nie sięgnie po przepis, o którym nie wie.

Dowód w tym obszarze to lista dostawców, od których zależy świadczenie usługi, z odpowiedzią na pytanie, co się stanie, gdy każdy z nich zniknie na tydzień. W małym podmiocie ta lista jest krótka, a zapis o bezpieczeństwie w umowie ma zwykle tylko część dostawców z tej listy. Co wpisać do umowy, opisałem w tekście o łańcuchu dostaw.

Czy ktoś patrzy na logi i czy wiemy, kogo zawiadomić?

Obszar 6 to monitorowanie (pkt 6.1) i reagowanie na incydenty (pkt 6.2). Monitoring ma objąć systemy krytyczne, logi mają być zbierane centralnie, analizowane pod kątem anomalii i prób nieuprawnionego dostępu oraz zabezpieczone przed usunięciem lub modyfikacją; rekomendacja zaleca „stosowanie narzędzi klasy SIEM lub rozwiązań równoważnych”, a dla aktywów o wysokiej krytyczności monitorowanie adekwatne do ryzyka, „w uzasadnionych przypadkach w modelu 24/7”.

Słowo „równoważne” jest tu ważne, bo ustawa wymaga monitorowania w trybie ciągłym, a nie klasy produktu (art. 8 ust. 1 pkt 2 lit. g). W podmiocie z kilkoma serwerami centralny serwer logów z kilkunastoma regułami alarmów, które ktoś codziennie czyta, może być równoważny; licencja na SIEM, do którego nikt nie zagląda, równoważna nie jest. Pytam o ostatni alarm i o to, kto go obsłużył.

Pkt 6.2 wylicza procedury obsługi incydentów, ścieżki eskalacji, osoby odpowiedzialne, możliwość zabezpieczenia materiału dowodowego, terminowe zgłaszanie do właściwego CSIRT właściwymi kanałami, w tym przez system S46 „w przypadkach przewidzianych przepisami prawa”, gotowość do współpracy z CSIRT i organami oraz procedury ograniczania skutków ataków, w szczególności DDoS. Terminy zgłoszeń są w ustawie: wczesne ostrzeżenie o incydencie poważnym w ciągu 24 godzin od wykrycia, zgłoszenie w ciągu 72 godzin, sprawozdanie końcowe w ciągu miesiąca od zgłoszenia (art. 11 ust. 1 pkt 4, 4a i 4c), przez system S46 (art. 11 ust. 2). Przypis 6 rekomendacji podaje przy tym datę 3 kwietnia 2027 r.; jak ją czytać wobec ustawy, wyjaśniłem w planie do 3 kwietnia 2027 r..

Dowód w tym obszarze to procedura z nazwiskiem osoby, która decyduje, czy incydent jest poważny, i z numerem telefonu drugiej osoby na wypadek, gdyby pierwsza była na urlopie. Procedura bez nazwisk w pierwszej dobie incydentu nie działa, bo wtedy nikt nie ma czasu jej czytać.

Czy pracownicy wiedzą, co zgłaszać?

Obszar 7 to program podnoszenia świadomości: regularne szkolenia, dostosowane do ról i poziomu dostępu do informacji, ćwiczenia praktyczne i kampanie phishingowe, zasady bezpiecznego korzystania z poczty, zabezpieczenia antyphishingowe i antymalware, zasady korzystania z urządzeń prywatnych, edukacja o obowiązku niezwłocznego zgłaszania podejrzanych zdarzeń oraz korzystanie z materiałów w serwisie cyber.gov.pl i w bazie wiedzy o cyberbezpieczeństwie, do której odsyła przypis 7.

Z tej listy najwięcej mówi mi jeden punkt: czy pracownicy wiedzą, komu i jak zgłosić podejrzany e-mail, i czy ktoś to kiedyś zrobił. Liczba zgłoszeń od pracowników w ostatnim kwartale jest lepszym dowodem niż lista obecności ze szkolenia. Zero zgłoszeń w podmiocie zatrudniającym kilkaset osób nie znaczy, że phishing go omija.

Kto nadzoruje i kto sprawdza?

Obszar 8 zamyka katalog: co najmniej dwie osoby odpowiedzialne za kontakty w sprawach cyberbezpieczeństwa, zgłoszone punkty kontaktowe w odpowiednich systemach teleinformatycznych, okresowe audyty bezpieczeństwa, monitorowanie realizacji zaleceń poaudytowych, regularne testy skuteczności zabezpieczeń, analiza przyczyn i skutków incydentów, wykorzystywanie wyników audytów i testów do doskonalenia systemu oraz okresowe raporty dla kierownictwa o poziomie zgodności z ustawą o KSC i skuteczności środków.

Liczba osób do kontaktu wynika z art. 9 ustawy o KSC, który dla części podmiotów dopuszcza jedną; różnicę między ustawą a pkt 8 lit. a rozpisałem w planie do 3 kwietnia 2027 r.. W praktyce wyznaczam dwie, bo jedna osoba bywa nieosiągalna w dniu, w którym liczą się 24 godziny.

Przy „okresowych audytach” zaznaczam jedno: audytu z art. 15 nie przeprowadza osoba, która w podmiocie realizuje zadania z art. 8 (art. 15 ust. 2a). Jeśli więc jestem pełnomocnikiem ds. cyberbezpieczeństwa w podmiocie, pkt 8 lit. c i d to dla mnie przygotowanie dowodów dla audytora i pilnowanie zaleceń po audycie, a nie sam audyt.

Raport dla kierownictwa o ryzyku i o stanie obowiązków z ustawy o KSC pojawia się w rekomendacji dwa razy, na początku i na końcu, i to nie jest przypadek.

Pkt 1.3 lit. e i pkt 8 lit. h mówią o tym samym raporcie z dwóch stron: o ryzyku i o zgodności. Kierownik podmiotu odpowiada za wykonywanie obowiązków z zakresu cyberbezpieczeństwa także wtedy, gdy powierzył je innej osobie (art. 8c ust. 3), więc bez tego raportu odpowiada za coś, czego nie widzi.

Jak zapisać to, czego nie wdrażamy?

Po przejściu ośmiu obszarów zostaje tabela. Ta, którą prowadzę, ma jeden wiersz na każdą literę rekomendacji i pięć kolumn: stan („mamy”, „częściowo”, „nie mamy”, „nie dotyczy”), dowód (nazwa dokumentu, zapisu albo konfiguracji), ryzyko z szacowania, do którego punkt się odnosi, osoba odpowiedzialna i termin. Wiersz „nie dotyczy” ma w kolumnie dowodu powód: „nie mamy systemów OT”, „poczta u dostawcy, który stosuje MFA dla wszystkich kont”.

Ta tabela robi dwie rzeczy naraz. Zapisy poświadczające wykonywanie czynności z dokumentacji normatywnej są dokumentacją operacyjną z art. 10 ust. 4 ustawy o KSC, więc tabela z dowodami jest częścią dokumentacji, której ustawa wymaga. A wiersz „nie mamy” z powodem i terminem to decyzja o ryzyku, którą kierownik podejmuje świadomie (art. 8d pkt 1), zamiast dowiedzieć się o niej od kontrolującego.

Rekomendacja nie mówi, ile z jej punktów podmiot ma spełniać, i nie powie tego żaden dokument z ministerstwa, bo o tym rozstrzyga ryzyko konkretnej organizacji. Mówi za to, czego kontrolujący będzie szukał w pierwszej kolejności, i to wystarczy, żeby przejść te osiem obszarów z działem IT w jedno popołudnie, zanim ktokolwiek zaproponuje zakup czegokolwiek.

Które rekomendacje Pełnomocnika Rządu ukazały się ostatnio?

Rekomendacja nr 2026-67a-9 jest ogólna, a ministerstwo pisze, że ma być fundamentem dla dotychczasowych i przyszłych rekomendacji w poszczególnych obszarach. Dziesięć ostatnich, od najnowszej, z datą dokumentu i datą publikacji na stronie ministerstwa:

Nr 2026-67a-9, środki organizacyjne i techniczne dla podmiotów krajowego systemu cyberbezpieczeństwa: dokument z 15 października 2026 r., publikacja 16 października 2026 r.
Nr 2026/33/5, podatności w oprogramowaniu MikroTik RouterOS: dokument z 1 października 2026 r., publikacja 2 października 2026 r.
Nr 2026-67-8, bezpieczeństwo systemów OT w sektorze wodociągowo-kanalizacyjnym: dokument z 18 września 2026 r., publikacja 21 września 2026 r.
Nr 2026-67a-7, ochrona kont w komunikatorze Signal przed przejęciem z wykorzystaniem klucza odzyskiwania kopii zapasowej: dokument z 4 września 2026 r., publikacja 8 września 2026 r.
Nr 2026/33/4, podatności w oprogramowaniu WordPress: dokument z 4 sierpnia 2026 r., publikacja 5 sierpnia 2026 r.
Nr 2026/67a/6, utrzymywanie i konfiguracja urządzeń brzegowych: dokument z 21 lipca 2026 r., publikacja 21 lipca 2026 r.
Nr 2026/67a/5, ochrona ISP przed atakami typu DDoS: dokument z 29 czerwca 2026 r., publikacja 30 czerwca 2026 r.
Nr 2026/67a/3, przeciwdziałanie atakom ransomware: dokument z 29 czerwca 2026 r., publikacja 30 czerwca 2026 r.
Nr 2026/67a/4, bezpieczeństwo poczty elektronicznej: dokument z 25 czerwca 2026 r., publikacja 26 czerwca 2026 r.
Dwie rekomendacje z 15 maja 2026 r., obie opublikowane 18 maja 2026 r.: podatności w cPanel oraz WHM i system PAN-OS firmy Palo Alto.

Rekomendacje o jednym produkcie (MikroTik, WordPress, cPanel, PAN-OS) są wydawane na podstawie art. 33 ust. 4 i 4a ustawy o KSC, a nie art. 67a, i ustawa nie nazywa ich dobrowolnymi; różnicę między tymi dwoma rodzajami opisuję w FAQ. Numery i daty biorę z samych dokumentów i ze stron ministerstwa, bo omówienia w mediach czasem przedstawiają starszą rekomendację jako nową.

Pojęcia w tym tekście (26)

Rekomendacja Pełnomocnika: Dokument Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa o środkach ochrony albo o stosowaniu konkretnego produktu lub usługi ICT. Publikowany w BIP; rekomendacje o środkach ochrony są dobrowolne.
Szacowanie ryzyka: Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”.
Podmiot kluczowy: Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata.
System zarządzania bezpieczeństwem informacji: Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów.
Ustawa o KSC: Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.
Technologia operacyjna: Systemy, które sterują procesami fizycznymi: sterowniki, SCADA, automatyka w wodociągach i energetyce. W tekstach zostaje angielski skrót OT.
System S46: System teleinformatyczny ministra właściwego do spraw informatyzacji, przez który zgłasza się incydenty i prowadzi wykaz podmiotów. Nazwa S46 jest potoczna, od numeru artykułu.
Podatność: Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV.
CSIRT: Zespół reagowania na incydenty bezpieczeństwa komputerowego. Na poziomie krajowym działają trzy: CSIRT GOV (Szef ABW), CSIRT MON (Minister Obrony Narodowej) i CSIRT NASK (NASK-PIB).
ISAC: Information Sharing and Analysis Center, centrum wymiany i analizy informacji: organizacja, w której podmioty jednego sektora dzielą się informacjami o zagrożeniach, podatnościach i incydentach.
Zarządzanie ryzykiem: To, co podmiot robi z oszacowanym ryzykiem: dobiera zabezpieczenia, a ryzyko, którego nie ogranicza, akceptuje świadomie.
Incydent: Zdarzenie, które szkodzi albo może zaszkodzić bezpieczeństwu systemów informacyjnych. Zgłaszać trzeba nie każdy incydent, tylko incydent poważny.
Ciągłość działania: Zdolność podmiotu do świadczenia usługi mimo awarii albo ataku. Ustawa wymaga planów ciągłości działania, które są dokumentowane, testowane i utrzymywane.
Kierownik podmiotu: Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie.
Uwierzytelnianie wieloskładnikowe: Logowanie, które wymaga więcej niż jednego składnika, na przykład hasła i kodu z aplikacji. Ustawa o KSC wymienia je wśród środków bezpieczeństwa.
Wirtualna sieć prywatna: Virtual Private Network: szyfrowany tunel, którym pracownik albo oddział łączy się z siecią firmy przez internet. Brama VPN wystawiona do internetu to częsty cel ataków.
Ransomware: Złośliwe oprogramowanie, które szyfruje dane i żąda okupu za ich odszyfrowanie. Coraz częściej sprawcy także wykradają dane i grożą ich upublicznieniem.
Docelowy czas odtworzenia: Recovery time objective: czas od decyzji o uruchomieniu planu do chwili, gdy proces albo system ma znów działać, choćby w ograniczonym zakresie. Musi być krótszy niż maksymalny tolerowany okres zakłócenia.
Docelowy punkt odtworzenia: Recovery point objective: ile danych, liczonych w czasie, podmiot godzi się stracić. RPO równe dobie oznacza kopię zapasową raz dziennie; RPO równe godzinie wymaga replikacji.
Łańcuch dostaw: Dostawcy sprzętu, oprogramowania i usług ICT, od których zależy świadczenie usługi. Ich bezpieczeństwo podmiot uwzględnia w swoim zarządzaniu ryzykiem.
System SIEM: Security Information and Event Management: system, który zbiera w jednym miejscu logi z wielu systemów i urządzeń, żeby można je było analizować i wykrywać w nich ślady incydentów.
Wczesne ostrzeżenie: Pierwsze zgłoszenie incydentu poważnego do CSIRT sektorowego, niezwłocznie i najpóźniej w ciągu 24 godzin od wykrycia. Pełne zgłoszenie idzie w ciągu 72 godzin.
Incydent poważny: Incydent, który poważnie zakłóca usługę, przynosi podmiotowi straty finansowe albo wyrządza poważną szkodę innym. Podmiot kluczowy lub ważny zgłasza go do CSIRT sektorowego.
Audyt bezpieczeństwa: Sprawdzenie, czy system informacyjny używany do świadczenia usługi spełnia wymagania ustawy o KSC. Podmiot kluczowy przeprowadza go na własny koszt co najmniej raz na trzy lata.
Osoba do kontaktu: Osoba wyznaczona przez podmiot kluczowy lub ważny do kontaktów z CSIRT, organami i innymi podmiotami krajowego systemu cyberbezpieczeństwa. Zwykle co najmniej dwie.
Pełnomocnik ds. cyberbezpieczeństwa: Osoba, której kierownik podmiotu powierza zadania z zakresu cyberbezpieczeństwa. To nazwa praktyki: ustawa o KSC nie tworzy takiej funkcji ani nie określa jej zadań.

Najczęściej zadawane pytania

Jakie przesłanki odrzucenia oferty z Prawa zamówień publicznych wskazuje rekomendacja nr 2026-67a-9?

Pkt 5 rekomendacji wskazuje zamawiającym publicznym art. 226 ust. 1 pkt 16, 17 i 19 ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych. Pkt 16 dotyczy oferty, której przyjęcie naruszałoby bezpieczeństwo publiczne lub istotny interes bezpieczeństwa państwa, pkt 17 oferty obejmującej produkt, usługę lub proces ICT wskazane w rekomendacji z art. 33 ust. 4 ustawy o KSC jako mające negatywny wpływ na podstawowy interes bezpieczeństwa państwa, a pkt 19 oferty obejmującej produkt, usługę lub proces ICT określone w decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka.

Czy rekomendacja wymaga wdrożenia systemu SIEM?

Pkt 6.1 lit. d rekomendacji zaleca „stosowanie narzędzi klasy SIEM lub rozwiązań równoważnych”, a lit. f monitorowanie aktywów o wysokiej krytyczności adekwatnie do poziomu ryzyka, w uzasadnionych przypadkach w modelu 24/7. Ustawa o KSC wymaga objęcia systemu informacyjnego systemem monitorowania w trybie ciągłym (art. 8 ust. 1 pkt 2 lit. g) i nie wskazuje klasy produktu. O tym, czy równoważne jest centralne zbieranie logów z regułami alarmów, rozstrzyga oszacowane ryzyko.

Czy zasada 3-2-1 dla kopii zapasowych wynika z ustawy o KSC?

Nie z ustawy, tylko z pkt 4.1 rekomendacji, która w przypisie 4 definiuje ją jako co najmniej trzy kopie danych na co najmniej dwóch nośnikach lub technologiach, z jedną kopią poza podstawową lokalizacją albo offline. Ustawa wymaga planów ciągłości działania, planów awaryjnych i planów odtworzenia działalności, wdrażanych, dokumentowanych, testowanych i utrzymywanych (art. 8 ust. 1 pkt 2 lit. f). Zasada 3-2-1 to sposób, w jaki Pełnomocnik rozumie część tego obowiązku.

Źródła

Stan prawny sprawdzony: 19.10.2026. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).