ISO 27001 Załącznik A: jak wdrożyć w praktyce 93 zabezpieczenia

Załącznik A daje zespołom bezpieczeństwa użyteczny zestaw odniesienia. Jego wartość operacyjna wynika z pokazania, dlaczego dane zabezpieczenie ma zastosowanie, jak zostało wdrożone i jakie dowody je potwierdzają w Twoim środowisku. Rejestr z 93 zielonymi wskaźnikami statusu nie wystarczy, jeśli nikt nie potrafi wyjaśnić, jakich systemów te wskaźniki dotyczą.

Dla CTO praktycznym wyzwaniem jest przełożenie celu zabezpieczeń na pracę inżynierską i operacyjną bez przekształcania systemu zarządzania bezpieczeństwem informacji w równoległą biurokrację. Przeglądy dostępu powinny opierać się na rzeczywistych danych o uprawnieniach. Plany odtwarzania powinny odzwierciedlać zależności między usługami. Oceny dostawców powinny dotyczyć usług, z których firma faktycznie korzysta.

Ten przewodnik wyjaśnia, jak dobierać zabezpieczenia, rozdzielać odpowiedzialność, definiować wdrożenia i testować wynikające z nich twierdzenia. Poniższe częstotliwości przeglądów i przykłady wdrożeń są praktycznymi rekomendacjami, a nie uniwersalnymi interwałami narzuconymi przez normę.

Zrozum, czym jest Załącznik A, a czym nie jest

ISO/IEC 27001:2022 zawiera 93 zabezpieczenia w Załączniku A, pogrupowane w cztery tematy. Rozdziały 4–10 zawierają wymagania dotyczące systemu zarządzania: kontekst organizacji, przywództwo, planowanie, wsparcie, działania operacyjne, ocenę efektów działania i doskonalenie. Załącznik A wspiera dobór zabezpieczeń; nie zastępuje tych wymagań ani Twojej oceny ryzyka.

To rozróżnienie ma znaczenie podczas wdrażania. Konfiguracja kopii zapasowych może wspierać wybrane zabezpieczenie, ale nie dowodzi, że określono zakres SZBI, oceniono ryzyka, przeprowadzono audyt wewnętrzny lub przegląd zarządzania. To odrębne działania z odrębnymi dowodami.

Dobór zabezpieczeń opiera się na ryzyku. Określ zabezpieczenia niezbędne do postępowania z Twoimi ryzykami, a następnie porównaj je z Załącznikiem A, aby sprawdzić, czy nie pominięto żadnego niezbędnego zabezpieczenia. Mogą być potrzebne dodatkowe zabezpieczenia spoza Załącznika A. Z drugiej strony możliwe jest uzasadnione wyłączenie; nie istnieje reguła, że każda organizacja musi coś wyłączyć lub wdrożyć dokładnie ten sam zestaw.

ISO/IEC 27002:2022 zawiera wytyczne dotyczące wdrażania zabezpieczeń. Jej atrybuty pomagają porządkować zabezpieczenia według rodzaju zabezpieczenia, właściwości bezpieczeństwa informacji, koncepcji cyberbezpieczeństwa, zdolności operacyjnej i domeny bezpieczeństwa. Są to przydatne pomoce do filtrowania, a nie dodatkowe listy kontrolne certyfikacji. Wiążące brzmienie znajdziesz w licencjonowanych normach.

Wykorzystaj cztery tematy, aby znaleźć właściwych właścicieli

Tematy zapewniają strukturę nawigacyjną, a nie cztery niezależne strumienie prac. Proces odejścia pracownika łączy na przykład obowiązki wynikające z zatrudnienia, administrowanie tożsamością, zwrot sprzętu i dostęp do aplikacji.

Zabezpieczenia organizacyjne: powiąż ład z decyzjami operacyjnymi

Te zabezpieczenia obejmują polityki, obowiązki, rozdzielenie obowiązków, aktywa, klasyfikację informacji i postępowanie z nimi, zarządzanie dostępem, dostawców, incydenty, ciągłość działania, obowiązki prawne i działania przeglądowe.

