Dodatkowe kontrolki w ISO/IEC 27001: jak otworzyć SZBI na nowe technologie

Picture of Dariusz Rycek

Dariusz Rycek

CEO, MBA, Lead Auditor ISMS, BCMS, AIMS, etc. (CoC PECB), Ekspert w zakresie certyfikacji systemów zarządzania, QSCert Lead Auditor - ISO/IEC 27001, ISO 22301, etc.

Dodatkowe kontrolki ISO/IEC 27001 dla generatywnej AI i nowych technologii

Coraz więcej organizacji pracuje w modelu „AI‑first”, korzysta z kont Pro w narzędziach takich jak ChatGPT, Claude, Gemini czy Perplexity, wdraża IoT, blockchain, edge computing i kontenery. Tymczasem Annex A ISO/IEC 27001 nie zawiera „kontrolki na ChatGPT” ani „kontrolki na blockchain”. W tym artykule pokazuję, jak – zgodnie z duchem normy – projektować dodatkowe kontrolki bezpieczeństwa dla nowych technologii, tak aby SZBI był elastyczny, nowoczesny i dobrze wyglądał na audycie, bez przebudowy całego systemu od zera.

Na tym, polega dojrzałość Twojego SZBI

Jeśli chcesz przełożyć te koncepcje na konkretną politykę, procedury i Deklarację Stosowania w swojej organizacji.
Pomożemy dobrać dodatkowe kontrolki tak, żeby jednocześnie zadowolić biznes, bezpieczeństwo i audytora.
Odezwij się

Dlaczego w ISO/IEC 27001 potrzebujemy dodatkowych kontrolek?

ISO/IEC 27001 jest normą intencjonalnie technicznie neutralną – ma przetrwać kolejne fale technologii, od klasycznych serwerów po generatywną AI i 5G. Kluczową rolę odgrywa tu klauzula 6.1, która nakazuje najpierw zrozumieć kontekst, potrzeby interesariuszy, a potem zidentyfikować ryzyka i zaplanować działania, w tym kontrolki bezpieczeństwa.​

W punkcie 6.1.3 norma wymaga, aby organizacja: wybrała opcje postępowania z ryzykiem, określiła wszystkie niezbędne kontrolki, porównała je z Annex A i udokumentowała to w Deklaracji Stosowania (SoA). Co istotne, w Nocie 3 wprost stwierdzono, że lista kontrolek w Annex A nie jest wyczerpująca – organizacja może i powinna dodawać własne środki, jeśli wymaga tego ryzyko związane z jej technologią, procesami i modelem biznesowym.​

Przy generatywnej AI, IoT, blockchain czy DevSecOps często nie chodzi o to, że Annex A jest „zły”, ale o to, że jest zbyt ogólny. Dodatkowe kontrolki stają się wtedy pomostem między ogólną strukturą normy a konkretną technologią, z którą pracuje organizacja.

ISO 27001

Generatywna AI (ChatGPT, Claude, Gemini, Perplexity) – od ryzyka do kontrolek

Jakie ryzyka niesie generatywna AI w organizacji?

Z perspektywy ISO/IEC 27001 generatywna AI (LLM, GenAI) wprowadza szereg specyficznych zagrożeń: wycieki danych w promptach, możliwość rekonstrukcji fragmentów poufnych informacji, halucynacje i bias w odpowiedziach, brak pełnej przejrzystości co do lokalizacji przetwarzania czy trudności w audytowalności działań użytkowników.

Jeżeli organizacja korzysta z subskrypcji Pro (ChatGPT, Claude, Gemini, Perplexity), to z punktu widzenia SZBI są to normalne zasoby objęte zakresem systemu, tak jak inne aplikacje w chmurze. Różnica polega na tym, że model „rozumie” i „tworzy” treść – więc ryzyko nadużyć i błędnych decyzji na podstawie odpowiedzi AI jest dużo większe niż w klasycznym SaaS. To uzasadnia doprojektowanie dodatkowych kontrolek.​

Propozycja: osobna gałąź A.9 – Emerging Technology Controls (Generative AI)

Dobrym podejściem jest stworzenie w strukturze organizacyjnej listy kontrolek osobnej sekcji, np. A.9 Emerging Technology Controls, gdzie pierwszym podzbiorem są kontrolki dla generatywnej AI. Przykładowo:

A.9.1 – Polityka korzystania z generatywnej sztucznej inteligencji
Organizacja definiuje, zatwierdza i komunikuje politykę korzystania z generatywnej AI (w tym ChatGPT, Claude, Gemini, Perplexity), określając dopuszczalne i niedopuszczalne zastosowania, wymagania weryfikacji wyników AI oraz odpowiedzialności użytkowników i właścicieli procesów. Polityka jest spójna z innymi politykami SZBI i przeglądana co najmniej raz do roku lub po istotnej zmianie technologii.

