SZBI w 2026 r. - obowiązki KSC i KRI a dobrowolne ISO/IEC 27001

System, polityka i dokumentacja

Systemu, polityki bezpieczeństwa i dokumentacji nie należy traktować jako synonimów. System zarządzania obejmuje ludzi, role, procesy, zasoby, technologię, dokumentację oraz mechanizmy oceny i doskonalenia. Polityka bezpieczeństwa informacji jest dokumentem nadrzędnym, który wyznacza kierunek i zobowiązania kierownictwa. Polityki tematyczne rozwijają zasady dla konkretnych obszarów.

W systemie zgodnym z ISO/IEC 27001 ustanowienie polityki bezpieczeństwa informacji jest elementem wymagań normy ^[1]. KSC działa inaczej: art. 8 wymaga między innymi polityk szacowania ryzyka i bezpieczeństwa systemu informacyjnego, w tym polityk tematycznych, ale nie narzuca jednego urzędowego wzoru dokumentacji ^[13].

Polityki tematyczne mogą dotyczyć kontroli dostępu, kryptografii, kopii zapasowych, ciągłości działania, pracy zdalnej, bezpieczeństwa dostawców, zarządzania podatnościami lub obsługi incydentów. Procedura opisuje przebieg czynności, instrukcja sposób wykonania konkretnego zadania, a rejestr lub zapis dokumentuje rezultat. Dokument nadrzędny warto projektować tak, aby wyznaczał trwałe zasady, a szczegóły techniczne pozostawiał w dokumentach, które można aktualizować bez przebudowy całej polityki. Ten temat rozwija materiał 4crypto dotyczący Polityki Bezpieczeństwa Informacji.

Dowodem działania SZBI nie są wyłącznie podpisane dokumenty. Audytor może oceniać także konfiguracje techniczne, logi, zgłoszenia incydentów, próbki nadanych uprawnień, wyniki skanowania podatności, wyniki testów odtworzeniowych, raporty z testów bezpieczeństwa, protokoły przeglądów i wywiady z personelem. Audyt bezpieczeństwa IT, skanowanie podatności, testy penetracyjne albo przegląd hardeningu mogą dostarczyć ważnych dowodów technicznych, ale nie zastępują oceny całego systemu zarządzania.

ISO/IEC 27001:2022 - co rzeczywiście zmieniło się względem wydania z 2013 r.

ISO/IEC 27001:2022 zastąpiła wydanie z 2013 r. ^[1]. Najbardziej widoczna zmiana dotyczy struktury referencyjnego katalogu zabezpieczeń w Załączniku A. Aktualne wydanie zawiera 93 zabezpieczenia pogrupowane w cztery obszary: organizacyjny, dotyczący ludzi, fizyczny i technologiczny. Oficjalne materiały komitetu ISO/IEC JTC 1/SC 27 wskazują odpowiednio 37, 8, 14 i 34 zabezpieczenia ^[3][4]. W wydaniu z 2013 r. katalog był zorganizowany inaczej i obejmował 114 pozycji.

Samo porównanie liczb nie mówi jednak, że poziom wymagań zmalał. Część wcześniejszych pozycji połączono, przeorganizowano albo opisano w inny sposób. W wydaniu z 2022 r. większą widoczność uzyskały między innymi zagadnienia związane z informacjami o zagrożeniach, usługami chmurowymi, zarządzaniem konfiguracją, maskowaniem danych i monitorowaniem działań ^[3][4]. ISO/IEC 27002:2022 zawiera wytyczne dotyczące zabezpieczeń i ich stosowania ^[3].

W 2024 r. opublikowano również Amendment 1 do ISO/IEC 27001:2022 dotyczący uwzględnienia zmian klimatu w analizie kontekstu organizacji ^[2]. Nie przekształca to SZBI w system technicznego reagowania na zjawiska pogodowe. Chodzi o ocenę, czy kwestie związane ze zmianą klimatu są istotne dla kontekstu organizacji i oczekiwań zainteresowanych stron, podobnie jak inne czynniki mogące wpływać na system zarządzania.