Zacznij od ustalenia, gdzie zapadają decyzje. Kto zatwierdza nową usługę chmurową? Kto nadaje klasyfikację informacji? Kto decyduje, czy zgłoszone zdarzenie jest incydentem? Polityka powinna czynić te decyzje powtarzalnymi i przypisywać uprawnienia, a nie jedynie wyrażać poparcie dla bezpieczeństwa.

Bezpieczeństwo dostawców wymaga łańcucha dowodów właściwego dla danej usługi: celu biznesowego usługi, przetwarzanych w niej informacji, ocenionych ryzyk, obowiązków umownych i bieżącego przeglądu. Raport zapewniający dostawcy może wspierać tę ocenę, ale jego zakres, okres i obowiązki po stronie klienta muszą odpowiadać sposobowi, w jaki korzystasz z usługi.

Podobnie zarządzanie incydentami wymaga czegoś więcej niż listy kontaktów awaryjnych. Zdefiniuj ścieżki zgłaszania, kryteria oceny, uprawnienia do reagowania, postępowanie z dowodami i wyciąganie wniosków. Zapisuj ćwiczenia lub rzeczywiste reakcje, w tym działania następcze i ich właścicieli.

Zabezpieczenia osobowe: uczyń zdarzenia kadrowe niezawodnymi wyzwalaczami

Osiem zabezpieczeń osobowych dotyczy weryfikacji kandydatów, warunków zatrudnienia, świadomości i szkoleń, postępowania dyscyplinarnego, obowiązków po zmianie zatrudnienia, poufności, pracy zdalnej i zgłaszania zdarzeń.

Wbuduj je w istniejące procesy kadrowe. Nowy pracownik potrzebuje odpowiednich zobowiązań, dostępu i instrukcji. Osoba zmieniająca stanowisko wymaga ponownej oceny uprawnień, a nie tylko ich dodania. Odchodzący pracownik wymaga odebrania dostępu, zwrotu aktywów i jasności co do dalszych obowiązków w zakresie poufności.

Odpowiedzialność często obejmuje kilka zespołów. HR może zainicjować odejście, administratorzy tożsamości wyłączają konto centralne, właściciele aplikacji usuwają lokalnie zarządzany dostęp, a przełożony potwierdza zakończenie. Przypisanie całego procesu zespołowi bezpieczeństwa ukrywa te zależności.

Użyteczne dowody obejmują zatwierdzone zapisy procesów, ukończone szkolenia i działania wobec zaległości, potwierdzone warunki oraz próbki zmian kadrowych. Ogranicz dostęp do wrażliwych dowodów kadrowych; osoba weryfikująca zabezpieczenie nie potrzebuje automatycznie pełnych akt osobowych.

Zabezpieczenia fizyczne: udokumentuj swoją granicę i granicę dostawcy

Zabezpieczenia fizyczne dotyczą pomieszczeń, wejść, monitorowania, zagrożeń środowiskowych, obszarów bezpiecznych, biurek i ekranów, sprzętu, nośników, mediów zasilających, okablowania, konserwacji i utylizacji.

Organizacja działająca przede wszystkim w chmurze nadal musi uwzględniać bezpieczeństwo fizyczne. Część wdrożenia może zapewniać dostawca chmury, a za dostęp do biura i urządzenia pracowników organizacja wciąż odpowiada sama. Zapisz ten podział, zamiast automatycznie wyłączać cały temat.

W przypadku własnych lokalizacji ustal, kto może do nich wejść, jak zmienia się dostęp, gdzie znajduje się wrażliwy sprzęt i jak obsługiwani są goście. W przypadku urządzeń używanych zdalnie określ zasady przechowywania, transportu, naprawy i utylizacji odpowiednie do ich ryzyk.