A.9.2 – Ograniczanie danych wejściowych do systemów generatywnej AI
Organizacja określa, jakie informacje mogą być wprowadzane do narzędzi GenAI, powiązując to z klasyfikacją informacji. W szczególności zabrania się wprowadzania niezaszyfrowanych danych osobowych, danych szczególnych, informacji objętych tajemnicą przedsiębiorstwa i NDA, chyba że spełnione są dodatkowe warunki bezpieczeństwa. W razie potrzeby stosuje się pseudonimizację lub anonimizację danych w promptach.

A.9.3 – Zarządzanie dostępem do usług generatywnej AI
Organizacja wdraża zasady nadawania, przeglądu i wycofywania dostępu do kont Pro w narzędziach AI, definiując role (użytkownik, zaawansowany użytkownik, administrator), wykorzystując integrację z systemem tożsamości (SSO/SCIM) oraz wprowadzając regularny przegląd uprawnień. Proces ten jest zintegrowany z ogólną polityką zarządzania tożsamością i dostępem.

A.9.4 – Logowanie i monitoring użycia generatywnej AI
Organizacja zapewnia rejestrowanie aktywności użytkowników w narzędziach AI (kto, kiedy, z jakiego konta, w jakim celu), przechowywanie logów przez zdefiniowany okres oraz ich integrację z systemami monitoringu bezpieczeństwa. Nietypowe lub niezgodne z polityką użycie (np. próby wprowadzania danych wrażliwych) jest analizowane, a w razie potrzeby traktowane jako incydent bezpieczeństwa.

A.9.5 – Bezpieczeństwo w relacjach z dostawcami generatywnej AI
Organizacja definiuje wymagania wobec dostawców GenAI, obejmujące lokalizację przetwarzania danych, wykorzystanie danych klienta do trenowania modeli, certyfikacje bezpieczeństwa (np. ISO/IEC 27001), mechanizmy zgłaszania incydentów oraz retencję danych. Te wymagania są zapisywane w umowach lub regulaminach i okresowo weryfikowane.

A.9.6 – Weryfikacja wyników generatywnej AI przed użyciem operacyjnym
Organizacja określa, w jakich procesach wyniki generatywnej AI muszą być obligatoryjnie weryfikowane przed użyciem, szczególnie gdy dotyczą decyzji o istotnych skutkach (prawnych, finansowych, HR, bezpieczeństwa). W tych obszarach wprowadza się zasadę human‑in‑the‑loop, a odpowiedzialność za decyzję pozostaje po stronie człowieka, co jest odpowiednio dokumentowane.

ISO 27001, Ai

Inne technologie, które „domagają się” dodatkowych kontrolek

Generatywna AI to dopiero początek. W wielu organizacjach równie dużym wyzwaniem dla SZBI są inne obszary: blockchain, IoT/OT, edge computing, 5G oraz DevSecOps z kontenerami.

Blockchain i Distributed Ledger Technology (DLT)

Blockchain (publiczny, prywatny, konsorcyjny) wymaga szczególnego podejścia do kluczy kryptograficznych, smart kontraktów i łańcucha dostaw. Przykładowe dodatkowe kontrolki:

  • proces zarządzania kluczami kryptograficznymi (generowanie, przechowywanie, rotacja, odzyskiwanie),

  • wymagania dotyczące przeglądu bezpieczeństwa smart kontraktów (code review, testy bezpieczeństwa przed wdrożeniem),

  • zasady dostępu do danych w łańcuchu (szczególnie w rozwiązaniach prywatnych),

  • kryteria wyboru i oceny dostawców platform blockchain (operatorzy węzłów, usługi „Blockchain as a Service”).

Można je zgrupować np. w podsekcji A.9.B – Blockchain and DLT Controls.

IoT i OT – systemy „poza klasycznym IT”

Środowiska IoT (czujniki, urządzenia, inteligentne budynki) oraz OT (linie produkcyjne, SCADA) bywają słabo pokryte przez ogólne zapisy Annex A, szczególnie w obszarze cyklu życia urządzeń i segmentacji sieci. Dodatkowe kontrolki mogą obejmować:

  • zarządzanie cyklem życia urządzeń (rejestr, konfiguracja, aktualizacje, wycofanie),

  • wymogi segmentacji sieci (wydzielone VLAN/zone dla IoT/OT, minimalizacja ruchu między strefami),

  • zasady hardeningu urządzeń (wyłączanie zbędnych usług, protokołów, portów),

  • centralne gromadzenie logów i zdarzeń z urządzeń IoT/OT i ich korelację z logami IT,

  • wymagania bezpieczeństwa i wsparcia aktualizacji w umowach z dostawcami.

