4crypto.eu
Bezpłatna konsultacja
Kompetencja · Wzmacnianie konfiguracji · 2026

Hardening urządzeń i systemów w 2026 r. - CIS, STIG, defense-in-depth

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

Hardening to systematyczne ograniczanie powierzchni ataku poprzez wyłączanie niepotrzebnych usług, zaostrzanie konfiguracji, stosowanie least privilege i wymuszanie standardów branżowych (CIS Benchmarks [1], DISA STIG [2], NIST SP 800-53 Rev. 5 [3]). To najtańsza i najtrwalsza forma redukcji ryzyka - patch łatwo cofnąć, ale dobrze zhardened system pozostaje odporny na lata.

W 2026 r. hardening musi obejmować pięć warstw: serwery (Linux/Windows), stacje robocze, Active Directory, urządzenia sieciowe (firewall, switche L2/L3, routery, Wi-Fi) i - często zaniedbywane - urządzenia OT/IoT (zgodnie z IEC 62443 [4]). Artykuł porządkuje standardy, pokazuje, jak podejść do automatyzacji i co odróżnia paper compliance od realnej odporności.

Hardening - czym jest i czym nie jest

Hardening nie jest:

  • jednorazowym projektem ("zhardujemy raz, zostawmy na 3 lata"),
  • synonimem patchowania (patch usuwa konkretną podatność, hardening eliminuje całe klasy),
  • wyłącznie security through obscurity (zmiana portu SSH z 22 na 2222),
  • antywirusem ani EDR-em (te działają wewnątrz, hardening redukuje to, na czym mogą działać atakujący).

Hardening jest:

  • procesem ciągłym z baseline'em, monitoringiem driftu, regularnym przeglądem,
  • wykonywaniem konkretnych benchmarków (CIS [1], STIG [2]) z udokumentowanymi wyjątkami,
  • standardyzacją obrazów (golden image dla Windows, Ansible playbook dla Linux),
  • częścią defense-in-depth - uzupełniającą EDR, NDR, SIEM i SOC.

Vielberth et al. [5] dokumentują, że organizacje z dojrzałym hardeningiem mają 2-3× mniej alertów krytycznych w SOC - bo wiele technik MITRE ATT&CK [6] (ang. T1059 Command Execution, T1547 Persistence, T1543 Create Service) zostaje zablokowanych konfiguracyjnie zanim EDR musiałby je wykryć.

Standardy - CIS, STIG, NIST i kiedy używać

Trzy główne biblioteki benchmarków:

  • CIS Benchmarks [1] - Center for Internet Security, ~150 benchmarków pokrywających Windows, Linux (Ubuntu, RHEL, Debian, Amazon Linux), macOS, MS SQL, Apache, nginx, Docker, Kubernetes, cloud (AWS, Azure, GCP), sieci (Cisco IOS, Juniper, Palo Alto). Każdy benchmark ma dwa poziomy: L1 (bezpieczny dla wszystkich), L2 (paranoidalny, może ograniczać funkcjonalność). Najszerzej stosowany standard w sektorze komercyjnym.
  • DISA STIG [2] - Defense Information Systems Agency, USA. Bardziej rygorystyczne niż CIS, projektowane pod sektor wojskowy. Pokrywa systemy operacyjne, bazy danych, sieci, aplikacje. Stosowane w polskim sektorze obronnym i wybranych JST.
  • NIST SP 800-53 Rev. 5 [3] - katalog kontroli, w tym kontrole konfiguracji (CM-1 do CM-14). Mniej szczegółowy niż CIS/STIG, ale wprost mapowany do NIST CSF [7] i FedRAMP. NIST SP 800-123 [8] specjalizacja do serwerów.