Dowodami mogą być zapisy autoryzacji dostępu, procedury dla gości, inwentarze sprzętu i zapisy utylizacji. Dowody dostawcy powinny wyjaśniać, jakie obiekty i usługi obejmują; nie należy ich traktować jako dowodu zabezpieczeń Twojego biura lub laptopów.

Zabezpieczenia technologiczne: określ pokrycie przed wyborem narzędzi

Temat technologiczny obejmuje urządzenia końcowe, dostęp uprzywilejowany, uwierzytelnianie, dostęp do kodu źródłowego, pojemność, złośliwe oprogramowanie, podatności, konfiguracje, postępowanie z danymi, kopie zapasowe, odporność, logowanie, monitorowanie, sieci, kryptografię, rozwój oprogramowania i zarządzanie zmianami.

Zacznij od pokrycia systemów. Polityka tożsamości jest niekompletna, jeżeli dostęp produkcyjny, konta usługowe lub osobno zarządzana aplikacja pozostają poza jej wdrożeniem. Platforma logowania jest niekompletna, jeżeli krytyczne zdarzenia nigdy do niej nie trafiają lub nikt nie reaguje na alerty.

W przypadku rozwoju oprogramowania powiąż wymagania i decyzje projektowe z przeglądem kodu, testami bezpieczeństwa, rozdzieleniem środowisk, postępowaniem z danymi testowymi i zatwierdzaniem wydań. Modelowanie zagrożeń może pomóc zidentyfikować wymagania bezpieczeństwa przed wdrożeniem. Głębokość testów powinna wynikać z ryzyka i obowiązków; ISO 27001 nie narzuca uniwersalnego harmonogramu testów penetracyjnych.

W przypadku kryptografii odróżniaj dane przechowywane od przesyłanych i dokumentuj odpowiedzialność za klucze, dostęp do nich, ich odtwarzanie, rotację i unieważnianie. Stwierdzenie „szyfrowanie włączone” pozostawia bez odpowiedzi ważne pytania wdrożeniowe.

Co zmieniło się w 2022 roku i gdzie szukać luk

Wydanie z 2013 roku zawierało 114 zabezpieczeń w 14 domenach. Wydanie z 2022 roku przeorganizowało je w 93 zabezpieczenia w czterech tematach, w tym 11 nowych. Mniejsza liczba nie oznacza mniej pracy w obszarze bezpieczeństwa: konsolidacja może umieścić kilka obowiązków operacyjnych pod jednym odniesieniem.

Aktualizując starszy rejestr, zachowaj istniejące wdrożenia i dowody, zamiast jedynie podmieniać identyfikatory. Sprawdź, czy nowe pogrupowanie zmienia pokrycie, odpowiedzialność lub testy potrzebne do potwierdzenia Twojego statusu.

Termin przejścia dla akredytowanej certyfikacji według ISO/IEC 27001:2013 upłynął 31 października 2025 r. Te certyfikaty nie są już ważne; sama aktualizacja rejestru zabezpieczeń nie zapewnia certyfikacji według wydania z 2022 roku.

Poniżej przedstawiono praktyczne punkty wyjścia dla 11 nowych zabezpieczeń, a nie odwzorowanie ich wiążącego brzmienia.

Nie traktuj ich jako jedenastu automatycznych zakupów produktów. Analiza zagrożeń wymaga na przykład analizy i działania, a nie tylko subskrybowanego źródła danych. Usuwanie danych wymaga zrozumienia kopii, kopii zapasowych i obowiązków przechowywania, a nie wyłącznie przycisku „usuń”. Monitorowanie potrzebuje operacyjnej ścieżki reagowania.

Zapisuj zastosowanie i wdrożenie oddzielnie

Twoja deklaracja stosowania (SoA) powinna wskazywać niezbędne zabezpieczenia, wyjaśniać ich uwzględnienie, zapisywać, czy zostały wdrożone, oraz uzasadniać wyłączenia zabezpieczeń z Załącznika A. Wymagania te znajdują się w przepisach dotyczących postępowania z ryzykiem w ISO/IEC 27001.

