Czym jest Deklaracja Stosowalności (SoA)?

Przegląd

Deklaracja Stosowalności (SoA) to obowiązkowy dokument ISO 27001, który zawiera listę wszystkich 93 kontroli z Załącznika A i wyjaśnia, czy każda kontrola jest włączona do twojego ISMS, czy wykluczona. W przypadku kontrolek włączonych opisuje, w jaki sposób są wdrażane. W przypadku kontrolek wykluczonych podaje uzasadnienie wykluczenia.

Co to oznacza w praktyce

SoA to twój plan wyboru kontrolek – łączy wyniki oceny ryzyka ze specyficznymi kontrolami bezpieczeństwa, które zdecydowałeś się wdrożyć. Audytorzy używają go jako mapy drogowej do weryfikacji, czy twój ISMS odpowiednio adresuje zidentyfikowane ryzyka.

Dlaczego SoA jest ważna dla ISO 27001

Obowiązkowy wymóg

Klauzula 6.1.3(d) ISO 27001 wyraźnie wymaga utrzymywania "Deklaracji Stosowalności zawierającej niezbędne kontrole oraz uzasadnienie włączeń i wyłączeń." Nie można uzyskać certyfikacji bez kompletnej i dokładnej SoA.

Demonstruje podejście oparte na ryzyku

SoA dowodzi, że nie wdrażasz kontrolek przypadkowo ani nie stosujesz szablonów bezrefleksyjnie. Pokazuje, jak każda decyzja dotycząca kontroli wynika z oceny ryzyka.

Mapa drogowa dla audytu

Audytorzy używają twojej SoA do planowania, co będą weryfikować podczas audytów certyfikacyjnych. Włączone kontrole wymagają dowodów wdrożenia i skuteczności. Wyłączenia muszą być uzasadnione na podstawie oceny ryzyka lub kontekstu biznesowego.

Zarządzanie zmianami

W miarę ewolucji ryzyk, twoja SoA powinna być aktualizowana, aby odzwierciedlać nowe wymagania dotyczące kontrolek lub umożliwiać usunięcie wcześniej wykluczonych kontrolek, jeśli ryzyka zmniejszą się.

Co musi zawierać SoA

Pełna lista kontrolek

Wszystkie 93 kontrole z Załącznika A z ISO 27001:2022 muszą pojawić się w twojej SoA, zorganizowane według tematów:

• Kontrole organizacyjne: A.5.1 do A.5.37 (37 kontrolek)
• Kontrole dotyczące osób: A.6.1 do A.6.8 (8 kontrolek)
• Kontrole fizyczne: A.7.1 do A.7.14 (14 kontrolek)
• Kontrole technologiczne: A.8.1 do A.8.34 (34 kontrolek)

Status włączenia/wykluczenia

Dla każdej kontroli jasno określ, czy jest włączona do twojego ISMS, czy wykluczona. Unikaj niejednoznacznych statusów, takich jak "częściowo stosowalne" – kontrole są albo włączone, albo wykluczone.

Opis wdrożenia (dla włączonych kontrolek)

Krótko opisz, w jaki sposób wdrażasz każdą włączoną kontrolę. Uwzględnij:

• Konkretne polityki, procedury lub technologie używane
• Kto jest odpowiedzialny za kontrolę
• Gdzie można znaleźć dowody wdrożenia
• W jaki sposób kontrola adresuje zidentyfikowane ryzyka

Uzasadnienie wykluczenia (dla wykluczonych kontrolek)

Wyjaśnij, dlaczego wykluczone kontrole nie są częścią twojego ISMS. Prawidłowe uzasadnienia:

• Oparte na ryzyku: "Żadne ryzyka w naszej ocenie nie wymagają tej kontroli"
• Oparte na kontekście: "Niewłaściwe – działamy wyłącznie w chmurze, bez fizycznej infrastruktury"
• Prawne/regulacyjne: "Zabronione przez przepisy dotyczące lokalizacji danych w naszej jurysdykcji"

Struktura i format SoA

Format tabelaryczny (najczęściej stosowany)

Tabela z kolumnami dla:

• Numer kontroli (np. A.5.1)
• Nazwa kontroli (np. "Polityki bezpieczeństwa informacji")
• Status (Włączona / Wykluczona)
• Opis wdrożenia lub uzasadnienie wykluczenia
• Odniesienie do ryzyka (powiązanie z rejestrem ryzyka)
• Lokalizacja dowodów (opcjonalne, ale pomocne)