Taką grupę można oznaczyć jako A.9.I – IoT/OT Security Controls.

Edge computing i rozproszone przetwarzanie

Edge computing, lokalne mikrowęzły i rozproszone przetwarzanie przenoszą dane i logikę bliżej użytkownika, co oznacza nowe ryzyka fizyczne i logiczne. Dodatkowe kontrolki mogą obejmować:

  • minimalne wymagania fizycznego zabezpieczenia lokalizacji edge (szafy, pomieszczenia, dostęp),

  • szyfrowanie danych at‑rest i in‑transit dopasowane do ograniczeń urządzeń,

  • automatyczne egzekwowanie polityk bezpieczeństwa i konfiguracji na wszystkich węzłach,

  • agregację logów z wielu lokalizacji i centralną analizę w SIEM/SOC,

  • zastosowanie zasad Zero Trust i mikrosegmentacji w architekturze rozproszonej.

To może trafić do podsekcji A.9.E – Edge Computing Security.

5G i sieci prywatne

Nowe architektury sieciowe (5G, sieci prywatne, network slicing) wymagają kontrolek, które rozszerzą ogólne środki z Annex A dotyczące sieci. Organizacje często definiują:

  • kontrolki dla bezpieczeństwa network slicing (izolacja między wirtualnymi sieciami),

  • zasady konfiguracji i aktualizacji elementów sieci 5G,

  • wymagania wobec operatora/dostawcy sieci (logowanie, incydenty, retencja),

  • mechanizmy uwierzytelniania i autoryzacji urządzeń w sieci prywatnej.

Można to zebrać np. jako A.10.1 – 5G and Private Network Security.

DevSecOps, kontenery i orkiestracja

DevSecOps oraz konteneryzacja (Docker, Kubernetes) zmieniają sposób tworzenia i wdrażania systemów – i wymagają bardziej szczegółowych kontrolek niż ogólne wymagania dot. bezpieczeństwa w cyklu życia systemu. Przykładowo:

  • skanowanie obrazów kontenerów pod kątem podatności w pipeline CI/CD,

  • standardy hardeningu klastrów Kubernetes i systemowy przegląd konfiguracji,

  • zaufane rejestry obrazów (dozwolone źródła, podpisywanie obrazów),

  • monitoring bezpieczeństwa kontenerów w runtime, reagowanie na anomalie,

  • zabezpieczenie pipeline’ów CI/CD przed nieautoryzowanymi zmianami (kontrola dostępu, separacja obowiązków).

Takie środki można zgromadzić pod nagłówkiem A.10.2 – Container and DevSecOps Security Controls.

Certyfikacja ISO 27001 – Dołącz do nas. Jesteśmy otwarci na nowe technologie. Każdy audytor tak jest przygotowany do swojej roli aby wspierać klienta w budowaniu kultury bezpieczeństwa, by traktował swój system jak narzędzie.

ISO 27001

Jak to wszystko poukładać w systemie – struktura A.9 i A.10

Aby uniknąć chaosu, warto zaprojektować spójną strukturę, np.:

  • A.9 – Emerging Technology Controls
    – A.9.1 Polityka korzystania z generatywnej AI
    – A.9.2 Ograniczanie danych wejściowych do systemów GenAI
    – A.9.3 Zarządzanie dostępem do usług GenAI
    – A.9.4 Logowanie i monitoring użycia GenAI
    – A.9.5 Bezpieczeństwo w relacjach z dostawcami GenAI
    – A.9.6 Weryfikacja wyników GenAI
    – A.9.B1–B… Kontrolki Blockchain/DLT
    – A.9.I1–I… Kontrolki IoT/OT
    – A.9.E1–E… Kontrolki Edge Computing

  • A.10 – Advanced Infrastructure Controls
    – A.10.1 5G and Private Network Security
    – A.10.2 Container and DevSecOps Security

Każda kontrolka powinna mieć: opis celu, zakres, odpowiedzialności, powiązane procedury/standardy techniczne oraz zasady monitorowania. W Deklaracji Stosowania wszystkie te kontrolki otrzymują swój numer, status, uzasadnienie oraz powiązanie z ryzykami z analizy ryzyka

Jak udokumentować i „sprzedać” dodatkowe kontrolki na audycie