Wykorzystanie wszystkich 93 odniesień jako indeksu przeglądu to praktyczny sposób, aby porównanie dało się sprawdzić. Uwzględnij też wszelkie dodatkowe niezbędne zabezpieczenia. Deklaracja stosowania nie jest rejestrem ryzyka, planem postępowania z ryzykiem ani repozytorium dowodów, choć tam, gdzie to istotne, powinna się z każdym z nich łączyć.

Dla każdego mającego zastosowanie zabezpieczenia zapisz:

• Ryzyka lub obowiązki uzasadniające jego uwzględnienie.
• Właściwe systemy, lokalizacje, informacje i procesy.
• Faktyczne wdrożenie i odpowiedzialnego właściciela.
• Dowody potwierdzające i okres ich przeglądu.
• Zależności, wyjątki i niedokończone prace.
• Datę kolejnego przeglądu lub zdarzenie wyzwalające.

Utrzymuj zastosowanie niezależnie od statusu realizacji. „Ma zastosowanie, częściowo wdrożone” to uczciwy i użyteczny zapis. „Nie ma zastosowania, bo nie kupiliśmy narzędzia” nie jest uzasadnieniem zastosowania.

Wyłączenie powinno opisywać fakty dotyczące zakresu, które czynią zabezpieczenie zbędnym, i pozostawać spójne z oceną ryzyka. Stwierdzenie „nie rozwijamy oprogramowania” wymaga weryfikacji, jeżeli Twój portal klienta tworzy wykonawca. Outsourcing zmienia ścieżkę wdrożenia i dowodów; nie usuwa automatycznie ryzyka.

W przypadku rozproszonych wdrożeń zapisz podział. Zabezpieczenie ochrony fizycznej może zależeć od obiektów hostingowych prowadzonych przez dostawcę, kontroli wejścia do biura zarządzanej przez firmę i sposobu postępowania pracowników z urządzeniami. Jeden właściciel może odpowiadać za łączne twierdzenie, podczas gdy czynności wykonują różne zespoły.

Użyteczny opis wdrożenia jest na tyle konkretny, że da się go przetestować: „Administratorzy produkcji otrzymują imienny, zatwierdzony dostęp przez usługę tożsamości; dostęp awaryjny jest osobno logowany i przeglądany”. Zdanie „dostęp jest bezpiecznie zarządzany” nie pokieruje ani inżyniera, ani osoby weryfikującej.

Testuj twierdzenie, które kryje się za statusem

Polityka opisuje zamierzone zachowanie. Może wykazać projekt i zatwierdzenie, ale sama nie dowodzi działania. Zbuduj łańcuch dowodów od wymagania przez wdrożony mechanizm do zaobserwowanego wyniku.

W przypadku zarządzania dostępem porównaj zatwierdzone reguły z faktycznymi uprawnieniami użytkowników i zapisami odejść. W stosownych przypadkach uwzględnij tożsamości uprzywilejowane, konta nieosobowe i aplikacje spoza centralnego zarządzania tożsamością. Zapisz populację, próbkę i wyjątki, zamiast przedstawiać pojedynczy wygodny zrzut ekranu.

W przypadku kopii zapasowych sprawdź konfigurację i wynik przywracania. Udane zadanie kopii zapasowej dowodzi mniej niż udane odtworzenie użytecznych informacji. Sprawdź uprawnienia, zależności i cele odtworzenia; przywrócona baza danych bez kluczy szyfrujących może nie przywrócić usługi.

W przypadku bezpieczeństwa dostawców powiąż ocenę z konkretną usługą i obowiązkami umownymi. Sprawdź, czy dowody obejmują usługę, z której korzystasz, i czy zidentyfikowane obowiązki po stronie klienta zostały wdrożone.

Praktyczny zapis testu powinien zawierać oczekiwany wynik, metodę, zakres, datę dowodu, osobę weryfikującą, wynik i decyzję o dalszych działaniach. Rozróżniaj:

