4crypto.eu
Bezpłatna konsultacja
Kompetencja · Audyt i ocena · 2026

Audyt bezpieczeństwa IT w 2026 r. - metodyki, zakres i jak nie przepalić budżetu

Autor: dr inż. Adam CzubakCzas czytania: 14 minAktualizacja: 2026-05-13

Audyt bezpieczeństwa IT to ustrukturyzowana, niezależna ocena infrastruktury, procesów i polityk bezpieczeństwa organizacji - zakończona pisemnym raportem z udokumentowanymi obserwacjami, klasyfikacją ryzyka i planem działań naprawczych. W odróżnieniu od vulnerability assessmentu (techniczna ocena podatności) i penetration testu (symulacja realnego ataku), audyt obejmuje trzy warstwy jednocześnie: technologię, procesy i ludzi - i jest wymagany regulacyjnie przez ISO/IEC 27001 [1], rozporządzenie KRI [2], dyrektywę NIS2 [3], ustawę KSC [4], RODO art. 32 [5] oraz DORA [6] dla sektora finansowego.

Niniejszy artykuł porządkuje metodyki audytu (ISO 19011, ISO/IEC 27007, NIST SP 800-53A, ISACA ITAF, COBIT 2019), pokazuje, co wchodzi w zakres w typowym projekcie 2026 r., omawia najczęstsze błędy organizacyjne i przedstawia ramową checklistę 10 pytań do dostawcy audytu.

Audyt, assessment, pentest - różnice

W praktyce te trzy pojęcia są często mieszane, co prowadzi do nieadekwatnych zamówień. Różnice:

  • Audyt to systemowa ocena zgodności z wybranym kryterium (norma, regulacja, polityka wewnętrzna). Zgodnie z ISO 19011 [7] cechuje się formalnym planem, listą kontrolną i raportem z obserwacjami sklasyfikowanymi jako niezgodność większa, niezgodność mniejsza lub spostrzeżenie. Audyt nie ma celu wykazania, że organizacja jest bezpieczna - ma wykazać, czy spełnia kryteria.
  • Vulnerability assessment to techniczna ocena podatności w określonym zakresie systemów (zwykle skanowanie automatyczne + weryfikacja ręczna). Skupiony na CVE/CVSS i konfiguracji, bez wnikania w procesy. Szczegółowo omówiony w osobnym artykule o skanowaniu podatności.
  • Penetration test (pentest) to symulacja realnego ataku w warunkach zbliżonych do rzeczywistych - z aktywną eksploatacją podatności i lateralnym ruchem (osobny artykuł o testach penetracyjnych).

Audyt jest podstawowym narzędziem dla compliance i zarządu, pentest - dla zespołu technicznego. Vulnerability assessment łączy obie perspektywy. Najlepsza praktyka to wszystkie trzy w cyklu rocznym: audyt raz na rok, vulnerability assessment co kwartał, pentest - minimum raz w roku (dla operatorów usług istotnych z NIS2 - częściej, zgodnie z polityką organizacji).

Metodyki - który framework wybrać

