Deklaracja Stosowania (Statement of Applicability – SoA) to jeden z kluczowych dokumentów wymaganych przez ISO/IEC 27001. Choć formalnie jest to „tylko” załącznik do systemu zarządzania bezpieczeństwem informacji (ISMS), w praktyce stanowi logiczne połączenie pomiędzy analizą ryzyka, decyzjami zarządczymi oraz wdrożonymi zabezpieczeniami.

„Kontrolka” to potoczne określenie używane jako synonim normatywnego terminu „zabezpieczenie”

Dobrze przygotowana SoA	Źle przygotowana SoA
pokazuje dojrzałość organizacji	jest kopią Załącznika A
ułatwia audyt	zawiera lakoniczne uzasadnienia
porządkuje architekturę zabezpieczeń	nie wykazuje związku z analizą ryzyka
minimalizuje ryzyko niezgodności	jest aktualizowana „pod audyt”

I. Czym jest SoA zgodnie z normą?

Zgodnie z pkt 6.1.3 d) ISO/IEC 27001 organizacja musi:

sporządzić Deklarację Stosowania zawierającą:

• niezbędne zabezpieczenia,
• uzasadnienie ich włączenia,
• informacje o wdrożeniu,
• uzasadnienie wyłączenia zabezpieczeń z Załącznika A.

Załącznik A (w wersji 2022/2023 to 93 zabezpieczenia podzielone na 4 kategorie) pochodzi z ISO/IEC 27002 i stanowi katalog referencyjny.

II. Co powinna zawierać poprawna SoA?

Minimalny zestaw elementów dla SoA to:

Nazwa kolumny	Wartości
Identyfikacja zabezpieczenia	Numer i nazwa zabezpieczenia
Decyzja/Status	Wdrożona W trakcie wdrożenia Wyłączona
Uzasadnienie włączenia	Powiązanie z ryzykiem (ID ryzyka z rejestru) Wymaganie prawne / kontraktowe / klienta / wewnętrzne
Właściciel ryzyka	Stanowisko (o ile jest ono unikalne) / osoba
Uzasadnienie wyłączenia	Brak zastosowania (np. brak przetwarzania danych w chmurze) Brak istotności ryzyka
Odniesienie do dokumentów	Polityka / Procedura / Instrukcja / Rejestr

III. Czego unikać (najczęstsze błędy)

Podczas audytów często widzę następujące błędy:

• kopiowanie opisów z normy ISO/IEC 27002 bez refleksji
• Uzasadnień typu: „Wymaganie normy”
• Braku powiązania z analizą ryzyka
• Braku identyfikowalności dokumentów – brak samych dokumentów lub brak możliwości zastosowania wymagania. Czyli opisane jest stosowanie zabezpieczenia bez jego wdrożenia – działania w chmurze bez wdrożenia rozwiązań chmurowych
• Uzasadnień „nie dotyczy”, bez wyjaśnienia dlaczego

IV. Jak SoA powinna być powiązana z analizą ryzyka

Logika powinna wyglądać tak:

Kontekst → Ryzyko → Decyzja → Zabezpieczenie → SoA → Monitorowanie

Jeśli stosowanie zabezpieczenia nie wynika z ryzyka, z wymagań prawnych, czy ze zobowiązań umownych to jego obecność w SoA powinna być uzasadniona strategicznie.

Uzasadnienie zastosowania danego zabezpieczenia powinno wynikać przede wszystkim z jej wpływu na ograniczenie zidentyfikowanego ryzyka w obszarze bezpieczeństwa informacji. W praktyce wystarczające jest odwołanie się do wyników przeprowadzonej oceny ryzyka oraz do planu postępowania z ryzykiem, z jednoczesnym wskazaniem, w jaki sposób wdrożenie danej kontroli wpłynie na poziom ryzyka (np. jego redukcję, przeniesienie lub akceptację). Kluczowe jest wykazanie oczekiwanej zmiany poziomu ryzyka jako bezpośredniego efektu implementacji określonych zabezpieczeń.

Uzasadnienie wyłączenia określonego zabezpieczenia wskazanego w Załączniku A normy ISO/IEC 27001:2023 może opierać się na kilku przesłankach. W szczególności może ono wynikać z faktu, że:

• dane zabezpieczenie nie jest wymagane do realizacji przyjętych sposobów postępowania z ryzykiem bezpieczeństwa informacji, określonych na podstawie przeprowadzonej oceny ryzyka;
• zabezpieczenie nie znajduje zastosowania w kontekście organizacji, ponieważ dotyczy obszaru pozostającego poza zakresem ustanowionego systemu zarządzania bezpieczeństwem informacji (np. wymagania odnoszące się do outsourcingu rozwoju nie mają zastosowania, jeśli całość prac rozwojowych realizowana jest wyłącznie wewnętrznie);
• zabezpieczenie może zostać uznane za zbędne z uwagi na wdrożenie innego, niestandardowego zabezpieczenia (spoza listy 93 zabezpieczeń określonych w załączniku A), które w sposób równoważny lub skuteczniejszy eliminuje dane ryzyko (np. gdy przyjęte rozwiązania organizacyjne lub techniczne uniemożliwiają wystąpienie sytuacji, do której odnosi się dana kontrolka).