W praktyce największe znaczenie nadal ma nie liczba pozycji w Załączniku A, lecz spójność między zakresem, oceną ryzyka, decyzjami o postępowaniu z ryzykiem, wdrożonymi zabezpieczeniami i dowodami ich działania.

Ciągły cykl zarządzania, a nie coroczna akcja dokumentacyjna

SZBI powinien działać w sposób ciągły. Organizacja planuje system, wdraża środki, monitoruje ich działanie, przeprowadza oceny i audyty, reaguje na niezgodności oraz wprowadza ulepszenia. Dwunastomiesięczny kalendarz bywa wygodny organizacyjnie, ale nie oznacza, że wszystkie działania muszą być wykonywane dokładnie raz w roku.

Częstotliwość powinna wynikać z rodzaju działania, ryzyka, zmian i właściwych wymagań prawnych. Uprawnienia użytkownika powinny zostać odebrane wtedy, gdy ustaje potrzeba dostępu, a nie podczas corocznego przeglądu. Krytyczna podatność wymaga reakcji adekwatnej do ryzyka, a nie czekania na kolejny audyt. Test odtworzenia kopii zapasowej powinien mieć częstotliwość wynikającą ze znaczenia systemu i przyjętych parametrów ciągłości działania.

Prawo może narzucać własne terminy. Obowiązujące KRI wymaga okresowego audytu wewnętrznego bezpieczeństwa informacji nie rzadziej niż raz w roku ^[11]. KSC wymaga raz w roku kalendarzowym szkolenia kierownika podmiotu kluczowego lub ważnego oraz osoby, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa ^[13]. Z kolei ustawowy audyt z art. 15 KSC dotyczy podmiotu kluczowego i jest przeprowadzany co najmniej raz na trzy lata, licząc od ostatniego audytu ^[13]. To trzy różne mechanizmy, których nie należy zastępować jednym wpisem w harmonogramie.

W obszarze pomiarów pomocnicze wytyczne daje ISO/IEC 27004:2016 ^[6]. Warto jednak odnotować, że na 24 sierpnia 2026 r. wydanie to nadal jest opublikowane, ale ISO pracuje nad jego następcą, a obecna wersja została przygotowana w odniesieniu do ISO/IEC 27001:2013 ^[6]. To dobry przykład, dlaczego podczas wdrożenia trzeba sprawdzać nie tylko numer normy, ale również jej status i relację z aktualnym wydaniem normy bazowej.

Załącznik A i Deklaracja Stosowania

Załącznik A do ISO/IEC 27001 zawiera referencyjny katalog zabezpieczeń. Nie jest to jednak checklista, którą należy mechanicznie zaznaczyć w całości. Punktem wyjścia pozostają ryzyka, wymagania prawne, umowne i biznesowe oraz potrzeby organizacji. ISO/IEC 27002:2022 pomaga interpretować i wdrażać zabezpieczenia ^[3], a ISO/IEC 27005:2022 zawiera wytyczne dotyczące zarządzania ryzykiem bezpieczeństwa informacji ^[5].

Jeżeli organizacja deklaruje zgodność swojego SZBI z ISO/IEC 27001, przygotowuje Deklarację Stosowania, czyli Statement of Applicability (SoA). Dokument łączy decyzje dotyczące zabezpieczeń z procesem postępowania z ryzykiem i pokazuje, które zabezpieczenia są stosowane oraz jak uzasadniono decyzje dotyczące katalogu referencyjnego ^[1]. Nie należy jednak traktować SoA jako samodzielnego wymogu KSC lub KRI. Jeżeli organizacja nie przyjęła ISO/IEC 27001 jako modelu wykazywania zgodności, przepisy te nie tworzą odrębnego obowiązku posiadania dokumentu o nazwie "Deklaracja Stosowania".

Outsourcing nie usuwa problemu z zakresu SZBI. Jeżeli kopie zapasowe, poczta, monitoring, infrastruktura chmurowa albo obsługa incydentów są realizowane przez dostawcę, zmienia się sposób wykonania zabezpieczenia i podział odpowiedzialności. Organizacja nadal powinna znać ryzyko, wymagania umowne, model odpowiedzialności, sposób nadzoru i dowody wykonania usługi. Własny lub zewnętrzny SOC 24/7 może dostarczać istotnych dowodów dotyczących monitorowania i obsługi incydentów, ale samo korzystanie z SOC nie przesądza o zgodności całego SZBI.