Z punktu widzenia audytora najważniejsze jest, żeby dodatkowe kontrolki:

  • wynikały logicznie z aktualnej analizy ryzyka,

  • były spójne z istniejącymi wymaganiami Annex A (a nie całkowicie „obok”),

  • miały właścicieli, zasady wdrożenia i mierniki skuteczności,

  • pozostawiały dowody działania (logi, raporty, przeglądy, decyzje komitetu).

W Deklaracji Stosowania warto dodać notatkę, że kontrolki A.9–A.10 stanowią rozszerzenie katalogu Annex A, zaprojektowane w odpowiedzi na konkretne technologie wykorzystywane przez organizację (GenAI, IoT, blockchain, 5G, DevSecOps). To bardzo czytelny sygnał, że SZBI nie jest jednorazowym projektem, ale systemem, który rośnie wraz z biznesem.

W kontekście NIS2 i DORA dodatkowe kontrolki przestają być tylko „dobrą praktyką”, a często stają się wymaganiem regulacyjnym lub kontraktowym. Dyrektywa NIS2, odpowiednie ustawy krajowe ją wdrażające oraz rozporządzenie DORA nakładają na organizacje obowiązek wykazania, że zarządzają ryzykiem ICT w sposób adekwatny, udokumentowany i mierzalny – także wtedy, gdy w grę wchodzą generatywna AI, IoT czy złożone łańcuchy dostaw. Coraz częściej to właśnie regulator, bank, ubezpieczyciel albo kluczowy klient wprost oczekuje, że w naszym SZBI pojawią się konkretne, dodatkowe kontrolki (np. dla AI, usług chmurowych, dostawców krytycznych), które uzupełniają ISO/IEC 27001 tak, aby razem spełnić wymogi NIS2/DORA i zapisów umowy.

Podsumowanie

Przewaga organizacji, które wyprzedzają normę, tak można podsumować w jednym zdaniu takie podejście. 
Norma ISO/IEC 27001 celowo zostawia przestrzeń na dodatkowe kontrolki – to zaproszenie dla organizacji, by wyprzedzały zmiany technologiczne, zamiast na nie tylko reagować. Tworząc dedykowaną gałąź kontrolek dla AI, blockchain, IoT, Edge czy DevSecOps:

  • zwiększasz realną dojrzałość bezpieczeństwa informacji,

  • wzmacniasz argumentację na audytach i przed interesariuszami,

  • przygotowujesz grunt pod przyszłe normy (np. ISO/IEC 42001) bez rewolucji w systemie.

W efekcie Twój SZBI przestaje być zbiorem statycznych wymagań, a staje się rzeczywistym narzędziem zarządzania ryzykiem w środowisku, w którym technologia zmienia się szybciej niż kolejne wydania standardów.

FAQ: ISO/IEC 27001 - dodatkowe kontrolki (zabezpieczenia)

To kontrolki bezpieczeństwa zaprojektowane przez organizację ponad to, co znajduje się w Annex A ISO/IEC 27001. Powstają na podstawie analizy ryzyka i są formalnie ujęte w Deklaracji Stosowania jako własne środki bezpieczeństwa, uzupełniające listę referencyjną z Załącznika A.

Tak. Klauzula 6.1.3 wymaga, aby organizacja zidentyfikowała wszystkie niezbędne kontrolki, a następnie porównała je z Annex A. Norma wprost wskazuje, że lista kontrolek z Załącznika A nie jest wyczerpująca i można dodać własne, jeśli wymaga tego ryzyko.

Najczęściej są to: generatywna sztuczna inteligencja (ChatGPT, Claude, Gemini, Perplexity), systemy ML i MLOps, blockchain i DLT, IoT/OT, edge computing, sieci 5G i prywatne oraz DevSecOps i kontenery.

Typowy zestaw obejmuje: politykę korzystania z GenAI, zasady danych wejściowych powiązane z klasyfikacją informacji, zarządzanie dostępem do kont Pro, logowanie i monitoring użycia AI, wymagania wobec dostawców oraz zasady weryfikacji wyników AI przed użyciem w procesach krytycznych

Nie zawsze. W wielu organizacjach wystarczy rozszerzyć istniejący SZBI ISO/IEC 27001 o dodatkowe kontrolki dla AI. ISO/IEC 42001 ma sens wtedy, gdy systemy AI są centralnym elementem modelu biznesowego i wymagają pełnego systemu zarządzania.

Najpierw zaktualizuj analizę ryzyka, dodając scenariusze dla GenAI, IoT, DevSecOps itd. Następnie zidentyfikuj luki w obecnych kontrolkach i zbuduj małą, spójną „gałąź” kontrolek (np. A.9), którą pilotażowo wdrożysz w wybranych obszarach. Dopiero potem skaluj je na całą organizację.

Bibliografia:

Przewijanie do góry