• Projekt: proponowany mechanizm odpowiada na zidentyfikowane ryzyko.
• Wdrożenie: mechanizm istnieje w całym deklarowanym zakresie.
• Działanie: zapisy pokazują, że funkcjonował w odpowiednim okresie.
• Skuteczność: testy wskazują, że osiąga zamierzony rezultat.

Dowodami mogą być konfiguracje, eksporty, zgłoszenia, umowy, wywiady i obserwacje fizyczne. Wybieraj dowody, które potwierdzają faktyczne twierdzenie. Eksport konfiguracji może pokazywać bieżące ustawienia; historyczne zgłoszenia mogą pokazywać, czy wyjątki były obsługiwane w czasie.

Zachowuj pochodzenie: system źródłowy, datę zebrania, objęty okres i ewentualne filtrowanie. Chroń dowody zawierające sekrety lub dane osobowe przez ograniczenia dostępu i odpowiednie zaczernianie. Zbieranie dowodów nie powinno tworzyć nowego, niekontrolowanego repozytorium wrażliwych danych.

Przykład: jak uczynić proces odejścia pracownika sprawdzalnym

Weźmy przykładową firmę SaaS zatrudniającą 45 osób, z jednym biurem, hostingiem w chmurze, centralnie zarządzaną tożsamością i dwiema aplikacjami z kontami lokalnymi. Są to założenia przykładu, a nie wyniki klientów Secani.

Ryzykiem jest utrzymanie dostępu do informacji klientów lub firmy po odejściu pracownika. Właściwe zabezpieczenia obejmują obowiązki przy zmianie zatrudnienia, zarządzanie tożsamością, prawa dostępu i zwrot aktywów. Wdrożenie wspierają też techniczne uwierzytelnianie i ograniczenia dostępu.

Firma zapisuje zabezpieczenie jako mające zastosowanie. HR odpowiada za wyzwalacz odejścia; IT za działania dotyczące tożsamości i urządzeń; każdy właściciel aplikacji za usunięcie kont lokalnych. Przełożony pracownika potwierdza wymagany termin odejścia. Właściciel ds. bezpieczeństwa przegląda proces i nierozwiązane wyjątki.

Wdrożenie obejmuje autoryzowane zgłoszenie odejścia, zaplanowane wyłączenie konta centralnego, unieważnienie sesji tam, gdzie jest to możliwe, usunięcie kont lokalnych, zwrot aktywów i sprawdzenie danych uwierzytelniających, którymi dysponowała dana osoba. W razie potrzeby zmieniane są wspólne sekrety; konta osobiste nie są pochopnie przekazywane następcy.

Pakiet dowodów łączy zatwierdzoną procedurę, zgłoszenie odejścia, zapisy działań na kontach, potwierdzenia z aplikacji lokalnych i zapis dotyczący sprzętu. Każdy element potwierdza określoną część twierdzenia.

Podczas przykładowego przeglądu zespół analizuje cztery odejścia. Konta centralne zostały wyłączone zgodnie z planem, ale jedna aplikacja lokalna zachowała dostęp przez dwa dni. Zabezpieczenie nie zostaje uznane za w pełni skuteczne wyłącznie na podstawie dowodów z centralnego systemu tożsamości.

Właściciel aplikacji usuwa konto, ocenia, czy doszło do dostępu, i zapisuje wynik. Zespół dodaje aplikację do listy kontrolnej odejść i przypisuje krok uzgadniania. Działanie naprawcze otrzymuje właściciela i termin; późniejszy test sprawdza, czy zmieniony proces działa.

Przykład pokazuje, dlaczego dowody muszą podążać za zależnościami. Cztery systemy zgłaszające „zakończone” nie dowodzą zakończenia, jeżeli piątego systemu nigdy nie uwzględniono.

Utrzymuj działanie zabezpieczeń między przeglądami

Zabezpieczenia zmieniają się wraz ze zmianą systemów, dostawców, ludzi i wymagań biznesowych. Oprócz zaplanowanych przeglądów ustal wyzwalacze przeglądów dla istotnych wydań, nowych usług, zmian w biurach, incydentów i zmienionych obowiązków.