KRI w 2026 r. - obowiązek SZBI bez obowiązkowego certyfikatu ISO

Na 24 sierpnia 2026 r. obowiązuje rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności ^[11]. Jego § 19 ust. 1 nakazuje podmiotowi realizującemu zadania publiczne opracować, ustanowić, wdrożyć i eksploatować, monitorować i przeglądać oraz utrzymywać i doskonalić system zarządzania bezpieczeństwem informacji.

§ 19 ust. 2 wymienia katalog działań, które mają być zapewnione przez kierownictwo. Obejmuje on między innymi aktualizację regulacji wewnętrznych, inwentaryzację sprzętu i oprogramowania, analizę ryzyka, zarządzanie uprawnieniami, szkolenia, ochronę informacji, bezpieczeństwo pracy zdalnej i mobilnej, wymagania wobec umów serwisowych, aktualizacje oprogramowania, zarządzanie podatnościami, zgłaszanie incydentów oraz okresowy audyt wewnętrzny nie rzadziej niż raz w roku ^[11].

§ 19 ust. 3 wprowadza ważny mechanizm. Wymagania ust. 1 i 2 uznaje się za spełnione, jeżeli SZBI został opracowany na podstawie PN-ISO/IEC 27001, a ustanawianie zabezpieczeń i zarządzanie ryzykiem odbywa się na podstawie wskazanych Polskich Norm związanych z tą normą, w tym PN-ISO/IEC 27002 i PN-ISO/IEC 27005 ^[11]. Nie jest to nakaz certyfikacji ISO/IEC 27001. Jest to prawny sposób wykazania spełnienia wymagań KRI przez zastosowanie określonego modelu normatywnego.

Organizacja może więc spełniać KRI bez certyfikatu ISO/IEC 27001. Musi jednak faktycznie wykonać wymagania rozporządzenia i umieć je wykazać. W praktyce audyt KRI powinien być prowadzony według kryteriów rozporządzenia, nawet jeżeli organizacja równolegle utrzymuje system zgodny z ISO/IEC 27001.

Ważne zastrzeżenie dotyczy 2027 r. ELI wskazuje, że obecne rozporządzenie KRI utraci moc 23 lutego 2027 r. ^[11]. W lipcu 2026 r. opublikowano projekt nowego rozporządzenia KRI, oznaczony RD313 ^[12]. Na dzień odniesienia tego artykułu jest to projekt, a nie obowiązujące prawo. Oznacza to, że opisu § 19 z rozporządzenia z 2024 r. nie należy automatycznie przenosić na stan prawny po 23 lutego 2027 r.

KSC po 3 kwietnia 2026 r. - SZBI jako obowiązek podmiotów kluczowych i ważnych

Nowelizacja KSC wdrażająca NIS2 weszła w życie 3 kwietnia 2026 r. ^[14][15]. Aktualny tekst ustawy o KSC, opracowany przez Kancelarię Sejmu według stanu na 18 sierpnia 2026 r., uwzględnia Dz.U. 2026 poz. 20, 252, 815 i 1003 ^[13]. Jest to istotne przy korzystaniu z wcześniejszych opracowań, które zatrzymały się na samej nowelizacji z poz. 252.

Art. 8 ust. 1 KSC nakazuje podmiotowi kluczowemu lub ważnemu wdrożyć SZBI w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi ^[13]. Ustawa wiąże ten system z systematycznym szacowaniem ryzyka oraz z odpowiednimi i proporcjonalnymi środkami technicznymi i organizacyjnymi.