W 2026 r. dla audytu bezpieczeństwa IT funkcjonuje pięć kluczowych frameworków, które wzajemnie się uzupełniają, a nie wykluczają.

  1. ISO 19011:2018 [7] - Guidelines for auditing management systems. Wytyczne ogólne dotyczące planowania, prowadzenia i raportowania audytów systemów zarządzania (jakością, bezpieczeństwem informacji, środowiskiem). To metodologiczna podstawa każdego profesjonalnego audytu - wymaga się od audytora znajomości jej zasad (kompetencje, niezależność, ślad audytowy).
  2. ISO/IEC 27007:2020 [8] - Guidelines for ISMS auditing. Specjalizacja ISO 19011 do audytu systemu zarządzania bezpieczeństwem informacji (SZBI/ISMS) - czyli przy audycie zgodności z ISO 27001:2022 [1] (i jego 93 kontrolkami z ISO 27002:2022 [9]).
  3. NIST SP 800-53A Rev. 5 [10] - szczegółowy katalog procedur oceny dla kontroli z NIST SP 800-53 Rev. 5 [11]. W praktyce: dla każdej kontrolki (np. AC-2 Account Management) NIST SP 800-53A definiuje listę kroków oceniających, dowodów do zebrania i kryteriów uznania kontroli za skuteczną. Audyt na bazie NIST jest szczególnie dopasowany do organizacji z amerykańskim ekosystemem (kontrakty federalne, sektor produkcji wojskowej, FedRAMP).
  4. ISACA ITAF, 4. edycja [12] - Information Technology Assurance Framework. Stosowany przez audytorów CISA, COBIT-certyfikowanych konsultantów. Skupia się na roli audytora IT w cyklu życia organizacji - od oceny strategicznej IT po audyty operacyjne.
  5. COBIT 2019 [13] - framework zarządzania i nadzoru IT (ang. governance and management). Definiuje 40 obiektywów (procesów) z metrykami i kryteriami dojrzałości CMMI-style. Używany w audytach governance IT, szczególnie przy ocenie zgodności z NIS2 (która kładzie nacisk na ład korporacyjny i odpowiedzialność zarządu).

Wybór zależy od kontekstu:

  • JST i podmioty publiczne - ISO 19011 + ISO 27007 + ISO 27001:2022 + KRI § 20. To pakiet wymagany rozporządzeniem [2] i sprawdzany przez NIK [14].
  • Operator usługi kluczowej (NIS2) - ISO 27007 + COBIT 2019 (komponent governance) + ISO 27001:2022. NIS2 [3] wymaga oceny adekwatności środków, nie konkretnej normy, ale praktyka audytowa konwerguje wokół ISO.
  • Sektor finansowy (DORA) - wszystkie powyższe + TIBER-EU [15] dla testów odporności.

Co dokładnie wchodzi w zakres audytu

Profesjonalny audyt bezpieczeństwa IT w 2026 r. obejmuje siedem warstw, badanych równolegle.

  1. Warstwa fizyczna i środowiskowa - kontrole dostępu, monitoring, klimatyzacja, zasilanie zapasowe, ochrona przed pożarem i zalaniem. Mapowanie do ISO 27001:2022 A.7.1-A.7.14 [1].
  2. Warstwa infrastruktury sieciowej - architektura, segmentacja (VLAN, mikrosegmentacja), firewalle (reguły, log review), VPN, NAC, zabezpieczenia Wi-Fi (WPA3, 802.1X). Wykrywanie shadow IT i nielegalnych punktów dostępu. Dla sektora przemysłowego - separacja IT/OT zgodnie z IEC 62443 [16].
  3. Warstwa systemów operacyjnych i platform - konfiguracja serwerów (Windows, Linux), Active Directory, kontrolki domenowe, hardening zgodny z CIS Benchmarks [17] lub DISA STIG [18]. Patch management zgodnie z NIST SP 800-40 Rev. 4 [19].
  4. Warstwa aplikacji - autoryzacja i uwierzytelnianie, szyfrowanie w spoczynku i w tranzycie, zarządzanie sesjami, ochrona przed OWASP Top 10 [20] dla aplikacji webowych. Dla aplikacji wewnętrznych: nie zapomnijcie o SaaS - typowa organizacja w 2026 r. ma 50-150 aplikacji SaaS, z których 30-40% nie ma scentralizowanego SSO.
  5. Warstwa danych - klasyfikacja informacji (publiczne / wewnętrzne / poufne / tajne), DLP, retencja, backupy (test odtworzeń!), szyfrowanie w spoczynku. Mapowanie do RODO art. 32 [5] i ISO 27001:2022 A.5.12-15.
  6. Warstwa procesów i polityk - polityka bezpieczeństwa informacji (PBI), procedury zarządzania incydentami (zgodne z ISO/IEC 27035-1:2023 [21]), procedury zmian (change management), zarządzanie dostawcami, plany ciągłości działania (BCP/DRP). Audyt sprawdza nie tylko czy dokumenty istnieją, ale czy są wdrożone i znane personelowi.
  7. Warstwa ludzi - szkolenia świadomościowe, rejestr osób z dostępem uprzywilejowanym, separacja obowiązków (ang. segregation of duties), procedury onboardingu i offboardingu pracowników. Sundaramurthy et al. [22] pokazali, że luka między polityką a praktyką jest największym źródłem niezgodności w typowej organizacji.