Jeżeli plan postępowania z ryzykiem wskazuje konieczność podjęcia konkretnych działań, należy je jasno zaplanować, przypisując odpowiedzialności i terminy realizacji (zob. również pkt 6.2 Cele bezpieczeństwa informacji i planowanie ich osiągnięcia). Taki plan można przedstawić w formie zestawienia działań.

Praktycznym sposobem opracowania planu postępowania z ryzykiem bezpieczeństwa informacji jest tabela uporządkowana według ryzyk zidentyfikowanych podczas oceny ryzyka, obejmująca wszystkie określone środki kontroli. W tabeli można wyróżnić kolumny wskazujące osoby odpowiedzialne za wdrożenie środków kontrolnych, datę ich realizacji, opis sposobu funkcjonowania środków (lub procesów) oraz kolumnę prezentującą docelowy status wdrożenia.

Jako przykład części procesu zarządzania ryzykiem można rozważyć scenariusz kradzieży telefonu komórkowego. Konsekwencjami takiego zdarzenia mogą być utrata dostępności urządzenia oraz potencjalne niepożądane ujawnienie informacji. Jeśli ocena ryzyka wskaże, że jego poziom jest nieakceptowalny, organizacja powinna podjąć działania mające na celu zmniejszenie prawdopodobieństwa wystąpienia zdarzenia lub ograniczenie jego skutków.

Aby wpłynąć na prawdopodobieństwo utraty lub kradzieży telefonu komórkowego, organizacja może przyjąć jako środek kontroli zobowiązanie pracowników do odpowiedniego dbania o urządzenia mobilne oraz okresowego sprawdzania, czy nie zostały one zagubione, zapisane w polityce dotyczącej urządzeń mobilnych.

W celu ograniczenia skutków utraty lub kradzieży telefonu organizacja może wdrożyć następujące środki kontroli:

• proces zarządzania incydentami, umożliwiający zgłaszanie utraty urządzeń przez użytkowników;
• rozwiązanie do zarządzania urządzeniami mobilnymi (MDM), pozwalające na zdalne usunięcie zawartości telefonu w przypadku jego utraty;
• plan tworzenia kopii zapasowych urządzeń mobilnych, zapewniający odzyskanie danych z utraconego telefonu.

Przy opracowywaniu Deklaracji Stosowania (zgodnie z 27001, punkt 6.1.3 d)) organizacja może uwzględnić wybrane zabezpieczenia, takie jak polityka dotycząca urządzeń mobilnych oraz MDM, uzasadniając ich zastosowanie poprzez wpływ na zmniejszenie prawdopodobieństwa i konsekwencji utraty lub kradzieży telefonu, co przekłada się na redukcję ryzyka resztkowego.

Analizując zabezpieczenia w kontekście normy PN-EN ISO/IEC 27001:2023, Załącznik A, można stwierdzić, że polityka dotycząca urządzeń mobilnych odpowiada wymaganiom punktu A.8.1 Urządzenia końcowe. Natomiast MDM nie jest bezpośrednio wymienionym środkiem zabezpieczeń i powinien być traktowany jako zabezpieczenie dodatkowe, dostosowane do potrzeb organizacji. Jeśli MDM i inne zabezpieczenia zostaną uznane za istotne w ramach planu postępowania z ryzykiem bezpieczeństwa informacji, powinny zostać ujęte w Deklaracji Stosowania.

Jeżeli organizacja chce dodatkowo ograniczyć ryzyko, może odwołać się do normy PN-EN ISO/IEC 27001:2023, A.5.15 (Kontrola dostępu), która wskazuje na konieczność nadzoru nad dostępem do urządzeń końcowych (w tym mobilnych). W tym celu polityka dotycząca urządzeń mobilnych może zostać zmodyfikowana tak, aby wymagać stosowania kodów PIN na wszystkich telefonach komórkowych. Taki środek powinien stanowić dodatkowe zabezpieczenie, wpływające na ograniczenie skutków utraty lub kradzieży urządzeń.

Przy opracowywaniu planu postępowania z ryzykiem bezpieczeństwa informacji (6.1.3 e)) organizacja powinna uwzględnić działania związane z wdrożeniem polityki dotyczącej urządzeń mobilnych oraz systemu MDM, przypisując jednocześnie odpowiedzialności i ramy czasowe realizacji tych działań.

Po przygotowaniu planu, w ramach procesu zarządzania ryzykiem organizacja powinna uzyskać zgodę właścicieli ryzyka (6.1.3 f)). Zgoda ta powinna opierać się na ustalonych kryteriach akceptacji ryzyka lub, w przypadku odstępstw, na uzasadnionych ustępstwach. Organizacja powinna rejestrować zarówno akceptację ryzyka resztkowego przez właścicieli ryzyka, jak i zatwierdzenie planu postępowania przez kierownictwo.

Przykładowo, zgodę właściciela ryzyka można udokumentować poprzez rozszerzenie planu postępowania z ryzykiem, opisanego w wytycznych pkt 6.1.3 e), o dodatkowe kolumny wskazujące skuteczność wdrożonych kontroli, poziom ryzyka resztkowego oraz wyraźne potwierdzenie akceptacji przez właściciela ryzyka.