Katalog ustawowy jest rozbudowany. Obejmuje między innymi bezpieczeństwo cyklu nabywania, rozwoju i utrzymania systemów, bezpieczeństwo fizyczne i zasobów ludzkich, łańcuch dostaw, ciągłość działania i odtwarzanie, ciągłe monitorowanie systemu informacyjnego, ocenę skuteczności zabezpieczeń, edukację i cyberhigienę, kryptografię, bezpieczną komunikację, uwierzytelnianie wieloskładnikowe w stosownych przypadkach, zarządzanie aktywami, kontrolę dostępu, informacje o cyberzagrożeniach i podatnościach, zarządzanie incydentami oraz aktualizacje oprogramowania ^[13].

To pokazuje różnicę między "posiadaniem polityki" a wykonaniem KSC. Dokumentacja musi odpowiadać rzeczywistym środkom organizacyjnym i technicznym. Jeżeli na przykład polityka wymaga ciągłego monitorowania, ale systemy krytyczne nie generują odpowiednich logów albo nikt nie analizuje alertów, problem nie jest redakcyjny. Jest to luka w działaniu systemu.

KSC zawiera również przepisy szczególne. Podmiot ważny będący podmiotem publicznym oraz określone podmioty szkolnictwa wyższego, wskazane w art. 8 ust. 3, nie stosują art. 8 ust. 1 w zwykłym kształcie, lecz prowadzą SZBI spełniający wymagania załącznika nr 4 ^[13]. Podmiot publiczny powinien również uwzględnić w swoim SZBI system informacyjny dostarczany przez inny podmiot publiczny w zakresie wynikającym z polityki bezpieczeństwa tego systemu lub przepisów regulujących jego działanie ^[13].

Dodatkowe wymagania mogą wynikać bezpośrednio z prawa UE. Art. 8b KSC wskazuje między innymi dostawców DNS, chmury, centrów przetwarzania danych, CDN, usług zarządzanych i usług zarządzanych w zakresie cyberbezpieczeństwa, którzy stosują środki zarządzania ryzykiem określone w rozporządzeniu wykonawczym Komisji (UE) 2024/2690 ^[13][16]. W ich przypadku sama mapa ISO/IEC 27001 do KSC nie wystarczy, ponieważ trzeba uwzględnić również szczegółowe wymagania unijne.

Odpowiedzialność kierownictwa w KSC

KSC wyraźnie przypisuje odpowiedzialność kierownikowi podmiotu kluczowego lub ważnego. Art. 8c stanowi, że odpowiedzialność pozostaje po stronie kierownika również wtedy, gdy część albo wszystkie obowiązki powierzono innej osobie ^[13]. Art. 8d wiąże kierownika między innymi z decyzjami dotyczącymi przygotowania, wdrażania, stosowania, przeglądu i nadzoru SZBI, planowaniem środków finansowych oraz przydzielaniem zadań ^[13].

To ma praktyczną konsekwencję: zewnętrzny konsultant, administrator, koordynator bezpieczeństwa czy dostawca SOC może wykonywać część działań operacyjnych, ale nie "przejmuje KSC" od kierownika. Podobnie nie powinno się automatycznie przypisywać całości SZBI inspektorowi ochrony danych. RODO pozwala IOD wykonywać inne zadania, ale administrator lub podmiot przetwarzający musi zapewnić, aby nie prowadziło to do konfliktu interesów ^[18].

KSC przewiduje również coroczne szkolenie kierownika i osoby, której powierzono jego obowiązki w zakresie cyberbezpieczeństwa, a udział w szkoleniu ma być udokumentowany ^[13]. Szkolenia personelu i Security Awareness są osobnym zagadnieniem: powinny wynikać z ryzyka i roli pracownika, a nie ograniczać się do jednorazowego podpisania listy obecności.

Terminy KSC dla podmiotów objętych reformą z 2026 r.

Dla podmiotów, które już 3 kwietnia 2026 r. spełniały przesłanki uznania ich za podmiot kluczowy albo ważny, art. 33 ustawy nowelizującej przewiduje 12 miesięcy na realizację obowiązków z rozdziału 3 KSC ^[14]. Oznacza to termin 3 kwietnia 2027 r.