Dla typowej JST (50 stanowisk, 5 serwerów):

  • Windows 10/11 (workstation): CIS L1 + selektywnie L2 (RDP, BitLocker).
  • Windows Server: CIS L1 (Active Directory), L2 dla DC.
  • Linux: CIS L1, dla serwerów krytycznych L2.
  • Firewall/switch: CIS Cisco IOS lub odpowiedni do urządzenia.
  • Aktive Directory: Microsoft Security Compliance Toolkit + LAPS + Tiered Admin Model.

Co konkretnie się hardening-uje

Siedem warstw, każda z własnym checklistem.

  1. System operacyjny. Wyłączenie zbędnych usług, hardening uwierzytelniania (silne hasła + MFA dla admin, hash NTLM disabled tam gdzie się da, Kerberos AES), polityki haseł, ograniczenie local admin (LAPS w AD, sudo w Linux), wyłączenie protokołów legacy (SMBv1, NTLMv1).

2. Active Directory (najczęściej najsłabsze ogniwo w polskich JST). Hardening: - Tiered Admin Model (Tier 0 = DC i krytyczne serwery; Tier 1 = serwery aplikacyjne; Tier 2 = stacje robocze; konta admin nie mogą przekraczać tierów). - LAPS (Local Administrator Password Solution) - rotacja haseł local admin. - AD ACL hardening - ograniczenie domyślnych uprawnień zwykłych użytkowników (zwłaszcza Authenticated Users na partycjach DNS i SYSVOL). - Kerberos hardening - usunięcie kont z PRE-AUTH disabled, krótkie TGT lifetimes, AES-only.

  1. Sieć. Segmentacja na VLAN-y/zony (LAN użytkownicy / serwery / OT / DMZ / management), reguły firewall default-deny, prywatne VLAN-y dla użytkowników (uniemożliwiające peer-to-peer scanning), 802.1X w sieci kabelowej i Wi-Fi, MAC randomization OFF dla zarządzanych urządzeń, hardening interfejsów zarządzających (out-of-band management, no telnet, SSH key-only).
  2. Endpoint (stacje robocze). AppLocker / Windows Defender Application Control (whitelist wykonywalnych zgodny z NIST SP 800-167), BitLocker pełny dysk, Windows Defender Exploit Guard, Controlled Folder Access, EDR z polityką block-on-suspicious.
  3. Aplikacje. Hardening webservera (TLS 1.2+/1.3, HSTS, security headers - CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy), hardening DB (limit konta dostępu, audit log, row-level security gdzie sensowne), hardening reverse-proxy (rate limiting, WAF).
  4. Cloud i SaaS. CIS Cloud Benchmarks (AWS, Azure, GCP) - MFA, log audit, IAM least privilege, szyfrowanie domyślne, network ACL/NSG. Conditional Access w Microsoft 365 (Geofence Polska, MFA dla admin, block-legacy-protocols).
  5. OT/ICS. Zgodnie z IEC 62443 [4]: separacja sieciowa od IT (DMZ pomiędzy), strict allow-list portów, monitoring NDR (Claroty, Nozomi, Dragos), pasywne (nie aktywne) skanowanie, jasne procedury jump server dla zdalnego dostępu.

Automatyzacja - bez tego nie ma trwałości

Hardening ręczny degraduje się. Po 6 miesiącach typowa konfiguracja wraca do 60-70% zgodności z baseline (przyczyny: tymczasowe zmiany pod incydenty, nowe usługi, błędy adminów).

Trzy filary automatyzacji w 2026 r.:

  1. Infrastructure as Code - Ansible (najprostszy próg wejścia), Puppet, Chef, SaltStack. Hardening zapisany jako playbook → odtwarzalność, audyt zmian w Git, możliwość wyłonienia driftu. Microsoft stack: PowerShell DSC, Group Policy.
  2. Continuous Configuration Compliance - Tenable Nessus z CIS audit policy, Wazuh + CIS-CAT, OpenSCAP (SCAP - Security Content Automation Protocol, standard NIST). Codzienne skany sprawdzające, które maszyny odeszły od baseline.
  3. Golden image pipeline - automatyczne budowanie obrazów Windows/Linux (Packer + Ansible + scan CIS-CAT), publikacja do repozytorium, używanie do każdego nowego wdrożenia. Zapobiega configuration drift już na starcie.