Format narracyjny

Niektóre organizacje preferują dokument narracyjny opisujący wdrożenie kontrolek pogrupowanych według tematów. Mniej powszechny, ale akceptowalny, jeśli jasno adresuje wszystkie 93 kontrole.

Format oparty na narzędziach

Platformy GRC i narzędzia ISMS często generują SoA automatycznie na podstawie wyboru kontrolek i powiązań z ocenami ryzyka. Nadal wymagają ręcznej walidacji pod kątem dokładności.

Tworzenie SoA

Krok 1: Przeprowadź ocenę ryzyka

Twoja SoA jest bezpośrednim wynikiem oceny ryzyka. Zidentyfikuj wszystkie ryzyka wymagające leczenia przed określeniem, które kontrole wdrożyć.

Krok 2: Mapuj kontrole do ryzyk

Dla każdego ryzyka wymagającego leczenia zidentyfikuj, które kontrole z Załącznika A zmniejszyłyby je do akceptowalnego poziomu. Jedno ryzyko może wymagać wielu kontrolek; jedna kontrolka może adresować wiele ryzyk.

Krok 3: Określ włączenie/wykluczenie

Kontrole adresujące zidentyfikowane ryzyka są włączane. Kontrole, które nie adresują żadnego z twoich ryzyk, mogą być wykluczone (z uzasadnieniem).

Krok 4: Opisz wdrożenie

Dla włączonych kontrolek udokumentuj, w jaki sposób je wdrażasz. Bądź wystarczająco szczegółowy, aby audytorzy zrozumieli twoje podejście, nie powielając całych procedur.

Krok 5: Uzasadnij wykluczenia

Dla wykluczonych kontrolek wyjaśnij, dlaczego na podstawie oceny ryzyka lub kontekstu organizacyjnego. Odnoś się do konkretnych ustaleń z rejestru ryzyka, jeśli to możliwe.

Krok 6: Przegląd i zatwierdzenie

Zarząd powinien formalnie przejrzeć i zatwierdzić SoA, potwierdzając decyzje dotyczące wyboru kontrolek i wszelkie ryzyka rezydualne.

Typowe błędy w SoA

Wykluczanie zbyt wielu kontrolek

Organizacje czasami wykluczają kontrole, aby zmniejszyć wysiłek wdrożeniowy. Audytorzy dokładnie analizują wykluczenia – jeśli twoja ocena ryzyka jest dokładna, większość kontrolek powinna być włączona.

Generyczne opisy wdrożenia

Kopiowanie opisów kontrolek z ISO 27002 bez opisywania rzeczywistego wdrożenia. Audytorzy muszą zrozumieć, co robisz, a nie to, co mówi norma.

Brak powiązań z ryzykiem

Niezłączenie kontrolek z konkretnymi ryzykami w ocenie ryzyka. To przerywa możliwość śledzenia i sugeruje, że kontrole zostały wybrane arbitralnie.

Niekompletne pokrycie

Zapominanie o zaadresowaniu wszystkich 93 kontrolek. Nawet jeśli kontrola wydaje się oczywiście nieodpowiednia, musi pojawić się w SoA z uzasadnieniem wykluczenia.

Brak cyklu przeglądu

Tworzenie SoA raz podczas początkowego wdrożenia i nigdy jej nie aktualizowanie pomimo zmian w organizacji lub nowych ryzyk.

SoA a inne dokumenty ISO 27001

SoA vs. Plan Postępowania z Ryzykiem

Plan Postępowania z Ryzykiem szczegółowo opisuje, w jaki sposób wdrożysz wybrane kontrole (harmonogramy, odpowiedzialności, zasoby). SoA deklaruje, które kontrole są wdrożone i dlaczego. Te dwa dokumenty się uzupełniają.

SoA vs. Dowody Kontroli

SoA opisuje, jakie kontrole wdrażasz. Dowody potwierdzają, że kontrole rzeczywiście działają skutecznie. Podczas audytów audytorzy próbkują kontrole z twojej SoA i żądają odpowiednich dowodów.

SoA vs. Polityki i Procedury