Typowy zakres audytu pełnego dla średniej JST (50 stanowisk + 5 serwerów + 2 lokalizacje): 8-12 osobodni audytora, 2-3 tygodnie kalendarzowe, raport 80-120 stron z mapowaniem każdej obserwacji do KRI § 20, ISO 27001 i RODO art. 32.

Deliverables - co dokładnie dostajesz

Raport z audytu nie jest listą wszystkich znalezionych problemów ani załącznikiem do umowy "dla pieczątki". Powinien zawierać:

  • Streszczenie zarządcze (1-3 strony) - dla zarządu, bez żargonu, z wnioskami strategicznymi i tabelaryczną oceną dojrzałości.
  • Tabela niezgodności - każda obserwacja z (a) kategorią ryzyka (krytyczne / wysokie / średnie / niskie), (b) odniesieniem do konkretnego przepisu lub kontrolki, (c) opisem dowodu, (d) zaleceniem.
  • Mapa pokrycia - heatmapa pokazująca, które obszary ISO 27001 / KRI / RODO są spełnione, a które nie.
  • Plan remediacji - proponowane działania z czasem realizacji (quick wins w 30 dni, średnioterminowe 90 dni, strategiczne 365 dni) i szacunkowym kosztem.
  • Załączniki techniczne - szczegółowe wyniki skanów, logi, screenshoty (anonimizowane).

ENISA NIS Investments Report 2024 [23] wskazuje, że organizacje z dobrze przeprowadzonym audytem inwestują 40% mniej w nadmiarowe narzędzia - bo wiedzą, czego naprawdę brakuje, zamiast kupować "rozwiązania" reklamowane na targach.

Najczęstsze błędy organizacji

Z naszej praktyki i z raportów NIK [14] wynikają powtarzalne pomyłki:

  1. Audyt jako jednorazowy event, nie cykl. Jeden audyt rocznie, niezależnie od zmian w środowisku (nowa aplikacja, nowy zespół, fuzja). KRI § 20 wymaga audytu minimum raz w roku - to nie znaczy tylko raz.
  2. Audytor wewnętrzny = osoba odpowiedzialna za IT. Konflikt interesów dyskwalifikuje obserwacje (ISO 19011 [7] zasada niezależności). W małych JST praktyczne rozwiązanie: audyt wewnętrzny prowadzony przez audytora z innej jednostki samorządu (wymiana usług) lub przez zewnętrznego eksperta.
  3. Raport bez planu remediacji. "Wykryto 247 podatności" bez priorytetyzacji i właściciela zadania = raport idzie do segregatora, nic się nie zmienia. Tabela niezgodności musi mieć kolumnę "odpowiedzialny" i "termin".
  4. Pomijanie SaaS i shadow IT. Audyt obejmuje tylko zarządzane zasoby. Tymczasem aplikacje kupione "na karty" przez działy biznesowe (typowe: Asana, Notion, ChatGPT Plus) nigdy nie trafiają do rejestru. Microsoft Digital Defense Report 2024 [24] wskazuje, że średnio 70% wycieków danych odbywa się przez aplikacje spoza scentralizowanego IT.
  5. Audyt bez warstwy ludzkiej. Skupianie się tylko na konfiguracji urządzeń i pomijanie pytania: "czy pracownicy wiedzą, jak rozpoznać phishing"? DBIR 2024 [25] - 68% naruszeń ma komponent ludzki.
  6. Audyt przed pierwszym wdrożeniem. Często JST zlecają audyt, gdy nie ma jeszcze polityki bezpieczeństwa informacji, rejestru aktywów ani matrycy uprawnień. Audyt wtedy stwierdza brak wszystkiego - co zarząd już wie. Sensowna kolejność: PBI + SZBI → operacjonalizacja 6-12 miesięcy → audyt.