Najczęstsze błędy

Z naszej praktyki audytowej:

  1. "Zhardujemy raz". Brak procesu monitorowania driftu. Sześć miesięcy później system wraca do default'ów.
  2. L2 dla wszystkich. Stosowanie najwyższego poziomu CIS niezależnie od kontekstu. Skutek: dział biznesowy zgłasza, że "nic nie działa", IT odwołuje hardening, organizacja jest mniej bezpieczna niż gdyby wybrała sensowny L1.
  3. Brak wyłączeń w audit policy. Cel hardeningu nie jest 100% zgodność, ale udokumentowane odchylenia. Jeśli serwer X nie może spełnić kontrolki Y bo łamie aplikację Z, to powinno być rejestrowane wyjątkowo z compensating control i przeglądem co 6-12 miesięcy.
  4. Endpoint zhardened, brama otwarta. Stacje robocze i serwery w CIS L2, ale na brzegu sieci wystawiony stary firewall Cisco PIX bez patchowania od 2018. Atakujący wchodzi przez brzeg, wewnętrzny hardening to nieistotne.
  5. AD bez Tiered Admin Model. Konto admin używane jednocześnie do logowania na stacji roboczej i do administrowania DC. Phishing na stację → poświadczenia → DC = pełna kompromitacja w godzinę. DBIR 2024 [9] notuje to jako najczęstszy łańcuch ataku w polskich JST.
  6. Hardening bez monitoringu. Konfiguracja Linux + AppArmor + integralność systemu plików (AIDE) - bez SIEM-u, który zarejestruje alerty z tych mechanizmów, jest niewidoczne. Zob. SOC 24/7.

Regulacje wymagające hardeningu

Pośrednio lub wprost:

  • KSC art. 8 ust. 2 [16] - operatorzy usług kluczowych i dostawcy usług cyfrowych wdrażają "odpowiednie i proporcjonalne środki techniczne i organizacyjne" zapewniające bezpieczeństwo systemu informacyjnego. Po nowelizacji UC59 (transpozycja NIS2, projekt 2024) wymóg jest doprecyzowany przez art. 21 (1) lit. d i h dyrektywy - bezpieczeństwo łańcucha dostaw oraz "podstawowe procedury cyberhigieny", których hardening jest fundamentalnym elementem. Najtwardszy polski wymóg krajowy obligujący do hardeningu systemów.
  • NIS2 art. 21 (1) lit. d [10] - "środki dotyczące bezpieczeństwa łańcucha dostaw" i lit. h - "podstawowe procedury cyberhigieny" - interpretowane jako wymóg hardeningu.
  • DORA art. 9 [11] - sektor finansowy, ICT security.
  • RODO art. 32 (1) lit. a [12] - "pseudonimizacja i szyfrowanie" - częste kontrolki CIS dotyczą szyfrowania w spoczynku i w tranzycie.
  • KRI § 20 ust. 2 pkt 3 [13] - wymóg "zabezpieczenia systemu IT przed nieautoryzowanym dostępem".
  • IEC 62443-3-3 [4] - wymogi systemowe dla bezpieczeństwa OT (norma techniczna sektora przemysłowego, wymagana w wielu jurysdykcjach jako quasi-regulacja).

Trendy 2025-2027

  1. Zero Trust Architecture (NIST SP 800-207) jako naturalny rozwój hardeningu - od wzmacniania poszczególnych systemów do "nie ufaj niczemu, weryfikuj zawsze". ZTA wymaga jako fundamentu poprawnie zhardened endpoint i sieć.
  2. Hardening AI/ML pipeline. Z AI Act [15] - nowy obszar: hardening środowisk treningowych (data poisoning protection), serwowania (prompt injection guards), model registry.
  3. Confidential Computing - TPM 2.0, SGX, AMD SEV-SNP, Arm CCA. Hardening rozszerzony o ochronę in-use (nie tylko at rest i in transit). Krytyczne dla sektora ochrony zdrowia i danych sensytywnych.