Stosuj częstotliwość odpowiednią do zmienności i ryzyka. Wyjątki w dostępie uprzywilejowanym mogą wymagać szybkiego przeglądu, a stabilna polityka może mieć dłuższy cykl uzupełniony wyzwalaczami zmian. To decyzje kierownictwa, a nie uniwersalne częstotliwości Załącznika A.

Śledź niewielką liczbę użytecznych wskaźników: zaległe działania naprawcze, nieobjęte systemy, nierozwiązane wyjątki w dowodach i nieudane testy zabezpieczeń. Oddziel je od liczby dokumentów. Duża biblioteka dowodów może wciąż pozostawiać krytyczne środowisko produkcyjne nieprzetestowane.

Audyt wewnętrzny zapewnia odrębną ocenę SZBI; rutynowe przeglądy dokonywane przez właścicieli zabezpieczeń go nie zastępują. Przegląd zarządzania również wymaga decyzji kierownictwa dotyczących efektów działania, zmian, zasobów i doskonalenia, a nie tylko wypełnionego arkusza zabezpieczeń. Certyfikację przeprowadza niezależna jednostka certyfikująca, a nie ISO ani dostawca oprogramowania.

Typowe błędy to przypisywanie wszystkiego zespołowi bezpieczeństwa, kopiowanie wyłączeń innej organizacji, poleganie na certyfikatach dostawców bez sprawdzenia zakresu i zamykanie ustaleń po zmianie polityki, a nie po przetestowaniu zmienionego procesu.

Zacznij od jednej usługi i kompletnego łańcucha dowodów

Wybierz reprezentatywną usługę i prześledź jej systemy, dostawców, informacje i właścicieli operacyjnych. Wybierz niewielki zestaw powiązanych zabezpieczeń, takich jak dostęp, zarządzanie zmianami, logowanie i odtwarzanie, i uczyń każde wdrożenie sprawdzalnym, zanim rozbudujesz rejestr.

Secani wspiera ten sposób pracy przez modelowanie systemów i zależności, łączenie dowodów z wymaganiami, zabezpieczeniami i decyzjami oraz śledzenie luk jako zadań. Przypisz właściciela i osobę weryfikującą, dołącz istniejące zapisy oraz zachowaj komentarze i zatwierdzenia z przeglądu. Traktuj mapowania i podsumowania przygotowane z pomocą AI jako wersje robocze: weryfikuj źródła i utrzymuj wyraźne zatwierdzenie przez człowieka. Ustrukturyzowane przygotowanie do audytu wyjaśnia leżący u podstaw model dowodów.

Pierwszym rezultatem powinien być spójny łańcuch od ryzyka do zabezpieczenia, wdrożenia, dowodu, wyniku testu i decyzji o dalszych działaniach. Ten łańcuch można następnie powtórzyć w pozostałym zakresie bez wymyślania nowego procesu dla każdego odniesienia z Załącznika A.

Pytania praktyczne

Czy jeden zapis może potwierdzać kilka zabezpieczeń?

Tak. Zgłoszenie odejścia może potwierdzać kilka powiązanych zabezpieczeń. Wyjaśnij, które twierdzenie potwierdza w przypadku każdego z nich; współdzielenie dowodów nie czyni zabezpieczeń identycznymi.

Czy każde zabezpieczenie musi mieć własną politykę?

Nie. Porządkuj polityki i procedury wokół zrozumiałych procesów operacyjnych. Jeden dokument może dotyczyć kilku zabezpieczeń, o ile obowiązki i wdrożenie pozostają jasne.

Skąd powinna pochodzić wiążąca lista zabezpieczeń?

Brzmienie Załącznika A bierz z licencjonowanej normy ISO/IEC 27001, a wytyczne wdrożeniowe z ISO/IEC 27002. Podsumowania operacyjne są przydatnymi pomocami nawigacyjnymi, a nie substytutem norm.