Podmioty, które w dniu wejścia w życie nowelizacji spełniały przesłanki uznania ich za podmiot kluczowy, mają 24 miesiące na pierwszy audyt z art. 15 ust. 1 KSC, czyli do 3 kwietnia 2028 r. ^[14]. Przepisy przejściowe zawierają jednak rozwiązania dotyczące podmiotów, które wcześniej były operatorami usług kluczowych, dlatego przy konkretnym podmiocie trzeba uwzględnić jego wcześniejszy status i historię audytów.

Jeżeli podmiot spełni przesłanki dopiero później, terminy liczy się według mechanizmu przewidzianego w samej KSC. Art. 16 przewiduje 12 miesięcy na realizację obowiązków rozdziału 3, a dla podmiotu kluczowego 24 miesiące na pierwszy audyt, liczone od dnia spełnienia przesłanek ^[13].

Nie należy zatem traktować 3 kwietnia 2027 r. jako uniwersalnej daty dla każdej organizacji, która kiedykolwiek znajdzie się w zakresie KSC.

Audyt KSC, audyt KRI i audyt ISO to różne oceny

Jednym z częstszych błędów jest używanie słowa "audyt" bez wskazania kryteriów. Audyt KRI sprawdza wymagania właściwego rozporządzenia. Ustawowy audyt KSC z art. 15 ma własną podstawę, zakres, częstotliwość i wymagania wobec audytorów ^[13]. Audyt wewnętrzny systemu zgodnego z ISO/IEC 27001 służy ocenie zgodności i skuteczności systemu według kryteriów przyjętego programu audytów ^[1][8].

W KSC art. 15 ust. 2a dodatkowo wyłącza możliwość przeprowadzenia ustawowego audytu przez osobę, która w audytowanym podmiocie realizuje zadania z art. 8 oraz art. 9-13 lub realizowała je w ciągu roku przed rozpoczęciem audytu ^[13]. To bardziej konkretne ograniczenie niż ogólna zasada obiektywności audytu systemu zarządzania.

Dla programów audytów systemów zarządzania aktualną ogólną normą jest ISO 19011:2026, opublikowana w maju 2026 r., która zastąpiła wydanie z 2018 r. ^[7]. Dodatkowe wytyczne dla audytowania SZBI zawiera ISO/IEC 27007:2020 ^[8]. Na 24 sierpnia 2026 r. ISO/IEC 27007:2020 nadal jest opublikowana, ale znajduje się w procesie rewizji ^[8].

Jeżeli organizacja zamawia zewnętrzny Audyt KRI, Audyt KSC & NIS2 albo Audyt bezpieczeństwa IT, warto zatem w umowie i raporcie nazwać kryteria. Sama nazwa usługi nie powinna pozostawiać wątpliwości, czy oceniane są przepisy, norma, stan techniczny infrastruktury, czy wszystkie te elementy w rozdzielonych zakresach.

Zgodność z ISO/IEC 27001 a certyfikacja

Obowiązek prawny, zgodność z normą i certyfikacja to odrębne pojęcia. Ustawa o normalizacji stanowi, że stosowanie Polskich Norm jest dobrowolne ^[17]. Organizacja może więc wdrożyć SZBI oparty na ISO/IEC 27001 z własnej decyzji, z powodu wymagań klienta lub umowy, dla uporządkowania zarządzania albo z zamiarem certyfikacji.

Zgodność z normą bez certyfikacji oznacza, że organizacja wdrożyła wymagania i ocenia system, ale nie posiada decyzji certyfikacyjnej wydanej przez zewnętrzną jednostkę certyfikującą. Certyfikacja jest odrębnym procesem oceny zgodności. Akredytacja dotyczy kompetencji jednostki oceniającej zgodność, a nie samej organizacji wdrażającej SZBI.

Ani § 19 KRI, ani art. 8 KSC nie ustanawiają ogólnego obowiązku posiadania certyfikatu ISO/IEC 27001 ^[11][13]. Certyfikat może jednak stać się wymaganiem konkretnej umowy lub postępowania zakupowego. Wtedy jego znaczenie wynika z danego zobowiązania, a nie z samego faktu istnienia normy.