Checklist: 10 elementów programu hardening

Lista do przeglądu kwartalnego - nie do jednorazowego "odhaczenia".

  1. Baseline standardów. Wybrany standard (CIS L1/L2, STIG, własny) z dokumentacją uzasadniającą wybór. Wersjonowanie baseline'u (zmiana = wersja + changelog).
  2. Pokrycie warstwowe. Wszystkie 7 warstw (OS, AD, sieć, endpoint, aplikacje, cloud, OT) ma własny baseline. Brak warstwy = ryzyko nieudokumentowane.
  3. Automatyzacja wdrożenia. Ansible/Puppet/PowerShell DSC/Group Policy dla każdej warstwy. Manualne hardening jest dopuszczalne dla one-off serwerów, nie dla floty.
  4. Pomiar driftu. Codzienny skan z porównaniem do baseline (Tenable, Wazuh, OpenSCAP). Drift > 5% generuje alert.
  5. Wyłączenia formalne. Każde odchylenie od baseline ma: nazwę kontrolki, powód, kompensującą kontrolę, datę przeglądu (max 12 mies.), zatwierdzenie.
  6. LAPS w AD. Wszystkie konta lokalne admin mają unikalne, rotujące hasła. Brak LAPS = krytyczna luka.
  7. Tiered Admin Model. Konta admin nie pracują na stacjach roboczych. Konta domain admin używane wyłącznie z dedykowanych Privileged Access Workstations (PAW).
  8. MFA dla wszystkich kont z dostępem zdalnym. RDP, SSH (key + passphrase), VPN, RDP gateway, M365 admin - wszędzie MFA.
  9. Hardening urządzeń sieciowych. Out-of-band management, SSH key-only, brak telnet/http management, syslog do SIEM, regularny patch (zwłaszcza firewall - DBIR 2024 [9] wskazuje 68% wzrost ataków).
  10. Test odzyskiwania. Hardening uniemożliwia typowe problemy konfiguracyjne; ale testuj kopię zapasową i procedurę przywracania min. raz kwartalnie.

Najczęściej zadawane pytania

Czy hardening L2 to przesada dla JST?

Dla serwerów krytycznych (DC, plików, kopia zapasowa) - nie, L2 jest właściwy. Dla stacji roboczych - selektywnie (np. L2 dla MFA, BitLocker, Windows Defender; L1 dla pozostałych ustawień). L2 całościowo dla użytkowników biznesowych zwykle generuje konflikty (Excel makra, drukarki).

Ile czasu zajmuje pełny hardening średniej JST?

Z naszego doświadczenia: 40-80 godzin wdrożenia początkowego (baseline + Ansible + AD hardening + golden image) i 8-16 godzin/miesiąc utrzymania (drift correction, nowe systemy, przegląd wyjątków). Bez automatyzacji utrzymanie podwaja się.

Czy hardening rusza działanie aplikacji?

Czasami tak - szczególnie L2 i STIG. Strategia:

  1. Hardening w środowisku testowym przed produkcją.
  2. Logowanie wszystkich błędów aplikacji po hardeningu.
  3. Wyłączenia formalne dla zidentyfikowanych konfliktów, nie wycofanie całego baseline.
Czy LAPS wystarczy zamiast PAM (Privileged Access Management)?

LAPS rotuje hasła lokalnego administratora - to fundament. PAM (CyberArk, BeyondTrust, Microsoft PIM) dodaje: just-in-time access, sesje nagrywane, dostęp z aplikacji bez ujawniania hasła. PAM jest wymagany dla operatorów usług kluczowych z NIS2, LAPS to absolutne minimum.

Co z OT - czy CIS pokrywa SCADA?