Regulacje wymagające audytu

Bezpośrednio lub pośrednio audyt bezpieczeństwa IT (lub jego elementów) wymagają:

  • KRI § 20 [2] - JST i podmioty publiczne - audyt minimum 1 raz w roku z elementami ISO/IEC 27001. Najczęściej kontrolowany w raportach NIK [14].
  • NIS2 art. 21 (1) lit. g [3] - operatorzy usług istotnych i kluczowych - "zarządzanie polityką w obszarze cyberbezpieczeństwa, ze szczególnym uwzględnieniem oceny skuteczności środków".
  • DORA art. 6 i art. 24 [6] - sektor finansowy - coroczny przegląd ICT risk management framework + niezależna ocena zewnętrzna (raz na 3 lata).
  • RODO art. 32 (1) lit. d [5] - "regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych". Brak wymogu konkretnej formy, ale audyt jest najtwardszym dowodem na spełnienie tego obowiązku - istotne przy ewentualnym postępowaniu PUODO [26].
  • ISO/IEC 27001:2022 [1] - audyt wewnętrzny (klauzula 9.2) + audyt certyfikacyjny (co 3 lata + roczne nadzorcze).
  • NIST CSF 2.0 funkcja IDENTIFY [27] - ocena ryzyka i kontroli jako pierwszy krok cyklu.

Trendy 2025-2027

Trzy zmiany zmieniają charakter audytu w nadchodzących latach:

  1. Audyt ciągły (ang. continuous auditing). Zastępowanie corocznego audytu strumieniem zautomatyzowanych kontroli (CSPM/CWPP w chmurze, SIEM-based compliance dashboards, automatyczne zbieranie evidence). NIST SP 800-53A Rev. 5 [10] uznaje continuous monitoring za pełnoprawną formę oceny.
  2. Audyt AI/ML w produkcji. AI Act [28] wymaga audytu systemów AI wysokiego ryzyka: jakości danych treningowych, bias testing, robustness, transparency, monitoring po wdrożeniu. To nowa specjalizacja audytora bezpieczeństwa - łącząca cyber, prywatność i ML engineering.
  3. Audyt łańcucha dostaw. Po atakach SolarWinds, MOVEit, XZ Utils - fokus przesuwa się na third-party risk. Audyt wymaga teraz oceny u dostawców (lub żądania od nich własnych audytów typu SOC 2, ISO 27001 - evidence at a distance).

Checklist: 10 pytań przed zamówieniem audytu

Zanim podpiszesz umowę, zweryfikuj: czy audyt będzie miał wartość operacyjną, czy tylko wypełni rubrykę z KRI.

  1. Kryterium audytu. Audytujemy wg czego: ISO 27001:2022, KRI § 20, RODO art. 32, NIS2, COBIT 2019, NIST CSF 2.0 - czy kombinacji? Bez jasnego kryterium audyt to dyskusja, a nie ocena.
  2. Niezależność audytora. Audytor nie może być stroną wdrażającą kontrolowane systemy ani dostawcą żadnych usług IT dla audytowanej organizacji (ISO 19011 zasada niezależności).
  3. Zakres. Które systemy/lokalizacje/aplikacje są w zakresie, a które wyłączone? Wyłączenia muszą być uzasadnione i udokumentowane.
  4. Metodyka pobierania próbek. Czy losowa próba użytkowników/komputerów/uprawnień jest reprezentatywna? Czy próbka pokrywa wszystkie role (admin, kadra zarządzająca, pracownik liniowy, kontraktor)?
  5. Lista kontrolna. Czy otrzymujesz listę pytań przed audytem, żeby zespół IT mógł się przygotować? Dobre audyty są nielutowanie dla audytowanego - celem jest wykryć luki, nie zaskoczyć ludzi.
  6. Komunikacja w trakcie. Codzienny stand-up audytora z koordynatorem klienta (15 min) zapobiega błędom interpretacyjnym w raporcie końcowym.
  7. Klasyfikacja niezgodności. Czy w raporcie obserwacje są kategoryzowane jednoznacznie (np. wg ISO 19011) - krytyczne / wysokie / średnie / niskie + odniesienie do przepisu/kontrolki?
  8. Plan remediacji. Czy raport zawiera proponowane działania z czasem realizacji i (przybliżonym) kosztem? "Wprowadzić MFA" to nie zalecenie - "MFA dla wszystkich kont uprzywilejowanych do 31.03" jest zaleceniem.
  9. Re-test. Czy w cenie jest re-test wybranych obserwacji po remediation? (Często audytorzy proponują re-test po 90 dniach - kluczowe dla zarządu, że problemy faktycznie zostały zamknięte.)
  10. Format raportu. Czy oprócz PDF dostajesz tabelaryczny eksport (CSV/XLSX) niezgodności? To krytyczne dla integracji z systemem ticketów (Jira, GLPI, ServiceNow) i monitorowania remediation.