Certyfikat nie powinien być też traktowany jako automatyczny dowód wykonania wszystkich obowiązków KSC lub KRI. Zakres certyfikowanego SZBI może być inny niż zakres systemów podlegających ustawie. Prawo może również wymagać działań, których norma nie formułuje w taki sam sposób, na przykład ustawowego raportowania incydentów, określonego audytu KSC lub obowiązków związanych z wykazem podmiotów.

Ile pracy wymaga wdrożenie SZBI

Nie istnieje wiarygodny uniwersalny przelicznik typu "jeden tydzień na 50 pracowników". Liczba pracowników wpływa na projekt, ale często nie jest najważniejszą zmienną. Mała firma może utrzymywać kilka środowisk chmurowych, własne oprogramowanie, rozbudowany łańcuch dostaw i usługę działającą 24/7. Duża jednostka może mieć stosunkowo prostą architekturę i dobrze uporządkowane procesy.

Nakład zależy przede wszystkim od zakresu SZBI, liczby usług i lokalizacji, architektury systemów, zależności od dostawców, wymagań prawnych i umownych, jakości inwentaryzacji aktywów, dojrzałości zarządzania ryzykiem, stanu dokumentacji i dostępności właścicieli procesów.

ISO/IEC 27003:2017 pozostaje na 24 sierpnia 2026 r. opublikowaną normą z wytycznymi wdrożeniowymi, ale jej oficjalny opis odnosi ją do ISO/IEC 27001:2013 i ISO prowadzi jej rewizję ^[9]. Dlatego może być pomocnym materiałem metodycznym, ale nie powinna być bez zastrzeżeń przedstawiana jako aktualny przewodnik do każdego szczegółu wdrożenia ISO/IEC 27001:2022.

W projektach wdrożeniowych rozsądna kolejność to najpierw kwalifikacja prawna i określenie zakresu, następnie analiza luk, a dopiero później harmonogram i wycena. Pozwala to oddzielić prace wymagane prawem od dobrowolnych celów certyfikacyjnych. Zewnętrzne wsparcie przy SZBI może uporządkować metodykę i zapewnić niezależną perspektywę, ale nie zastąpi decyzji kierownictwa ani wiedzy właścicieli procesów.

Jak połączyć wymagania organizacyjne z techniką

SZBI nie powinien kończyć się na poziomie regulaminów. Wymaganie dotyczące zarządzania dostępem powinno mieć przełożenie na proces zakładania, zmiany i odbierania kont oraz na okresowe przeglądy uprawnień. Wymaganie dotyczące podatności powinno prowadzić do źródeł informacji o podatnościach, procesu ich oceny, priorytetyzacji, usuwania i weryfikacji. Wymaganie dotyczące ciągłości działania powinno być powiązane z rzeczywistymi kopiami zapasowymi, celami odtworzeniowymi i testami.

To samo dotyczy monitorowania. Centralne zbieranie logów nie jest celem samym w sobie. Trzeba ustalić, jakie zdarzenia są istotne, jakie źródła powinny być objęte monitoringiem, jakie alerty wymagają reakcji, kto reaguje i jak zachowywane są dowody. Usługa SOC 24/7 może realizować część tej funkcji operacyjnej, ale musi być osadzona w procedurach incydentowych i modelu odpowiedzialności organizacji.

Skanowanie podatności i testy penetracyjne również pełnią różne role. Skanowanie pomaga systematycznie wykrywać określone klasy znanych problemów. Test penetracyjny ocenia, czy wybrane słabości można wykorzystać w określonym scenariuszu i jaki może być ich skutek. Hardening ogranicza powierzchnię ataku przez bezpieczniejszą konfigurację. Żaden z tych mechanizmów pojedynczo nie "zapewnia zgodności", ale każdy może stanowić element zarządzania ryzykiem i dostarczać dowodów skuteczności konkretnych środków.

Najczęstsze błędy