Częściowo. CIS ma benchmarki dla Windows Server (często serwery SCADA są Windows-based), ale specyficzne urządzenia OT (PLC Siemens, Rockwell, Schneider) wymagają IEC 62443 [4]. Praktyka: CIS dla warstwy IT/SCADA HMI + IEC 62443 dla warstwy PLC/RTU.

Czy Group Policy wystarczy do hardeningu Windows?

GPO + Microsoft Security Compliance Toolkit pokrywa 80-90% CIS L1 dla Windows. Pozostałe 10-20% (np. fine-grained AppLocker rules, EDR policies, niektóre AD hardening) wymaga PowerShell DSC, Intune (dla zarządzania nowoczesnego) lub dedykowanych narzędzi.

Co odróżnia 'hardening' od 'security baseline'?

Security baseline to konkretna konfiguracja docelowa (np. "CIS Windows 11 L1 Build 12345"). Hardening to proces wdrożenia i utrzymania tego baseline'u. Baseline jest dokumentem, hardening jest praktyką.

Kiedy CIS Benchmark wyjdzie dla najnowszego Windows Server / Ubuntu LTS?

Typowo 3-6 miesięcy po wydaniu OS. Przykład: Windows Server 2025 wydany w listopadzie 2024, CIS Benchmark opublikowany marzec 2025 (cytat z CIS Knowledge Base). Ubuntu LTS - zwykle 2-4 miesiące po wydaniu. Strategia przejściowa dla nowo wydanych OS:

  1. Stosuj CIS Benchmark dla poprzedniej wersji + Microsoft Security Compliance Toolkit (Microsoft Security Baselines dla Windows pojawiają się szybciej, zwykle ~1 miesiąc po RTM).
  2. DISA STIG [2] - często szybsze cykle wydawania niż CIS.
  3. Mapuj kontrole NIST SP 800-53 Rev. 5 [3] jako fallback.
Hardening psuje Microsoft 365 / Teams / OneDrive - co zrobić?

Typowy konflikt - CIS L2 dla Edge i Defender bywa zbyt rygorystyczny dla Microsoft 365 web apps. Strategia:

  1. Microsoft Security Baselines zamiast CIS L2 dla consumer apps (Microsoft Security Compliance Toolkit). Są bardziej dostosowane do natywnej integracji.
  2. Conditional Access w Entra ID/Azure AD zamiast hardeningu w przeglądarce - egzekwowanie MFA, geofencing PL, blokada legacy auth (POP/IMAP/SMTP-Basic).
  3. Defender for Cloud Apps (CASB) + DLP w M365 do egzekwowania klasyfikacji informacji.
  4. Wyłączenia formalne w SoA (ISO 27001:2022 klauzula 6.1.3 [14]) dla konkretnych kontrolek CIS, które konfliktują z M365 - z udokumentowaną kontrolą kompensującą.
Hardening Active Directory - od czego zacząć?

Praktyczna kolejność (z naszych projektów + Microsoft Securing Privileged Access roadmap):

  1. LAPS ([Local Administrator Password Solution]) - w 1 tygodniu wdrożenia. Bez tego pozostałe kroki to security theater.
  2. Tiered Admin Model (Tier 0/1/2) - separacja kont admin od stacji roboczych. NIST SP 800-53 Rev. 5 AC-6, AC-2 [3].
  3. MFA dla wszystkich kont z dostępem do DC (PrivilegedAccessWorkstations, Windows Hello for Business, klucze sprzętowe FIDO2).
  4. Wyłączenie legacy protocols: NTLMv1, SMBv1, LM hash, Kerberos DES.
  5. AdminSDHolder review - kwartalnie usuwanie nieautoryzowanych obiektów z Protected Users group.
  6. AD ACL hardening - usunięcie nadmiarowych uprawnień Authenticated Users na partycjach DNS/SYSVOL.