Najczęściej zadawane pytania

Ile trwa audyt bezpieczeństwa IT dla średniej JST?

Standardowy zakres (KRI § 20 + ISO 27001 + RODO art. 32 dla 50 stanowisk, 5 serwerów, 2 lokalizacje): 8-12 osobodni audytora, 2-3 tygodnie kalendarzowe, raport 80-120 stron. Audyt zakończony spotkaniem zamykającym z zarządem.

Czy audyt można zrobić zdalnie?

Częściowo. Warstwy systemów i procesów audytujemy zdalnie (dostęp do dokumentacji, screen-share, wywiady zdalne). Warstwa fizyczna i środowiskowa wymaga wizyty - minimum 1 dzień na lokalizację. Dla JST z 2-3 lokalizacjami: hybryda 70% zdalnie + 30% on-site.

Czy raport może być utajniony?

Tak. Raport oznaczamy jako poufne - wyłącznie dla wewnętrznego użytku zamawiającego. Wewnętrzne dane techniczne (adresy IP, nazwy hostów, struktury katalogowe) są w załączniku oddzielnym, z innym poziomem dostępu. Klient decyduje, kto z zarządu/IT/audytu wewnętrznego widzi pełen raport.

Czy audyt zwalnia z obowiązku pentestu?

Nie. To różne narzędzia - audyt sprawdza zgodność procesów, pentest weryfikuje techniczną odporność. Operatorzy usług kluczowych z NIS2 powinni robić oba: audyt rocznie + pentest minimum rocznie.

Jaki jest koszt audytu KRI dla JST?

Bazowo 4 900 zł rocznie jako add-on do SOC 24/7 (zamówiony razem). Sam audyt KRI w wariancie standalone: 9 900 zł brutto. Wycena każdorazowo po zapoznaniu z zakresem.

Czy audytor współpracuje z naszym dostawcą IT?

Tak - i powinien. Dostawca IT to często główne źródło wiedzy o środowisku i partner do remediacji. Audytor i dostawca IT to dwie różne role z różnymi celami (audytor: wykryć, dostawca: naprawić). Konflikt interesów zachodzi tylko, gdy audytor i dostawca IT to ta sama firma lub osoby z bezpośrednią zależnością finansową - co łamie zasadę niezależności ISO 19011:2018 [7].

Czy audyt można zrobić w pełni zdalnie? Co audytor faktycznie widzi?

2026 r. - 70-80% zakresu można pokryć zdalnie: dokumentacja (Confluence, SharePoint, intranet), konfiguracja systemów (ang. screen-share, jump host), logi (SIEM, audit log z M365/AzureAD), polityki i procedury, wywiady z personelem. Klauzule 9.2 i 9.3 ISO 27007 [8] wprost dopuszczają audyt zdalny. Warstwa fizyczna i środowiskowa wymaga wizyty (kontrole dostępu, monitoring, UPS, klimatyzacja) - minimum 1 dzień on-site na lokalizację. Hybryda 70/30 jest standardem.

Czy audyt musi być co roku - czy raz na 3 lata wystarczy?