Polityki i procedury dostarczają szczegółowych instrukcji dotyczących wdrażania kontrolek. SoA podsumowuje na wysokim poziomie, które kontrole istnieją i jak działają.

Jak audytorzy wykorzystują SoA

Audyt Etapu 1 (przegląd dokumentacji)

Audytorzy weryfikują, czy twoja SoA jest kompletna (zaadresowano wszystkie 93 kontrole), logicznie uporządkowana i zgodna z oceną ryzyka. Sprawdzają, czy uzasadnienia wykluczeń mają sens.

Audyt Etapu 2 (weryfikacja wdrożenia)

Audytorzy próbkują kontrole z twojej SoA i żądają dowodów, że są wdrożone zgodnie z opisem. Przetestują kontrole we wszystkich czterech obszarach tematycznych i obszarach organizacyjnych w zakresie.

Przyczyny niezgodności

Typowe powody, dla których audytorzy zgłaszają niezgodności związane z SoA:

• Kontrole oznaczone jako "włączone", ale faktycznie niewdrożone
• Wykluczenia bez ważnego uzasadnienia
• SoA nie odzwierciedla rzeczywistych wyników oceny ryzyka
• Brakujące kontrole (mniej niż 93 wymienione)
• Opisy wdrożenia zbyt ogólne, aby je zweryfikować

Utrzymywanie SoA na przestrzeni czasu

Roczne aktualizacje oceny ryzyka

Podczas planowanych ponownych ocen ryzyka przejrzyj SoA, aby ustalić, czy wybór kontrolek pozostaje odpowiedni. Nowe ryzyka mogą wymagać wcześniej wykluczonych kontrolek.

Zmiany organizacyjne

Zaktualizuj SoA, gdy:

• Wdrażana jest nowa technologia (może wymagać nowych kontrolek technicznych)
• Zmienia się model biznesowy (np. przejście do chmury zmienia kontrole fizyczne)
• Ekspansja geograficzna wprowadza nowe wymagania regulacyjne
• Fuzje lub przejęcia zmieniają profil ryzyka

Przeglądy wywołane incydentami

Po znaczących incydentach bezpieczeństwa przejrzyj, czy istniejące kontrole były skuteczne, czy należy wdrożyć dodatkowe kontrole (wcześniej wykluczone).

Audyty nadzoru

Audytorzy sprawdzą podczas rocznych audytów nadzoru, czy SoA była utrzymywana na bieżąco. Dowody regularnego przeglądu pokazują, że twój ISMS jest aktywny, a nie porzucony po certyfikacji.

SoA i dostosowywanie kontrolek

Norma pozwala na dostosowanie

ISO 27001 pozwala organizacjom na różne wdrażanie kontrolek w zależności od wielkości, złożoności i ryzyka. Twoja SoA powinna odzwierciedlać twoje specyficzne wdrożenie, a nie generyczny szablon.

Dodatkowe kontrole poza Załącznikiem A

Jeśli ocena ryzyka identyfikuje ryzyka, które nie są odpowiednio zaadresowane przez 93 standardowe kontrole, możesz wdrożyć dodatkowe kontrole. Wymień je w swojej SoA lub w dokumencie uzupełniającym.

Liczy się proporcjonalność

Wdrożenie kontroli "A.6.3 Szkolenie w zakresie świadomości bezpieczeństwa informacji" przez startup z 10 osobami będzie się różnić od wdrożenia w przedsiębiorstwie z 10 000 pracownikami. Oba mogą być zgodne, jeśli są odpowiednie do kontekstu i skuteczne w redukcji ryzyka.

Powiązane pojęcia

• Kontrole Załącznika A - 93 kontrole bezpieczeństwa, które musi adresować twoja SoA
• Ocena Ryzyka - Proces, który napędza wybór kontrolek w twojej SoA
• Postępowanie z Ryzykiem - Wdrażanie kontrolek zidentyfikowanych w twojej SoA
• Kontrola - Środki bezpieczeństwa, które wybierasz w swojej SoA
• Jak rozpocząć wdrażanie ISO 27001 z wykorzystaniem AI

Uzyskanie pomocy

Przyspiesz tworzenie SoA z ISMS Copilot. Generuj dostosowane opisy wdrożenia, waliduj swoje uzasadnienia względem wyników oceny ryzyka i upewnij się, że wszystkie 93 kontrole są odpowiednio zaadresowane.