Zgodne z CIS Microsoft Active Directory Benchmark [1] i Microsoft Security Compliance Toolkit. Bez tych 6 kroków DBIR 2024 [9] notuje średni time-to-DC-compromise na poziomie 4-8 godzin po pierwszym foothold.

Czy CIS L2 ma sens dla deweloperów (laptopy z prawami admina)?

Częściowo. Deweloperzy potrzebują elewacji uprawnień do pracy (instalacja narzędzi, Docker, WSL, debugger). Kompromis:

  • CIS L1 dla bazy (BitLocker, Defender, brak SMBv1).
  • L2 selektywnie: MFA, BitLocker pre-boot, audit logging, blokada eksportu kluczy.
  • WDAC (ang. Windows Defender Application Control) w trybie audit-only dla deweloperów (logowanie, nie blokada).
  • Endpoint privilege management (Microsoft Endpoint Privilege Management, BeyondTrust, CyberArk EPM) - elewacja just-in-time zamiast permanentnych praw admina.

Zgodne z NIST SP 800-53 Rev. 5 AC-6 [3] (ang. Least Privilege) - uprawnienia adekwatne do roli, ale nie permanentne.

Hardening kontenerów Docker/Kubernetes - od czego zacząć?

CIS Docker Benchmark i CIS Kubernetes Benchmark [1] to standard. Najszybsza wartość:

  1. Image scanning w CI/CD (Trivy, Snyk, Grype) - żaden obraz z krytycznymi CVE nie trafia do produkcji.
  2. Distroless images lub minimum minimal base (Alpine, Wolfi) - mniejsza powierzchnia ataku.
  3. Non-root user w obrazach (run as user > 0, NET_BIND_SERVICE capability jeśli potrzeba portu < 1024).
  4. Read-only root filesystem (readOnlyRootFilesystem: true).
  5. NetworkPolicy w K8s - default deny + explicit allow.
  6. Pod Security Standards (Restricted profile dla produkcji).
  7. Falco lub Tetragon - runtime monitoring zachowania kontenerów (zob. SOC).

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]guidelineCenter for Internet Security (2024). CIS Benchmarks (Linux, Windows, AD, network devices, cloud). CIS · https://www.cisecurity.org/cis-benchmarks
  2. [2]guidelineDefense Information Systems Agency (DISA) (2024). Security Technical Implementation Guides (STIG). DISA Cyber Exchange · https://public.cyber.mil/stigs/
  3. [3]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
  4. [4]standardInternational Electrotechnical Commission (2018). IEC 62443 - Industrial communication networks - Network and system security. IEC · https://www.iec.ch/cyber-security
  5. [5]peer-reviewedVielberth, M., Böhm, F., Fichtinger, I., Pernul, G. (2020). Security Operations Center: A Systematic Study and Open Challenges. IEEE Access, vol. 8, pp. 227756-227779 · DOI: 10.1109/ACCESS.2020.3045514
  6. [6]standardMITRE Corporation (2024). MITRE ATT&CK Framework v15 (Enterprise, Mobile, ICS). MITRE · https://attack.mitre.org/
  7. [7]standardNational Institute of Standards and Technology (2024). NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, February 2024 · DOI: 10.6028/NIST.CSWP.29
  8. [8]standardScarfone, K., Jansen, W., Tracy, M. (2008). NIST SP 800-123: Guide to General Server Security. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-123
  9. [9]reportVerizon Business (2024). 2024 Data Breach Investigations Report (DBIR). Verizon, 17th edition · https://www.verizon.com/business/resources/reports/dbir/
  10. [10]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
  11. [11]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
  12. [12]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
  13. [13]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
  14. [14]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
  15. [15]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
  16. [16]regulationSejm RP (2018, z projektem nowelizacji UC59 z 2024 r.). Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (KSC) - z projektem nowelizacji transponującym dyrektywę NIS2 (UC59, Rządowy Proces Legislacyjny). Dz.U. 2018 poz. 1560 z późn. zm. · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20180001560