Częstotliwość zależy od kryterium audytu:

  • KRI § 20 [2] - minimum raz na rok (wprost w rozporządzeniu).
  • ISO 27001:2022 [1] - audyt wewnętrzny corocznie (klauzula 9.2), audyt certyfikacyjny zewnętrzny co 3 lata + nadzorcze corocznie.
  • NIS2 [3] - bez wprost wskazanej częstotliwości, "regularnie"; praktyka i rekomendacja ENISA [23]: minimum corocznie dla podmiotów istotnych.
  • PCI DSS - kwartalne skany ASV + roczny audyt QSA.
  • DORA [6] - coroczny przegląd ICT risk + niezależna ocena co 3 lata.

Dla większości polskich organizacji: audyt roczny to standard, niezależny audyt zewnętrzny co 2-3 lata jako wartość dodana.

Audytor pyta o RPO/RTO - co to oznacza i czy mam wiedzieć?

RPO (ang. Recovery Point Objective) - "ile danych możemy stracić" - maksymalny okres, za jaki utrata danych jest akceptowalna (np. RPO = 1h ⇒ backup co godzinę). RTO (ang. Recovery Time Objective) - "jak szybko musimy wrócić" - maksymalny dopuszczalny czas niedostępności (np. RTO = 4h ⇒ usługa musi być z powrotem online w 4h). Oba są zdefiniowane w NIST SP 800-34 Rev. 1 i ISO/IEC 27031. Pytanie audytora oznacza: czy mamy plan ciągłości działania? Brak odpowiedzi = niezgodność z ISO 27001 A.5.30, RODO art. 32 lit. c [5], NIS2 art. 21 [3].

Audyt zewnętrzny vs wewnętrzny - co wybrać dla małej JST?

ISO 27001:2022 klauzula 9.2 [1] wymaga audytu wewnętrznego - to obowiązek organizacji niezależnie od zewnętrznego. Audyt wewnętrzny spełnia formalny wymóg KRI § 20 [2], audyt zewnętrzny daje niezależne potwierdzenie i wyższą wiarygodność (np. dla zarządu, organów nadzorczych, klientów B2B). Praktyka dla małej JST: audyt wewnętrzny prowadzony przez audytora z innej JST (na zasadzie wymiany usług - wymóg niezależności [7] spełniony) + audyt zewnętrzny co 2-3 lata.

Potrzebujesz konsultacji w tym obszarze?

Bezpłatna 30-60 minutowa konsultacja. Bez zobowiązań. Omawiamy potrzeby, skalę i ramowy harmonogram.

Zadzwoń: +48 691 122 312office@4crypto.eu

Powiązane treści

Pozostałe obszary kompetencyjne

Bibliografia i źródła