1. Sprowadzenie systemu do dokumentacji. Jeżeli pracownik nie wie, jak klasyfikować informacje, administrator nie zna procesu obsługi podatności, a właściciel systemu nie potrafi wskazać, jakie ryzyko zaakceptował, to podpisane polityki nie dowodzą wdrożenia procesu. Są co najwyżej jego deklaracją.
2. Niejasna odpowiedzialność. Kierownictwo powinno określić właścicieli procesów, ryzyk i zabezpieczeń oraz ich uprawnienia decyzyjne. W KSC odpowiedzialność kierownika jest dodatkowo wyraźnie uregulowana ustawowo ^[13].
3. Mieszanie kryteriów. Audyt KSC, KRI i ISO/IEC 27001 nie są wymienne. Certyfikat ISO nie zastępuje ustawowego audytu KSC, a techniczny pentest nie zastępuje audytu SZBI.
4. Zbyt słabe powiązanie ryzyka z decyzjami. Rejestr ryzyka ma wartość wtedy, gdy prowadzi do decyzji: uniknięcia ryzyka, ograniczenia go, przeniesienia, świadomej akceptacji albo innego uzasadnionego sposobu postępowania. Ocena wykonana raz i nieaktualizowana po zmianie architektury szybko traci znaczenie.
5. Brak użytecznych pomiarów. Nie chodzi o produkowanie wskaźników dla samego raportu. Pomiar ma pomagać odpowiedzieć na pytanie, czy zabezpieczenie lub proces osiąga zamierzony cel. Przykładowo można mierzyć czas odebrania uprawnień po zakończeniu współpracy, odsetek wykonanych testów odtworzeniowych, czas obsługi krytycznych podatności albo pokrycie systemów wymaganym monitoringiem. Metryka ma sens tylko wtedy, gdy jest powiązana z decyzją.
6. Audytowanie własnej pracy. Obiektywność audytu wymaga takiego podziału zadań, aby osoba nie oceniała bezkrytycznie rozwiązań, za których projektowanie i wykonanie sama odpowiada. W ustawowym audycie KSC ograniczenie jest jeszcze bardziej precyzyjne i wynika z art. 15 ust. 2a ^[13]. Dla audytów systemów zarządzania wskazówki dotyczące obiektywności i programu audytów zawierają ISO 19011:2026 i ISO/IEC 27007:2020 ^[7][8].
7. Przegląd zarządzania sprowadzony do podpisu. Przegląd powinien prowadzić do decyzji o zmianach, zasobach, ryzykach i działaniach doskonalących. Sam protokół bez decyzji i śledzenia ich wykonania ma ograniczoną wartość.
8. Narzędzia GRC traktowane jako system sam w sobie. Oprogramowanie może automatyzować zbieranie części dowodów, przypomnienia, mapowanie wymagań i monitorowanie konfiguracji. Nie rozstrzyga jednak automatycznie, czy zakres jest prawidłowy, czy ryzyko zostało właściwie ocenione i czy dane zabezpieczenie jest skuteczne w konkretnym kontekście.
9. Modele językowe użyte bez weryfikacji. Mogą wspierać przygotowanie pierwszej wersji dokumentu, pytań audytowych lub wstępnej mapy wymagań, ale wynik trzeba zweryfikować względem rzeczywistych procesów i źródeł. Dokument opisujący procedurę, która w organizacji nie istnieje, pogarsza jakość systemu, bo tworzy fałszywy dowód zgodności.

Kierunki integracji

Systemy zarządzania można integrować, jeżeli organizacja ma ku temu uzasadnienie. Bezpieczeństwo informacji może być powiązane z zarządzaniem prywatnością i ciągłością działania. W obszarze prywatności aktualnym wydaniem jest ISO/IEC 27701:2025, które zastąpiło wydanie z 2019 r. ^[10]. W ciągłości działania punktem odniesienia pozostaje ISO 22301:2019 z Amendment 1:2024, przy czym ISO pracuje już nad kolejnym wydaniem ^[19].

Integracja nie oznacza jednak, że jeden zestaw dokumentów automatycznie spełnia wszystkie przepisy. RODO ma własne wymagania prawne dotyczące przetwarzania danych osobowych ^[18]. KSC ma własny zakres podmiotowy i obowiązki ^[13]. KRI ma własne kryteria ^[11]. Wspólne procesy mogą ograniczyć duplikację, ale ocena zgodności nadal wymaga właściwego kryterium dla każdego reżimu. Zob. Audyt RODO.