Wszystkie cytowane źródła są publicznie dostępne. Standardy ISO/IEC, RFC IETF, dyrektywy UE i akty krajowe odsyłają do oryginalnych dokumentów.

  1. [1]standardInternational Organization for Standardization (2022). ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements. ISO/IEC · https://www.iso.org/standard/27001
  2. [2]regulationRada Ministrów RP (2012). Rozporządzenie Rady Ministrów z 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (KRI). Dz.U. 2012 poz. 526 (z późn. zm.) · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20120000526
  3. [3]regulationParlament Europejski, Rada UE (2022). Dyrektywa (UE) 2022/2555 (NIS2) w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
  4. [4]regulationSejm RP (2018). Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (KSC). Dz.U. 2018 poz. 1560 (z późn. zm.) · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20180001560
  5. [5]regulationParlament Europejski, Rada UE (2016). Rozporządzenie (UE) 2016/679 (RODO) w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych. Dziennik Urzędowy UE, L 119, 4.5.2016 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679
  6. [6]regulationParlament Europejski, Rada UE (2022). Rozporządzenie (UE) 2022/2554 (DORA) w sprawie operacyjnej odporności cyfrowej sektora finansowego. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022R2554
  7. [7]standardInternational Organization for Standardization (2018). ISO 19011:2018 - Guidelines for auditing management systems. ISO · https://www.iso.org/standard/70017.html
  8. [8]standardInternational Organization for Standardization (2020). ISO/IEC 27007:2020 - Guidelines for information security management systems auditing. ISO/IEC · https://www.iso.org/standard/77802.html
  9. [9]standardInternational Organization for Standardization (2022). ISO/IEC 27002:2022 - Information security controls. ISO/IEC · https://www.iso.org/standard/75652.html
  10. [10]standardJoint Task Force (2022). NIST SP 800-53A Rev. 5: Assessing Security and Privacy Controls in Information Systems and Organizations. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-53Ar5
  11. [11]standardJoint Task Force (2020). NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-53r5
  12. [12]guidelineISACA (2020). ITAF: A Professional Practices Framework for IS Audit/Assurance, 4th Edition. ISACA, Schaumburg IL · https://www.isaca.org/resources/itaf
  13. [13]guidelineISACA (2019). COBIT 2019 Framework: Governance and Management Objectives. ISACA · https://www.isaca.org/resources/cobit
  14. [14]reportNajwyższa Izba Kontroli (NIK) (2022). Informacja o wynikach kontroli: Realizacja zadań w obszarze cyberbezpieczeństwa przez podmioty publiczne (P/21/006). NIK, Warszawa · https://www.nik.gov.pl/kontrole/P/21/006/
  15. [15]guidelineEuropean Central Bank (2018). TIBER-EU Framework: Threat Intelligence-Based Ethical Red Teaming. ECB · https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
  16. [16]standardInternational Electrotechnical Commission (2018). IEC 62443 - Industrial communication networks - Network and system security. IEC · https://www.iec.ch/cyber-security
  17. [17]guidelineCenter for Internet Security (2024). CIS Benchmarks (Linux, Windows, AD, network devices, cloud). CIS · https://www.cisecurity.org/cis-benchmarks
  18. [18]guidelineDefense Information Systems Agency (DISA) (2024). Security Technical Implementation Guides (STIG). DISA Cyber Exchange · https://public.cyber.mil/stigs/
  19. [19]standardSouppaya, M., Scarfone, K. (2022). NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-40r4
  20. [20]guidelineOpen Worldwide Application Security Project (OWASP) (2021). OWASP Top 10:2021 - Most Critical Web Application Security Risks. OWASP Foundation · https://owasp.org/Top10/
  21. [21]standardInternational Organization for Standardization (2023). ISO/IEC 27035-1:2023 - Information security incident management - Part 1: Principles and process. ISO/IEC · https://www.iso.org/standard/78973.html
  22. [22]peer-reviewedSundaramurthy, S. C., McHugh, J., Ou, X., Wesch, M., Bardas, A. G., Rajagopalan, S. R. (2016). Turning Contradictions into Innovations or: How We Learned to Stop Whining and Improve Security Operations. Twelfth Symposium on Usable Privacy and Security (SOUPS 2016), USENIX Association, pp. 237-251 · https://www.usenix.org/conference/soups2016/technical-sessions/presentation/sundaramurthy
  23. [23]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). NIS Investments Report 2024. ENISA, Heraklion · https://www.enisa.europa.eu/publications/nis-investments-2024
  24. [24]reportMicrosoft (2024). Microsoft Digital Defense Report 2024. Microsoft Threat Intelligence · https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2024
  25. [25]reportVerizon Business (2024). 2024 Data Breach Investigations Report (DBIR). Verizon, 17th edition · https://www.verizon.com/business/resources/reports/dbir/
  26. [26]reportPrezes UODO (2024). Sprawozdanie roczne z działalności Prezesa UODO za 2023 r.. UODO, Warszawa · https://uodo.gov.pl/pl/138/3270
  27. [27]standardNational Institute of Standards and Technology (2024). NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, February 2024 · DOI: 10.6028/NIST.CSWP.29
  28. [28]regulationParlament Europejski, Rada UE (2024). Rozporządzenie (UE) 2024/1689 (AI Act) ustanawiające zharmonizowane przepisy dotyczące sztucznej inteligencji. Dziennik Urzędowy UE, L seria, 12.7.2024 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689